A risk is essentially the chance of something bad happening. That sounds simple enough, but in an operational-technology (OT) cybersecurity risk assessment, one of the first challenges is often not calculating the risk. It is defining exactly what risk we are assessing.
Consider a statement such as “Unauthorized control of the control system.” It sounds like a risk, and it could easily appear in a risk register and be assigned a likelihood, consequence, and rating. But what exactly are we rating? Which control system? Which asset? Who is trying to take control? What are they trying to do? What capability do they have? What weakness in the system allows that action to happen?
If those questions are not clear, different people participating in the same assessment may be thinking about different scenarios while discussing the same risk. Before we rate the risk, we first need to establish the scenario properly.
Building the risk scenario
ISA/IEC 62443-3-2 provides the wider risk-assessment context: define the system under consideration, partition it into zones and conduits, and assess risk within that architecture. For this discussion, I assume that groundwork has already been done. The sequence below is a practical way of building an individual risk scenario using those concepts; it is not intended as a verbatim normative workflow from the standard.
A risk ID is useful for tracking, but it does not define the risk. Scenario definition starts by narrowing the lens to the zone, and where necessary, the subzone. The zone depends on the infrastructure. In an oil and gas environment, it may be an integrated control and safety system (ICSS), subsea, power generation, nitrogen generation, or telecommunications zone. In a transmission company, it may be MasterSCADA, substation automation, telecom, or another operational system. The terminology will vary from one organization to another. What matters is that we know where the scenario exists.
Within that zone, we identify the asset or asset group being assessed. This might be an engineering workstation, operator station, server, controller, network device, or a functional group of similar assets. Every relevant asset or asset group within scope should be considered; otherwise, the assessment can become a collection of obvious risks rather than a structured view of the environment.
Once the asset is identified, we need to understand its criticality. Criticality should reflect how important the asset is to the business or operational purpose. Confidentiality, integrity, and availability can support the classification, but the practical question is simpler: how important is this asset to what the organization is trying to operate, produce, protect, or deliver? Two technically similar systems may have very different criticalities because they perform different functions.
Once the asset is clear, we move to the threat source or threat actor. A useful threat catalog should do more than label the source as a “hacker” or “insider.” It should characterize the source sufficiently to establish a threat level. Typical attributes include whether the source is internal or external; whether the action is accidental or intentional; the actor’s motivation, capability, or skills; and the resources available to them. A casual actor with generic skills is not the same threat as a well-resourced actor with extensive industrial control system (ICS) knowledge. An authorized employee making an accidental change is different again.
The next question is what the threat source actually does. This is the threat action. It may be plugging an infected USB device into a workstation, conducting passive reconnaissance, attempting unauthorized access, taking unauthorized control of a system, modifying a configuration, introducing malicious code, or disrupting communications. The action must be specific enough that we can understand what is actually happening in the scenario.
Finally, we identify the vulnerability or weakness in the existing system that the threat action is trying to exploit. This is what connects the threat to the actual environment. A vulnerability should not sit in the risk register as an isolated technical finding; it matters here because it enables a particular action against a particular asset in a particular context.
A simple check is whether the scenario can answer these questions:
- Where are we looking? Zone/subzone.
- What are we assessing? Asset/asset group.
- How important is it? Asset criticality.
- Who or what is the threat? Threat source/actor.
- What level of threat does it represent? Threat level.
- What does the threat do? Threat action.
- What weakness enables that action? Vulnerability/weakness.
Building an OT cyber risk scenario. Each layer adds context until the risk being assessed is clearly defined. Source: Author.
The same threat action does not mean the same risk
This distinction becomes important when the same threat action can be performed by more than one actor. Take an engineering workstation within an ICSS zone. A risk entry that simply says “Unauthorized control of the engineering workstation” does not tell us enough.
Scenario A could involve an external malicious actor with the capability and resources to obtain unauthorized remote control by exploiting weak remote-access authentication. Scenario B could involve an internal privileged user intentionally making unauthorized changes by abusing excessive administrative privileges.
The asset may be the same and the broad threat action may be similar, but the risks are not the same. The threat source is different, the threat level is different, the pathway is different, and the vulnerability being exploited is different. A compromised contractor account could create yet another scenario. If we combine all of these into one generic statement, we lose information that matters later when we assess and treat the risk.
The same threat action does not necessarily represent the same risk. Changing the threat source and vulnerability creates a different scenario. Source: Author.
This is why I prefer to build the scenario through several fields rather than begin with a single risk sentence. The final risk statement may still be concise, but it is the output of the scenario-building exercise rather than the starting point. By the time we write it, the assumptions behind the risk are visible and can be challenged.
Define first, rate second
Once the scenario is clear, we can move to the next stage and ask how likely it is and what consequence could result if it materializes. Those questions enable us to rate the risk. The organization may use a qualitative or quantitative method; the scenario definition steps do not change.
If likelihood must be quantified in more detail, additional parameters are needed. I discussed one practical approach in an article titled “Simplifying Likelihood in OT Risk Assessments: A Practical ISA/IEC 62443 Perspective,” where likelihood is considered through access exposure and exploitability. That calculation comes after the scenario has been established; it does not replace scenario definition.
A sophisticated scoring methodology cannot compensate for an unclear risk. If one person is thinking about an external attacker, another about a malicious insider, and a third about an accidental operator action, a single likelihood and consequence rating does not resolve the problem. They may simply be rating different risks under the same description.
The starting point is therefore not the risk matrix. It is clarity about what risk is actually being assessed. Establish where it exists, the asset involved, its importance, the threat source and level, the action being attempted, and the vulnerability that makes the action possible. Once those elements are clear, the risk becomes much easier to understand, challenge, and assess.
