What incident response capabilities does CMMC require?

Incident response sits at the intersection of CMMC's IR family and DFARS 252.204-7012's reporting obligation. Both apply.

The three CMMC IR practices

What the operational capability must include

Per the IR.L2-3.6.1 assessment objectives:

• Preparation. Policy, procedures, IR team designation, training, tools, and contact lists for internal and external notification.
• Detection. SIEM, EDR, user reporting channels, analyst monitoring.
• Analysis. Structured triage, scoping, classification, severity rating.
• Containment. Isolating affected systems, preserving evidence.
• Eradication. Removing the threat.
• Recovery. Restoring services with monitoring.
• User response activities. Communication, notification, training implications.
• Post-incident activities. Lessons learned, capability improvements.

Tracking and reporting (3.6.2)

Per the typical CMMC IR procedure (and consistent with the CMMC Compliance Engine Incident Response Policy template), incident records should include:

• Unique identifier.
• Date and time of detection.
• Affected systems and data.
• Incident classification and severity.
• Actions taken at each phase.
• Final disposition.

Designated officials, both internal and external, receive reports per the OSA's IR plan and the contract's reporting requirements.

"We have never had an incident" is rarely true

The pushback I get most often during interviews is some version of "we have never had an incident, so we do not have any records to show." That is almost always a definition problem. An incident under 3.6.2 is not limited to reportable cyber incidents. It is any event the IR plan triggers on. Operational events that should be tracked, documented, and remediated include:

• Audit logging stopped coming in from a critical source (a 3.3.4 alert fires).
• A privileged account showed an unexplained login or an unusual login location.
• An EDR alert fired and turned out to be a false positive, but the investigation still happened.
• A user reported a suspicious email that turned out to be a phishing attempt.
• An anti-malware tool flagged and quarantined a file.
• A failed account-lockout chain that required investigation.
• A misconfiguration that briefly exposed something it should not have, caught and corrected.

Each one of these should produce a record that shows what was detected, what was investigated, what was determined, and what was remediated or accepted. The assessor wants to see the IR process running. They are not waiting to hear that the OSA was hit by ransomware.

If you genuinely have no such records, that itself is usually a problem. It typically means detection is not tuned to alert on anything actionable, or that operational events are happening and nobody is tracking them. The fix is to lower alerting thresholds where appropriate, exercise the IR process on planned events (tabletop after-actions, simulated alerts, response drills), and produce the documentation trail from those exercises. Walking into an assessment with an empty incident log when you have a live network and live users is not credible.

Contact lists are often missed

A gap I see often in IR readiness is contact lists. The OSA has an IR plan, has detection tooling, has run a tabletop, but the list of who to call when an incident happens is either missing, out of date, or covers only the internal team. Build the contact list early and refresh it on a defined cadence.

The contact list should cover at minimum:

• Internal contacts. IR team members, executives who need to be notified (CEO, CISO, General Counsel), legal, HR, communications, IT operations, and the Affirming Official.
• External contacts. The prime contractor's POC, the DoD POC, the C3PAO if the incident bears on certification, your cyber insurance carrier, your outside legal counsel, your MSP or MSSP, your CSP support contact, the FBI field office or other law enforcement, and any other party your IR plan or contract obligates you to notify.

Each entry should include name, role, organization, primary contact method, secondary contact method, and the conditions that trigger that contact. Review and refresh the list at the cadence the SSP states. Contact lists go stale fast, and stale contact information at 5pm on a Friday is worse than no list.

Include the contacts in testing when possible. Tabletops where only the internal IR team participates miss the operational reality of an incident. When you can, include the prime contractor's POC, your outside counsel, or your cyber insurance carrier in the exercise. A tabletop where the prime POC actually participates surfaces gaps in the notification path that no internal-only exercise will catch. Where external participation is not practical, simulate it: assign someone to play the role and document what would have been communicated and to whom. The test evidence should show that the contact list was exercised, not just that the technical IR team played out the scenario.

DFARS 252.204-7012 cyber incident reporting

For contractors holding contracts with DFARS 252.204-7012, the clause requires:

• Report within 72 hours of discovery of a cyber incident affecting covered defense information.
• Report to DoD via DIBNet at https://dibnet.dod.mil. A medium assurance certificate (DoD-approved external certificate authority) is required to access DIBNet.
• The report submission triggers a DoD damage assessment process the contractor must support.
• Submit malicious software discovered (if any) to DoD via the DIBNet portal.
• Preserve and protect images of affected systems and packet capture evidence for at least 90 days from submission of the report, to allow DoD review.
• Provide DoD personnel access to additional information or equipment necessary to conduct the damage assessment.

Testing (3.6.3)

The OSA must test the incident response capability. The Scoping Guide and CAP do not prescribe a frequency; the OSA defines based on its risk-based policy. Common patterns include annual tabletop exercises plus role-specific drills (technical IR, executive notification). Whatever cadence the SSP states is the cadence the assessor will expect to see evidence of. Include the contact list (internal and external, with simulated external participants where actual participation is not practical) in the test scope.

Common errors

• Documented IR plan but no operational capability. A plan that no one has practiced fails 3.6.1's operational requirement.
• "We have never had an incident" with an empty incident log. An incident under 3.6.2 includes operational events (logging dropped from a source, EDR alerts, suspicious emails, anti-malware quarantines, unusual logins). If the OSA has no records at all, either detection is not tuned to fire on actionable events or events are happening and no one is tracking them. Either way, the assessor sees a gap.
• Missing or stale contact lists. An IR plan that does not include current internal and external contacts (prime POC, DoD POC, outside counsel, cyber insurance carrier, MSP, CSP support, law enforcement, executives) fails when the OSA actually has to make calls under pressure.
• Testing only the internal technical team. 3.6.3 testing should exercise the contact list end-to-end. Include external contacts where possible; where not, simulate them and document what would have been communicated.
• No testing evidence. 3.6.3 requires testing. Tabletop exercises with documented after-action reports satisfy this.
• Missing DIBNet access. A contractor who discovers a 7012-reportable incident at 5pm Friday and has to scramble for a medium assurance certificate has lost the 72-hour clock.
• Failing to preserve evidence for 90 days post-report. 7012 explicitly requires this.
• Confusing internal-only IR with 7012 reporting. Both apply: internal handling per 3.6.1 and 3.6.2 plus external reporting to DoD per 7012(c).
• Not coordinating with the prime contractor. Subcontractors must report to the prime as well as to DoD; the prime needs to know.