The final part of the series closes the loop: how an alert becomes an assessment, how an assessment becomes an action operators can safely take, and how every incident feeds the next cycle of intelligence.
This is the last part of the series. We have an inventory, adversary profiles tied to it, a collection plan that answers real questions, and detections built on protocol behavior. Now something fires at two in the morning and a control room has to decide what to do.
Response in OT is a negotiation with physics
Enterprise response reflexes do not transfer cleanly. You cannot isolate a controller that is holding a process in a safe state. You cannot reimage a device whose firmware image nobody has. You cannot force a password rotation on an account a turbine skid needs to keep polling. Every containment option carries a process consequence, and the person who understands that consequence is an engineer, not an analyst.
So response has to be built as a joint procedure. The analyst brings the assessment. The engineer brings the safe options. Leadership brings the risk acceptance. The procedure exists so that conversation happens in minutes instead of being invented during the event.
The assessment that makes an alert actionable
An alert becomes decision ready when it carries four things, and the same discipline from part two applies here:
- Observed: the specific evidence, with device, protocol, source, and time
- Assessed: what this most likely represents and the confidence level
- Unknown: what has not been verified yet
- Recommended action: the smallest step justified by the evidence so far
Written that way, an alert stops being a question mark handed to an operator and becomes a proposal that can be accepted, modified, or declined with reasons.
Pre approve the safe moves
Speed comes from decisions made before the incident. For each consequence tier, decide in advance which actions are pre approved and which require engineering sign off. Typical pre approved actions include disabling a specific vendor remote access account, blocking a conduit rule at the boundary firewall, increasing capture depth on a segment, isolating an engineering workstation, and pulling a decoy sensor closer to the suspect segment. Actions that touch a controller, a setpoint, or a protective relay belong in the sign off column, without exception.
Keep an evidence timeline, not a chat log
The single most useful artifact during and after a SCADA incident is a timeline that separates observation from interpretation. Each entry gets a timestamp, the source of the evidence, what was seen, and who saw it. Assessments are recorded as entries too, clearly marked as judgments. This is what makes a regulatory conversation survivable and what lets a later analyst reconstruct why a decision looked correct at the time.
Feed the loop
An incident is the highest quality intelligence your program will ever produce, because it is about your environment specifically. Before closing it out, harvest it:
- Update the inventory with everything the investigation revealed that the records missed.
- Update the relevant adversary profile with observed behavior and revised relevance.
- Add the collection sources you wished you had, and delete the ones that stayed silent.
- Write or tune detections for the behavior that was seen, then validate them safely.
- Retire or rewrite the intelligence requirements the incident answered.
That list is the series in reverse, and that is the point. Threat intelligence for SCADA is not a feed and it is not a report. It is a cycle that ties what you operate to who is interested, what you can see, what you detect, and what you do. Each turn of the cycle should leave the plant measurably harder to operate against than the last one.
Where to start on Monday
If you take one action from these five parts, take this one: pick your three highest consequence devices and write down, honestly, whether you would detect an unauthorized write to any of them today. The answer will tell you which part of this series to work on first.