OT Incident Response: The First 48 Hours

Why OT IR Is Different

Incident response in an OT environment does not follow the same playbook as enterprise IT. In an IT environment, the primary concern during a security incident is confidentiality and integrity — preventing data exfiltration, containing lateral movement, eradicating the threat. Systems can be taken offline for forensic investigation. The operational cost of a few hours of downtime is measured in productivity.

In an OT environment, the calculus is different. Shutting down a SCADA system, disconnecting a PLC, or interrupting a distributed control system can have direct physical consequences: product loss, chemical safety events, equipment damage, or loss of services that communities depend on. The incident response team is operating under constraints that IT responders do not face, and decisions that are standard practice in IT can be actively dangerous in OT.

This playbook covers the first 48 hours of an OT incident — the period when the most consequential decisions are made and the options available to responders are at their widest.

Hour 0-2: Confirm and Contain Without Breaking Things

Confirm the Incident

The first task is establishing that what you are seeing is actually a security incident, not a process fault, equipment failure, or network anomaly. In OT environments, unusual network traffic, unexpected process behaviour, and system alerts can have non-security explanations. Misidentifying a process fault as a cyber incident and taking inappropriate response actions can cause harm independent of any attacker.

Collect initial indicators without touching OT systems: review historian data, DCS alarm logs, network flow records, and any endpoint security alerts from OT hosts. Bring in your OT engineer or process engineer immediately — they can tell you whether what you’re seeing is process-normal or anomalous from an operations perspective.

Activate the OT-Specific IR Team

An OT incident requires a response team that includes both IT/security personnel and OT engineering staff. The security team knows how to investigate and contain threats. The OT engineers know which systems can be touched safely and what isolation or shutdown actions mean for plant operations.

Decisions about OT systems should not be made without OT engineering input. This is not optional — an IR response that damages physical equipment or causes a process safety event is a worse outcome than a temporary persistence of the threat.

Isolate, Don’t Eradicate

In the first two hours, the goal is containment, not eradication. You want to stop the threat from spreading and preserve your options — not take aggressive actions that might disrupt processes before you understand what you are dealing with.

Identify and implement network isolation that can be applied without touching OT devices directly:

Enforce firewall rules between OT zones and IT networks at the boundary
Block or rate-limit traffic between OT segments if you have managed switches with this capability
Take jump servers or remote access infrastructure offline if it is not needed for the response

Do not immediately power off PLCs, disconnect RTUs, or intervene in running processes without OT engineering sign-off.

Hour 2-8: Scope and Understand

Map the Affected Environment

Build a picture of what is compromised and what is adjacent but potentially clean:

Identify which OT network segments the threat has reached using network flow data and any available OT-specific monitoring (Nozomi, Claroty, Dragos, etc.)
Identify hosts with confirmed compromise indicators versus hosts that are exposed but not confirmed compromised
Map the Purdue model zones: if the threat is in Level 2 (supervisory), has it reached Level 1 (control) or Level 0 (process)?

The Purdue model zone the threat has reached determines what physical consequences are possible. A compromise limited to the SCADA historian (typically Level 3 or DMZ) has different implications than a compromise of engineering workstations with PLC programming software.

Assess Physical Process Risk

Work with your OT engineering team to assess whether current process conditions are safe to continue while the investigation proceeds:

Are there process states where a threat actor with control-system access could cause a safety event?
Are safety instrumented systems (SIS) independent of the compromised network, or do they share network infrastructure?
What is the consequence of losing HMI visibility suddenly? Is there local manual instrumentation that operators can use?

If there is credible risk that the attacker has or could gain influence over physical processes, the engineering team may need to implement manual overrides, move processes to safe states, or initiate controlled shutdown before the investigation is complete.

Preserve Evidence

OT systems are often not running standard EDR tooling, and forensic evidence on OT hosts is fragile. Preserve what you can without disrupting operations:

Collect network captures from OT network segments before traffic patterns change
Image or snapshot OT hosts if they can be taken offline without process impact (engineering workstations, historian servers)
Preserve PLC program versions and configuration backups immediately — a threat actor may modify these, and you need a baseline for comparison
Document alarm and event logs from the DCS and SCADA systems before they roll over

Engage Specialist Resources

Most enterprise IT security teams do not have deep OT/ICS expertise. If this incident involves Level 1 or Level 0 systems — actual control systems and field devices — engage OT-specialist IR resources:

CISA: Free incident response support for critical infrastructure operators; contact through CISA’s 24/7 operations center
OT IR firms: Dragos, Claroty, Nozomi Networks, and Forescout all provide OT-specific incident response capabilities
OEM vendor IR: For incidents affecting specific OEM equipment (Siemens, Rockwell, Schneider Electric, Honeywell), vendors often have specialist IR resources for their own equipment

Hour 8-24: Remediation Planning

Identify Safe Remediation Windows

OT systems often run continuously for months or years. Remediation that requires taking systems offline needs to be coordinated with operations:

Identify planned maintenance windows or process cycles where taking systems down is operationally acceptable
Understand which systems have hot standby or redundant configurations that can absorb a failover
Determine what patch or remediation steps require outages versus what can be applied with the system running

Rushing remediation outside of planned windows in a continuous process environment can cause the very disruption the incident response is trying to prevent.

Validate Before Restoring

Before restoring any compromised OT system to service:

Verify PLC programs against known-good backups or golden images — check for modifications to logic or setpoints
Review all engineering workstation connections to PLCs and RTUs for any configuration pushes during the incident window
Reset all credentials on OT network infrastructure, historian databases, and remote access systems
Validate that any web shells, malicious services, or persistence mechanisms identified have been removed from all affected hosts

Network Architecture Review

OT incidents almost always reveal network architecture shortcomings: insufficiently enforced Purdue model boundaries, flat OT networks with no east-west segmentation, remote access infrastructure without appropriate controls. The incident investigation period is the right time to document these findings for post-incident remediation, even if immediate architectural changes are not possible.

Hour 24-48: Stakeholder Management and Reporting

Regulatory Notification

OT incidents — particularly those affecting critical infrastructure — may trigger mandatory reporting obligations:

CISA: ICS-CERT reporting; critical infrastructure operators should notify within 72 hours for significant incidents
Sector-specific regulators: Energy (NERC CIP), water (EPA), healthcare (HHS), financial services (OCC/FRB) each have incident reporting requirements
State regulators: Many states have their own critical infrastructure incident reporting requirements

Legal counsel should be involved in determining reporting scope. Reporting requirements are triggered by the nature of the incident, not by the outcome — a contained incident with no physical impact may still require regulatory notification.

Internal Communication

Brief executive leadership with:

Current operational status — is production affected, and if so, by how much?
Scope of compromise as currently understood
Current containment status and what actions have been taken
Timeline for full investigation and remediation
Any regulatory notification obligations

Be precise about what is known and what is still under investigation. Executives making decisions about customer communications or operational changes need accurate information, not over- or under-stated assessments.

Lessons Learned

The 48-hour mark is not the end of the incident response — but it is a natural point to begin documenting what the first phase revealed about both the threat and the organisation’s detection and response capabilities. Schedule a formal lessons-learned session once the acute phase resolves. The findings from OT incidents are often systemic: detection gaps, network architecture weaknesses, missing playbooks, or gaps in the OT-IT IR team integration that this incident exposed.