OT cybersecurity risk is assessed by describing credible scenarios in which a threat exploits a weakness, estimating the operational consequence and its likelihood given existing safeguards, and recording a rating with its rationale. The point is not a precise number. It is a consistent, explainable basis for deciding what to do first.
This guide describes a practical approach that engineering, security and management can all follow.
Start with risk scenarios
A scenario is a short story: who or what could cause harm, how, against which asset, and with what result. For example:
Malware introduced through a vendor laptop spreads to engineering workstations in the control zone and prevents operators from using HMIs, forcing a controlled shutdown of the line.
Good scenarios are specific to your environment and grounded in realistic entry points — remote access, removable media, IT/OT connections, supply chain and insider error. Write down the assumptions behind each scenario, such as "the vendor laptop is not scanned before connection". Assumptions are where reviews often find errors.
Consider operational impact
OT consequences are physical and operational. Define the categories that matter to your organization, for example:
- Health and safety — injury or loss of life.
- Environment — releases or permit breaches.
- Availability — lost production or service interruption.
- Integrity — incorrect control, quality defects or equipment damage.
- Confidentiality — loss of sensitive process or business data.
- Regulatory and reputational consequences.
Use a defined scale for each category, ideally aligned with your corporate risk matrix so OT cyber risks can be compared with other business risks.
Where safety consequences are possible, coordinate with your process safety function. Safety studies such as HAZOP and LOPA describe engineered safeguards that are relevant to cyber scenarios, and the safety function remains responsible for safety analysis.
Weigh asset criticality
Criticality reflects how much the organization depends on an asset. A compromised controller on a non-critical utility has a different consequence than one controlling a reactor. An asset inventory with criticality ratings makes this step faster and more consistent.
Account for existing safeguards
Before rating a scenario, list what already reduces it:
- Preventive controls — segmentation, access control, hardening.
- Detective controls — monitoring and alarms.
- Engineered safeguards — safety instrumented systems, mechanical protection, manual overrides.
- Procedural controls — supervision of vendor access, change approval.
Credit only safeguards you have evidence for. A safeguard that exists on paper but is not maintained should not reduce the rating.
Estimate likelihood and impact
Use agreed scales — commonly three to five levels — with clear definitions. Likelihood in OT is hard to estimate statistically, so it is usually judged from factors such as exposure, ease of exploitation, threat interest and safeguard strength. Write down the reasoning; a rating without rationale cannot be reviewed or challenged.
Be honest about what the result is. Ratings are structured expert judgments, not measurements. Their value is consistency and transparency.
Choose risk treatment options
For each significant risk, decide on a treatment:
- Reduce — add or strengthen controls.
- Avoid — remove the cause, for example retiring an unnecessary connection.
- Transfer — shift part of the consequence, for example through contracts or insurance, where appropriate.
- Accept — document a decision to tolerate the risk, by someone with authority to do so.
Practical treatment often combines quick interim measures with longer-term fixes tied to planned outages.
Use compensating controls
When the ideal fix — usually a patch or upgrade — cannot be applied yet, compensating controls reduce risk in the meantime. Examples include restricting network access to the affected device, disabling an unused vulnerable service, tightening remote access, adding monitoring or increasing procedural supervision. Document them and their intended duration so they are revisited.
Prioritize the results
Sort risks by rating, then refine the order with practical factors:
- Effort and cost of treatment
- Whether an outage is required
- Dependencies between actions
- Quick wins that reduce several risks at once
The result is a roadmap that reflects risk and operational reality, rather than a list sorted by finding count or CVSS score.
Assign ownership and review
Each risk needs an owner who decides on treatment and accepts residual risk. Review the register:
- Periodically, at least annually
- After significant changes to systems or architecture
- After incidents or relevant new threat information
- When treatment actions are completed
Key takeaways
- Build specific scenarios with stated assumptions.
- Define consequence categories in operational terms.
- Credit only safeguards you can evidence.
- Treat ratings as structured judgments and record the rationale.
- Combine interim compensating controls with planned fixes.
- Give every risk an owner and a review date.
For how risk assessment fits within a wider assessment, see A practical guide to OT cybersecurity assessments. For the IEC 62443 approach to risk and security levels, see Understanding IEC 62443.