← Home

IEC 62443-3-2 – Mitigated Likelihood and Residual Risk

Detailed cybersecurity risk assessment (ZCR 5) scores risk twice for many threats: first unmitigated (ignore existing cyber countermeasures), then residual after putting those countermeasures back and judging their effectiveness. This page is the teaching deep-dive behind ZCR 5.8–5.12.

Teaching note: Paraphrased for learning from IACS risk-assessment practice and related ISA/IEC 62443 concepts. Not a verbatim extract of ISA publications or the standard — always refer to published text for normative wording.

Reference: ISA/IEC 62443-3-2:2020, Clause 4.6 (ZCR 5)
Related: Risk Equation | Bowtie Diagrams | Develop a Plan | ZCR 5 | Part 3-3 Security Levels | SP and Risk Assessment

Unmitigated then residual

  1. Unmitigated likelihood and risk — evaluate the threat without credit for existing cybersecurity countermeasures (ZCR 5.4–5.5). Compare with tolerable risk (ZCR 5.7). If already tolerable, detailed mitigation work for that threat can stop early.
  2. Identify and evaluate existing countermeasures (ZCR 5.8) — technical, administrative and procedural controls; Part 3-3 SL capability ratings help discuss relative strength.
  3. Re-evaluate likelihood and impact (ZCR 5.9) with those controls in place.
  4. Residual risk (ZCR 5.10) — combine mitigated likelihood and impact (typically via the corporate matrix). Compare again with tolerable risk (ZCR 5.11).
  5. Additional countermeasures (ZCR 5.12) where residual risk remains too high, unless the organisation accepts or transfers the risk under policy.

Mitigated Threat Likelihood (MTL)

Mitigated Threat Likelihood (MTL) is the likelihood that the threat scenario occurs and leads to the final consequence, taking into account all protection measures and cybersecurity countermeasures in place. It replaces the unmitigated likelihood once existing controls are credited.

Most cyber countermeasures aim to reduce likelihood (block threats or shrink the attack surface). Some also reduce consequence severity — for example rate limiting that prevents a device crash but still allows loss of view. Re-evaluate impact as well as likelihood.

When the team recommends further controls, they may record an Adjusted MTL (MTLa) — the expected likelihood if those recommendations are implemented. Recommendations should be independently reviewed for unintended safety or cybersecurity side effects.

Categories of countermeasures

Workshop teams often organise existing and proposed controls into categories such as:

CategoryFunction / objectiveExamples
Logical access controls Manage authentication and privileges System/device login, network access controls, domain controllers
Physical access controls Control physical access to critical cyber assets Guards, fences, doors, enclosures
Data-flow controls Control flow of data in, out and within the system Firewalls, routers, switches, conduits
Data integrity controls Prevent corruption or unauthorised disclosure Encryption, VPN, CRC checks, allow-listing
Detection Detect and alert anomalous or malicious events IDS, SIEM, anti-malware
Policy / procedure Define and reinforce appropriate behaviour Policy documents, procedures, group policy
Hardening Minimise vulnerability by disabling unnecessary functions Remove unused apps, block unused ports

Part 2-1 Security Program evidence (hardening, identity, crypto, incident response, backup) is often the proof that these categories are real on the SuC — see SP and Risk Assessment. Bowtie diagrams help place the same controls as preventative or recovery barriers.

Course review term: CRRF

Some training materials refer to a Cyber Risk Reduction Factor (CRRF) when discussing how much risk drops from unmitigated to residual after controls. Treat CRRF as a teaching label for that reduction — organisations still score risk with their own matrix and policies. Do not invent a universal formula; document the method the asset owner actually uses.

Key takeaways