They should predefine which systems can be isolated, which manual controls must take over, and which operators are authorised to cut remote access before a compromised session reaches process controls. OT response has to protect safety and continuity together, not just contain the intrusion after impact begins.
How OT incident response should be coordinated across security and operations
OT incident response works best when security and operations share a single playbook for isolation, fallback, and recovery. The key judgement is not whether to stop the intrusion at any cost, but whether the response preserves safe plant state, avoids unnecessary process disturbance, and gives operators a clear decision path when remote access or active sessions become part of the problem.
Coordination starts with pre-agreed authority. Security teams need visibility into signs of compromise and containment options, while operations teams need control of the process-level decisions that can affect safety, production, and equipment health. That division matters most when a live session, remote vendor path, or compromised workstation can reach controllers, historian links, or engineering tools.
The response plan should name the systems that can be isolated quickly, the systems that must remain reachable for monitoring or manual operation, and the steps that switch control to local or manual procedures. Where OT response is mature, the team does not improvise this during an incident. It rehearses the handoff so that containment actions do not accidentally remove the ability to run the plant safely.
Effective coordination also depends on timing. In OT, delaying action can allow an intruder to move from an exposed support system into process controls, but moving too fast can break visibility or force an unsafe shutdown. That is why the response model has to distinguish between remote access cut-off, endpoint isolation, process monitoring, and physical process intervention. Not every alert justifies the same containment move.
Why response decisions in OT differ from IT incident handling
OT response is constrained by process continuity, safety interlocks, and the possibility that a control system is still performing an essential function even while it is suspected to be compromised. A normal IT instinct, such as immediately pulling every affected host off the network, can be counterproductive if it removes telemetry, disables supervisory control, or creates an operator blind spot.
That is why OT teams should treat remote access as a high-value response lever. If a compromised session can still reach engineering workstations, HMIs, or controller management interfaces, the first containment move may be to revoke that path before widening the incident. NHIMG’s OT Incident Response Guide is useful here because it centers safety-first decision rights, containment choices, and validated recovery.
Manual fallback is equally important. Operators should know which controls, alarms, and run procedures can safely take over if automation is degraded or isolated. That includes understanding which actions must be taken locally, which can be supervised remotely, and which should be suspended until the integrity of the control path is restored. In practice, the response decision often turns on whether the plant can maintain a stable state with reduced connectivity.
Security and operations also need a common escalation threshold. If the incident touches an engineering workstation, remote access gateway, or privileged account used for OT administration, the response should move beyond IT containment and into process-aware coordination. The goal is to limit blast radius without creating a second incident through an unsafe or untested isolation step.
What a coordinated OT incident workflow should include
A coordinated workflow should define roles before the event: who declares an OT incident, who can disable remote access, who approves isolation of a controller segment, and who confirms that manual operation is viable. Those permissions are not administrative detail, they are the difference between a fast containment action and an ad hoc decision made under pressure.
The workflow should also include evidence handling and recovery sequencing. Security may need logs, session records, and forensic artefacts, but operations may need to prioritise restoring a safe state and validating that logic, set points, and operator authority still match expected configuration. When those goals compete, the plan should say which one wins first in each scenario.
A practical coordination model is to separate the response into three checks: can the process be kept safe, can the suspect path be removed, and can the team still observe what the process is doing? If the answer to any of those is no, the incident needs a higher-severity operational response rather than a narrow security response.
For teams building or refreshing that workflow, CISA Industrial Control Systems and NIST SP 800-82 Rev. 3 help anchor the response around industrial control realities, while FIRST is a useful reference for incident response coordination practice and SANS Security Resources provides practical incident-handling material for operational teams.
Risk and Threat Considerations
OT incidents create a dual risk: the attacker may use remote access or a privileged support path to reach process controls, while the defenders may disrupt a live process if they isolate the wrong system too early. That is why containment in OT is not just about preventing spread, it is about preserving safe operation while the compromise is being removed.
Failure mechanism: A compromised session, stolen support credential, or abused remote tool can cross from an IT-facing access path into engineering or control systems before the team has cut the right connection. If the response is improvised, operators may lose visibility or control at the same time they are trying to contain the event.
Impact: The result can be loss of supervisory control, degraded monitoring, unsafe manual intervention, production interruption, or a prolonged recovery because the team must first re-establish confidence in the control path before restoring normal operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IR-4 — Incident Handling | OT incident coordination hinges on containment, escalation, and response actions. |
| IR-8 — Incident Response Plan | The question is about predefining roles, authority, and response steps. | |
| CA-7 — Continuous Monitoring | OT response depends on timely detection and visibility into affected systems and sessions. | |
| Recommendation — Use IR-4 to define containment, escalation, and coordinated response actions for OT incidents. Use IR-8 to document OT incident roles, decision rights, and response procedures. Use CA-7 to maintain monitoring that supports OT containment decisions and recovery. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | OT response coordination depends on preplanned incident roles and procedures. |
| A.5.26 — Response to information security incidents | The question is directly about how teams should coordinate response actions. | |
| Recommendation — Prepare OT incident roles and response procedures under A.5.24. Apply A.5.26 to coordinate incident response actions across security and operations. | ||
Practitioner Guidance
What to prioritise: Decide in advance which systems are safe to isolate, which remote access paths can be cut immediately, and which manual controls must remain available. If those decisions are still being made during the incident, the team is already behind.
What to verify: Confirm that operators can run the process safely with the planned fallback mode, and that security can remove the suspected access path without eliminating essential visibility. Validate this with tabletop exercises, not just documentation.
Decision rule: If the compromise is in a session or access path that can reach OT administration or process controls, revoke that path first and then assess the rest of the environment. If the process cannot tolerate isolation, switch to the least disruptive containment that still reduces attacker reach.
Practitioner takeaway: The right OT incident response is the one that removes attacker control without removing operator control, because in industrial environments containment that breaks safe operation is not effective containment.
Related resources from NHI Mgmt Group
- Guide: Incident Response Guide
- How should security teams coordinate incident response across distributed stakeholders?
- How should security teams structure an incident response program to reduce damage and restore operations quickly?
- How should security teams implement logging and monitoring so they support incident response without drowning operations in noise?
- Why does disconnected threat intelligence increase incident response risk in busy security operations teams?