OT Ransomware Response Playbook Template

When ransomware hits the business network of a plant, pipeline or utility, the hardest decision is not technical: it is whether to keep the physical process running, island it, or shut it down. In several of the best known cases the production outage came from that decision rather than from encrypted controllers. This template gives [Organisation] a ready-to-adapt playbook for IT ransomware that threatens operational technology (OT), and for ransomware that reaches Level 2 and 3 hosts such as HMIs, historians and engineering workstations. It sits beside the OT Incident Response Guide, which explains OT response principles, and the generic Ransomware Playbook Template, which holds the enterprise ransom decision and legal workstream.

How to use this template

Agree the decision table before an incident: section 4.1 is the core of this playbook. Fill it in per site with operations and safety, and sign it off at plant manager level. A table drafted during the incident will be argued over while the encryptor runs.
Run it alongside the IT playbook: IT declares the ransomware incident; the OT Incident Lead opens this playbook as a parallel workstream with its own decision log.
Keep it offline: print it with the site dependency map (section 1.3), contact list and manual operating procedures. Assume email, Teams, the CMDB and the document management system are unavailable.
Owner and review: [Head of OT Security] with [Head of Operations], reviewed every [12] months, after every exercise and after any change to the IT/OT boundary.

1. Scope and triggers

1.1 This playbook covers ransomware or destructive malware that (a) is active in [Organisation]'s corporate IT network and could reach OT through a conduit, shared identity or shared service, or (b) is present on OT hosts at Purdue Levels 2 and 3, including HMIs, SCADA servers, historians, engineering workstations and OT jump hosts. Ransomware on the virtualisation layer also uses the ESXi Ransomware Playbook.

1.2 Triggers (any one opens this playbook):

Trigger	Typical source	ATT&CK v20
IT declares a ransomware incident at any severity on a site with an IT/OT conduit	IT incident manager	T1486 Data Encrypted for Impact
Encrypted files or ransom notes on an OT DMZ or Level 3 host (historian, patch server, jump host)	Operators, OT EDR, file integrity monitoring	T1486; T1490 Inhibit System Recovery
HMI screens frozen, blank or replaced, operators unable to see or command the process	Control room	T0815 Denial of View; T0813 Denial of Control
OT services stopped in bulk (historian, OPC, SCADA services) outside a change	OT monitoring, Windows service events	T0881 Service Stop
Use of a vendor, VPN or shared domain account inside the OT DMZ that does not match a ticket	Remote access logs, OT network monitoring	T0822 External Remote Services; T0859 Valid Accounts
Loss of a business system the process depends on (ordering, batch records, billing, shipping)	Operations, business owners	T0828 Loss of Productivity and Revenue

1.3 Dependency map (complete per site before use). List every IT service OT needs to run, and what happens without it: Active Directory and DNS for OT logins, licence servers, NTP, the historian and its IT replica, patch and antivirus update servers, MES and ERP interfaces, batch records, laboratory systems, and shipping or custody transfer systems. Mark each as "process stops", "process runs degraded for [x] hours" or "no impact".

2. Roles and contacts

Role	Named owner	Responsibilities in this playbook
Operations Decision Owner (shift manager or plant manager)	[Name, deputy, 24/7 number]	Owns the run, island, manual or shutdown decision and the restart decision. Security advises; it does not override.
OT Incident Lead	[Name, deputy]	Runs this playbook, keeps the OT decision log, links to the IT incident manager
Process and Safety Engineer	[Name per site]	Confirms safe states, safety instrumented system (SIS) independence and the impact of cutting each path
IT Incident Manager	[Name]	Enterprise containment, identity and backup workstreams, legal and insurer contact
OT network and identity engineer	[Name]	Conduit firewall rules, OT domain or local accounts, vendor access disablement
Integrators and OEM support	[Company, contract, phone]	System-specific guidance, rebuild media, controller logic support
Forensic retainer	[Firm, contract number]	Evidence capture on Windows OT hosts without touching Level 0 to 1 devices

2.1 Communications. Use the out-of-band channel listed here: [phone bridge number, radio channel, satellite phone]. CISA advises coordinating containment out of band because attackers who see their access being cut may deploy ransomware more widely. This matches ATT&CK for ICS mitigation M0810 Out-of-Band Communications Channel.

3. Detection and triage

Establish where the encryptor is: IT only, OT DMZ, Level 3, or Level 2. Ask the control room directly whether operators can see and control the process, and whether any alarms behave unusually.
Check the conduit: pull the last [72] hours of firewall logs for the IT/OT boundary and the OT DMZ. Look for new sessions from IT subnets, SMB or RDP across the boundary, and remote access sessions by vendor or shared accounts.
Check shared identity: if OT hosts are joined to the corporate domain or trust it, treat OT as exposed even if the firewall looks clean. Credentials, group policy and software deployment tools cross boundaries that firewall rules do not show.
Confirm the safety layer: the Process and Safety Engineer confirms the SIS is independent of the affected networks and is healthy.
Score the situation against the decision table in 4.1 and record the score, time and decision owner in the OT decision log.

3.1 Evidence to preserve: firewall and remote access logs, Windows Security and System logs from OT DMZ and Level 3 hosts, memory captures of affected Windows OT hosts before power-off where safe, ransom notes and screenshots of HMI screens, and a list of controller program versions read without change. CISA's ransomware guide treats powering off as a last resort because it destroys volatile memory; in OT, safety can override that, and the log should say so.

4. Containment

4.1 Decision table. Adapt per site. The default for any unproven boundary is to restrict, not to trust.

Situation	Default action	Who decides	Conditions before acting
A. Ransomware in IT only; conduit logs clean; OT runs without IT services	Island: close the IT/OT conduit to [named exceptions only]; keep the process running	OT Incident Lead with Operations Decision Owner	Dependency map shows no "process stops" items; time source and safety comms confirmed local
B. Ransomware in IT; conduit or shared identity cannot be proven clean	Island immediately and hunt; prepare manual operation	Operations Decision Owner	Manual procedures staffed and ready; SIS confirmed independent
C. Ransomware in OT DMZ or Level 3 (historian, jump host, patch server)	Island the site; isolate the DMZ; keep Level 2 and below running if HMIs are healthy	Operations Decision Owner	Operators retain view and control from unaffected HMIs
D. Ransomware on HMIs or SCADA servers; view or control lost on some screens	Fail over to redundant or local HMIs; move affected units to manual; isolate affected hosts	Operations Decision Owner with Process and Safety Engineer	Redundant HMIs on a separate segment and confirmed clean
E. View or control lost and cannot be restored quickly, or SIS health uncertain	Controlled shutdown to a safe state	Operations Decision Owner (plant manager)	Follow the unit's normal shutdown procedure, not an improvised one
F. OT unaffected but a business system the process needs is down (billing, custody transfer, batch records)	Business decision to reduce or stop production; record it as a business, not a safety, decision	[Executive role]	Legal and commercial input recorded

4.2 Row F is the Colonial Pipeline pattern: the Colonial Pipeline ransomware attack stopped fuel flow for about six days in May 2021 because the company shut down the pipeline to contain an IT intrusion, not because attackers operated pipeline controls. Similarly, the Jaguar Land Rover cyberattack began with a proactive shutdown of systems and production was halted for more than five weeks.

4.3 Containment actions (in order, once the decision is made):

Apply the pre-staged "island" rule set on the IT/OT firewall, leaving only the exceptions named in [annex]. Test the rule set in each annual exercise.
Disable all vendor and remote access paths into OT, and the VPN or jump host accounts that use them. See the OT Remote Access Guide.
Disable domain trust or synchronisation between corporate and OT directories; switch OT logins to pre-staged break-glass local accounts held in the site safe.
Stop software deployment, patching and antivirus update channels that originate in IT.
Isolate affected OT Windows hosts at the switch port rather than by power-off where the process allows.

5. Eradication

Find the path in: identify the systems and accounts used for initial access and lateral movement into OT. Common paths are remote access accounts without MFA (ATT&CK T1133 External Remote Services, T1078 Valid Accounts), dual-homed hosts and shared domain credentials.
Rebuild, do not clean: reimage affected HMIs, historians and engineering workstations from offline golden images held per [site]. Do not trust a decryptor's output on a control system without full validation.
Check controllers without changing them: compare PLC and controller programs and firmware against offline hashed known-good copies, using the vendor's read or compare function. Do not run active scans against Level 0 to 2 devices.
Reset credentials after rebuild: CISA advises resetting passwords only after the environment is cleaned. Rotate OT local administrator, service, historian interface and vendor accounts, and any shared credential found in scripts or HMI projects. See the Identity for OT Environments Guide.
Close the gap: fix the conduit rule, dormant account or dual-homed host that allowed spread before reconnecting anything.

6. Recovery

Restore order: safety and protection systems checks first, then Level 2 control (HMIs, SCADA servers), then Level 3 (historian, engineering workstations), then the OT DMZ, then the IT conduit last.
Validate backups first: NIST CSF 2.0 RC.RP-03 requires the integrity of backups and restoration assets to be verified before use. Restore from offline copies taken before the earliest known attacker activity, and check hashes.
Recover into a clean segment: CISA recommends adding only verified clean systems to a recovery VLAN to avoid reinfection.
Test with operators: functional tests of alarms, trends, interlocks and commands with the Process and Safety Engineer present.
Restart in stages under the Operations Decision Owner's sign-off, unit by unit.
Reconnect IT through the conduit with the minimum rule set, after the IT incident manager confirms the enterprise side is clean, and with enhanced monitoring for [30] days.
Rollback: if anomalies reappear after reconnection, return to the island rule set (4.3 step 1) and the last safe operating mode.

7. Communication and notification

Audience	Owner	When	Notes
Control room and site staff	Operations Decision Owner	At each mode change	Plain instruction: current mode, what not to touch, who to call
Executive team	IT Incident Manager and OT Incident Lead	Within [1] hour, then every [4] hours	State OT status separately from IT status
CISA (US)	[Role]	As soon as practicable	Incident reporting form or 24/7 line (888) 282-0870
EU NIS2 competent authority or CSIRT	[Role]	Early warning within 24 hours, notification within 72 hours, final report within one month	Applies to essential and important entities under NIS2 Article 23 as transposed nationally
Sector regulator, ISAC, insurer, law enforcement	[Role]	[Per contract and law]	Insurer and legal counsel before any contact with the attacker
Customers and supply chain	[Communications lead]	When production or delivery is affected	Agree wording with legal; do not speculate on cause

7.1 Ransom payment questions follow the enterprise process in the Ransomware Playbook Template and the Ransomware Payments and Sanctions Guide.

8. Post-incident review

8.1 Within [10] working days, hold a joint IT, OT and operations review using the Post-Incident Review and Root Cause Analysis Template. Cover at least:

Decision timing: time from IT detection to the OT decision, and whether the decision table gave a clear answer.
Dependency surprises: any IT service that the map in 1.3 did not show.
Manual operation: how long the site ran manually and what failed.
Recovery assets: whether golden images, logic backups and break-glass accounts worked first time.
Path in: the account, conduit or host that allowed exposure, and its fix owner and date.

Implementation guidance

Map dependencies first (weeks 1 to 4): complete section 1.3 for every site.
Pre-stage the island: build and test the firewall rule set, break-glass local accounts and offline copies of procedures. CISA, FBI, EPA and DOE list segmenting IT and OT and practising manual operation among their primary OT mitigations.
Sign the decision table with operations and safety at each site.
Exercise it: a tabletop for each row of 4.1, then an annual live island test in a planned window, with a timed rollback to normal.
Small sites: one person may hold several roles; the decision table and island test matter more than the full role list. Large multi-site operators should run one OT lead per site with a central coordinator.

Measures that show the playbook works:

Percentage of sites with a signed decision table and a dependency map reviewed in the last 12 months.
Time to apply the island rule set in the last exercise (target [15] minutes).
Hours each site can run with the IT conduit closed, as proven in an exercise.
Percentage of HMIs, historians and engineering workstations with a golden image restored successfully in the last 12 months.
Number of OT accounts that depend on the corporate domain (target falling to zero for Level 2 and below).

Playbook activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ATT&CK for ICS mitigation
Decision table, roles, exercises	RS.MA-01	IR-8 Incident Response Plan; IR-4 Incident Handling	M0810 Out-of-Band Communications Channel
Island and isolate	RS.MI-01	IR-4	M0930 Network Segmentation
Rebuild and credential reset	RS.MI-02	IR-4	M0953 Data Backup
Verified restore and staged restart	RC.RP-01; RC.RP-03	CP-2 Contingency Plan; CP-9 System Backup; CP-10 System Recovery and Reconstitution	M0953 Data Backup
Notification	RS.CO-02	IR-4	Not applicable

OT Ransomware Response Playbook: Deciding Whether to Isolate, Island or Shut Down