Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
03.06.05OFFICIAL TITLEPENDING NIST SME REVIEW

03.06.05 — Incident Response Plan

03.06 Incident Response · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires developing an incident response plan with organization-defined content — including the structure and organization of the incident response capability, how it fits into the overall organization, and definitions of reportable incidents — distributing the plan to designated incident response personnel and organizational elements, updating it to address system and organizational changes or problems encountered during execution or testing, and protecting it from unauthorized disclosure.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

The response capability gets a written charter: who responds, how the function is organized, what counts as a reportable incident, and how incident information is shared. The plan must actually reach the people named in it, change when the organization changes, and stay out of adversary hands — a response plan is a map of your defenses.

Across revisions

New as a standalone requirement in Rev. 3. Rev. 2's incident-handling requirement implied an organized capability but named no written plan as its own requirement; organizations that ran capable-but-undocumented response now need the plan as an explicit, maintained, and protected artifact.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportModerate confidence

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.

Practice-side activities
  • Write the OT plan with plant-specific reportable events, decision authorities, and safety interlocks documented
  • Distribute the plan to named operations and engineering personnel and keep an offline copy reachable during an outage
  • Update the plan after every OT incident, exercise, and significant process change
Evidence this produces
  • The versioned OT incident response plan
  • Distribution records for operations personnel
  • Update history tied to incidents and exercises

Where this holds: Direct for the OT portion of an assessed environment; organizations without OT in scope get no coverage from it.

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Write the plan the responders will use at 2 a.m.: contact trees, decision authorities, and reportable-incident definitions up front, background prose in appendices.
  • Distribute deliberately and record who holds current copies — a plan sitting on a file share nobody was pointed to has not been distributed.
  • Update after every incident, exercise, and organizational change; the version trail is itself evidence.
  • Keep an offline copy reachable when systems are down, and restrict access so an attacker inside the network cannot simply read the playbook being run against them.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The current plan with version history reflecting post-incident and post-exercise updates
  • Distribution records naming the personnel or roles holding the plan
  • Access restrictions on the plan document itself

Suggested owners, derived from the mapped practices and artifacts: Plant / OT leader · IT leader or incident response lead. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

PLAN · REVIEW ANNUALIncident Response Plan Template
The other revision

Where this came from in Rev. 2

No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated