OT Incident Response Plan: The Complete 2026 Guide

An OT incident response plan is the documented set of decisions, roles and playbooks your organization follows when a cyber incident touches industrial control systems, and its first job is to keep people safe and the physical process in a known, safe state. That one priority changes much of what an IT plan takes for granted, from who can pull a network cable to whether you can image a compromised device.

Most plants already have a corporate incident response plan. In our audits, the usual gap is a plan written for laptops and email servers that says nothing about operators, manual fallback, controller logic or the integrator who holds the only working backup.

This guide covers how an OT incident response plan differs from an IT one, what it must contain, how it maps to IEC 62443-2-1 SPE 7 and NIST SP 800-82 Rev. 3, how it feeds NIS2 reporting, and three common playbooks.

How an OT incident response plan differs from an IT plan

An IT plan is built to contain the attacker and protect data. An OT plan protects people and equipment, and keeps the process running or stops it in a controlled way. Six differences matter most:

• Safety and availability come first. Every containment step is judged by its effect on the process. Shutting down a server mid-batch can create a hazard the attacker never did.
• Operations holds the authority to isolate. The shift supervisor or control room lead, not the SOC, decides when a zone is disconnected. Security advises and operations executes.
• Manual operation is a planned state. The plan defines which units can run manually, for how long, with what staffing, and what triggers a controlled shutdown instead.
• Forensics has hard limits. Many PLCs and controllers keep little or no security logging, cannot be imaged like a disk, and are usually read through vendor engineering software. Evidence collection must not disturb the running process.
• Vendors and integrators are part of the team. They often hold the engineering software, licenses and project files needed to restore a controller, so their contacts and response commitments belong in the plan.
• Safety instrumented systems are off-limits for ad hoc changes. No responder bypasses, resets or reprograms an SIS outside your functional safety management of change process. In our experience, if the SIS may be affected, the right move is a safe state and a call to the safety engineers.

What an OT incident response plan must contain

The table below is the structure we use when reviewing an OT incident response plan. Section names vary, but assessors typically look for each element.

Plan section	What it must contain
Scope and objectives	Sites, zones and systems covered; the safety-first objective; links to the IT plan and site emergency plan
Roles and decision authority	Incident lead, operations lead with authority to isolate or shut down, OT security, safety engineer, IT liaison, legal and communications, with a deputy for every shift
Contact directory	24/7 contacts for staff, vendors, integrators, the CSIRT or regulator, insurer and external responders, held offline too
Asset and network references	Asset inventory, zone and conduit drawings, critical processes, and where known-good backups and project files live
Detection and triage	Event sources (OT monitoring, HMI alarms, operator reports) and severity criteria tied to safety and production impact
Isolation and containment	Pre-approved isolation points per zone and conduit, what each disconnects, and its process effect
Manual operation and safe state	Units that can run manually, staffing, maximum duration and shutdown triggers
Evidence handling	What to capture from network, workstations and controllers, by whom, with which tools, and chain of custody
Recovery and restoration	Restore order, known-good logic and configuration baselines, verification before restart, operations sign-off
Reporting and communications	Internal escalation, regulatory deadlines such as NIS2, customer and public messaging
Playbooks	Step-by-step actions for the most likely scenarios
Exercises and maintenance	Tabletop schedule, after-action reviews, plan owner and review triggers

Keep a printed copy in every control room. A plan stored only on a file server that ransomware has just encrypted will not help anyone.

Aligning the plan with IEC 62443-2-1 SPE 7

IEC 62443-2-1 Edition 2.0, published in August 2024, restructured the asset owner requirements into eight security program elements (SPEs). SPE 7, Event and incident management, is where your OT incident response plan sits as evidence. The standard also defines a maturity model, so an assessor will ask how consistently the plan is practiced and improved, not just whether it exists.

SPE 7 depends on other program elements:

• SPE 2 Configuration management supplies the known-good baselines you restore from.
• SPE 3 Network and communications security provides the zones and conduits that make clean isolation possible.
• SPE 6 User access control supports fast removal of compromised or vendor accounts.
• SPE 8 System integrity and availability covers the backup and recovery capability the plan relies on.

At system level, IEC 62443-3-3 groups event response capabilities under FR 6 Timely response to events. For integrators, IEC 62443-2-4 sets security program requirements for IACS service providers, the right reference when you write their incident duties into contracts. For how the parts fit together, see our guide to IEC 62443 parts explained.

What NIST SP 800-82 Rev. 3 says about incident response

NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, published in September 2023, is direct in its executive summary: incidents are inevitable, and an incident response plan is essential. It notes that OT objectives typically put integrity and availability ahead of confidentiality, with safety as an overarching priority.

Three parts are worth reading alongside your plan:

• Sections 3.3.8 and 3.3.9 cover building an incident response capability and a recovery and restoration capability.
• Section 6.4 works through the CSF Respond categories (planning, communications, analysis, mitigation and improvements), with recovery in Section 6.5.
• Appendix F holds the OT overlay for SP 800-53 Rev. 5, including the incident response (IR) control family.

The guide also recommends graceful degradation from full automation to manual operation, exactly the fallback your plan should define. NIST released the Rev. 4 initial public draft on September 21, 2026 (comments close November 30, 2026), so Rev. 3 remains final for now. CISA’s ICS recommended practices add guidance on ICS incident response capability and forensics plans for control systems.

Building NIS2 reporting into your OT incident response plan

If your organization is an essential or important entity under NIS2, the plan has to start a regulatory clock as well as a technical response. Article 23 requires notification of any significant incident to the CSIRT or competent authority:

• an early warning within 24 hours of becoming aware of the incident;
• an incident notification within 72 hours of becoming aware of it;
• intermediate status reports on request;
• a final report no later than one month after the incident notification, or a progress report at that point if the incident is still ongoing.

An incident is significant if it has caused, or can cause, severe operational disruption or financial loss, or considerable damage to others. In OT, operations usually holds the facts that decide this: downtime, safety impact and lost customer service.

Name who makes the significance call, give them a decision template, and make sure the OT incident lead briefs them within hours. National transposition laws add detail, so confirm your member state’s rules. Our NIS2 incident reporting guide covers each stage.

OT incident response playbook examples

Your OT incident response plan sets authority and structure. Playbooks turn it into steps a shift lead can follow under pressure, ideally on one or two pages. Start with these three.

Ransomware on an HMI or engineering workstation

1. Operators confirm process state from other HMIs or the field, and move affected units to manual or a safe state if visibility is lost.
2. Operations authorizes isolation at pre-approved points, starting with the IT-to-OT conduit.
3. Preserve evidence: photograph screens, keep the disk, and avoid rebooting until the evidence decision is made.
4. If the workstation could reach controllers, verify their logic against known-good baselines.
5. Rebuild from clean images, restore project files from offline backups, and restart only after operations signs off.

Unauthorized remote access to the control network

1. Disable the remote access path and the account used, at the conduit and not only at the endpoint.
2. Establish from session logs which hosts and controllers were reached.
3. Ask the vendor or integrator who owns the account whether the session was theirs.
4. Check logic, setpoints and configuration on every asset the session touched.
5. Restore access only through the approved route, with new credentials and multifactor authentication.

Our guide to OT secure remote access covers the controls that make this scenario less likely.

Unexpected PLC logic change

1. Treat it as a potential safety issue. Operations confirms the process behaves as intended and moves to a safe state if not.
2. Compare online logic with the known-good offline project in the vendor’s engineering tool, and record every difference.
3. Rule out an authorized but undocumented change through the change log, maintenance staff and the integrator.
4. Save the modified program as evidence before reloading anything.
5. Reload verified logic, test it, and get operations sign-off before returning to automatic control.

None of these playbooks touch SIS logic. Safety system issues go to the safety engineers under management of change.

Testing the OT incident response plan with tabletop exercises

An unexercised plan tends to fail at the first real decision. Tabletops find that out cheaply, before an attacker does.

• Who attends: operations, control engineers, safety, OT and IT security, the integrator, and whoever owns regulatory reporting.
• Scenario design: use your own playbooks and plant drawings, then add injects such as loss of HMI view at shift change or an unreachable vendor.
• What to measure: time to the isolation decision, time to stable manual operation, whether contacts answered, and whether the significance call fit inside 24 hours.
• Close the loop: assign owners to findings, update the plan, and keep the records as maturity evidence for SPE 7.

If you would rather not build your OT incident response plan from a blank page, the IEC 62443 Toolkit ($149) includes 117 editable templates (82 Word, 35 Excel) in 16 sections, written against IEC 62443-2-1:2024, with procedures for SPE 1 to SPE 8, including SPE 7 Event and incident management. It is built for asset owners and service providers. It supplies the documented layer; your team still runs the exercises, operates the processes and keeps the records, and no template set can certify anyone.

OT incident response plan FAQs

Is an ICS incident response plan the same as an OT incident response plan?

In practice, yes. ICS usually means industrial control systems in plants and utilities, while OT is broader and also covers building automation, transportation and physical access control, the scope NIST SP 800-82 Rev. 3 uses. Scope the plan to the systems you run.

Who should have authority to isolate the control network?

Operations. Name the control room lead or shift supervisor as the person who authorizes isolation or shutdown, with security advising. Pre-approved isolation points keep that decision to minutes.

Can we use our IT plan with an OT annex?

Often, yes. Many organizations keep one corporate plan for governance and reporting, then add an OT annex for decision authority, manual operation, controller handling and playbooks. For an IEC 62443-2-1 assessment, expect the assessor to look for OT-specific content that is approved and exercised.

How often should an OT incident response playbook be tested?

Typically at least once a year in a tabletop, and again after major system changes, new remote access arrangements or a real incident. Short drills, such as restoring one controller from backup, can run more often.