Develop and implement OT-specific incident response playbooks aligned with SANS PICERL framework, IEC 62443, and NIST SP 800-82 that address unique ICS challenges including safety-critical systems, limited downtime tolerance, and coordination between IT SOC, OT engineering, and plant operations teams.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Develop and implement OT-specific incident response playbooks aligned with SANS PICERL framework, IEC 62443, and NIST SP 800-82 that address unique ICS challenges including safety-critical systems, limited downtime tolerance, and coordination between IT SOC, OT engineering, and plant operations teams.
When building OT-specific incident response procedures for the first time
When existing IT IR playbooks do not address ICS/SCADA-specific requirements
When preparing for OT ransomware scenarios like EKANS or LockerGoga
When aligning IR procedures with IEC 62443 and NERC CIP incident reporting requirements
When conducting post-incident reviews to improve OT IR capabilities
Do not use for IT-only incident response without OT components (use standard NIST 800-61 playbooks), for day-to-day OT security monitoring (see implementing-dragos-platform-for-ot-monitoring), or for tabletop exercise design (see performing-ics-tabletop-exercise).
Common Misconfigurations & Verification
Treating PLCs like Windows hosts. The most damaging IR mistake is powering off or "isolating" running PLCs to contain ransomware — PLCs run firmware, not Windows, and shutting them down disrupts the physical process. Containment isolates the IT/OT conduits at the DMZ, not field controllers; verify the playbook says so explicitly.
No out-of-band comms or offline backups. If the IR plan depends on the same IT network the incident compromised, coordination fails. Confirm out-of-band channels exist and that verified offline PLC/HMI/historian backups exist and restore-test them.
SIS branch missing from the playbook. A separate SAFETY/SIS path (engage process safety, verify physical barriers, never assume false positive) must exist, per TRITON/TRISIS lessons.
Reporting clocks not wired in. CIRCIA 72-hour, NERC 1-hour BES, and sector ISAC timelines are easy to miss under pressure.
Verify without disrupting the process. Validate the playbook through a tabletop and a non-production restore drill — exercise conduit isolation and backup restoration in a lab, never by severing live IT/OT links or shutting controllers on a running plant.
Prerequisites
OT asset inventory with criticality ratings and safety system identification
Defined roles: OT IR Lead, IT SOC Analyst, Plant Operations Manager, Process Safety Engineer
Communication plan including out-of-band channels (OT incidents may compromise IT communications)
Known-good backups of PLC programs, HMI configurations, and historian data
Contact information for ICS vendors, Dragos/Claroty support, and CISA ICS-CERT
Workflow
Step 1: Define OT-Specific Incident Classification and Response Procedures
"""OT Incident Response Playbook Engine.
Implements structured OT incident response procedures following
SANS PICERL lifecycle with ICS-specific considerations for safety,
availability, and cross-team coordination.
"""
import
import
from
import
from
import
from
import
Dict
List
Optional
class
OTIncidentSeverity
Enum
"SEV1-SAFETY"
# Safety system compromise
"SEV2-PROCESS"
# Active process manipulation
"SEV3-ACCESS"
# Unauthorized OT access
"SEV4-RECON"
# Reconnaissance in OT network
"SEV5-IT-SPILLOVER"
# IT incident with OT exposure
class
OTIncidentCategory
Enum
"ransomware"
"malware_ics_specific"
"unauthorized_ot_access"
"process_manipulation"
"safety_system_compromise"
"ot_data_exfiltration"
"supply_chain_compromise"
"insider_threat"
# PICERL phase definitions for OT
"preparation"
"description"
"Readiness activities before an incident occurs"
"ot_specific"
"Maintain offline backups of all PLC programs and HMI configurations"
"Document safe shutdown procedures for each process area"
"Establish out-of-band communication (satellite phone, analog radio)"
"Pre-stage forensic tools that work in air-gapped OT networks"
"Maintain spare PLCs and engineering workstations"
"Conduct quarterly OT tabletop exercises"
"identification"
"description"
"Detect and confirm the OT security incident"
"ot_specific"
"Correlate OT IDS alerts with process anomalies from historian data"
"Verify if process deviations are cyber-caused vs operational"
"Check Safety Instrumented Systems (SIS) status and integrity"
"Review engineering workstation logs for unauthorized access"
Incident Command System for Industrial Control Systems -- adapts FEMA ICS to OT cybersecurity response
Safety Instrumented System (SIS)
Independent safety controller that prevents hazardous conditions; compromising SIS can cause physical harm
Manual/Local Mode
Operating PLCs with local panel controls instead of remote SCADA; used when remote access is compromised
CIRCIA
Cyber Incident Reporting for Critical Infrastructure Act requiring reporting to CISA within 72 hours
Known-Good Backup
Verified, offline copy of PLC programs and configurations used as the trusted baseline for recovery
Common Scenarios
Scenario: Ransomware Spreads from IT to OT Level 3
Context: Ransomware encrypts enterprise IT systems and spreads through an inadequately protected IT/OT conduit to Level 3 historian servers. HMIs at Level 2 begin showing connectivity errors.
Approach:
Activate the OT IR playbook for ransomware immediately
Sever IT-OT connectivity at the DMZ firewall (both north and south firewalls)
Verify PLCs are still running and process is stable (PLCs run independently of IT)
Switch operators to local HMI panels if networked HMIs are affected
Assess which Level 2/3 systems are encrypted vs operational
Prioritize restoring HMI visibility, then historian, then engineering workstations
Restore from offline backups -- never attempt to decrypt using attacker-provided tools without sandbox testing
Report to CISA within 72 hours per CIRCIA requirements
Pitfalls: Do not shut down PLCs to "protect" them from ransomware -- PLCs run firmware, not Windows, and are typically unaffected by ransomware. Shutting down PLCs disrupts the physical process. Never reconnect IT-OT conduit until the IT side is fully remediated.