Official intent
Have an OT-specific incident response and recovery plan so you respond to an OT incident without guessing. The official source remains authoritative.
Read the official campaign ↗An IT incident-response plan does not fit the plant. OT response has to weigh safety and physical process first, involve engineers and operators alongside IT, and account for the reality that you may run degraded or in a safe state rather than simply pulling systems offline. A written, exercised OT plan — with roles, safe-state procedures, and tested recovery — is what prevents improvisation during a crisis.
Who this applies to: Every environment where a security action could affect physical operations. The IT incident-response plan does not cover this, however good it is.
Why it matters
In OT, a wrong response can be worse than the incident: isolating the wrong device can trip a process or create a safety hazard. Response decisions must be made with process owners, ahead of time, and rehearsed. Recovery also depends on validated backups of controller logic and configurations that most IT plans never cover.
Risks this reduces
- Containment actions that trip a process or create a safety hazard
- Improvised decisions during an incident because nobody agreed them in advance
- Recovery blocked by the absence of controller logic and configuration backups
- IT and OT responding separately, or contradicting each other, under pressure
Containment actions in OT — isolating a device, cutting a network path — can directly affect physical operations and safety systems. Every response and recovery procedure must be reviewed with process and safety owners, define safe-state options, and be exercised in a way that never puts production or people at risk.
Who owns it
Plant / OT leader
OT engineer, IT / security lead, Executive sponsor
Medium
Medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: OT-02 — Validated OT asset inventory, OT-08 — OT system resiliency
- A validated inventory so responders know what they are looking at
- Named contacts across IT, OT engineering, operations, leadership, and key vendors
- Backups of controller logic and configuration that someone has actually restored
Action timeline
- Confirm whether any OT-specific response plan exists
- List who to call for an OT incident, including engineers and vendors
- Write the one-page version first: who to call, what may never be isolated without the process owner, and where the safe-state procedures are
- Confirm backups of controller logic and configuration exist for your most critical line
- Draft an OT IR plan with roles, contacts, and safe-state options
- Confirm backups of controller logic/config exist
- Write playbooks for the most likely OT scenarios
- Validate an OT recovery by test-restoring a configuration
- Run a tabletop exercise with IT, OT, and leadership
- Fold lessons into the plan and set an annual cadence
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Build an OT-specific IR plan with named roles spanning IT, OT engineering, operations, and leadership.
- Define containment options that weigh safety and process impact, including safe-state and degraded operation.
- Ensure recovery relies on validated backups of controller logic, configurations, and set points.
- Write playbooks for the incidents most likely to hit your environment.
- Exercise the plan at least annually with all stakeholders and update it from what you learn.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
No OT-specific plan; the IT plan is assumed to cover the plant.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A written OT plan names roles, reachable contacts, and safe-state guidance distinct from the IT plan.
Is the intent written down, with a named owner and a scope? - Configured
Playbooks exist for the most likely OT scenarios, and recovery sources — logic and configuration backups — are identified.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
The plan is distributed, responders know their role, and a recovery has been proven by test-restoring a configuration.
Does it cover everything in scope, with the exceptions written down? - Measured
Exercises and real events are measured against response and recovery expectations, and findings are tracked to closure.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
An owner runs the annual exercise, maintains the plan against plant change, and retains after-action records as evidence.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Confirm the OT plan names specific people and reachable after-hours contacts, not just titles.
- Test-restore a controller configuration or logic backup to prove recovery works.
- Verify the last tabletop involved OT engineers and produced changes to the plan.
Evidence to retain
OT incident-response and recovery plan with roles and safe-state procedures
Inventory of controller logic/config backups used for recovery
Exercise reports and incident after-action records
Test-restore results and plan-revision history
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Plan currency | Days since the OT plan was last reviewed against the current plant and contact list. | Within the agreed review interval; contacts verified reachable. |
| Recovery proven | Critical control systems for which a logic or configuration restore has been successfully tested. | 100% of critical systems within the agreed cycle. |
| Exercise-to-improvement rate | Exercises that changed the plan, a playbook, or a runbook ÷ exercises run. | 100%. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
Reusing the IT plan unchanged, backups of servers but not of PLC logic and set points, and a plan that has never been exercised with the people who run the plant. A response plan first read during an incident is a liability.
Two sized paths
A two-page plan beats no plan: who to call at 2am including the integrator, what may never be unplugged without the process owner, how to reach a safe state, and where the controller backups live. Test one configuration restore. Run one tabletop with the plant manager in the room.
Maintain scenario playbooks for the incidents your environment actually faces, exercise jointly with IT, operations, leadership, and vendors, measure against defined response and recovery expectations, and feed both exercises and real events into plan revisions with a documented history.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Response actions are changes made under pressure. Pre-authorize the containment options that are safe, name the ones that require the process owner regardless of urgency, and require an after-the-fact review of every emergency change made during an incident.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The publication addresses response in environments where containment can affect physical process and safety, which is the substance of this practice.
What this does not claim: 800-82 is guidance, not a compliance standard.
Why: The incident-management and recovery-plan-execution outcomes describe the intent directly.
What this does not claim: The CSF describes outcomes, not testable controls.
Why: The 2024 edition's security program elements include incident response for control system environments.
What this does not claim: IEC 62443 is a voluntary industrial standard; conformance is a separate, scoped exercise. The 2024 edition restructured the 2010 requirements into Security Program Elements; The specific requirement identifiers are pending verification against the licensed normative text and should be treated as directional until that check completes.
Why: The guide directly addresses the recovery half of this practice: regular OT backups, integration with change management, testing, and recovery exercises.
What this does not claim: A quick-start guide, advisory by nature. It informs how the recovery capability is built; it imposes no requirement and its scope is backups, not the full response plan.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.6.1Incident-handling capabilityPartial implementation supportModerate
Why: The practice builds and exercises the response-and-recovery capability for the operational side of the house — named roles, containment options pre-agreed with process owners so a response action does not trip a process or create a safety hazard, and identified recovery sources for controller logic and configuration. That is the requirement's preparation-through-recovery arc, applied to the plant.
What this does not claim: The practice is deliberately OT-scoped, while this requirement covers the organization's entire in-scope environment — the enterprise incident-handling capability has to exist independently of anything this practice does. It applies at all only where OT systems fall within the CUI boundary, which is the exception rather than the rule.
Review status: Technical review complete.
Open the 3.6.1 page →3.6.2Incident tracking and reportingPartial implementation supportModerate
Why: The practice's named contacts, escalation paths, and after-action documentation are the tracking and internal-reporting machinery for incidents that touch production — the OT slice of what this requirement asks the organization to track, document, and report.
What this does not claim: External reporting obligations — including the 72-hour DFARS 252.204-7012 report where the clause applies — sit with the organization, not the plant, and the practice does not establish the organization-wide incident register or the reporting matrix behind it. It feeds those mechanisms with OT incident records; it does not create them, and it applies only where OT falls within the CUI boundary.
Review status: Pending NIST SME review.
Open the 3.6.2 page →3.6.3Incident response testingPartial implementation supportModerate
Why: The practice's operating rhythm is exactly this requirement's substance for the plant: tabletops and joint exercises run on a cadence, measured against response and recovery expectations, with findings tracked to closure and fed back into the plan.
What this does not claim: Exercising the OT plan tests the OT plan — the organization's wider response capability, including the enterprise-side scenarios an assessor will ask about, needs its own testing. As with the rest of this family, the mapping applies only where OT systems fall within the CUI boundary.
Review status: Technical review complete.
Open the 3.6.3 page →NIST SP 800-171 Rev. 3
03.06.01Incident HandlingPartial implementation supportModerate
Why: The practice builds and rehearses an OT-specific incident response and recovery capability — preparation, detection paths, containment decisions that respect safety and production, and recovery of plant operations — which is the substance of incident handling for the OT portion of the environment.
What this does not claim: The requirement covers incident handling for the whole assessed environment, and this practice works only the OT slice — enterprise IT incidents, business-system compromises, and CUI spills outside production need their own handling procedures. Consistency between the OT plan and the organization-wide incident response plan (03.06.05) must also be established separately; an OT plan that contradicts the enterprise plan creates confusion mid-incident rather than capability.
Review status: Pending NIST SME review.
Open the 03.06.01 page →03.06.02Incident Monitoring, Reporting, and Response AssistancePartial implementation supportModerate
Why: An OT incident plan worth the name defines how plant incidents are tracked, escalated, and reported — including who informs corporate, customers, and authorities when production is affected — which advances the tracking-and-reporting portion of this requirement for OT events.
What this does not claim: The requirement's reporting obligations are organization-wide, with organization-defined authorities and time periods — for defense contractors, the DFARS 72-hour report runs through corporate processes the OT plan does not own. The user-facing incident response support resource the requirement adds is likewise an enterprise function; an OT escalation tree does not stand in for it.
Review status: Pending NIST SME review.
Open the 03.06.02 page →03.06.03Incident Response TestingPartial implementation supportModerate
Why: The practice calls for exercising the OT plan — tabletops with operations, drills against realistic plant scenarios — which is incident response testing for the part of most environments that is hardest to test any other way.
What this does not claim: Testing the OT scenario does not test the rest of the capability: enterprise scenarios, cross-boundary incidents, and the organization-defined testing frequency all sit outside this practice's scope. An assessor evaluates whether the capability as a whole is tested at the defined frequency, and OT tabletop records cover only part of that picture.
Review status: Pending NIST SME review.
Open the 03.06.03 page →03.06.05Incident Response PlanDirect implementation supportModerate
Why: The practice's core deliverable is a written OT incident response and recovery plan — structure, roles, reportable events, and recovery priorities for production systems — the same artifact class this requirement demands, built for the part of the environment where generic IT plans fail.
What this does not claim: Supports implementation of the requirement within OT scope only: the requirement calls for an incident response plan covering the organization's systems as a whole, with organization-defined content, distribution, maintenance, and protection obligations that extend well beyond production. Whether the OT plan stands alone or becomes an annex to the enterprise plan, the enterprise-level document and its upkeep are separate work this practice does not perform.
Review status: Pending NIST SME review.
Open the 03.06.05 page →Review status
| Technical review | Reviewed — pending SME sign-off |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.1 |
This guide has been reviewed by practitioners but is awaiting sign-off from a subject-matter expert in this specific domain. Treat the safety and change-control guidance as a floor, not a ceiling, and validate it against your own process and vendor requirements.