CMMC NUGGET #22

Incident Response Requirements

IR.L2-3.6.1: Establish an Operational Incident-Handling Capability

Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities

This is the whole lifecycle, not just “have a plan document.” Assessors expect to see each phase actually addressed: how you prepare before an incident happens, how you detect one, how you analyze what’s going on, how you contain it, how you recover, and how affected users are informed and supported along the way. A plan that stops at “detect and contain” and never addresses recovery or user communication is incomplete.

IR.L2-3.6.2: Track, Document, and Report Incidents

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

This is where most organizations lose ground, and the original guidance you’d find in a lot of compliance overviews stops short of the part that actually matters most: who is “external,” specifically?

For defense contractors, this control doesn’t exist in isolation. DFARS 252.204-7012 layers mandatory, specific reporting obligations on top of it that go well beyond “report incidents to somebody”:

• Cyber incidents must be reported to the DoD Cyber Crime Center (DC3) within 72 hours of discovery
• Reports go through the DCISE Cybersecurity Reporting Portal at https://icf.dcise.cert.org
• You must preserve images of all affected systems for 90 days following the report, not delete, not reimage, not “we cleaned it up already”
• DoD may request access to additional information or equipment for damage assessment, and you need to be positioned to provide it

That 72-hour clock starts at discovery, not at confirmation, not at “once we’re sure it’s serious.” An organization can build a technically excellent internal IR plan, contain an incident well, document everything internally, and still fail this control entirely by missing the DC3 reporting window because nobody built it into the plan. This is one of the most consequential gaps a contractor can carry into an actual incident, not just an assessment.

Beyond DC3, depending on the nature of what’s compromised, your organization may also have reporting obligations to CISA under separate federal incident reporting frameworks. The takeaway for your IR plan: “report to designated officials and/or authorities” needs to resolve to actual names, actual portals, and actual deadlines before an incident happens, not be figured out in the moment.

Common reasons organizations fail this control even when they think they’re covered:

• Underestimating severity. An incident dismissed as “minor” still needs documentation, and the DC3 threshold for reportable incidents is broader than most people assume.
• No defined procedure. An IR plan without a specific, step-by-step tracking and reporting process leaves documentation to memory and good intentions.
• Resource pressure. Containment gets the attention; the paperwork gets pushed to “later,” and later doesn’t meet a 72-hour deadline.
• Wrong priorities. Treating documentation as secondary to technical response, when both are required, at the same time, on the clock.
• Not knowing the deadline exists. Plenty of organizations have simply never heard of the 72-hour DC3 requirement until it’s the reason they failed an assessment, or worse, the reason they missed it during a real incident.

IR.L2-3.6.3: Test the Organizational Incident Response Capability

This control gets a single line in a lot of guidance, and that undersells what assessors actually expect. “Testing” means more than confirming the plan exists on paper.

• Tabletop exercises with documented participant lists and after-action reports
• Testing that reflects realistic scenarios, not a generic template exercise nobody’s customized to the organization’s actual environment
• Evidence the plan gets updated based on what testing reveals, a test that never changes anything wasn’t really a test

Periodic, documented, and demonstrably acted upon. A plan that’s never been tested is a plan you’re hoping works, not one you know works.

IR.L2-3.6.1 Plan addresses detection and containment but skips recovery and user response activities
IR.L2-3.6.2 No DFARS 252.204-7012 reporting procedure defined; 72-hour DC3 deadline unknown to the team
IR.L2-3.6.2 System images not preserved for the required 90 days following a reported incident
IR.L2-3.6.3 IR plan exists but has never actually been tested, or testing isn’t documented

All three controls belong under Incident Response in your SSP, but IR.L2-3.6.2 specifically should reference your DFARS 252.204-7012 obligations by name, including the DC3/DIBNet reporting process and the 90-day system image retention requirement. Don’t leave the external reporting piece as a vague reference to “designated authorities.”

For each control your SSP should document:

• The specific technical and procedural implementation, including the DC3/DIBNet reporting workflow
• The policy governing detection-to-report timelines and evidence preservation
• Who is responsible for each phase of the incident lifecycle and who owns external reporting specifically
• How and how often the plan is tested, with evidence retained

Three controls, one very real clock. If your IR plan doesn’t already name DC3, DIBNet, and a 72-hour window, that’s worth fixing before an incident forces the question. Reach out to DTC’s C3PAO team if you want a second look at your plan while the clock isn’t running.