You cannot secure an industrial control system you have not assessed: risk assessment is where ICS security starts and where it keeps coming back. IEC 62443-3-2 ("Security risk assessment for system design") standardizes the methodology: identify the system and its zones, identify threats and vulnerabilities, evaluate the risk of each threat scenario, and decide the treatment. The output — a documented, repeatable risk picture — drives the security requirements for every later decision: network design, product selection, and procedures.
Why ICS Risk Assessment Differs from IT
Enterprise risk frameworks focus on confidentiality first; ICS risk assessment is dominated by different priorities:
- Safety and availability lead — a security event that triggers a safe shutdown may be a "success" in IT terms (the attack failed) but a production catastrophe in OT terms. The risk model must weight availability and physical consequences (safety, environment) explicitly.
- The system-of-interest boundary — the assessment covers the ICS (controllers, historians, HMIs, networks, field devices) plus its interfaces: to the IT network, to vendors, to remote access, to the cloud.
- Legacy realities — the assets under assessment include 20-year-old controllers that cannot run modern security controls; the assessment must treat "cannot patch" as a finding with compensating controls, not an unsolvable problem.
- Physical vectors — USB sticks, laptops, and contractor devices are not abstractions in a plant; they are the most common attack path into OT.
The IEC 62443-3-2 Process
- Identify the system under consideration (SuC) — its boundary, assets, and interfaces; the asset inventory (hardware, software, network, data) is the foundation and is itself usually the first real finding (most plants cannot produce a complete inventory).
- Identify threats and threat scenarios — using the standard's threat model (human, malicious and accidental; environmental; system/software faults), enumerate realistic scenarios for the plant: which attacker, which vector, which consequence.
- Identify vulnerabilities — technical (unpatched, default passwords, open ports, weak protocols) and organizational (no access control, untrained staff, unmanaged remote access), mapped to assets and scenarios.
- Assess risk — for each scenario: likelihood × consequence, scored with the plant's own criteria (safety, environment, production, regulatory). The scoring matrix must be agreed with management before the assessment — a risk nobody agreed on is a number nobody acts on.
- Risk treatment decisions — accept (documented, with owner), reduce (mitigations), transfer (insurance, contracts), or avoid (remove the function). Reductions become the security requirements and the project backlog.
- Re-assess periodically and after changes — the risk picture decays with every new connection, new vendor, and new threat; annual review is the minimum, with event-triggered reviews.
Scoring That Works on the Plant Floor
Elaborate scoring scales fail; simple, consistent ones work. A practical scheme: consequence classes (1: nuisance; 2: production impact < 1 day; 3: production impact > 1 day or safety/environmental reportable; 4: major safety/environmental event), likelihood classes (1: improbable; 2: possible; 3: likely), and a 3×4 matrix with clear treatment bands. The critical discipline is evidence: every score is traceable to a fact (asset version, exposure, existing control) — a risk assessment built on guesses trains nobody and convinces nobody.
Assessment Outputs
The deliverable package: the asset inventory, the network diagram (as-built, which is itself usually a finding), the threat scenario register, the risk register with scores and owners, and the security requirements specification (the IEC 62443-3-2 document that feeds system design — zones, conduits, and the controls per zone). These documents are living: they are reviewed when the plant changes, and they are the evidence that security investment is based on risk, not fear.
Common Assessment Mistakes
- Assessing only the IT-facing boundary — the OT network's internal weaknesses (flat network, shared credentials) dominate real risk.
- Assessment as a report, not a process — the deliverable gets filed; the risk register must drive the work plan.
- Ignoring the human and physical vectors — USB, contractors, and remote access are where OT attacks actually start.
- One-size scoring — copying a consultant's matrix without the plant's own consequence criteria.
- Perfect assessment of an incomplete inventory — fix the inventory first; it is 30% of the value and the prerequisite for everything else.
Summary
IEC 62443-3-2 gives the ICS risk assessment a standard shape: define the system, enumerate threat scenarios and vulnerabilities, score with agreed criteria, and decide treatments with owners. Run it on evidence, weight availability and safety consequences, include the physical and human vectors, and keep it alive with the work plan. The risk assessment is the map; without it, security spending is navigation by guess.