The Three IR Requirements
The CMMC Incident Response domain contains three requirements, but it carries disproportionate weight in assessments. Every defense contractor subject to CMMC Level 2 must implement all three. The IR domain is where the gap between having a policy and actually being prepared is most visible to a C3PAO assessor — and most consequential when a real incident occurs.
| IR.L2-3.6.1 | Establish an operational incident-handling capability. You must have a functioning IR capability covering preparation, detection, analysis, containment, recovery, and post-incident user response. The word “operational” is deliberate — a plan on paper that has never been exercised does not satisfy this requirement. The capability must be real, tested, and ready to activate. |
| IR.L2-3.6.2 | Track, document, and report incidents. Incidents must be tracked through their full lifecycle, documented with sufficient detail to support analysis and reporting, and reported to appropriate officials and authorities — including the DoD through DIBNet when the incident involves covered defense information. Tracking means a formal incident log or ticketing system, not an email chain. |
| IR.L2-3.6.3 | Test your incident response capability. The plan must be tested through exercises, tabletop simulations, or actual response activities, and testing must be documented. This is the requirement most commonly found as a gap during assessments — organizations have written IR plans but no evidence of ever having exercised them. Annual testing is the standard expectation. |
The 72-Hour Reporting Requirement
DFARS 252.204-7012 requires contractors to report cyber incidents to the DoD within 72 hours of discovery. This is the most operationally urgent compliance obligation in the CMMC framework — it runs on a real-time clock from the moment you become aware of an incident, with no grace period for investigation, confirmation, or internal approvals.
The reporting destination is the DIBNet portal at dibnet.dod.mil. Submitting requires a DIBNet account with a DoD-approved medium assurance certificate. If you do not have a DIBNet account and you handle CUI, getting one is an immediate action item — you cannot register during an active incident under a 72-hour clock.
| What triggers reporting | Unauthorized access to systems containing CUI. Malware affecting covered contractor information systems. Data exfiltration confirmed or suspected. Ransomware on systems in scope. Unauthorized disclosure of CUI. Any incident resulting in actual or potential compromise of covered defense information. |
| What does not trigger reporting | Blocked login attempts with no successful access. Phishing emails not opened or clicked. Vulnerability scans from authorized sources. Security alerts investigated and found to have no impact on CUI systems. Routine security events that did not affect covered defense information. |
| What to include in the report | Company name and CAGE code. Contract numbers for affected systems. Date and time of discovery. Nature of the compromise — systems affected, data potentially exposed. Actions taken. Whether the incident is ongoing or contained. The DoD may request additional information after initial submission. |
| Notify your prime | If you are a subcontractor, notify your prime contractor immediately in addition to submitting to DIBNet. Your incident may affect the prime's own reporting obligations. The prime's 72-hour clock may start from their discovery of your incident — which could precede your own discovery if they detect anomalous activity in shared systems first. |
Evidence Preservation: The 90-Day Requirement
Following a reportable cyber incident, DFARS 252.204-7012 requires preserving images of all known affected systems and all relevant monitoring and packet capture data for at least 90 days from the date of your incident report submission. This supports DoD damage assessment activities and potential follow-on investigation.
Your incident response procedure must include a forensic imaging step before any remediation begins. Do not wipe, reimage, or otherwise modify affected systems until forensic images are captured. The 90-day clock runs from report submission, not from when you complete remediation.
| What to preserve | Full disk images of affected systems. Memory captures if the system is still running. Security log exports from SIEM, endpoint detection, and network monitoring tools. Packet capture data if network monitoring was active during the incident. Email headers and message data if the incident involved email. |
| Storage requirements | Preserved evidence must be stored securely for the full 90-day period, isolated from production systems and access-controlled. Document who has access to forensic images and maintain a chain of custody record. If the DoD requests access to preserved data, you must be able to provide it. |
| Malware submission | If malware was involved, the DoD Cyber Crime Center (DC3) may request a malware sample submission. Your IR plan should include a procedure for malware submission to DC3 and a designated point of contact. DC3 submission procedures are available at dc3.mil. |
Incident Classification and Severity
Your IR plan must define incident severity levels and the response actions associated with each. This is what assessors look for when evaluating your detection and analysis capability. A plan that does not differentiate between a blocked phishing attempt and an active ransomware attack does not demonstrate a mature IR capability.
| CRITICAL | Active data breach, ransomware, complete system compromise, confirmed CUI exfiltration. Requires immediate containment, mandatory DIBNet reporting within 72 hours, executive notification, legal counsel engagement. |
| HIGH | Malware infection, unauthorized access confirmed, data exposure risk present. Rapid containment and forensic imaging required. DIBNet reporting likely required. Senior management notification and detailed documentation throughout response. |
| MEDIUM | Successful phishing with credential compromise, policy violations with potential CUI exposure, suspicious activity requiring investigation. DIBNet reporting to be determined based on investigation outcome. |
| LOW | Attempted attacks blocked, minor policy violations, failed phishing attempts, security alerts with no confirmed CUI impact. Requires logging and documentation. No DIBNet reporting required. Monitor for pattern escalation. |
Every incident regardless of severity should be logged. Low-severity blocked events still create the audit trail assessors want to see — evidence that your detection capability is functioning and your team is responding to the threat landscape.
Building an IR Plan That Passes Assessment
A C3PAO assessor evaluating your IR domain is looking for evidence of a real, operational capability. The assessment considers whether your IR plan exists, whether it is comprehensive, whether personnel know their roles, and whether the plan has been tested. All four elements must be present.
| 1. Preparation | Define what constitutes an incident. Establish roles including an incident commander with a named backup. Set up incident tracking infrastructure. Register for DIBNet. Establish communication trees for notifying the DoD, prime contractors, and internal stakeholders. Document escalation thresholds by severity level. |
| 2. Detection & Analysis | Define detection sources — SIEM alerts, endpoint tools, user reports, external notifications. Establish triage procedures for categorizing incidents by severity and scope. Document how you determine whether CUI is involved and whether DIBNet reporting is required. |
| 3. Containment | Define immediate containment actions for different incident types: network isolation, account disablement, system quarantine. Document the forensic imaging requirement and who is responsible for executing it before any affected system is modified. |
| 4. Eradication | Remove the threat from your environment: malware removal, closure of exploited vulnerabilities, revocation of compromised credentials, verification that the attacker no longer has access. Document verification steps — assessors want to see that eradication is confirmed, not assumed. |
| 5. Recovery | Restore affected systems from verified clean backups or known-good states. Verify restoration before returning to production. Monitor restored systems for recurrence. Document the recovery timeline and what was restored. |
| 6. Post-Incident Review | Conduct a lessons-learned review after every significant incident and after every IR exercise. Document what happened, what gaps the response revealed, and what changes are being made. Post-incident review records are strong evidence that your IR capability is genuinely operational and improving. |
Testing Your IR Capability (3.6.3)
IR.L2-3.6.3 requires testing, and testing requires documentation. A tabletop exercise conducted annually — where your IR team walks through a simulated incident scenario and tests their procedures — satisfies the requirement if properly documented. Documentation must show the date, participants, scenario used, findings, and corrective actions identified.
| Tabletop exercises | A facilitated walkthrough of a realistic incident scenario with your IR team. Test detection and escalation procedures, the DIBNet reporting process, forensic imaging steps, and communication protocols. Document scenario, participants, actions taken, gaps identified, and remediation plan. Annual minimum. |
| Functional exercises | Team members actually execute procedures rather than discussing them — running the DIBNet portal process in a test environment, executing network isolation on a test system. Produces stronger evidence than tabletop alone and demonstrates genuine operational readiness. |
| Post-incident reviews | Documented reviews of actual incidents serve as evidence of real-world IR capability testing. A well-documented review of a real incident is more compelling to an assessor than a tabletop exercise with a fabricated scenario. |
| What to avoid | Exercises where the only documentation is a calendar invite. Tests not involving the actual IR roles defined in your plan. Any exercise where the outcome is “everything worked fine” with no gaps identified — assessors are skeptical of perfect exercises. Re-testing after significant IR plan updates. |
What 1TEN Tracks for the IR Domain
1TEN's incident response module handles both the compliance documentation requirements and the operational response workflow in a single interface. When an incident is logged, the platform captures the full record — incident number, type, severity, detection method, systems affected, CUI involvement, business impact, and initial response actions — and automatically flags whether the incident triggers DFARS 252.204-7012 DIBNet reporting based on CUI involvement and system scope.
Every incident logged in 1TEN creates a permanent, timestamped audit record satisfying IR.L2-3.6.2. The incident log is directly available as assessment evidence during a C3PAO review. Tabletop exercise records — scenario, participants, findings, corrective actions — are documented in the platform and linked directly to IR.L2-3.6.3 as assessment evidence.
Common IR Assessment Failures
The IR domain produces a consistent pattern of assessment findings. Knowing what assessors commonly find lets you close gaps before your C3PAO engagement begins.
| No DIBNet account | The most basic gap — and one of the most common. Contractors discover during assessment prep that they lack the required medium assurance certificate or that their account registration lapsed. Register and verify your DIBNet access before assessment, not during an incident. |
| Plan exists, no testing evidence | A written IR plan satisfies part of IR.L2-3.6.1 but not IR.L2-3.6.3. Without documented testing evidence — tabletop records, after-action reports, drill documentation — the testing requirement is an automatic finding. This is the most common IR domain gap in pre-assessment readiness reviews. |
| Undefined roles | An IR plan assigning activities to “IT staff” or “management” without named roles and backup assignments does not demonstrate operational readiness. Assessors want named roles (incident commander, technical lead, communications lead, legal contact) with clear escalation paths. |
| No incident log history | A contractor operating for years with no incident log records raises credibility questions. Every organization experiences security events. Absence of any log history suggests either the tracking requirement is not being met or incidents are occurring but not recorded — both are findings. |
| Remediation before imaging | Contractors who experienced past incidents and remediated without capturing forensic images violated the preservation requirement even if unaware of it. This becomes a finding when assessors ask about previous incidents and the response was to restore from backup without evidence preservation. |
| No sub escalation procedure | Prime contractors sometimes lack procedures for receiving and acting on incident notifications from their subcontractors. If a sub experiences a CUI breach, the prime's own reporting obligations may be triggered. IR plans must address the supply chain dimension, not just internal incidents. |