Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
3.6.2OFFICIAL STATEMENT BELOWBASIC REQUIREMENTPENDING NIST SME REVIEW

3.6.2Incident tracking and reporting

3.6 Incident Response · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal SystemsNIST SP 800-171A — Assessing Security Requirements for CUI
Independent interpretation

What this requirement is after

Every incident gets a record, an owner, and a closure — and the right people hear about it, inside and outside the organization. For defense contractors the external half usually means the 72-hour cyber incident report to DoD under DFARS 252.204-7012, a deadline that is survivable only if the reporting path was decided in advance.

Across revisions

Carried into Rev. 3 as 03.06.02 (Incident Monitoring, Reporting, and Response Assistance), which makes incident monitoring and response assistance explicit alongside tracking and reporting.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

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.

Practice-side activities
  • Route OT incident records into the organization's incident register rather than a plant-local file
  • Name in the OT plan who notifies the organizational officials responsible for external reporting
  • Capture after-action records in a form the enterprise process can consume
Evidence this produces
  • OT incidents appearing in the organizational incident register
  • The OT plan's escalation path naming the officials who own external reporting

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
  • Keep an incident register even for small events; the tracking discipline is what turns 'we handled it' into something an assessor can examine and the organization can learn from.
  • Write the reporting matrix before it is needed: which internal officials, which external authorities, on what deadlines, and what evidence-preservation obligations attach once a report is made.
  • The tool matters less than the record — a ticket queue or a well-kept spreadsheet both work if every incident shows dates, categorization, actions, and disposition.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • An incident register showing detection, actions, and closure per incident
  • A written reporting matrix naming internal officials and external authorities with deadlines
  • Records of past external reports, or a documented position that none were required

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

The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

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