Deretti Cyber Labs CMMC Desk · Domains · Incident Response

Incident response.

Capability, reporting, and testing — three requirements, deliberately narrow.

Incident Response is 3 of Level 2’s 110 requirements — one of the smallest families, alongside Awareness & Training and Risk Assessment. It asks whether an organization can actually run through handling an incident when one happens, whether it tracks and reports what happened, and whether it has ever tested that capability instead of assuming it would work. It is not the same thing as the 72-hour DIBNet reporting clock most defense contractors have heard about — that comes from a different clause, covered in section 02 below.

This page explains the family. It does not replace the requirement text or assessment objectives.

01What this family protects

Incident Response protects an organization’s ability to respond competently when something does go wrong, rather than improvising for the first time under pressure. It is deliberately one of the smallest families in Level 2 — three requirements — because CMMC does not prescribe how incident response has to work. It only asks that a real capability exists, that what happens gets tracked and reported, and that the capability has actually been tested.

02The rule says

All 3 requirements, condensed to their operative sentence. NIST SP 800-171 Rev. 2 §3.6 has the full text and discussion for each; Source Library covers when to open it.

§Requirement
3.6.1Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
3.6.2Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
3.6.3Test the organizational incident response capability.
Not the same clock

The familiar “72 hours” figure belongs to DFARS 252.204-7012, a companion clause that requires reporting a cyber incident involving covered defense information to DIBNet within 72 hours of discovery. It is a contractual reporting duty that runs on its own timeline, independent of these three IR requirements and independent of any CMMC assessment. IR.3.6.2 asks that an organization track, document, and report incidents — it does not itself set a 72-hour deadline, and meeting 3.6.1–3.6.3 does not by itself satisfy 7012’s reporting duty, or the reverse. See the Glossary’s DIBNet entry and The System, section 03.

03In practice

IR’s three requirements sound minimal because they are — Level 2 does not ask for a formal incident-response plan document, a dedicated team, or specific tooling. It asks for three things to be true: the organization can actually run through preparation, detection, analysis, containment, recovery, and user notification when something happens (3.6.1); it tracks and reports what happened, internally and to whichever officials or authorities the situation calls for (3.6.2); and it periodically tests that capability instead of assuming it would work (3.6.3).

For a small shop, this usually means a short written procedure — who does what, in what order, who gets notified — rather than a formal plan modeled on a much larger organization’s playbook. What matters to an assessor is whether the practice is real: has anyone actually run it, even in a tabletop, and would the people involved know what to do without opening a document for the first time mid-incident.

Where 3.6.2’s reporting fans out matters. “Designated officials and/or authorities both internal and external” can include, depending on an organization’s specific contracts and situation, a prime contractor’s flow-down notice requirement, cyber-insurance carrier notification, state breach-notification law, and — separately from this family entirely — DFARS 252.204-7012’s 72-hour DIBNet report when covered defense information is involved. 3.6.2 asks that reporting happen; it does not itself define the DIBNet clock or make 7012 apply.

04Where it fails

More often than not, the gap is a procedure that exists only as a document — written once, filed away, never walked through. 3.6.3’s testing requirement exists precisely because an untested plan tends to fall apart on contact with an actual incident, usually at the handoff points: who has authority to make a containment call, and who is supposed to notify whom.

A second gap is conflating 3.6.2 with the DFARS 7012 DIBNet clock (see the callout above) — an organization that has never mapped out its 7012 reporting obligation separately from its general IR practice discovers the 72-hour window is already ticking before anyone has looked up what it requires.

05What evidence may look like

A short written incident-handling procedure covering roles, escalation, and notification; records from a past incident or a tabletop exercise, including what was tracked and who was notified; a note on which external parties — prime, insurer, DIBNet, regulators — the organization would need to notify under its specific contracts; and a date showing when the capability was last tested.

06At the shop

At the shop

Blanchard Tool & Machining is the desk’s fictional composite (any resemblance to an actual company is coincidental). After IT flagged a suspicious login attempt on the CAD/CAM share last year, Blanchard’s two-person IT team walked their written procedure step by step for the first time outside a drill: contain the affected account, preserve login logs before they rotated out, and notify the engineering lead and the regional MSP. The event turned out to be a lockout from a machinist’s own mistyped password, not an intrusion — but because DFARS 7012 was in play on that contract, IT already knew what would have triggered a DIBNet report if it had been real, mapped out in advance rather than discovered mid-incident. Blanchard re-runs the same walkthrough as a short tabletop once a year — the kind of test 3.6.3 asks for — without treating it as a fire drill.

07Commonly confused with

DFARS 252.204-7012’s 72-hour clock. Covered above (section 02) — a companion-clause reporting duty, not one of these three requirements.

Audit & Accountability (AU). AU’s records are frequently what an incident-response process draws on during 3.6.1’s analysis step; AU doesn’t investigate anything on its own, and IR doesn’t define what gets logged. See Audit & Accountability.

09Sources

DocumentWhat it’s for
NIST SP 800-171 Rev. 2, §3.6Full requirement text and discussion for all 3 IR requirements.
NIST SP 800-171AAssessment objectives — how an assessor determines MET for each IR requirement.
DFARS 252.204-7012The companion clause setting the 72-hour DIBNet incident-reporting obligation — separate from, and adjacent to, this family.
32 CFR 170.4Defines “CMMC Level 2 security requirement” and ties the 800-171 R2 families to the CMMC Program.