Risk Assessment for ICS System Design

The Checklist Cannot Know What You Are Protecting

Every ICS security checklist contains roughly the same items: segment the network, patch the systems, enable authentication, train the staff, document the policies. These are all correct. They are also context-free. A checklist does not know whether your blast furnace control network and your weather monitoring station occupy the same zone. It does not know whether your worst-case failure is a lost production batch or a plant evacuation. It cannot weigh the cost of a control against the consequence it is meant to prevent, because it has no information about either. The same five controls appear whether the protected asset drives a municipal water pump or a chemical reactor at operating pressure. The checklist either recommends controls that are unnecessary for lower-risk systems or misses controls that are critical for high-consequence ones. Risk assessment replaces the generic list with a site-specific question: given this specific threat environment, this specific architecture, and these specific failure consequences -- where does protection matter most, and how much is enough? The output is not another checklist. It is a defensible determination of which controls are needed, at what protection level, in which zones -- specific enough to drive procurement decisions, budget arguments, and design reviews, and documented well enough to survive an audit. IEC 62443-3-2, Assessment of Security Risk for System Design, provides the structured methodology for this work. It covers how to bound the system being assessed, how to perform the initial and detailed risk analysis, how to partition the system into zones and conduits with assigned security targets, and how to produce the Cybersecurity Requirement Specification that connects assessment to design. That methodology is the subject of this chapter.

The System Under Consideration: Drawing the Line First

Before any risk analysis can begin, a boundary must be drawn. Everything inside that boundary is in scope for the assessment -- every asset, every vulnerability, every network path is the organization's responsibility to understand and address. Everything outside is not in scope, until it creates a path into something that is. The IEC 62443-3-2 term for this bounded collection is the System Under Consideration, abbreviated SuC. It encompasses every IACS component, related asset, and network infrastructure element that the security risk analysis covers. Inside the SuC boundary, every asset belongs to either a zone or a conduit. There is no unclassified space -- every device and every network path is accounted for. Getting the boundary wrong means the assessment is wrong before it starts. Draw it too narrow and the assessment misses attack paths that run through excluded assets. Draw it to include everything and the assessment becomes unmanageable. The SuC boundary is the first decision in the IEC 62443-3-2 process, and it requires the asset owner in the room, documented reasoning for every inclusion and exclusion, and formal agreement before the detailed analysis begins. An asset outside the SuC boundary is outside the risk assessment by definition. If that asset has a network path into a zone inside the SuC, that network path is a conduit that must be identified and assessed even though the asset at the other end is not in scope. The remote access workstation in the corporate IT zone may not be part of your ICS SuC -- but the VPN connection from that workstation into the control zone is a conduit whose security posture belongs in your assessment.

Zone Boundaries Within the SuC

Once the SuC boundary is established, the next step is partitioning everything inside it into zones and conduits. IEC 62443-3-2 provides four criteria for determining where zone boundaries belong. Criticality addresses the severity of a loss-of-function event for this group of assets -- how bad is it if this group goes down, and does that severity differ from neighboring assets? Operational function identifies which process or subprocess the group serves -- devices that serve the same subprocess often share a zone boundary. Physical location asks whether assets are co-located or distributed across a facility -- geographic proximity can justify a zone even when operational function differs. Logical location identifies which network segment assets share -- devices on the same network segment that cross no firewall boundary are often already logically co-zoned. Each criterion can independently justify a zone boundary, and most real zone decisions involve more than one. Six specific separations are required by the standard regardless of how the other criteria apply. Business networks must be separated from control networks -- the foundational IT/OT boundary covered in Chapter 6. Safety-critical systems must be separated from non-safety systems, because a safety failure during a security event carries different consequences than a control failure. Temporarily connected devices -- maintenance laptops, portable engineering tools brought in during outages -- must be separated from production assets. Wireless segments must be separated from wired control networks. Connections from untrusted external networks require their own zone boundary. Remote access entry points, including vendor connections, must be bounded separately. Each missing separation is a path between zone types that the risk assessment will not see unless the assessor looks for it explicitly.

Risk = Threat × Vulnerability × Consequence

Chapter 4 introduced the simplified risk equation: Risk = Likelihood × Consequence. IEC 62443-3-2 expresses the same concept in three-factor form: Risk = Threat × Vulnerability × Consequence, where Likelihood is the product of Threat and Vulnerability. The three-factor form is more useful in design because it allows threat and vulnerability to be analyzed independently when deciding where to invest. A high-consequence zone with a low-capability threat profile requires different controls than a high-consequence zone with nation-state-level threat actors in scope. Collapsing threat and vulnerability into a single likelihood number would obscure that distinction. The threat factor in OT risk assessment covers four categories with different profiles. Nation-state actors represent the highest-capability ICS threat -- groups that have demonstrated ICS-native tooling, long-term access to operational networks, and willingness to execute attacks that produce physical consequences. PIPEDREAM from Chapter 11 and Triton from Chapter 4 are documented examples of this threat tier. Criminal ransomware groups represent a real OT availability threat but most lack ICS-specific targeting knowledge; their attacks tend to encrypt business IT infrastructure and create operational uncertainty rather than directly manipulating control systems. Insiders bring process knowledge that external actors rarely have -- which valve, which setpoint, which safety interlock matters -- and account for a meaningful share of real OT incidents that never appear in public reporting. Unintentional events -- operator error, misconfiguration, accidental command -- are technically a threat factor and account for a documented fraction of actual ICS disruptions; the Oldsmar incident from Chapter 10 represents this category. The consequence factor in OT extends beyond financial and reputational impact. Process disruption stops production and may require hours of manual restart to return to controlled operating conditions. Equipment damage can destroy assets with six-month or longer replacement lead times -- a blast furnace refractory lining or a large transformer is not an off-the-shelf item. A safety event can injure or kill workers. An environmental release can trigger regulatory response and affect communities beyond the plant fence. A public-facing service failure in water, power, or fuel supply affects people who have no relationship with the facility. Consequence severity is typically the largest driver of zone SL-T assignment in most OT risk assessments.

Likelihood and consequence combine in a 3×3 risk matrix. High likelihood and severe consequence place a zone in the highest risk category and drive a high SL-T. Low likelihood and negligible consequence place it in the lowest. The matrix does not produce a precise numerical score -- it produces a structured judgment. Working through the matrix for each zone forces the assessment team to name the threat, the vulnerability, and the consequence explicitly rather than assuming a shared understanding. That exercise reveals assumptions and disagreements before they become design gaps or, later, incidents. A zone where the team cannot agree on the threat profile is a zone where the risk assessment has not actually been completed, regardless of how much paperwork surrounds it. The risk equation is a structured argument, not a calculator.

The Security Level Vector: Seven Requirements, One Zone

A single SL number for a zone papers over meaningful distinctions. Authentication at SL2 while availability protection remains at SL0 because the zone runs legacy hardware with no redundancy option is a legitimate and different situation from both requirements at SL2. IEC 62443 addresses this through the SL vector: an assignment of a target security level to each of the seven Foundational Requirements independently, for each zone. The seven FRs cover the full security envelope. FR1 IAC -- Identification and Authentication Control -- governs who can access the zone and its systems. FR2 UC -- Use Control -- governs what authenticated users can do once inside. FR3 SI -- System Integrity -- requires protecting communication channels from unauthorized modification. FR4 DC -- Data Confidentiality -- requires protecting data from eavesdropping. FR5 RDF -- Restrict Data Flow -- limits information movement to authorized paths only. FR6 TRE -- Timely Response to Events -- requires the ability to detect and respond to security violations. FR7 RA -- Resource Availability -- requires that the system remain operational under the expected threat profile. The SL vector for a zone is written as a sequence of seven values, one per FR. The BPCS zone example below shows what this looks like in practice. Three SL types apply. SL-T is the target -- the level the risk assessment determines is required for each FR. SL-C is the capability -- the level the system can provide natively before any compensating controls are added. SL-A is the achieved level -- what is measured after design, countermeasures, and compensating controls are in place. The objective is SL-A meeting or exceeding SL-T. Where SL-C falls short of SL-T, compensating controls fill the gap. That gap analysis is what drives design decisions.

BPCS Zone example: SL-T = {2 2 0 1 3 1 3}. Amber cells indicate where SL-C falls below SL-T -- compensating controls are required to close the gap and achieve SL-A = SL-T. FR3 SI = 0 is a deliberate decision: integrity protection for this zone's traffic is handled at the conduit boundary, not inside the zone itself.

The practical use of the SL vector is in the differentiation it forces. When FR4 Data Confidentiality is assigned a target of SL0 for a particular zone, the assessment team is making an explicit decision: this zone's process data does not require confidentiality protection, and here is the reasoning. That explicit decision is fundamentally different from an implicit assumption that nobody recorded. It can be challenged, reviewed in future audits, and updated when circumstances change. The vector forces a position on each of the seven requirements -- including when that position is zero. One qualification matters. The SL vector approach was designed with the expectation that ICS risk assessment would shift from qualitative expert judgment to precise numerical scoring. That shift has not happened in practice across most of the industry. SL vectors are useful for structuring conversations, communicating requirements, and documenting design decisions. The values must be grounded in the same qualitative analysis -- risk matrix, expert judgment, threat profiling -- that drives the rest of the assessment. They do not replace that judgment and should not be treated as independently derived numbers.

The ZCR Workflow: From Boundary to Approval

IEC 62443-3-2 defines a seven-step workflow, designated ZCR1 through ZCR7, that moves the assessment from boundary identification to formal asset owner approval. ZCR1 identifies the System Under Consideration: the assets in scope, the boundary, and the external entities outside it. ZCR2 performs the initial risk assessment at the system level, before zone partitioning, to determine whether detailed analysis is warranted. ZCR3 partitions the SuC into zones and conduits using the four criteria and six required separations described earlier in this chapter. ZCR4 is a decision gate: does the initial risk assessment show that risk already exceeds tolerable levels, requiring the detailed zone-by-zone analysis? If the answer is no -- risk is already tolerable -- the workflow moves directly to ZCR6, skipping the detailed assessment entirely. If the answer is yes, ZCR5 performs the detailed risk assessment per zone and conduit, establishing residual risk levels and SL-T values for each. ZCR6 documents the results in the Cybersecurity Requirement Specification: which controls are required per zone and conduit, what assumptions were made during the assessment, what operational constraints limit the available options, and which residual risks the asset owner explicitly accepts. ZCR7 is the asset owner's formal approval of the CRS, making it the accountability record that governs procurement, design reviews, supplier requirements, and future audits. The decision gate at ZCR4 is the step most commonly skipped in practice and the one with the most practical value. It prevents over-engineering low-risk zones by requiring a deliberate determination of whether detailed analysis is needed before investing in it. Risk assessment is as much about knowing where not to invest as where to. A process that requires the same depth of analysis for a weather monitoring station as for a safety instrumented system is not a proportional risk methodology -- it is a compliance exercise with the costs of one and the benefits of neither.

From SL-T to Design: IEC 62443-3-3 and the CRS

The ZCR workflow produces SL-T values per zone. An SL-T is not a design. It is a target that specifies what the design must achieve. The translation from target to design is governed by IEC 62443-3-3, System Security Requirements and Security Levels. For each foundational requirement at each SL level, 62443-3-3 defines the system-level security requirements that must be met. FR1 Identification and Authentication Control at SL3 requires multi-factor authentication, role-based access control, and a dedicated authentication server. The same requirement at SL1 requires only a unique password per user. Those requirements drive procurement specifications, architecture decisions, and vendor selection. The SL-T is a contract between the risk assessment and the design team: meet the requirements that 62443-3-3 specifies for this target, and the design satisfies the risk assessment's conclusions. Where SL-C -- the native capability of the components being specified -- falls short of SL-T, compensating controls are added and documented. Where residual risk remains after compensating controls, the asset owner documents explicit acceptance of that risk in the CRS. The Cybersecurity Requirement Specification produced at ZCR6 is the document that governs everything downstream: design reviews validate against it, procurement specifications derive from it, supplier requirements reference it, and future audits compare achieved capability to what it specifies. It is not an internal engineering artifact that gets filed after the project closes. It is the accountability record for what was decided, why it was decided, and who approved it.

What's Next

Chapter 12 has covered the formal risk assessment methodology: the System Under Consideration as the prerequisite boundary, the four zone criteria and six required separations inside the SuC, the three-factor risk equation and the 3×3 matrix that structures its output, the SL vector that differentiates protection requirements across seven dimensions, the ZCR1-ZCR7 workflow from boundary to CRS to asset owner approval, and the translation from SL-T to design through IEC 62443-3-3. Chapter 13 turns to the third-party dimension: how IEC 62443 structures the evaluation of the vendors and integrators whose products and services the design will depend on, and what the supply chain attack history says about where that evaluation matters most.

Reflect

• The SuC boundary determines what the risk assessment can see. For your organization's most recent ICS risk assessment, where was the SuC boundary drawn -- and were vendor remote access connections, employee VPN paths, and temporarily connected maintenance devices inside the boundary or explicitly excluded? If they were excluded, are they conduits into the SuC that should be assessed even though the assets at the other end are out of scope?
• The ZCR4 decision gate allows the workflow to skip the detailed per-zone analysis if the initial assessment shows risk is already tolerable. For any low-criticality zone in your environment -- an auxiliary monitoring system, an environmental sensor network -- has a conscious determination been made that detailed assessment is or is not needed, or has the same assessment depth been applied uniformly regardless of risk level?
• The SL vector assigns a target level to each of the seven FRs separately. For the highest-consequence zone in your environment, has FR4 Data Confidentiality been explicitly evaluated and assigned a target -- even if the target is SL0? A documented SL0 decision and an undocumented assumption look identical in the zone record but represent completely different states of organizational accountability.
• The SL-C gap -- where native system capability falls short of the SL-T -- requires compensating controls. For any zone where the documentation shows SL-A = SL-T despite known legacy constraints, what are the compensating controls, who is responsible for maintaining them, and when were they last verified to still be in place and effective?