OT incident response: when you cannot just isolate the system

The first instruction in most incident response plans is to contain, and in an operational environment that instruction can be dangerous. Disconnecting a controller, isolating a network segment or shutting down a workstation may remove an operator's visibility of a physical process that is still running.

The inversion

IT response prioritises confidentiality and containment. OT response prioritises safety, then availability. That reorders almost every step:

• Isolation may be unsafe, so it is a decision for operations rather than security.
• Powering down for imaging may be impossible on a running process.
• Restoring from backup may require a controlled shutdown and restart sequence measured in days.
• Patching as remediation is constrained by vendor certification.

The decisive question in an OT incident is not "how do we stop the attacker?" but "can we continue to operate this process safely while we find out?" Security does not own that answer.

Authority must be settled in advance

The single most valuable preparation is agreeing, before anything happens, who can authorise what:

• Who can order a process shutdown, at any hour, and what is the escalation if they are unreachable?
• Who decides to disconnect the OT network from IT - and is that link even designed to be severed cleanly?
• Who declares that operations may continue while an investigation runs?

Improvising these at 3am with a plant manager and a security lead who have never spoken produces the delays that turn an incident into an outage.

Detection differs too

Endpoint agents often cannot be installed on control systems, and active scanning has knocked over fragile devices. Detection therefore leans on passive network monitoring at the boundary and on process anomalies - a setpoint that changed without a corresponding work order, a controller that rebooted unexpectedly, a value that does not match physical reality.

That last category matters: operators frequently notice something wrong before security tooling does, so the reporting route from the control room to the security team must exist and be used.

Forensics under constraint

You often cannot take an image, cannot power down, and cannot install tooling. What you can usually do: capture network traffic at the boundary, export controller logs and configuration, photograph HMI screens and physical indicators, record operator observations with timestamps, and preserve engineering workstation artefacts - the workstation is frequently the actual entry point and is usually a normal Windows machine you can treat normally.

Recovery

Rebuilding a controller means restoring a validated configuration, not reinstalling an OS. That requires having current configuration backups - which many sites do not, because the configuration lives only on an engineering laptop. Verify you hold them before you need them, and store them where a compromised IT network cannot reach.

Exercise the realistic scenario

The scenario worth rehearsing is not a dramatic attack on a controller. It is an IT-side compromise - ransomware in corporate, credentials stolen - forcing a decision about whether operations can safely continue, under uncertainty, with a regulator to notify and a public to inform. Several major disruptions involved no compromise of control systems at all; operations stopped because nobody could prove they were unaffected.

Key takeaways

• Safety and availability outrank containment - isolation is an operations decision.
• Settle shutdown and disconnection authority before an incident.
• Forensics means network capture, logs and configuration, not imaging.
• Rehearse the IT-compromise scenario that forces an operational decision.