OT Incident Response Checklist
When an incident reaches the plant, safety comes before evidence. A checklist for ICS and OT incidents: who can stop the process, engineering on the team, no scanning of fragile devices, HMI, historian and engineering-workstation evidence, IT/OT boundary isolation, manual operations and restoring logic from known-good.
Template & sample only — a structured starting point with sample content, not legal, audit, certification or investment advice.Customise it with your own details for free; exporting the generated document is part of Pro.
A response checklist for incidents that touch industrial control systems, where safety and continuity come before evidence. It starts with who can stop the process, brings engineering in before anyone touches a controller, contains at the IT/OT boundary, preserves HMI, historian and engineering-workstation evidence without scanning fragile devices, restores logic only from known-good copies, and ends with sector and national reporting. Mark each step and the page builds an incident record.
Your context
1. Safety first
In an industrial incident the first question is not "what did the attacker do" but "is the process safe, and who can stop it".
Confirm who has authority to stop, slow or hand-run the process, and that they are reachable nowmaterial
Ask operators whether the process is behaving normally: alarms, setpoints, valve and pump states, HMI values that do not match the fieldmaterial
Confirm the safety instrumented system (SIS) is healthy and has not been bypassed, put into program mode or changedmaterial
Check manual operation is possible for the critical units: staff, procedures, local controls, and how long it can be sustained
2. Bring in engineering and operations
Form a joint team: incident commander, control engineers, operations, process safety, IT security and the OT vendor or integrator where neededmaterial
Freeze all non-emergency changes to control systems and suspend vendor remote sessions until reviewed
Agree a communication path to the control room that does not depend on systems that may be compromised (radio, phone tree)
3. Contain at the IT/OT boundary
Contain at the boundaries first; the plant floor is the last place to cut cables.
Decide whether to cut or restrict the IT/OT connection (DMZ firewall rules, remote access), with operations agreeing what will stop workingmaterial
Disable remote access into OT: vendor VPNs, jump hosts, remote-desktop tools, cellular modemsmaterial
Do not run active scans, vulnerability scanners or aggressive endpoint tools against controllers, safety systems or legacy devicesmaterial
Contain inside OT by zone and conduit where needed, following the plant network design rather than ad-hoc unplugging
4. Preserve OT evidence
Collect what you can without touching the process.
Preserve the engineering workstations: isolate from the network but keep powered on; capture memory and disk with the control engineer presentmaterial
Preserve HMI and SCADA server logs, alarm and event journals, and operator action logs before they roll over
Preserve historian data for the incident window: process values, gaps and any edits or deletions
Pull the running logic and configuration from controllers (read-only) and compare with the last known-good version
Keep network captures and firewall logs from the IT/OT boundary and inside OT
5. Recover from known-good
Restore logic and configuration only from verified known-good copies (offline backups, version-controlled projects), checked by hash or comparisonmaterial
Rebuild engineering workstations, HMIs and historians from clean media; do not reuse a machine that may hold attacker tools
Change OT passwords and shared accounts, including default and vendor accounts, before reconnecting anything
Reconnect IT to OT only when the IT side is shown to be clean, with tighter rules than before and monitoring in placematerial
Run a staged restart and functional test with operations and safety sign-off before full production
6. Report and learn
Report to the right authorities: national CERT or CISA, sector regulator, and any mandatory reporting regime for critical infrastructureCISAmaterial
Report any safety or environmental impact through the normal safety and environmental reporting routes as well
Hold a joint IT/OT post-incident review and feed the findings into zones and conduits, remote access and backup of logicIEC 62443
What this template gives you
- Six phases: safety first, bring in engineering and operations, contain at the IT/OT boundary, preserve OT evidence, recover from known-good, report and learn.
- Built around rules IT playbooks miss: operations decides on the process, never disable a safety system to contain, never scan fragile controllers, and keep engineering workstations powered on for evidence.
- Sample values show a fictional utility where ransomware on IT reached the historian. Replace them with your own and the page builds an incident record.
- Reporting guidance is phrased by regime and sector; check deadlines with counsel for your country.
Frequently asked questions
How is OT incident response different from IT incident response?
The priorities are reversed. In IT you often trade availability for containment and evidence. In OT, stopping or disturbing the process can injure people, damage equipment or harm the environment, so safety and controlled operation come first and evidence collection works around them. Operations and control engineers decide what happens to the process; security advises.
Should we scan the OT network to find the attacker?
Not with active scanners. Many PLCs, RTUs and older devices can fault or stop when scanned. Use passive network monitoring, existing OT security sensors, logs from firewalls and the engineering workstations, and vendor-approved tools used with the control engineer present.
Should we disconnect the plant from the IT network?
Often yes, and early, when the attack is on the IT side. But know what the link carries first: production reporting, recipe or batch downloads, licence servers, time sync and remote vendor support may stop. Agree the consequences with operations, then cut decisively. The Safe-to-Isolate Matrix helps plan this per asset.
Who do we report an OT incident to?
It depends on country and sector. In the US, CISA takes reports from critical infrastructure owners and some sectors have their own rules. In the EU, entities in scope of NIS2 send an early warning within 24 hours, a notification within 72 hours and a final report within one month. Safety and environmental incidents also go through their usual routes. Check with counsel.
Is this a finished document I can rely on?
No. Every tool in this suite is a template with sample content. It gives you a structured, editable starting point and generates a document from your own answers, but it is not legal, audit, certification, investment or professional advice. Review and adapt the output, and have it checked by the appropriate specialist before you rely on it.
Who can use it?
Anyone. Using it and customising it with your own details is free, and your work is saved in your own browser. Exporting the generated document (Word, PDF, Markdown, CSV) is part of any PlayCISO paid plan.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.