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

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):

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

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

1. 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.
2. 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.
3. 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.
4. Confirm the safety layer: the Process and Safety Engineer confirms the SIS is independent of the affected networks and is healthy.
5. 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.

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):

1. 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.
2. 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.
3. 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.
4. Stop software deployment, patching and antivirus update channels that originate in IT.
5. 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

1. 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.
2. 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.
3. Recover into a clean segment: CISA recommends adding only verified clean systems to a recovery VLAN to avoid reinfection.
4. Test with operators: functional tests of alarms, trends, interlocks and commands with the Process and Safety Engineer present.
5. Restart in stages under the Operations Decision Owner's sign-off, unit by unit.
6. 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.
7. 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

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

1. Map dependencies first (weeks 1 to 4): complete section 1.3 for every site.
2. 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.
3. Sign the decision table with operations and safety at each site.
4. 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.
5. 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).

Standards and references

• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• CISA: #StopRansomware Guide
• CISA: Report a Cyber Issue
• MITRE ATT&CK for ICS: Loss of Productivity and Revenue
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: OT Incident Response Guide · Ransomware Playbook Template · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide · OT and ICS Identity and Access Guide