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

03.06.02 — Incident Monitoring, Reporting, and Response Assistance

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

Independent summary of the official requirement

Requires tracking and documenting system security incidents; reporting suspected incidents to the organizational incident response capability within an organization-defined time period; reporting incident information to organization-defined authorities; and providing an incident response support resource that offers advice and assistance to system users.

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

Incidents must leave a record and reach the right people on a clock: an internal report within the defined period, external reports to the authorities the organization names, and a tracking trail that survives the incident. Rev. 3 adds a help channel — somewhere a user who suspects something can go for advice instead of sitting on it.

Across revisions

Expands Rev. 2's 3.6.2: tracking and reporting carry forward, while Rev. 3 adds organization-defined reporting time periods and authorities plus an explicit incident response support resource for users.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

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.

Practice-side activities
  • Define OT incident severity levels and the escalation path from operators into the enterprise response process
  • Write external-reporting hand-offs (corporate, customer, authorities) into the OT plan rather than assuming them
Evidence this produces
  • OT incident records showing tracking and escalation
  • The OT plan's reporting and escalation matrix

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
  • Name the external authorities and time periods in writing before an incident; for defense contractors, the DFARS 252.204-7012 72-hour report to DoD belongs on that list from day one.
  • Track every incident and suspected incident in one register — severity, timeline, actions taken, reporting decisions — so 'track and document' survives staff turnover.
  • Make the support resource concrete: a monitored mailbox, help-desk queue, or on-call number that users are actually told about.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • An incident register with timelines and reporting decisions per entry
  • The written reporting matrix naming recipients, authorities, and time periods
  • User-facing guidance or help-desk routing for reporting suspected incidents

Suggested owners, derived from the mapped practices and artifacts: Plant / OT leader · IT leader or incident response lead · Incident response lead · Compliance lead or contracts manager. 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 TemplateRECORD · REVIEW REVIEWED AT EVERY INCIDENT CLOSE-OUTIncident Timeline WorksheetWORKSHEET · REVIEW ANNUAL72-Hour Reporting Decision Worksheet
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