Building an Incident Response Plan That Satisfies CMMC and DFARS 7012

Let me paint a scenario I've seen play out too many times: A small defense contractor discovers suspicious activity on their network at 4:47 PM on a Friday. The IT guy is out. Nobody knows who to call. By Monday morning, the 72-hour DFARS reporting window is nearly closed, evidence has been overwritten, and leadership is scrambling to figure out if Controlled Unclassified Information (CUI) was compromised.

This is what happens when your incident response plan is a document sitting in a SharePoint folder that nobody has read since it was written three years ago.

After 30 years in cybersecurity — and as a CIO who has managed real incidents involving sensitive government data — I can tell you that the quality of your incident response plan is the difference between a manageable security event and a contract-ending catastrophe.

With CMMC Phase 2 assessments beginning in November 2026, assessors won't just check if you have an incident response plan. They'll check if it works.

Why Incident Response Matters More Than You Think

Most small defense contractors focus their compliance efforts on access controls, encryption, and system hardening. Those are important. But here's what keeps me up at night: a solid perimeter means nothing if you can't detect, contain, and report a breach within the required timeframes.

Consider the regulatory landscape you're operating in:

• DFARS 252.204-7012 requires you to report cyber incidents involving covered defense information to the DoD within 72 hours of discovery via DIBNet.
• NIST SP 800-171 (the backbone of CMMC Level 2) includes an entire family of Incident Response controls (IR 3.6.1 through 3.6.3).
• CMMC Level 2 requires demonstrated implementation of these controls — not just documentation.
• False Claims Act exposure means that claiming compliance when you can't actually execute your IR plan creates legal liability.

The 72-hour clock doesn't start when you finish your investigation. It starts when you discover the incident. That distinction has caught more contractors off guard than any technical vulnerability.

The NIST 800-171 Incident Response Controls

Before building your plan, understand exactly what the controls require. NIST SP 800-171 Rev 2 specifies three IR controls:

3.6.1 — Establish an operational incident-handling capability

This is your foundation. You need:

• Defined incident response procedures
• An identified incident response team (even if it's two people)
• Preparation activities including tools, communication channels, and training
• The ability to actually handle incidents — not just document them

3.6.2 — Track, document, and report incidents

Every incident needs a paper trail:

• Detection timestamps
• Actions taken and by whom
• Evidence preserved
• Reporting to appropriate authorities (including the DoD for CUI-related incidents)
• Lessons learned documentation

3.6.3 — Test the organizational incident response capability

This is where most small contractors fail their assessments. You can't just write a plan and file it away. You need evidence that you've tested it — tabletop exercises, simulations, or actual incident after-action reviews.

The Six Phases of an Effective Incident Response Plan

Your plan should follow the NIST SP 800-61 framework, adapted for the defense contracting environment. Here's how to build each phase so it actually works under pressure.

Phase 1: Preparation

Preparation isn't glamorous, but it's where incidents are won or lost. Before anything happens, you need:

Define your incident response team. For a 20-person contractor, this doesn't need to be a dedicated SOC. It might be:

• Incident Commander: The person who makes decisions (often the business owner or CIO)
• Technical Lead: Your most capable IT person
• Communications Lead: Handles notifications to DoD, legal counsel, and affected parties
• External Support: A pre-contracted incident response firm on retainer

Establish communication channels. When your primary email is compromised, how does the team communicate? Document:

• Primary and backup communication methods (out-of-band — think personal cell phones, a dedicated Signal group)
• Contact information for all team members, updated quarterly
• Escalation procedures with specific time thresholds

Pre-stage your tools. At minimum, you need:

• A forensic imaging tool (FTK Imager is free)
• Network traffic capture capability
• A secure, isolated system for analysis
• Pre-formatted incident documentation templates
• Access to DIBNet for DFARS reporting (test this before you need it)

Identify your CUI boundaries. You can't protect what you can't find. Map exactly where CUI lives in your environment — which systems, which file shares, which cloud services. This is directly tied to your System Security Plan (SSP) and makes incident scoping dramatically faster.

Pro tip: If you haven't logged into DIBNet recently, do it this week. I've seen contractors discover their credentials are expired at the worst possible moment — 60 hours into a 72-hour reporting window.

Phase 2: Detection and Analysis

Detection is where small contractors are most vulnerable. You probably don't have a 24/7 SOC, and that's okay. But you need something.

Minimum detection capabilities:

• Endpoint Detection and Response (EDR): Solutions like Microsoft Defender for Business, CrowdStrike Falcon Go, or SentinelOne provide automated detection that doesn't require a full-time analyst. This is non-negotiable in 2026.
• Log aggregation: At minimum, collect and retain logs from firewalls, authentication systems, and any system that processes CUI. A basic SIEM or even a centralized syslog server works.
• Email security: Business email compromise is the number one attack vector for defense contractors. Use a solution with advanced threat protection.

Analysis framework — when something triggers an alert:

1. Validate the alert. Is this a true positive or noise? Check against known baselines.
2. Determine scope. Which systems are affected? Is CUI involved?
3. Assess severity. Use a predefined scale:
   • Critical: Active data exfiltration of CUI, ransomware spreading across CUI systems
   • High: Confirmed compromise of a system that processes CUI
   • Medium: Compromise of a non-CUI system with potential lateral movement paths to CUI
   • Low: Isolated malware on a system with no CUI access
4. Document everything. Timestamps, screenshots, log excerpts. Start your incident timeline immediately.

The CUI question drives everything. If the incident involves — or might involve — systems that store, process, or transmit CUI, your DFARS reporting obligation is triggered. When in doubt, assume CUI involvement and report.

Phase 3: Containment

Containment is about stopping the bleeding without destroying evidence. This is where many organizations make critical mistakes.

Short-term containment (first hours):

• Isolate affected systems from the network (disconnect, don't power off)
• Block identified malicious IPs/domains at the firewall
• Disable compromised user accounts
• Preserve volatile memory before it's lost (this is where your pre-staged tools matter)

Long-term containment (while you investigate):

• Stand up clean systems for critical business operations
• Implement additional monitoring on potentially affected systems
• Change credentials for any accounts that may be compromised
• If CUI was on the compromised system, ensure backup copies are secured

Critical mistake to avoid: Don't wipe systems before preserving evidence. I've watched contractors panic-reimage compromised machines, destroying the forensic evidence needed for both the DoD damage assessment and their own understanding of what happened. Contain first. Image second. Remediate third.

Phase 4: Eradication

Once you've contained the threat and preserved evidence:

• Remove malware, backdoors, and unauthorized access mechanisms
• Patch the vulnerability that was exploited
• If the root cause was a phishing email, sweep for similar messages across all mailboxes
• Verify eradication with a thorough scan using updated signatures

For CUI-involved incidents: Document exactly what you removed and how. The DoD may request damage assessment information under DFARS 7012(f), and you need to demonstrate that the threat was fully eliminated.

Phase 5: Recovery

Bring systems back online methodically:

• Restore from known-good backups (verify backup integrity before you need them)
• Monitor restored systems closely for 48-72 hours post-recovery
• Implement any additional controls identified during the investigation
• Confirm CUI integrity — verify that CUI data hasn't been modified or corrupted

Validate before declaring victory. Run vulnerability scans. Check for persistence mechanisms. Verify that the attacker's access has been fully revoked.

Phase 6: Lessons Learned

This is the phase everyone skips — and it's the phase that CMMC assessors will specifically ask about.

Within two weeks of incident closure:

• Conduct a formal after-action review with all involved parties
• Document what worked, what didn't, and what needs to change
• Update your incident response plan based on findings
• Update your risk assessment if the incident revealed new threats
• Brief leadership on the incident and any resource requirements

Save everything. Your after-action report is evidence of NIST 800-171 control 3.6.3 (testing the IR capability). Real incidents — and how you handled them — are the strongest evidence you can present to a CMMC assessor.

The 72-Hour DFARS Reporting Requirement: A Step-by-Step Guide

When a cyber incident affects covered defense information, DFARS 252.204-7012 requires reporting within 72 hours. Here's exactly what that looks like:

What triggers the reporting requirement?

Any cyber incident that affects a covered contractor information system or the covered defense information residing therein. This includes:

• Unauthorized access to systems containing CUI
• Exfiltration or potential exfiltration of CUI
• Malware on systems that process CUI
• Any compromise that could affect the confidentiality, integrity, or availability of CUI

Where do you report?

Through DIBNet. You'll need:

• A DoD-approved Medium Assurance Certificate (from a DoD-authorized Certificate Authority)
• An active DIBNet account
• The ability to access the portal (don't wait until an incident to set this up)

What information is required?

At minimum, your report should include:

• Company name and point of contact
• Date the incident was discovered
• Location and description of affected systems
• Type of compromise or incident
• Description of CUI involved (types, not content)
• Impact assessment (what was affected and how)

What happens after you report?

The DoD Cyber Crime Center (DC3) may:

• Request additional information
• Ask for forensic images or malware samples
• Conduct a damage assessment
• Require you to preserve evidence for 90 days

The 90-day preservation requirement is often missed. After reporting, you must retain all images, logs, and forensic data for at least 90 days, and provide it to the DoD upon request. Plan your storage accordingly.

Common Incident Response Failures in CMMC Assessments

Having consulted on numerous CMMC readiness reviews, I consistently see the same failures:

1. "Paper plans" with no testing evidence

An IR plan that hasn't been tested is just creative writing. Assessors will ask: "When did you last test this plan? Show me the evidence." If your answer involves awkward silence, you're not passing that control.

Fix: Conduct at least one tabletop exercise per year. It takes 90 minutes, costs nothing, and generates the evidence you need. Document who participated, the scenario, decisions made, and lessons learned.

2. No CUI scoping in the IR plan

Generic incident response plans downloaded from the internet don't address CUI-specific requirements. Your plan needs to explicitly address:

• How you determine if CUI is involved
• The DFARS reporting trigger and timeline
• CUI-specific containment procedures
• Evidence preservation for DoD damage assessments

3. Contact information is outdated

It sounds trivial, but I've seen IR plans with phone numbers for employees who left two years ago. Review and update contact information quarterly.

4. No relationship with external incident response support

If you're a 15-person company and you experience a sophisticated intrusion, you'll need help. Establish a relationship with an IR firm before the incident. Many offer retainer agreements that guarantee response time.

5. No integration with the System Security Plan

Your IR plan should reference your SSP, and your SSP should reference your IR plan. They need to tell the same story about your environment, your CUI boundaries, and your security controls.

Building Your Plan: A Practical Template

Here's a skeleton you can adapt. The key is making it yours — specific to your organization, your people, and your environment.

Section 1: Purpose and Scope

• What this plan covers (all systems in the CMMC assessment scope)
• Regulatory requirements (DFARS 7012, NIST 800-171, CMMC)
• Definition of a security incident in your context

Section 2: Roles and Responsibilities

• Incident Response Team roster with contact information
• Decision authority matrix (who can isolate a system, who can authorize a shutdown)
• External contacts (IR firm, legal counsel, cyber insurance carrier, DoD DC3)

Section 3: Incident Categories and Severity Levels

• Your severity scale (Critical/High/Medium/Low)
• Response time requirements for each level
• Escalation triggers

Section 4: Detection and Reporting Procedures

• How incidents are detected (tools, user reporting, external notification)
• Internal reporting chain
• DFARS 72-hour reporting procedures with DIBNet instructions

Section 5: Response Procedures by Incident Type

• Malware/ransomware
• Unauthorized access
• Data exfiltration
• Insider threat
• Business email compromise
• Denial of service

Section 6: Evidence Preservation

• Chain of custody procedures
• Forensic imaging process
• 90-day retention requirements per DFARS

Section 7: Recovery and Restoration

• System restoration procedures
• Post-incident monitoring requirements
• Return-to-normal criteria

Section 8: Communication Plan

• Internal communication templates
• DoD notification template
• Customer/partner notification procedures (if applicable)
• Media response (if applicable)

Section 9: Testing and Maintenance

• Tabletop exercise schedule (minimum annual)
• Plan review and update triggers
• Training requirements for IR team members

The Policy Foundation

An incident response plan tells you what to do during an incident. An incident response policy establishes the organizational commitment to incident response — the authority, the requirements, and the governance structure.

You need both. The policy is what auditors check first. The plan is what they check second.

If you're building your security policy framework from scratch, you'll need an incident response policy that aligns with your broader security governance. This is one of the core policies that every defense contractor needs, and it must be tailored to your specific environment and CUI scope. At TalonPoint Security, our PolicyPack includes an incident response policy template specifically designed for defense contractors pursuing CMMC compliance — written to integrate with the other 11 core policies you need for a complete compliance framework.

Tabletop Exercise: A Scenario to Run This Month

Here's a ready-to-use tabletop exercise scenario. Gather your IR team, walk through it, and document the results.

Scenario: At 2:15 PM on a Wednesday, your EDR solution alerts on suspicious PowerShell execution on a workstation belonging to your contracts manager. The workstation has access to a shared drive containing CUI — specifically, technical drawings for a DoD contract. Initial analysis shows the PowerShell script attempted to connect to an external IP address. The contracts manager reports clicking a link in an email that appeared to be from your prime contractor.

Discussion questions:

1. Who takes the lead? What's the first phone call?
2. How do you determine if CUI was exfiltrated?
3. At what point do you report to DC3 via DIBNet? What information do you include?
4. How do you contain the threat without disrupting ongoing contract work?
5. The prime contractor calls asking if their data is safe. What do you tell them?
6. What evidence do you preserve, and how?

Walk through each question. Time the exercise. Document the answers and any gaps you discover. That documentation is your CMMC assessment evidence for control 3.6.3.

What Good Looks Like

A mature incident response capability for a small defense contractor doesn't require a SOC or a six-figure budget. It requires:

• A plan that people have actually read — Keep it under 20 pages. Brief your team annually.
• Tested procedures — One tabletop exercise per year minimum. Two is better.
• Working tools — EDR deployed, logs collected, DIBNet access verified.
• Clear CUI boundaries — You know exactly which systems are in scope.
• External support on speed dial — An IR firm retainer or at minimum a known point of contact.
• A culture that reports — Employees know how to report suspicious activity without fear of blame.

The contractors who handle incidents well aren't the ones with the biggest budgets. They're the ones who planned, practiced, and built muscle memory before the crisis hit.

Start Today, Not After the Assessment

CMMC Phase 2 assessments start in November 2026. If your incident response plan is outdated, untested, or nonexistent, now is the time to fix it — not when the assessor is scheduling their visit.

Build the plan. Run the tabletop. Update your contacts. Test your DIBNet access. These aren't expensive activities, but they require intention and follow-through.

When the 72-hour clock starts ticking at 4:47 PM on a Friday, you'll be glad you did.

---

TalonPoint Security helps defense contractors build practical, assessment-ready cybersecurity programs. Need help developing your incident response plan or preparing for CMMC? Contact us.