IEC 62443 Risk Assessment: Complete 2026 Step-by-Step Guide

An IEC 62443 risk assessment is the process defined in IEC 62443-3-2 for turning an industrial automation and control system (IACS) into documented zones, conduits and a target security level (SL-T) for each one. The asset owner is accountable for it, and the end product is a set of requirements that designers, integrators and suppliers can actually build to.

The standard sets out seven zone and conduit requirements, ZCR 1 to ZCR 7. It says what must be done, not how to score it, which is why many teams stall after kickoff. This guide covers the practical side of an IEC 62443 risk assessment: inputs, tolerable risk, a step-to-output table, how SL-T is derived, the workshop team, effort and common mistakes. New to the series? Start with how the IEC 62443 parts fit together.

What an IEC 62443 risk assessment covers

IEC 62443-3-2:2020, “Security risk assessment for system design”, was published on 24 June 2020. It works on one system under consideration (SUC) at a time, such as a process unit, a substation or a packaging line, rather than the whole enterprise. The full text is available from the IEC webstore page for IEC 62443-3-2:2020.

• It is design-focused. Results feed system design and procurement, so run it before a project or major upgrade and again when the architecture changes.
• It is method-neutral. You choose the risk matrix, scales and threat catalog. An informative annex only offers example risk matrices.
• It ends in requirements, not a score. The key deliverable is the Cybersecurity Requirements Specification (CRS), which the system requirements in IEC 62443-3-3 then help satisfy.

Inputs to gather before the first workshop

In our experience, much IEC 62443 risk assessment time is lost hunting for drawings. Collect these before booking a meeting room:

• Current architecture and network drawings, including firewalls, remote access paths and vendor connections
• An OT asset inventory with make, model, firmware version, function and location
• Process safety studies such as HAZOP and LOPA
• The corporate risk matrix and any HSE risk criteria already in use
• A data flow list: which systems talk, over which protocol, and why
• Sector threat intelligence and your own incident records
• Regulatory and contractual requirements, plus existing security policies

If the asset inventory is weak, fix it first. Otherwise you get zones containing assets nobody listed and conduits nobody knew existed.

Set tolerable risk and consequence categories first

Tolerable risk decides everything downstream: whether a zone needs a detailed assessment, its SL-T and which countermeasures become mandatory. The asset owner sets it, and ZCR 6.8 expects it to be documented. Agree it in writing before the workshop, or the session turns into a debate about scores.

Reuse the risk matrix your process safety and enterprise risk teams already apply. A cyber-triggered release is still a release, so it belongs on the same scale. Define at least these consequence categories, each with three to five severity levels:

• Safety: injury or fatality to workers or the public
• Environment: releases, spills or emission breaches, scaled by reportability
• Production: lost output, downtime, quality loss or equipment damage, expressed in hours or currency
• Regulatory: license conditions, mandatory incident notifications, fines or enforcement action

Many organizations add financial and reputational categories. Keep levels concrete (“more than 24 hours of lost production”, not “major”) so two people rating the same scenario agree.

IEC 62443 risk assessment step by step: ZCR 1 to ZCR 7

The table maps each zone and conduit requirement in IEC 62443-3-2 to the work and the output we expect on file, using the standard’s step names.

ZCR step	What you do	Output
ZCR 1: Identify the SUC	Define the system boundary, list its assets, and identify the perimeter and every access point	SUC description, boundary drawing, asset list
ZCR 2: Initial cyber security risk assessment	Rate worst-case consequences, assuming the attack succeeds and no countermeasures exist	Initial risk ratings per function or asset group
ZCR 3: Partition the SUC into zones and conduits	Group assets by risk, function and location; separate business, safety-related, wireless, temporarily connected and externally connected assets	Draft zone and conduit drawing and register
ZCR 4: Risk comparison	Compare initial risk with tolerable risk for each zone and conduit	List of zones and conduits needing detailed assessment
ZCR 5: Perform a detailed cyber security risk assessment	Identify threats and vulnerabilities, rate unmitigated likelihood and impact, set SL-T, credit existing countermeasures, determine residual risk, add countermeasures	Risk register, SL-T per zone and conduit, countermeasure list
ZCR 6: Document cyber security requirements, assumptions and constraints	Write the CRS with its supporting characteristics, assumptions and constraints	CRS (ZCR 6.1), zone and conduit register, drawings
ZCR 7: Asset owner approval	Present results and residual risk to the accountable owner for sign-off	Signed approval record

ZCR 1 to 3: scope, worst case, partition

Draw the SUC boundary tightly enough to finish, but include every way in: remote access, historian links, vendor laptops, USB and wireless. At ZCR 2, assume the cyber event happens and ask how bad it could get. The ISA Global Cybersecurity Alliance white paper on 62443-3-2 notes that likelihood at this stage is often expressed as a conditional probability of one, which keeps attention on consequence.

Then partition. ZCR 3 expects business and IACS assets, safety-related assets, temporarily connected devices, wireless devices and devices reached over external networks to be separated. Our guide to designing IEC 62443 zones and conduits covers the grouping logic.

Initial vs detailed IEC 62443 risk assessment

The initial assessment is fast and consequence-led; it shows where to spend effort. The detailed assessment (ZCR 5) runs per zone and conduit through 13 sub-steps, from threats and vulnerabilities to residual risk and documented results.

A zone whose initial risk exceeds tolerable risk goes through ZCR 5. If it already sits within tolerable risk, record the rationale and carry it forward to documentation.

ZCR 6 and 7: document and approve

ZCR 6 makes the work usable. Alongside the CRS, it covers the SUC description, zone and conduit drawings and characteristics, operating environment assumptions, threat environment, organizational security policies, tolerable risk and regulatory requirements. Our Cybersecurity Requirements Specification guide explains each section. ZCR 7 closes the loop with formal asset owner approval.

How SL-T per zone falls out of the assessment

SL-T is determined inside the detailed assessment (ZCR 5.6), after unmitigated risk is known and before existing countermeasures are evaluated. That order matters: the target reflects what the zone must withstand, not what it happens to have today.

The standard does not prescribe one formula. Two practical checks work well together:

1. Risk-to-SL mapping. Agree a table in advance that maps unmitigated risk ratings to SL-T, so an intolerable safety consequence can never land at SL 1.
2. Threat-capability check. Compare your credible attacker with the SL definitions. SL 2 covers intentional violation using simple means with low resources and generic skills; SL 3 covers sophisticated means with moderate resources and IACS-specific skills. If that attacker could cause an intolerable consequence, target that level.

Where the two checks disagree, take the higher value and record why. The standard allows SL-T as a single value or a vector, and many teams use a vector across the seven foundational requirements, because a zone may need strong integrity and availability but only modest confidentiality. Conduits get their own SL-T too; we usually set it no lower than the more demanding zone it connects.

The outputs you should end up with

A finished IEC 62443 risk assessment leaves a trail an auditor, integrator or supplier can follow unaided. At minimum:

• Risk register: each threat scenario with zone, threat source, vulnerability, consequence by category, unmitigated likelihood, SL-T, existing and additional countermeasures, residual risk and owner
• Zone and conduit register: identifier, accountable owner, logical and physical boundary, safety designation, assets, access points, permitted data flows, connected zones and SL-T
• Zone and conduit drawings that match the register and the as-built network
• CRS: requirements, assumptions and constraints for detailed design and procurement
• Approval record: accepted residual risks, any SL-T not yet met, and review triggers such as architecture changes, new remote access or a significant incident

These records matter even more if you are looking at ISASecure ACSSA, which covers an operating IACS against parts 2-1, 2-4, 3-2 and 3-3.

Who should be in the workshop, and how long it takes

The workshop roster

• Facilitator with OT security and IEC 62443 experience, internal or external
• Operations or plant manager, who owns production consequences
• Process safety engineer who knows the HAZOP and safety instrumented system design
• Control system engineer or automation lead
• OT network engineer
• Maintenance lead, who knows how laptops, USB media and vendors really get in
• IT security or the CISO’s delegate, for the enterprise boundary
• Main system integrator or vendor, for specific sessions only

Keep the core group to six to eight people.

Typical effort (estimates)

These are Governance Docs practitioner estimates for a single mid-sized site with reasonable documentation, not figures from the standard:

• Input gathering and inventory clean-up: one to three weeks elapsed
• ZCR 1 to 4 workshop: one to two days
• ZCR 5 detailed assessment: half a day to a day of workshop time per zone, plus analyst time
• ZCR 6 documentation and CRS: one to three weeks
• Review and ZCR 7 approval: one to two weeks, driven mostly by calendars

In our experience, a first IEC 62443 risk assessment for one site typically takes 6 to 12 weeks elapsed and 20 to 60 person-days. Poor drawings can double that; templates and an experienced facilitator shorten it.

Common mistakes in zones and conduits risk assessment

1. Copying Purdue levels as zones. Levels describe function, not risk.
2. Crediting countermeasures too early. If the initial assessment counts the firewall, worst-case risk looks tolerable and zones skip ZCR 5.
3. Using an IT risk matrix. Confidentiality-heavy scales underrate safety and production impact.
4. Setting SL-T by habit. “Everything is SL 2” with no trace back to risk will not survive an audit.
5. Treating conduits as just firewalls. Remote access, vendor links and removable media are conduits too, often the weakest.
6. Leaving safety systems in the control zone. ZCR 3 expects safety-related assets to be separated.
7. Running it once. Without review triggers, the IEC 62443 risk assessment drifts away from the as-built network.

If you would rather not build the registers from scratch, the IEC 62443 Toolkit includes templates for the 3-2 risk assessment and CRS, zones and conduits, and an SL-T/SL-C/SL-A gap workbook among its 117 editable templates (82 Word, 35 Excel). It is written for asset owners and service providers. It supplies the documented layer; your team still runs the workshops, makes the risk decisions and keeps the records.

IEC 62443 risk assessment FAQs

Is IEC 62443-3-2 mandatory?

Not by itself. IEC 62443 is a voluntary standard, and certification against it is voluntary. It becomes binding when a regulator, customer contract or project specification calls it up.

How often should we repeat an IEC 62443 risk assessment?

Repeat it whenever the SUC changes materially: new zones, new remote access, major upgrades or a significant incident. We also recommend a scheduled review every one to three years.

Can we use our existing HAZOP or PHA?

Yes, and you should. HAZOP and LOPA results show which deviations lead to the worst consequences and which safeguards are independent of the control system. A cyber PHA built on that study keeps ZCR 2 and ZCR 5 consistent with process safety.

Who approves the IEC 62443 risk assessment?

The asset owner, under ZCR 7. In practice that means the executive accountable for the site, not the security team that ran the workshop. The approval should name the residual risks being accepted.