Why incident response fails industrial networks

IT and OT are fundamentally different. For decades, industrial systems developed, became more digitized and automated, and finally, interconnected. A digital development of this kind was never anticipated; industrial networks have been designed to function as air gapped environments. This ensured a physical barrier from external unauthorized access, with no incidents recorded before the Maroochy Shire Sewage attack of 2000. Once they started getting connected to corporate IT networks, the playbook changed. Suddenly, cyberattacks could have physical outputs – the most crucial part of most nations’ infrastructure became exposed.

Industrial and critical infrastructure have never been designed to operate in interconnected environments, therefore lack the protection mechanisms and fail safes that IT environments have

For incident response, the tools, the doctrine, and the playbooks all come from the IT world. In industrial environments, they do not just underperform, they cause further damage and loss of evidence, making recovery almost impossible.

When a breach is detected in a corporate IT environment, the response is almost automatic. Isolate the affected host, kill the process, preserve the disk image, push the remediation. It’s a well established routine. The whole framework, from NIST SP 800-61 to your vendor's MDR runbook, is built around this sequence.

In an OT environment, every one of those steps is a potential operational catastrophe.

Let’s consider isolation. In an IT network, pulling a compromised endpoint offline is containment and prevents the spread or lateral movement of unauthorized access. In an industrial network, that same action can sever a PLC from its supervisory system mid-cycle. The physical process it controls does not pause while you investigate, but fails. These failures and the disruption caused to the industrial process it controls can have catastrophic consequences that endanger the integrity of the process, as well as the lives of all those affected by this process.

"Contain and remediate" is a doctrine written for systems that can tolerate downtime. Industrial systems cannot, they were designed to work non-stop for decades, shutting them down is not a simple emergency process, but a procedure that takes planning, preparation and security measures, often lasting days. Applying IT incident response to such environments can further exacerbate the consequences of an incident and hinder your ability to respond.

The forensics problem is just as severe. Standard IR procedures assume you can acquire volatile memory, collect logs, and image the affected drive without disrupting the system. In OT environments, that assumption collapses. Many PLCs and RTUs have no logging capability at all. Others run proprietary operating systems that commercial forensic tools cannot read. And critically, the act of connecting an incident response tool to an industrial network introduces traffic that the environment was never designed to handle. That way, instead of collecting the evidence, you destroy it.

This is not a staffing problem or a budget problem. It is an architectural one. Industrial networks were built for deterministic, real-time control. They were not built for the nearly automated “contain and remediate” process that is well established in IT. Retrofitting one onto the other, without understanding the underlying physics and process dependencies, can produce incidents more severe than the original attack.

The answer is not faster incident response. It is continuous, passive visibility into what is normal, so that when something deviates, you know before the incident ever escalates to the point where comprehensive incident response becomes necessary. By having full visibility over your systems, the network traffic and an automated response to block unauthorized access, you can prevent intrusions that cause downtime in systems that cannot stop.

Prevention does not fail the way response does. In industrial environments, stopping the attack on time is the difference between an alert and a complete shutdown. Between a simple security protocol improvement and a potential disaster.

Cyber resilience is not optional.