An OT risk assessment should answer one question for the people who run the plant: which cyber events could hurt people, the environment, the equipment or production, and what should we do first about them? Many assessments never get there. They produce a vulnerability list, a heat map and a long report that operations does not trust. This article sets out a methodology that starts from consequences, speaks the language of engineers, and ends in a roadmap that can be funded and executed.
The problem in real environments
OT environments are not data centers with unusual protocols. Assets run for decades, patching is constrained by vendor support and outage windows, and the worst outcomes are physical: a release, a fire, a flooded basement, a damaged turbine or days of lost production. Ownership is split between operations, engineering, maintenance, IT and outside integrators, and each group sees a different part of the system.
Against that background, assessments often fail in predictable ways. Some are IT risk methods transplanted unchanged, scoring confidentiality first and treating availability as an afterthought. Others are tool-driven: a passive monitoring sensor is installed for a few weeks and its vulnerability output becomes the risk register. Both approaches count weaknesses instead of describing what an adversary, or an accident, could actually make the process do.
Principles of the method
- Consequence first: begin with what must not happen, then work back to the cyber paths that could cause it. This reflects the thinking behind consequence-driven approaches such as INL's Consequence-driven Cyber-informed Engineering (CCE).
- Engineering context: use existing safety and process studies, such as HAZOP and LOPA, rather than reinventing hazard analysis.
- Scenarios, not findings: risk is expressed as a scenario with a path, a consequence and a likelihood, not as a CVE count.
- Standards-aligned: the structure maps onto IEC 62443-3-2 for zones, conduits and target security levels, and onto the OT guidance in NIST SP 800-82r3.
- Actionable output: every high risk ends with an owner, a treatment and a date.
Step 1: Scope and governance
Define the system under consideration: which sites, process areas and systems are in scope, and where the boundary sits with corporate IT, cloud services and third parties. Agree the risk criteria before any analysis begins. That means a consequence scale covering safety, environment, equipment, production and regulatory impact, a likelihood scale, and a statement of tolerable risk signed off by someone with authority to accept it.
Assemble the right people. At minimum you need a process or controls engineer who knows the plant, an operations representative, the OT or ICS owner, IT network and identity staff, and the safety or HSE lead. Vendors and integrators should be consulted for the systems they maintain.
Step 2: Asset and connectivity baseline
You cannot assess what you have not described. Build an inventory that is good enough for risk decisions, not a perfect CMDB:
- Controllers, safety systems, HMIs, engineering workstations, historians, servers and network devices, grouped by process area.
- Firmware and operating system versions, vendor support status and who maintains each asset.
- Every path into the environment: remote access, vendor connections, cellular modems, wireless, removable media, transient laptops and links to corporate IT or cloud.
- Actual data flows, observed where possible, compared with what the architecture drawings claim.
Combine document review, interviews, physical walkdowns and passive traffic capture. Avoid active scanning of live control networks unless it has been agreed with operations and the vendor and tested on representative equipment first.
Step 3: Consequence analysis
For each process area, identify the worst credible outcomes and ask how cyber could contribute. Practical prompts include loss of view, loss of control, manipulation of view, manipulation of control, and loss or manipulation of the safety function. Map each outcome to the assets whose compromise could cause it. These become the crown jewels of the assessment, which is often a far shorter list than the full inventory.
Be explicit about safety. Where a safety instrumented system protects against a hazard, examine whether it is independent of the basic process control system in practice, not only on paper. Shared engineering workstations, shared networks or shared credentials can erode the independence that the safety case assumes. IEC 61511 requires a security risk assessment of the SIS, and this step is where that analysis belongs.
Step 4: Threat scenarios
A scenario connects a threat source, an entry point, a path through the architecture, an action on the process, and the consequence. Keep scenarios concrete and grounded in your own architecture. MITRE ATT&CK for ICS is a useful vocabulary for describing techniques, for example:
- External remote services (T0822): compromised vendor remote access credentials reach an engineering workstation.
- Replication through removable media (T0847): malware arrives on a contractor USB drive during a maintenance outage.
- Unauthorized command message (T0855): commands are sent to a controller that does not authenticate its clients.
- Loss of safety (T0880): the impact category when a scenario degrades or defeats a safety function.
Include non-malicious scenarios as well. A misconfigured switch, a broadcast storm from a faulty device or a well-meaning engineer pushing the wrong logic can produce the same consequences, and many controls address both. Aim for a manageable set, often a few dozen scenarios per site, that covers each crown jewel and each significant entry point.
Step 5: Likelihood in OT terms
Likelihood is the hardest part to estimate honestly. OT has little reliable incident frequency data, so precise probabilities are usually false precision. Instead, assess likelihood through observable factors that engineers and auditors can verify:
- Exposure: is the entry point reachable from the internet, from corporate IT, only from within the plant, or only with physical access?
- Path complexity: how many independent barriers must be crossed, and how well enforced is each one?
- Attacker capability needed: does the scenario require generic IT skills, or detailed knowledge of the specific process and control system?
- Existing controls: authentication, segmentation, application allowlisting, monitoring and the speed of response.
- Exposure time: is the path always open, or only during supervised maintenance windows?
Score these on a simple qualitative scale and record the reasoning. The attacker capability factor lines up naturally with the IEC 62443 security level definitions, which describe adversaries by means, resources, skills and motivation, making it easier to translate results into target security levels later.
Step 6: Safety and availability consequences
Rate the consequence of each scenario on the agreed scale, using the plant's existing severity categories wherever possible so that cyber risk sits on the same matrix as process safety risk. Distinguish clearly between unmitigated consequence (what could happen if cyber defeats the control) and mitigated consequence (what still happens when independent non-cyber safeguards work).
This is where engineering judgment adds the most value. Mechanical relief valves, hardwired trips, interlocks and manual operating procedures can limit physical outcomes even if a controller is compromised. Crediting those safeguards correctly prevents both alarmism and complacency. Availability deserves equal weight: for many utilities and manufacturers, a prolonged loss of view or production is the most likely serious outcome, and recovery time depends on backups, spares and tested restoration procedures.
Step 7: Build the risk register
Each register entry should be readable by an engineer and a board member alike. A practical structure:
| Field | Content |
|---|---|
| Scenario | One sentence: source, entry point, path, action and outcome. |
| Zone and assets | The affected zone, conduit and crown jewel assets. |
| Consequence | Unmitigated and mitigated ratings across safety, environment, equipment and production. |
| Likelihood | Rating with the factors and reasoning behind it. |
| Current controls | What already reduces likelihood or consequence, and how it was verified. |
| Risk and treatment | Current risk, proposed treatment, residual risk, owner and target date. |
Keep the register in a format the organization already uses for operational risk, and review it after significant changes, incidents and at a fixed interval.
Step 8: A prioritized roadmap
Group treatments rather than listing one action per risk. A single well-designed remote access architecture may reduce a dozen scenarios at once. A workable structure has three horizons:
- Immediate (weeks): remove internet exposure, disable unused remote access paths, change default credentials, verify and protect backups of controller logic and configurations, and establish a removable media procedure.
- Near term (months): enforce segmentation and documented conduits, move vendor access to a brokered, approved and recorded model, introduce passive OT monitoring tied to an incident response plan, and harden engineering workstations.
- Strategic (one to three years): align with IEC 62443 target security levels per zone, embed security requirements in procurement and projects, plan lifecycle replacement of unsupported assets, and test restoration through exercises.
Prioritize by risk reduction per unit of effort and by operational feasibility. Treatments that need an outage should be scheduled into planned turnarounds rather than competing with production.
Common mistakes
- Letting a vulnerability scan or monitoring report stand in for the risk assessment.
- Scoring likelihood with invented probabilities that nobody can defend.
- Ignoring non-cyber safeguards, or crediting them without checking they still work.
- Running the assessment without operations and engineering in the room.
- Producing a register with no owners, so findings age quietly until the next audit.
Where to start
Choose one site or process area with real consequences, agree the risk criteria, and run a short workshop that names the five to ten outcomes that must not happen. Trace the cyber paths to those outcomes, verify them against the actual network, and turn the results into a first register and a ninety-day action list. That first pass builds the shared language between engineering and security that every later assessment depends on.