# OT / ICS Incident Response Plan: Safety First, Then Containment, Then Evidence

> How incident response changes when industrial control systems are involved: who has authority over the process, how to reach a safe state, when it is safe to isolate each kind of OT system, and how to recover controllers from known-good copies.

Source: https://playciso.com/blog/ot-incident-response-plan · Published: 2026-10-29 · Publisher: PlayCISO (https://playciso.com)

---

When industrial control systems are involved, the order changes: **safety first, then a safe operating state, then containment, then evidence.** Operations, not security, holds authority over the physical process, so an OT incident is run jointly. Security brings containment and investigation; the plant decides anything that touches the process. Actions that are routine in IT, like rebooting a server or scanning a subnet, can trip a controller. This guide is the OT / ICS playbook in the [master plan and playbooks](/blog/incident-response-plan-topology) structure; the [incident response hub](/incident-response) has the rest. ## How is OT incident response different from IT? - Safety outranks everything. A wrong containment step can create a physical hazard. - Availability usually outranks confidentiality. The plant may need to keep running while you investigate. - Systems are old and fragile. Many cannot be patched, rebooted on demand or run endpoint agents. - Vendors and integrators matter. They may hold the only engineering knowledge, and sometimes remote access. - Evidence comes later. Collect what you can without disturbing the process. ## Who is in charge during an OT incident? Agree this in writing before an incident. A workable split: - Incident commander (master plan): runs the incident, the log, communications and the clocks. - Plant or operations manager: final authority over anything that affects the process, including isolation, shutdown and restart. - Process safety: advises on safe states and confirms safety systems are working. - Control systems engineering: knows the logic, the devices and what can be touched. - Security: containment options, investigation and evidence, advising rather than acting alone inside the control network. ## What should you do first? - Confirm the process is safe, using independent readings: local gauges, field checks or a separate system, not just the HMI, which may be what was compromised. - Declare under the master plan, with operations and engineering in the room. - Stop the spread at the IT/OT boundary. Tighten or cut connections through the industrial DMZ; disable remote access paths, including vendor access, until reviewed. - Do not scan the control network actively. Use passive monitoring, asset inventories and device logs. - Decide isolation system by system (next section). - Collect evidence without disturbing the process: network captures from span ports, logs from historians and engineering workstations, copies of controller logic. The [OT Incident Response Checklist](/tools/ot-incident-response-checklist) has each step with owners and sample answers. ## When is it safe to isolate an OT system? It depends on the system’s role and what depends on it: - Historians and reporting servers (usually in the DMZ or upper levels): generally safe to isolate; the process keeps running, though you may lose visibility and reports. - Engineering workstations: usually safe to isolate, and a priority, because they can change controller logic. - HMIs and supervisory (SCADA) servers: isolate only when operators have a manual fallback or a clean alternative view of the process. - Controllers (PLCs, RTUs): operations and engineering decide. Cutting their network may be safe or may stop the process, depending on design. - Safety instrumented systems: never changed or isolated without process safety approval. If there is any sign they were targeted, treat it as a top-severity safety event. The [OT Safe-to-Isolate Matrix](/tools/ot-safe-to-isolate-matrix) maps your own systems by role and level and records who must approve each isolation. ## What if ransomware hits the IT side or the historian? This is the most common OT incident. The control systems are often untouched, but the plant still stops: because systems it depends on (scheduling, shipping, billing, the historian) are down, or because nobody can be sure the IT/OT boundary held. Decide quickly and deliberately: can the process run safely with the boundary cut and IT unavailable, and for how long? Tested manual procedures make this a real option rather than a hope. The [Historian Ransomware OT Lab](/tools/historian-ransomware-ot-lab) rehearses exactly this decision, and the [OT downtime calculator](/tools/ot-downtime-calculator) puts a cost on each hour of stoppage for the executive conversation. ## How do you recover controllers safely? - Keep known-good copies of controller logic, configurations and firmware versions, stored offline, with hashes. - Compare the running logic on each controller with the known-good copy before trusting it. - Verify firmware against the vendor’s published versions. - Rebuild engineering workstations and HMIs from clean images rather than cleaning them. - Restart under engineering supervision, with process safety sign-off, one area at a time. ## Which reporting rules apply? OT operators are often in regulated sectors with their own reporting rules. In the EU, NIS2 covers energy, transport, water, manufacturing and other sectors, with an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within one month. Sector regulators in the US, Australia and elsewhere have their own requirements and timelines. Map them with counsel in advance and keep them in the master plan’s clocks table. ## What should be ready before an OT incident? - An asset inventory that says what each device does, where it sits and who owns it. You cannot decide isolation for a system you cannot name. - Offline, hashed copies of controller logic, configurations and HMI projects, refreshed after every engineering change. - Tested manual operating procedures for running or safely stopping each area without the HMI or IT systems. - A map of IT/OT connections and remote access paths, including vendors, so the boundary can be cut in minutes. - A joint tabletop with operations, engineering and security at least once a year. ## Checklist: OT incident response - Process confirmed safe using independent readings. - Incident declared with operations, engineering and process safety in the room. - Authority split recorded: who decides isolation, shutdown and restart. - IT/OT boundary tightened; remote and vendor access disabled pending review. - No active scanning of control networks. - Isolation decided per system and approved by the right owner. - Evidence collected passively: captures, historian and workstation logs, logic copies. - Controller logic compared with known-good copies before restart. - Sector reporting clocks added to the master plan’s table. - Restart staged and supervised, area by area. For the threat side, the [ICS attack threat model](/tools/ics-attack-threat-model) and the [SCADA HMI attack lab](/tools/scada-hmi-attack-lab) show what attackers do once they reach the control network. ## Frequently asked questions **How is OT incident response different from IT incident response?** In IT the usual priorities are confidentiality, integrity and availability, and containment often comes first. In OT, human safety and the physical process come first: an action that is routine in IT, such as rebooting a server or scanning a network, can disrupt a controller or a running process. OT response is run jointly with operations and engineering, who hold authority over the process. **Who is in charge during an OT cyber incident?** The incident commander under the master plan runs the incident, but the plant or operations manager holds authority over anything that affects the physical process, and process safety specialists advise on safe states. Security advises on containment and evidence. Agree this split in writing before an incident, not during one. **Should we shut down the plant during a cyber incident?** That is an operations decision based on safety and on whether the process can be run and monitored reliably. Many shutdowns are precautionary: the plant stops because the IT systems it depends on are unavailable or because the boundary with IT cannot be trusted. A pre-agreed decision matrix and tested manual operating procedures make the call faster and safer. **Can you run a vulnerability scan on an OT network during an incident?** Avoid active scanning of control networks unless engineering has confirmed the devices tolerate it. Some controllers and older devices can fault or stop when scanned. Use passive monitoring of network traffic, asset inventories and device logs instead.