The short answer
OT Risk Assessment
An operational technology risk assessment lists the consequences a utility cannot accept, identifies the control system assets and scenarios that could produce them, estimates how likely each scenario is given the current controls, and ranks the results so that the utility spends its effort on the risks that matter. It is consequence-first: the question is what happens to the process, the public, and the environment, not which vulnerability is newest. The output is a ranked list of risks with an owner and a treatment for each, reviewed on a schedule and after any change.
Key points
- Start from consequences: overflow, loss of supply, a treatment violation, an injury. Work back to the assets that could cause them.
- A scenario is an asset, a cause, and a consequence. Assess scenarios, not devices.
- Likelihood is a judgment. Express it in bands, from the current controls, and say why.
- The matrix ranks; it does not decide. The utility decides what it will tolerate.
- The deliverable is a work plan with owners, not a report.
What the assessment is for
A utility has limited people, time, and money for cybersecurity, and a long list of things it could do. The risk assessment is how it chooses. It asks, for each way the control system could be misused or fail, what would happen and how likely it is, and it ranks the answers so the measures that address the worst realistic outcomes come first. Done well, it is a few days of structured conversation among the people who run the plant, and it produces a work plan. Done badly, it is a consultant report with a hundred findings of equal weight that nobody reads twice.
The frameworks agree on the shape. IEC 62443-3-2 describes a zone-based risk assessment that assigns target security levels; the NIST framework calls for identifying and prioritizing risk; the water sector risk and resilience assessments required under federal law include cyber risk in the same structure as physical and natural hazards. The method below fits all of them and is sized for a utility.
Consequence first
The assessment starts with what the utility cannot accept. That list is short and the people who run the plant already know it.
| Consequence category | Examples | Typical severity bands |
|---|---|---|
| Public health | Under-disinfected water reaching customers; a chemical overfeed; a cross connection from negative pressure | Severe for any confirmed exposure; major for a boil water notice |
| Environmental | A sanitary sewer overflow; a treatment plant bypass; a chemical release | Severe for a large or repeated release; major for a reportable one |
| Loss of service | A zone without pressure; a plant unable to produce; a lift station down for a day | Major for loss of supply; moderate for reduced pressure |
| Safety | A chlorine gas release; an operator injured by equipment starting unexpectedly | Severe for any injury |
| Regulatory and financial | A permit violation; fines; recovery costs; a ransom | Moderate to major |
| Reputation | Public loss of confidence | Follows the others |
Each category gets a severity scale with three to five bands and a definition for each band in terms the utility uses. Those definitions are what make two people assess the same scenario the same way.
Assets and scenarios
- 1
List the assets
From the asset inventory: controllers, HMIs, servers, network devices, remote access paths, instruments that a controller trusts, packaged systems. Group them into zones if the zone drawing exists; if it does not, the assessment is where it gets drawn.
- 2
Write the scenarios
For each consequence, the ways the control system could produce it: a setpoint changed on the chlorine feed by someone with SCADA access; a lift station controller with its program erased; a ransomware infection on the SCADA server; a vendor laptop introducing malware; a radio network jammed; an insider with shared credentials. A scenario names the asset, the cause, and the consequence. Twenty to fifty scenarios cover a utility.
- 3
Note the existing controls
For each scenario, what currently prevents it or limits it: the firewall, the float backup, the manual operation, the keyswitch, the MFA, the backup. The controls are what the likelihood judgment is made against.
- 4
Judge the likelihood
In bands: rare, unlikely, possible, likely, almost certain, with a definition for each, given the current controls. A scenario that requires physical access to a locked site by a skilled attacker is unlikely; one that requires typing a default password into an internet-reachable HMI is likely. Write the reasoning beside the band; it is what will be argued later.
- 5
Judge the consequence
The worst credible outcome of the scenario, in the severity bands, considering the controls that limit consequence: the float backup that keeps a station pumping even with a dead controller reduces the consequence of the controller scenario from overflow to loss of visibility.
- 6
Place it on the matrix
Likelihood against consequence gives a risk band: low, medium, high, very high. The matrix is agreed before the scenarios are assessed so that the ranking is not adjusted to fit.
The matrix
| Likelihood | Minor | Moderate | Major | Severe |
|---|---|---|---|---|
| Almost certain | Medium | High | Very high | Very high |
| Likely | Medium | High | High | Very high |
| Possible | Low | Medium | High | Very high |
| Unlikely | Low | Low | Medium | High |
| Rare | Low | Low | Medium | Medium |
The utility decides which bands it will not tolerate and must treat, which it will treat as resources allow, and which it accepts. Very high and high are treated; medium is scheduled; low is accepted and recorded. That decision is the risk appetite, it is made by the people accountable for the utility, and it is written down.
From the ranked list to the work plan
Each scenario in the treat bands gets a treatment: a control that reduces likelihood, a control that limits consequence, or both, with a cost, an owner, and a date. Treatments that address many scenarios at once, such as getting devices off the internet, MFA on remote access, and tested backups, rank first because they move the most scenarios down the matrix for the least effort. The plan is the deliverable; the assessment report is its appendix. Progress is reviewed on a schedule, the scenarios are re-assessed after each treatment lands, and the whole assessment is repeated when the system changes materially and at least every few years.
Keeping it honest
- Involve the operators. They know which scenarios are real and which controls actually work at three in the morning.
- Use the incident record. Scenarios that have happened, at this utility or at others like it, are not rare.
- Resist the vulnerability list. A scanner output of two hundred findings is an input to a few scenarios, not two hundred risks.
- Do not rate down to fit the budget. A high risk that the utility cannot afford to treat this year is recorded as high and accepted with a date, not re-scored as medium.
- Write the reasoning. A band without a reason cannot be defended or updated.
Frequently asked questions
- How long does an assessment take at a small utility?
- Two or three working sessions of a few hours each with the operator in charge, the superintendent, and the integrator or the person who maintains the network, plus a day to write it up. The asset inventory takes longer if it does not exist, and it is the first thing to do.
- Do we need a consultant?
- A facilitator who has done it before helps with the structure and the scenario list and keeps the sessions moving. The judgments about consequence and likelihood belong to the utility, and an assessment done entirely by an outside party without the operators in the room misses the controls that matter and overrates the ones that do not.
- How does this relate to the federally required risk and resilience assessment?
- The water sector assessment covers all hazards, including cyber, for utilities above the size thresholds, and the method here produces the cyber portion in a form that fits it. A utility that has done a consequence-first OT assessment has the cyber scenarios, the controls, and the ranked list that the broader assessment asks for.
- What if likelihood is unknowable?
- It usually is, precisely. The bands are a judgment about how easy and how attractive the scenario is given the controls in place, and the reasoning is recorded. The ranking is robust to that uncertainty because the treatments that matter most, the ones that move many scenarios, are the same under any reasonable judgment.
Related topics
- IEC 62443The international standard series for industrial automation and control system security: how it is organized, what security levels and foundational requirements mean, and how a utility or integrator actually uses it.
- Zones and ConduitsThe IEC 62443 way to segment a control system: grouping assets into zones with a shared security level, inventorying every conduit between them, and turning the drawing into firewall rules. With a worked water utility example.
- Small Utility Cybersecurity PrioritiesWhat a utility with a few operators and no IT department should do first: the ten measures that remove most of the risk for the least money and time, in the order to do them, with what each one costs, what it prevents, and how to know it is done.
- Water and Wastewater Utility Threat LandscapeWhat has actually happened at water utilities, what those incidents had in common, and the small number of controls that would have prevented most of them.
- Lift Station Backup ControlHow a lift station keeps pumping when the transmitter, the PLC, or the SCADA link is gone: float backup logic, the control transfer relay, redundant-off protection, and how to test it with the controller actually dead.
- OT Security vs IT SecurityWhy the familiar security priorities invert on a plant floor, and what that changes about patching, scanning, authentication, and incident response.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.