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.01OFFICIAL TITLEPENDING NIST SME REVIEW

03.06.01 — Incident Handling

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

Independent summary of the official requirement

Requires implementing an incident-handling capability that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery.

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

When something goes wrong, the organization needs a rehearsed sequence — prepare, detect and analyze, contain, eradicate, recover — rather than improvisation by whoever notices first. Rev. 3 also ties handling explicitly to the incident response plan, so the capability and the document must describe the same organization.

Across revisions

Carried forward from Rev. 2's 3.6.1 with the phase list revised — Rev. 3 names eradication explicitly, drops 'user response activities', and requires handling to be consistent with the incident response plan that 03.06.05 now demands.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

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.

Practice-side activities
  • Define OT containment and shutdown decision authority with plant leadership before an incident
  • Rehearse loss-of-view and loss-of-control scenarios with operations and engineering
  • Pre-stage recovery resources — configuration backups, spares, vendor contacts — for critical OT assets
Evidence this produces
  • OT incident response plan sections covering the handling phases
  • Exercise or incident records from the OT environment
  • Recovery-resource inventories for critical production systems

Where this holds: Holds for organizations with production or OT environments in scope; contributes nothing to this requirement where the assessed boundary is IT-only.

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

Contextual relationshipModerate confidence

Why: Recovery is one of the incident-handling phases this requirement names, and a tested backup and disaster recovery architecture is what makes that phase real rather than aspirational when the incident is destructive.

What this does not claim: One phase is not the capability: preparation, detection and analysis, containment, and eradication are untouched by backup architecture, and restoring from backup before eradication completes simply re-runs the incident. The practice informs how the recovery phase executes; the handling capability itself is separate work.

Practice-side activities
  • Time test restores against the recovery expectations the incident plan assumes
  • Keep backup credentials and infrastructure separated so the recovery path survives the incident that triggers it
Evidence this produces
  • Test-restore records referenced from incident response documentation
  • Immutability or offline-copy verification for critical datasets

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
  • Build the handling procedure around the phases the requirement names, and confirm each phase has a named owner and the tooling it presumes actually exists.
  • Decide in advance who may take a production system offline for containment — for manufacturers that decision crosses into safety and revenue and cannot be improvised mid-incident.
  • Treat eradication as its own phase: closing the alert without confirming removal of persistence is how the same incident recurs a month later.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The documented handling procedure, consistent with the incident response plan
  • Records from real incidents or exercises showing the phases executed
  • Post-incident reviews feeding changes back into procedures

Suggested owners, derived from the mapped practices and artifacts: Plant / OT leader · IT 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

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