3.6 IR
629 paragraphs across ten sections. Here is what distinguishes this page and why the design decisions at each section level carry operational weight.
Document structure
The IR family has only three controls but generates the most operationally consequential documentation in the entire NIST 800-171 library — because an incident response failure creates liability exposure across multiple simultaneous reporting regimes. The document is accordingly weighted toward procedure rather than theory.
Section 2 covers the control implementations in the expected format, but the severity classification table embedded within 3.6.1 is the operational centrepiece of that section. The four-tier classification (P1 Critical through P4 Minor) determines every downstream decision: who is called, within what timeframe, which external reporting clocks are triggered, and whether legal counsel is engaged. A severity assessment made poorly under pressure — classifying a P1 as a P2 because the Incident Commander wants to avoid the escalation — is the single most common root cause of DFARS reporting failures.
Sections 3 through 6 move away from the control-by-control format used in other family pages and into operational procedure design. This reflects the nature of incident response: the procedures must be usable in a crisis, by a stressed engineer at 02:00, against a real attacker. Section 3 (incident record standard) gives the 23-field mandatory template that every declared incident must populate. Section 4 (external reporting procedures) is the most legally and contractually consequential section — it gives step-by-step DFARS, ICO, and DEFSTAN notification procedures with explicit clock management. Section 5 (evidence preservation) documents the chain-of-custody standard that determines whether forensic evidence can be used in a legal proceeding. Section 6 (exercise programme) defines the four exercises per year and what each exercise report must contain.
The DFARS 72-hour clock — the most operationally critical point in the document
Section 4A opens with a call-out box on the DFARS clock start point that deserves particular emphasis: the clock starts at discovery, not at confirmation of compromise. This single misunderstanding is the most common cause of DFARS reporting violations.
The scenario plays out the same way in most first-time violations: a SIEM alert fires at 09:00 Monday. The security team investigates. By Wednesday morning they confirm that CUI-scope data may have been accessed. The Incident Commander decides to report. 72 hours from Wednesday morning is 09:00 Saturday — they submit in time. But the 72-hour clock started Monday at 09:00. The submission was 48 hours late before the team began drafting it.
The operational fix is a single decision rule: when a potential incident involves a DFARS-covered system, the Incident Commander makes the DFARS scope decision within 4 hours of declaration (not within 4 hours of confirmation). If the system is within the DFARS boundary and the incident could plausibly affect it, report to DIBNet promptly with what is known. DIBNet allows updates — an initial report filed at hour 12 with limited information can be updated at hours 24, 48, and 72 as the investigation progresses. A timely incomplete report is defensible. A late comprehensive report is a violation.
The step-by-step procedure in Section 4A walks through exactly what to do on the DIBNet portal, including the note that the organisation must have a pre-existing DIBNet account. Creating a DIBNet account post-incident is slow and creates further delay. The account must exist before an incident occurs.
Three overlapping 72-hour clocks running simultaneously
Section 4D contains the reporting window comparison table, which is the most important table in the entire IR family page. In a P1 incident involving a DEFSTAN-scope system that also processes personal data, three external reporting obligations activate simultaneously:
DFARS — 72 hours from discovery — to DIBNet (if the system is within the DFARS boundary).
ICO — 72 hours from the controller becoming aware — to ico.org.uk (if personal data is involved and the breach meets the risk threshold).
DEFSTAN — 24 hours from discovery — to the named contracting authority contact (if the system is in DEFSTAN scope).
The DEFSTAN clock is shorter than both others and starts at the same time. An organisation that has tightly drilled DFARS reporting may still miss the DEFSTAN 24-hour window because it falls two days before the DFARS submission is due. The exercise programme (Section 6) specifically includes a DFARS reporting drill, and the assessor checklist (Section 8) asks whether the backup DFARS reporter participated — because the CISO will not always be available when the incident occurs.
The incident record template — 23 mandatory fields
Section 3 provides the 23-field incident record standard. The four fields that are most frequently incomplete in assessments are:
Discovery-to-declaration gap — the time between when the event was first detected and when it was formally declared as an incident. This field is relevant because the DFARS and DEFSTAN clocks start at discovery, not at declaration. An incident where the gap was 36 hours raises an obvious question: why did it take 36 hours to declare? The field forces the IRT to account for that time explicitly.
DFARS 72-hour clock — the discovery timestamp, the 72-hour deadline, and the DIBNet submission confirmation number or a documented N/A with justification. Without this field, there is no evidence the DFARS obligation was even considered.
CUI categories involved — which specific CUI Registry categories (not just "CUI" generically) may have been accessed. This field requires the IRT to have enough familiarity with the CUI Registry to make this determination, which is itself a useful training exercise.
Root cause (on closure) — the technical and process root cause of the incident. This field cannot be populated until the investigation is complete, which often means incidents are closed administratively before the root cause is known. The CISO sign-off on closure should specifically confirm that root cause has been determined.
The exercise programme — four exercises, not one
Section 6 defines four exercises per year: two tabletops (H1 and H2), one technical exercise, and one DFARS reporting drill. Most organisations conduct one tabletop per year and believe that satisfies 3.6.3. The NIST language says "test the capability" — singular — and many assessors accept one annual tabletop as sufficient. DEFSTAN Profile 2, however, expects a tested capability commensurate with the sensitivity of the data, and for OFFICIAL-SENSITIVE handling that implies more than one annual exercise.
The DFARS reporting drill is the most operationally neglected exercise type. The process of logging into DIBNet, finding the correct form, and completing the submission accurately requires practice. The drill does not involve submitting a real report — it uses a printed form or a sandbox environment. But both the CISO and the backup DFARS reporter must demonstrate they can complete the process independently. Finding six in the common findings section addresses the scenario where only the CISO has done this and goes on leave during a real incident.
Cross-linking in Confluence
The AT-IR page connects to five other family pages with direct operational dependencies. Link to AT-AU (the incident detection in 3.6.1 relies on SIEM alerts — the SIEM infrastructure documented in AT-AU is the primary detection mechanism, and SIEM log preservation during an incident is covered in AT-IR Section 5's evidence preservation procedure). Link to AT-SI (the SIEM correlation rules for attack detection in AT-SI 3.14.6 and 3.14.7 are the technical tools that generate the detection signals the IRT relies on). Link to AT-CA (Security Assessment) because 3.6.1's operational capability is one of the controls assessed during the CMMC 3.12.1 security assessment — the SSP's IRP section references this page. Link to AT-PE (the physical incident playbook in Section 4 of the IRP extends into physical protection controls — a server theft incident crosses both IR and PE). And link to AT-PS (Personnel Security) because many insider threat incidents require HR coordination that the IRP must anticipate — the Personnel Security family's leaver procedure has direct incident response implications.
Updated library status
Eleven of the fourteen family pages are now complete:
| Page | Controls | Status |
|---|---|---|
| AT-AC · Access Control | 22 | Complete |
| AT-AT · Awareness and Training | 3 | Complete |
| AT-AU · Audit and Accountability | 9 | Complete |
| AT-CM · Configuration Management | 9 | Complete |
| AT-IA · Identification and Authentication | 11 | Complete |
| AT-IR · Incident Response | 3 | Complete |
| AT-MP · Media Protection | 9 | Complete |
| AT-PE · Physical Protection | 6 | Complete |
| AT-SC · System and Comms Protection | 16 | Complete |
| AT-SI · System and Info Integrity | 7 | Complete |
Three families remain: AT-MA (Maintenance, 6 controls — vendor access, remote maintenance MFA, equipment sanitisation), AT-PS (Personnel Security, 2 controls — background screening and CUI protection during leaver transitions), and AT-CA (Security Assessment, 4 controls — the SSP master document, POA&M process, and continuous monitoring programme). AT-CA is the keystone document that cross-references every other completed family page.