IEC 62443-3-2 (security risk assessment for system design), explained

IEC 62443-3-2:2020, "Security for industrial automation and control systems – Part 3-2: Security risk assessment for system design," is the part of the ISA/IEC 62443 series that tells an asset owner how to actually run the risk assessment that every other system- and component-level part of the series assumes already happened. Per the IEC Webstore's own listing, the standard "establishes requirements for: defining a system under consideration (SUC) for an industrial automation and control system (IACS); partitioning the SUC into zones and conduits; assessing risk for each zone and conduit; establishing the target security level (SL-T) for each zone and conduit; and documenting the security requirements." Edition 1.0 was published 24 June 2020 by IEC Technical Committee 65, working with ISA99, and carries a stability date of 2027; a CENELEC national (EN) adoption followed on 27 August 2020.

The seven Zone and Conduit Requirements (ZCR 1-7)

A standards-catalogue preview of the document's own clause structure lists seven Zone and Conduit Requirements, run roughly in sequence:

#	Zone and Conduit Requirement (ZCR)
ZCR 1	Identify the system under consideration (SUC)
ZCR 2	Perform an initial cyber security risk assessment
ZCR 3	Partition the SUC into zones and conduits
ZCR 4	Risk comparison
ZCR 5	Perform a detailed cyber security risk assessment
ZCR 6	Document cyber security requirements, assumptions and constraints
ZCR 7	Asset owner approval

The structure is deliberately iterative, not a one-pass checklist: ZCR 2's initial assessment is coarse enough to scope where the detailed work in ZCR 5 actually needs to go, and ZCR 4's risk comparison exists specifically to check that the zone/conduit partition chosen in ZCR 3 produced a sensible risk picture before committing to the detailed assessment. ZCR 7 is notable for naming a specific accountable party: the standard assigns final approval to the asset owner, not to whichever integrator or consultant ran the analysis.

Zones, conduits and SL-T: the vocabulary everything downstream depends on

The standard's own definitions, confirmed through a catalogue preview of its text, are the foundation the rest of the series builds on:

• Zone — "a grouping of logical or physical assets based upon risk or other criteria, such as criticality of assets, operational function, physical or logical location, required access... or responsible organization." Every asset in the SUC belongs to at least one zone; there is no "unzoned" leftover category.
• Conduit — "a logical grouping of communication channels... connecting two or more zones" that share a common set of security requirements. In practice, a conduit is where network segmentation controls (firewalls, data diodes, VLAN boundaries) actually get specified.
• SL-T (target security level) — the security level the asset owner decides, through this standard's own risk-assessment process, that a given zone or conduit needs to reach. It is explicitly one of three distinct "security level" concepts in the series: SL-T (target, set here in 3-2), SL-C (capability — what a system or component can natively provide, set in IEC 62443-3-3 for systems and 62443-4-2 for components), and SL-A (achieved — what gets verified once something is actually built and installed).

From risk assessment to a design checklist: 3-1, 3-2 and 3-3

All three "3-x" parts of the series sit in its System category, but they do different jobs. IEC 62443-3-1 is a 2009 Technical Report (not a full, periodically-maintained standard) surveying security technologies applicable to an IACS. IEC 62443-3-2, covered in this guide, is the risk-assessment process: its ZCR 1-7 output — a documented SUC boundary, a zone/conduit partition, and an SL-T per zone and conduit — is exactly the input the next part needs. IEC 62443-3-3 then supplies the detailed technical system requirements (SRs), organized under seven foundational requirements, that a system design is checked against to see whether it can actually deliver the SL-T values that 3-2's risk assessment called for. An asset owner or integrator cannot meaningfully start a 62443-3-3 gap assessment without first having run 62443-3-2 — without an SL-T per zone, there is no target to check the design against.

The standard is published as IEC 62443-3-2 by IEC Technical Committee 65, and in the US as the identically-titled ANSI/ISA-62443-3-2-2020 through ISA's own standards store; European standards resellers also list a CENELEC national adoption, EN IEC 62443-3-2:2020.

A workable starting point

1. Run ZCR 1 before buying any tooling. Define the SUC boundary explicitly — a network diagram plus an asset list — rather than defaulting to "the whole plant" as the scope; an unbounded SUC makes every later step harder than it needs to be.
2. Let ZCR 2's initial assessment do triage. Its job is to flag which parts of the SUC need the detailed ZCR 5 treatment first, not to replace it — spending detailed-assessment effort evenly across a plant wastes it on the lowest-risk zones.
3. Don't skip ZCR 4's risk comparison. It is the standard's built-in sanity check that the zone/conduit partition chosen in ZCR 3 actually produced a risk picture worth acting on before the detailed work in ZCR 5 begins.
4. Carry SL-T values forward explicitly into any 62443-3-3 or component-level 62443-4-2 gap assessment — a target security level that only exists in a spreadsheet nobody else has seen doesn't constrain a design review.
5. Get ZCR 7 sign-off on paper, from the named asset owner, not implied by a project closing out — it is the standard's own accountability checkpoint.

SoftWSP's passive OT network assessment produces the asset inventory, network-boundary and criticality evidence that ZCR 1-3 need as a starting point, without requiring any agent install on live control-system equipment: see OT Snapshot.

This guide summarises standards-catalogue descriptions of IEC 62443-3-2:2020; it is not a substitute for the purchased standard and does not constitute legal or compliance advice.