CMMC Level 2Implementation GuideJune 11, 2026· 10 min read
How to Actually Implement CMMC Level 2 Incident Response: A Practitioner's Guide
The Incident Response domain has only three practices, but each one carries real weight. Practice 3.6.1 requires a functioning IR capability across all six response phases. Practice 3.6.2 requires reporting incidents to the DoD within 72 hours. Practice 3.6.3 requires testing that capability. Small defense contractors consistently underestimate the documentation and operational readiness these three practices require.
Why IR Gets More Scrutiny Than the Practice Count Suggests
Three practices sounds like the lightest domain in CMMC. It is not. The DoD cares deeply about incident response because compromises of contractor systems are how adversaries access defense information. The 72-hour reporting requirement in DFARS 252.204-7012 is a contractual obligation that predates CMMC and carries its own consequences. Assessors treat the IR domain seriously and will push beyond surface-level documentation to verify that a real capability exists.
The most common IR failure mode for small contractors is having a plan document that exists but was never operationalized. A plan sitting in a SharePoint folder that no one on the IT team has read is not an IR capability. The people who would respond to an incident need to know the plan, know their roles, and have practiced using it.
Critical reminder: DFARS 252.204-7012 requires reporting cyber incidents to the DoD Cyber Crime Center (DC3) within 72 hours of discovery, via the DIBNet portal at dibnet.dod.mil. This reporting obligation is contractual and exists regardless of CMMC certification status. A CMMC assessment finding for IR is a compliance gap. A missed 72-hour report during an actual incident is a contract violation.
Practice 3.6.1 — Establish an Operational Incident-Handling Capability
3.6.1
Build a real IR capability that covers all six phases. Document it. Make sure your team knows it.
This practice requires an operational incident-handling capability covering preparation, detection, analysis, containment, recovery, and user activities. "Operational" is the key word. A documented plan satisfies the evidence requirement, but assessors want to see that the organization can actually execute it.
The six IR phases and what CMMC expects from each:
Preparation: IR plan is documented, roles are assigned, contact lists are current, tools are available. IR team has been trained on the plan. External resources (legal, PR, MSSP, IR retainer) are identified and under contract or agreement before an incident occurs.
Detection and Reporting: Mechanisms exist to detect potential incidents. This includes security alerts from EDR, SIEM, or MDR; user reporting channels (who does an employee call when they think they've been phished?); and monitoring of in-scope systems. Detection is where logging and audit controls from the AU domain connect to IR.
Analysis: Once a potential incident is detected, the team can analyze it to determine scope, severity, and whether it meets the definition of a reportable incident. This phase requires someone with enough technical skill to review logs, examine affected systems, and make informed severity decisions.
Containment: The team has the authority and the technical ability to contain an incident. This means isolating affected systems from the network, revoking credentials, blocking malicious traffic, and preventing the incident from spreading. Containment procedures should be documented per scenario type (ransomware, data exfiltration, account compromise, etc.).
Recovery: Systems can be restored from clean backups or rebuilt. The IR plan addresses validation of restored systems before returning them to production, post-incident credential resets, and notification to affected parties. Recovery time and recovery point objectives should be documented.
User Activities: Users have a defined role in IR: how to report suspected incidents, what not to do (do not turn off or wipe a potentially compromised device before IT can image it), and how to communicate during an active incident.
How to implement:
Write an IR plan that addresses each phase with specific procedures, not just general descriptions. The plan should be specific enough that a competent IT professional who has never seen it before could execute the core response steps
Assign named roles: Incident Coordinator, Technical Lead, Communications Lead, and Management Escalation contact at minimum. Include backup contacts for each role
Maintain a current contact list: internal IR team, legal counsel, cyber insurance carrier's IR hotline, any external MSSP or IR retainer, and DoD reporting contacts (DC3 and your Contracting Officer)
Define incident severity levels (low, medium, high, critical) with criteria for each level and escalation triggers
Create response playbooks for the most likely incident types in your environment: ransomware, phishing with credential capture, unauthorized access, and lost/stolen device at minimum
Common mistake: An IR plan that lists NIST 800-61 phases as section headers but provides no actionable procedures. Assessors will read the plan and ask scenario-based questions. If the only answer is "we would figure it out," the capability is not operational.
Practice 3.6.2 — Track, Document, and Report Incidents
3.6.2
Every incident gets documented. Reportable incidents go to DoD within 72 hours.
This practice has two components: internal incident tracking and documentation, and external reporting to the DoD for incidents that meet the DFARS reporting threshold.
Internal tracking and documentation:
Use a ticketing system or dedicated IR log to record every incident, including the date and time of detection, description of the incident, systems involved, severity classification, actions taken at each phase, and resolution status
Maintain an incident register that summarizes all incidents by date, type, and severity. This register is part of your evidence package and demonstrates operational use of the IR capability over time
Preserve evidence according to your evidence preservation procedures. Do not wipe or reimage a compromised system before forensic imaging if the incident may require regulatory reporting or legal action
Document your incident analysis, including indicators of compromise (IOCs), root cause (when determinable), and corrective actions taken
External reporting to DoD:
Register on the DIBNet portal (dibnet.dod.mil) before you have an incident. The registration process takes time and doing it during an active incident adds unnecessary pressure
A reportable cyber incident under DFARS 252.204-7012 is any compromise or suspected compromise of a covered contractor information system. When in doubt, report. The consequences of under-reporting exceed the inconvenience of over-reporting
The 72-hour clock starts from discovery, not from confirmation. If your team identifies suspicious activity at 9 AM Monday and determines by 3 PM Monday that it's a confirmed incident, the clock started at 9 AM Monday
Your IR plan should include a checklist of what to include in the DC3 report: contract numbers, company POC, description of the incident, affected systems, affected CUI categories, and actions taken
Notify your Contracting Officer Representative (COR) in addition to DC3 reporting. The COR notification is a separate obligation under some contracts
Common mistake: Waiting to report until the investigation is complete. The 72-hour reporting requirement is based on discovery, not resolution. You can file an initial report with the information available at 72 hours and submit updates as the investigation progresses. Filing a complete report at hour 96 because you wanted to be thorough is a late report.
Practice 3.6.3 — Test the Incident Response Capability
3.6.3
The IR capability must be tested. A plan that has never been exercised is not a capability.
This practice requires testing the organization's IR capability to validate that it works. The most accessible testing method for small to mid-sized contractors is the tabletop exercise.
How to implement tabletop exercises:
Conduct a tabletop exercise at least annually. Quarterly is better for maturing programs
Select a realistic scenario relevant to your environment. Common scenarios: ransomware encrypts three file servers, a phishing email results in credential theft and account compromise, a laptop with CUI is stolen from an employee's vehicle
Invite all IR role holders plus management. The tabletop is valuable precisely because it surfaces gaps and disagreements about who does what when
Walk through the scenario phase by phase. At each step, ask the team: What would you do? Who makes that decision? How long would that take? What tools do you need?
Document everything: the scenario, attendees, discussion at each phase, gaps identified, and action items to resolve those gaps
Update the IR plan after every tabletop to incorporate lessons learned. An IR plan with a "Last Tested" date and revision history is strong evidence
Beyond tabletops:
Functional exercises test actual IR tools and capabilities. For example: can the team actually isolate a workstation from the network within the containment time target? Can backups actually be restored to a clean system?
Red team or penetration testing exercises, if in scope, generate real incident scenarios the IR team must respond to
Post-incident reviews after real incidents count as testing. Document the review and any plan updates that result
Common mistake: Conducting a tabletop exercise but treating it as a check-box activity with no documentation and no follow-through on identified gaps. The value of a tabletop is the gaps it surfaces. If no gaps were identified, either the scenario was too easy or the exercise wasn't challenging enough. Document findings and show evidence that gaps were addressed.
Quick Reference: Tools and Resources for IR Implementation
Need
Tool / Resource
Notes
Incident tracking
Jira Service Management, ServiceNow, Freshservice, or a structured SharePoint list
Any ticketing system with a defined IR workflow satisfies the documentation requirement
DoD reporting portal
DIBNet (dibnet.dod.mil)
Register before you need it. The DC3 reporting form is submitted here
Endpoint detection and response
Microsoft Defender for Endpoint, Huntress, CrowdStrike Falcon Go
EDR provides the detection capability that feeds the IR process; Huntress is particularly popular with MSP-managed contractors
IR retainer / external support
MSSP with IR capability, regional IR firms, cyber insurance IR panel firms
Having a retainer in place before an incident significantly reduces response time and cost
Forensic imaging
FTK Imager (free), Magnet ACQUIRE
Free tools for preserving evidence from compromised systems before remediation
Backup and recovery
Veeam, Azure Backup, Acronis
Tested, offsite, immutable backups are the foundation of ransomware recovery; backups must be tested to count
Tabletop scenario resources
CISA Tabletop Exercise Packages (CTEPs), free at cisa.gov
CISA provides free, ready-to-use tabletop scenarios including ransomware and supply chain attacks
Free resource worth knowing: CISA publishes Tabletop Exercise Packages (CTEPs) at no cost, including scenarios specifically designed for critical infrastructure and defense contractors. Using a CISA CTEP and documenting the exercise satisfies 3.6.3 without paying for an external facilitator.
Connecting IR to the Rest of Your CMMC Program
The IR domain does not stand alone. Effective incident response depends on the Audit and Accountability domain (AU) for the logs that enable detection and analysis. It depends on Configuration Management for the system inventory that scoping an incident requires. It depends on Access Control for the ability to revoke credentials quickly during containment.
When building your IR capability, trace the dependencies: if an incident occurred right now, could you identify affected systems (CM), review the relevant logs (AU), isolate the affected systems (CM/AC), revoke compromised credentials (AC/IA), and restore from backup (contingency planning)? Gaps in IR are often symptoms of gaps elsewhere in the program.
Need a Ready-to-Customize IR Plan?
Our CMMC Level 2 Incident Response Plan template covers all three IR practices with formal policy language, six-phase response procedures, a DoD reporting checklist, tabletop exercise guidance, and fill-in-the-blank role assignments. Built for defense contractors who need a plan that works, not just one that reads well.
DFARS 252.204-7012 requires reporting cyber incidents to the DoD Cyber Crime Center (DC3) within 72 hours of discovery. This is a contractual obligation that exists separately from CMMC practice 3.6.2. Reporting is done through the DIBNet portal at dibnet.dod.mil. The report must include the contract number, company information, a description of the incident, which systems were affected, and what CUI may have been compromised.
Under DFARS 252.204-7012, a reportable cyber incident is any actual or suspected unauthorized access, use, disclosure, modification, or destruction of information on a covered contractor information system. This includes ransomware attacks, confirmed data exfiltration, unauthorized access by an external actor, and compromise of credentials used on in-scope systems. Near-misses and unsuccessful attempts do not require external reporting but should be tracked internally. When uncertain whether an event is reportable, err toward reporting.
CMMC does not require a dedicated security team by name, but practice 3.6.1 requires an operational incident-handling capability covering all six response phases. For small contractors, this can be a documented plan that assigns IR roles to existing IT staff, with clear escalation paths and contact information for external resources like a managed security service provider or IR retainer firm. The key is that the capability is documented, roles are assigned, and the plan has been tested.
Practice 3.6.3 requires testing the IR capability. A tabletop exercise is a facilitated discussion where the IR team walks through a hypothetical incident scenario, discusses what they would do at each stage, identifies gaps in the plan, and documents lessons learned. Tabletops do not require actual system shutdowns or live attacks. They can be done in a conference room in two to three hours. The output is a written record of the exercise, what gaps were found, and what updates were made to the IR plan as a result. Annual tabletops are a defensible testing cadence for CMMC.
An MSP or MSSP can be part of your IR capability, but the organization retains responsibility for having a documented, tested IR capability. You need an IR plan that names the MSP as a response resource, defines escalation procedures to engage them, and includes contact information. The plan should also address what the organization does internally while waiting for the MSP to respond, how incidents are declared and communicated, and who has decision-making authority. A verbal agreement with your IT provider does not satisfy the practice.