← Home

IEC 62443-3-2 Clause 4.6 – Detailed Cybersecurity Risk Assessment

ISA/IEC 62443-3-2:2020, Clause 4.6 covers the detailed cybersecurity risk assessment as zone and conduit requirement ZCR 5.

ZCR 5 is applied to every zone and conduit (with permitted grouping where threats, consequences or assets are similar, or where a standardised reference design is replicated). It walks each partition from threats and vulnerabilities through unmitigated risk and SL-T, then through existing and additional countermeasures to residual risk, ending with protected documentation for stakeholders.

Teaching note: The summaries below paraphrase ISA/IEC 62443-3-2:2020 for learning purposes. They are not a verbatim extract of the standard — always refer to the published text for normative wording and assessment. Any recognised risk method (for example ISO 31000, NIST SP 800-39, ISO/IEC 27005) may be used if these requirements are met and scales stay consistent with the initial assessment.

Reference: ISA/IEC 62443-3-2:2020, Clause 4.6
Related: Zone, Conduit and Risk Assessment (Clause 4) | Threats | Vulnerabilities | Consequence | Risk Equation | Mitigated Likelihood and Residual Risk | Bowtie Diagrams | Prepare for an Assessment | Documentation | IEC 62443-3-3 Security Levels | IEC 62443-3-3 Foundational Requirements | SP and Risk Assessment

ZCR pages: ZCR 1 | ZCR 2 | ZCR 3 | ZCR 4 | ZCR 5 | ZCR 6 | ZCR 7

Detailed ZCR 5 zone and conduit risk assessment flow (ZCR 5.1 through ZCR 5.13)
Figure – Detailed cybersecurity risk assessment flow for ZCR 5, from threat and vulnerability identification through residual risk, additional countermeasures, and documentation (ANSI/ISA-62443-3-2-2020).

Requirements in this ZCR


ZCR 5 – Detailed cybersecurity risk assessment

Reference: ISA/IEC 62443-3-2, Clause 4.6

ZCR 5.1: Identify threats

Clause: 4.6.2

Summary
Develop a list of threats that could affect assets inside the zone or conduit. Useful threat records typically describe the source, capability/skill, possible vectors and affected assets. Grouping into classes is acceptable when the raw list would be unwieldy.

Expanded teaching material: Threats (sources, vectors, statements and catalog).

ZCR 5.2: Identify vulnerabilities

Clause: 4.6.3

Summary
Analyse the zone or conduit and record known vulnerabilities of its assets — including access points. Vulnerability assessments and trusted sources (for example ICS-CERT, product suppliers) help keep the list realistic.

Expanded teaching material: Vulnerabilities (including discovery questions by layer). (classes, assessment types and tools such as CSET).

ZCR 5.3: Determine consequence and impact

Clause: 4.6.4

Summary
For each threat scenario, evaluate consequence and impact — ideally as worst-case effect on areas such as personnel safety, finance, business interruption and environment. Draw on existing PHAs and related risk studies. Low impact may mean moving quickly to the next threat.

Expanded teaching material: Consequence (consequence vs impact, categories and ranking).

ZCR 5.4: Determine unmitigated likelihood

Clause: 4.6.5

Summary
Estimate the chance each threat materialises without counting existing cybersecurity countermeasures (treat those as temporarily removed). Inherent component behaviour and non-cyber IPLs (physical security, mechanical safeguards, emergency procedures) may still be recognised. Qualitative or quantitative methods are allowed; consequence-only methods that treat likelihood as constantly present are also permitted.

Frequency vs probability of success, and the two-pass (unmitigated then mitigated) pattern: Risk Equation – Frequency vs probability.

ZCR 5.5: Determine unmitigated cybersecurity risk

Clause: 4.6.6

Summary
Combine impact (ZCR 5.3) and unmitigated likelihood (ZCR 5.4) — typically via the corporate risk matrix — to obtain unmitigated cybersecurity risk for each threat.

How likelihood and consequence combine: Risk Equation.

ZCR 5.6: Determine SL-T

Clause: 4.6.7

Summary
Establish a target security level (SL-T) for each zone or conduit. SL-T may be a single value or a vector. There is no single mandated calculation: common approaches use the gap to tolerable risk, the SL definitions in Part 3-3 / Annex A, or iterative risk-matrix checks that raise SL until residual risk becomes acceptable.

SL-T communicates the desired protection level to designers, implementers and operators. It later pairs with Part 3-3 capability levels when selecting technical requirements.

Some organisations express the gap between unmitigated cybersecurity risk and tolerable risk as a cybersecurity risk reduction factor (CRRF) — a measure of how much risk reduction is required to reach tolerance. CRRF is a teaching aid for sizing SL-T; Part 3-2 does not prescribe a single formula. Practical methods for establishing SL-T include:

Record the chosen method with the assessment and carry SL-T into the CRS. Further teaching depth: Part 3-3 Security Levels.

ZCR 5.7: Compare unmitigated risk with tolerable risk

Clause: 4.6.8

Summary
Compare each threat’s unmitigated risk with tolerable risk. If it exceeds tolerance, decide whether to accept, transfer or mitigate. Mitigation continues through ZCR 5.8–5.12; otherwise document under ZCR 5.13 and move to the next threat.

ZCR 5.8: Identify and evaluate existing countermeasures

Clause: 4.6.9

Summary
Identify controls already present in the SUC and judge how effectively they reduce likelihood or impact. Part 3-3 SL-C assignments help reason about technical control strength.

Most countermeasures aim to reduce likelihood (block threats or shrink the attack surface). Some also reduce consequence severity — for example Ethernet rate limiting that prevents a device crash under a network storm but may still leave operators with loss of view. Record both effects when evaluating controls. Teaching depth: Mitigated Likelihood and Residual Risk, Bowtie Diagrams, SP evidence as countermeasures.

ZCR 5.9: Reevaluate likelihood and impact

Clause: 4.6.10

Summary
Re-score likelihood and impact with those existing countermeasures applied (technical, administrative and procedural). This produces mitigated values for residual risk.

The mitigated likelihood is often called Mitigated Threat Likelihood (MTL) — see Mitigated Likelihood and Residual Risk.

ZCR 5.10: Determine residual risk

Clause: 4.6.11

Summary
Combine mitigated likelihood and mitigated impact for each threat to obtain residual risk — a measure of current exposure and of how well existing controls work.

ZCR 5.11: Compare residual risk with tolerable risk

Clause: 4.6.12

Summary
Compare residual risk against tolerable risk. Where residual risk remains too high, decide under policy whether to accept, transfer or further mitigate.

ZCR 5.12: Identify additional cybersecurity countermeasures

Clause: 4.6.13

Summary
Unless the organisation chooses to tolerate or transfer remaining risk, identify further technical, administrative or procedural controls to bring residual risk within tolerance. Moving an asset into a higher-security zone can also reduce exposure. Part 3-3 is a guide for selecting technical measures and judging SL-C effectiveness; cost and complexity should be weighed in design.

ZCR 5.13: Document and communicate results

Clause: 4.6.14

Summary
Document, report and distribute the detailed assessment to appropriate stakeholders, protecting confidentiality with suitable information-security classification. Record session dates, participant names and titles, and archive supporting inputs (architecture diagrams, PHAs, vulnerability and gap assessments, threat sources) with the assessment.

The assessment is a living artefact for testing, audit and later refresh — and a sensitive one, because it often lists vulnerabilities and current safeguards.

In practice teams produce a Cybersecurity Risk Assessment Report that provides a risk profile — often presented like a heat map of unmitigated and mitigated risk by zone (and conduit where assessed). Check Process Hazard Analysis (PHA), safety, business continuity and disaster recovery units: they may already hold consequence or criticality artefacts you can leverage. There is no single mandated format; the standards provide examples.

A good assessment should give designers, for the whole SUC and for each zone and conduit:

Alongside the normative ZCR 5.13 expectations, also record:

Assign appropriate information-security classification and controlled access. The assessment output (and the CRS (ZCR 6)) is the primary input to Development & Implementation. Results also feed asset owner approval (ZCR 7) and conceptual design work such as zone and conduit security strategy. Catalogue context: Documentation.


Key Takeaways