Proactive incident response for OT environments

Most industrial organizations have an incident response plan. Far fewer can execute it effectively when an incident actually occurs. The gap between a document and operational readiness is bridged by regular practice, cross-team knowledge, and an up-to-date environmental baseline.

Incidents in OT environments follow a distinct dynamic. In IT, the priority is data confidentiality; in OT, it is process continuity and physical safety. Deciding to shut down an infected IT server is unpleasant but feasible within minutes. Deciding to halt a chemical process or power line requires consideration of physical, environmental, and economic consequences.

Three pillars of proactive response

1. Cross-training IT and OT teams

In most organizations, IT and OT teams operate separately. When an incident spans both environments, there is no shared language and limited understanding of each other’s constraints.

What the IT team should know about the OT environment:

PLCs and DCS systems do not behave like servers - a restart can take hours, not minutes
Port scanning in an OT network can cause controller failures
Updates require a maintenance window, not a Friday evening hotfix
Industrial protocols (Modbus, OPC UA, DNP3) lack built-in authentication

What the OT team should know about cybersecurity:

Network traffic that looks “normal” can contain data exfiltration
A service account with a password unchanged for years is an open attack vector
Backing up controller configuration on an unencrypted USB drive is a risk
Remote access via TeamViewer or AnyDesk without controls is an incident waiting to happen

Competency	IT team should	OT team should
Networks	Understand OT topology and IEC 62443 zones	Understand firewalling and NAC
Systems	Know PLC/DCS types and their limitations	Know AD and GPO mechanisms
Incidents	Know what NOT to do in OT networks	Recognize compromise symptoms
Communication	Have contacts for OT engineers	Have contacts for SOC/CSIRT

2. Establishing OT security baselines

You cannot detect anomalies without knowing the normal state. A baseline is a documented, verified picture of how the OT environment operates correctly.

Baseline elements:

Asset inventory - a complete device list with firmware versions, network configurations, and communication relationships. Not a spreadsheet updated once a year, but a living register supported by passive monitoring tools (e.g., Claroty, Nozomi Networks, Tenable.ot).

Network traffic profile - which devices communicate with which, on what ports, at what frequency. In a stable OT environment, the traffic profile is far more predictable than in IT. A new connection between a PLC and a workstation that never previously communicated with it is an anomaly requiring investigation.

Controller configurations - backup of configuration and program logic for all PLCs and DCS systems. Comparing the current configuration against a reference allows detection of unauthorized modifications.

Accounts and permissions - a list of accounts with OT system access, their permissions, and last-use date. Many OT environments still use shared accounts - document them and plan migration to individual credentials.

3. Practicing incident response plans

An IR document that sits on a drive and has never been tested has zero operational value. Regular exercises reveal gaps that are invisible on paper.

Three exercise levels:

Tabletop exercises - a scenario-based discussion in a conference room. A moderator presents a scenario (e.g., ransomware in the OT network), and participants walk through their actions step by step. Low cost, high diagnostic value. Recommended quarterly.

Functional exercises - teams execute their roles in a simulated scenario, but without real impact on production systems. They test communication, escalation, and decision-making procedures. Recommended every six months.

Full-scale exercises - an incident simulation in a test environment mirroring production. Includes technical containment, eradication, and recovery actions. Recommended annually.

IR exercise preparation checklist:

Scenario based on a realistic attack vector (e.g., phishing + lateral movement to OT)
Participation from both IT and OT teams
Clear criteria for the decision to stop the technological process
Procedure for communication with the regulator, media, and partners
Offline backup of contacts (what if email is down?)
Lessons-learned documentation after each exercise
IR plan update based on findings

Incident response in OT - specific challenges

The isolation vs. process continuation decision

In IT, the standard reaction to a confirmed compromise is isolation - disconnecting the infected system from the network. In OT, this decision requires analysis of process consequences:

Abruptly disconnecting a historian server will not stop the process
Disconnecting an engineering workstation during an ongoing chemical process prevents operator intervention
Isolating the communication network between controllers and a safety system may endanger human safety

Every isolation scenario should be analyzed in advance and documented in the IR plan.

Evidence preservation vs. operational continuity

In IT, forensics means a disk image, RAM dump, and logs. In OT, additional challenges include:

PLCs have limited memory and do not store logs in the traditional sense
Many OT devices do not support remote forensic data collection
The need to maintain process continuity may require keeping infected systems running until a planned shutdown

Action plan - from document to readiness

Month 1-2: OT asset inventory and baseline establishment
Month 3: Develop or update the OT-specific IR plan
Month 4: Cross-training for IT and OT teams
Month 5: First tabletop exercise
Month 6: Procedure verification and update based on findings
Quarterly: Tabletop exercises with new scenarios
Annually: Full-scale exercise

Summary

Proactive incident response is not a question of additional budget for tools. It is an organizational change - building cross-team competencies, documenting the normal state of the environment, and regularly testing procedures. Organizations that invest in these three pillars respond to incidents faster, with smaller losses, and with better collaboration between teams.

SEQRED helps organizations build incident response capabilities in industrial environments - from creating IR plans to conducting exercises and supporting actual incidents.

Sources

NIST SP 800-82 Rev. 3: Guide to OT Security - https://csrc.nist.gov/pubs/sp/800/82/r3/final
NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide - https://csrc.nist.gov/pubs/sp/800/61/r2/final
IEC 62443-2-1: Establishing an IACS Security Program - https://www.iec.ch/
SANS ICS IR Playbook (2024) - https://www.sans.org/white-papers/
Dragos: ICS/OT Cybersecurity Year in Review 2024 - https://www.dragos.com/year-in-review/