Risk Assessment
IEC 62443-3-2:2020 is the security risk assessment and system design part. It starts with a defined system under consideration, partitions that system into zones and conduits, assesses risk for each zone and conduit, establishes SL-T, and documents the security requirements that follow.
System under consideration
The system under consideration, or SUC, is the assessment boundary. It should identify the IACS function, assets, users, interfaces, communication paths, operating assumptions, and external connections that the risk assessment will treat as part of the system.
This boundary is the main difference between a system risk assessment and a loose network review. A site name, product name, or architecture drawing is not enough unless it defines which assets and interfaces are inside the SUC and which assumptions sit outside it.
Zones and conduits carry the risk
IEC 62443-3-2 uses zones and conduits to make the risk assessment practical. Zones group assets that should share similar security requirements. Conduits describe communication paths between zones that need their own controls and assumptions.
Zone
A zone is useful only if its assets can sensibly share security requirements, risk assumptions, and responsibility boundaries.
Conduit
A conduit is not just a cable or network segment. It is the communication path that carries risk between zones.
Risk is assessed for each relevant zone and conduit. That keeps a safety controller, engineering workstation, historian, remote-access path, and enterprise connection from being treated as one flat trust area.
SL-T is a target from risk
SL-T is the target security level established for a zone or conduit after risk assessment. It is not a generic rating that can be copied from a product certificate. It depends on the SUC, the threats being considered, the consequences of compromise, and the risk treatment chosen for the zone or conduit.
SL-T
The target level set by the risk assessment for a zone, conduit, or control system boundary.
SL-C
The capability level of a control system or component. It can support the design but does not decide the target.
SL-A
The achieved level in the implemented system. It depends on design, configuration, procedures, and validation.
Documented security requirements
IEC 62443-3-2 ends in documented security requirements. Those requirements should connect the SUC, zone and conduit model, risk rationale, selected SL-T, assumptions, and responsibilities. IEC 62443-3-3 can then be used to express detailed control system requirements for the relevant system boundary.
- SUC boundary and assets in scope;
- zone and conduit model with interfaces and trust boundaries;
- risk rationale for each zone and conduit;
- SL-T selected for each relevant zone and conduit;
- security requirements and assumptions that flow from that target;
- responsibilities for asset owner, integrator, maintenance provider, and product supplier evidence.
For the shorter concept overview, see Zones, conduits, and security levels. This page is the deeper risk-assessment view.
Product claims remain separate
A 3-2 risk assessment does not prove that a product complies with IEC 62443-4-2, that a supplier follows IEC 62443-4-1, or that a system meets IEC 62443-3-3. It can define what the system needs and what product evidence should support the design. The product claim still needs its own component type, product version, interfaces, capability level, supplier lifecycle evidence, and certificate scope if a certificate is used.
Useful product evidence
Product documentation, secure development evidence, component capability claims, vulnerability status, and hardening guidance are inputs to the system file. They are not the system risk assessment result.