Incident Response Playbook for Defense Contractors

Word count: ~2,050 Specificity markers hit: (1) NIST/CMMC control references — IR.L2-3.6.1, 3.6.2, 3.6.3, SI.L2-3.14.2 (2) Cost/time estimates — 72-hour DC3 reporting window, tabletop $5K–$15K (3) Tool/product names — DFARS 252.204-7012, DIBNet portal, Jira/ServiceNow for ticketing (4) Common mistake — playbook written for general IT, not CUI-specific (5) Decision point — when to call DC3 vs. when an incident is below reporting threshold

---

Incident Response Playbook for Defense Contractors

A playbook is different from an incident response plan. Your IR plan is the strategic document — it defines your IR capability, your team structure, and your overall approach. Your playbook is the operational document — it's what your analyst opens at 1 a.m. when an alert fires. It tells them exactly what to do, in what order, without needing to think through the strategy from scratch.

Defense contractors need playbooks that reflect the specific requirements that come with handling Controlled Unclassified Information: the 72-hour DC3 reporting obligation, the CUI preservation requirements, the contractual notifications to prime contractors. A generic IT incident response playbook doesn't cover any of that, and your assessor will ask whether your procedures address those specifics.

Here's what goes into a defense contractor IR playbook, how to structure it, and what to avoid.

Why Defense Contractor Playbooks Are Different

Most IR playbooks are written with internal IT concerns as the primary driver: restore services, contain the damage, get back to normal. Defense contractors have additional obligations that change the calculus:

The 72-hour DC3 reporting requirement under DFARS 252.204-7012 applies to cyber incidents involving covered defense information (CDI) — which includes CUI. From the moment you discover an incident, the clock runs. You have 72 hours to report to the DoD Defense Cyber Crime Center (DC3) via the DIBNet portal (dibnet.dod.mil). Miss that window and you're in violation of your contract.

Forensic preservation is required under the same clause. You must preserve images of all systems involved in the incident for 90 days, available to DoD on request. "We wiped and reimaged" is not an acceptable incident response for a defense contractor — you need to capture forensic images before remediation begins.

Prime contractor notification is also required if you're a subcontractor. Your prime needs to know about incidents affecting CDI on your systems.

None of this appears in a standard IT playbook. Building it in from the start is far easier than retrofitting it after your assessor flags the gap.

The Structure of a Working Playbook

A defense contractor playbook should have two tiers: a general section that covers all incidents, and scenario-specific appendices that walk through the steps for the incident types your organization is most likely to face.

General Section: Every Incident

Incident classification table. Every alert that comes in gets classified before anything else happens. Four or five severity levels work: Critical (active compromise of CUI systems), High (confirmed intrusion, scope unclear), Medium (suspicious activity under investigation), Low (policy violation, no confirmed breach). Classification determines whether you activate the full IR team, who gets notified, and whether the DC3 clock starts.

Reporting thresholds. Explicitly define when the DC3 reporting obligation triggers. Under DFARS 252.204-7012, reportable incidents involve covered defense information and/or affect "the ability of the contractor to provide operationally critical support." Write the decision criteria in plain language, not legal language, so your analyst can make the call at 1 a.m. without a lawyer on speed dial.

Contact list. Keep it current. Include: IR Lead and backup, system owners for CUI systems, IT administrator on-call, legal counsel contact, cyber insurance carrier breach response line, DC3 reporting portal URL and phone (410-981-0104), prime contractor security contact (if applicable), and MSSP 24/7 number if you use one. Review this list quarterly — people change roles and companies.

Incident documentation requirements. Every incident gets a ticket. Define the required fields: date/time discovered, date/time first alerted, systems involved, data potentially exposed, classification, actions taken (with timestamps), outcome, and lessons learned. Jira, ServiceNow, or even a shared spreadsheet work as long as the log is protected from modification and accessible to the assessor.

Scenario Appendices

Write a separate appendix for each major incident type. Keep each one to two pages, structured as a numbered checklist. Here are the four scenarios every defense contractor playbook should cover:

---

Appendix A: Ransomware

1. Confirm ransomware activity (encrypted files, ransom note, behavioral indicators in EDR).
2. Immediately isolate affected systems — remove from network, do NOT power off. Unplugging the network cable or disabling the NIC via EDR preserves forensic state.
3. Identify patient zero — which system, which user, what was the initial infection vector?
4. Assess scope — map which systems are encrypted, which share network segments with CUI systems.
5. Capture forensic images of affected systems before any remediation. This is a DFARS requirement.
6. Determine whether CUI systems are affected. If yes, start the 72-hour DC3 clock from this moment; document the time.
7. Contact cyber insurance carrier breach response line — they often have IR firms on retainer at no additional cost.
8. Notify IR Lead, legal counsel.
9. Begin DC3 report via DIBNet if CUI is involved. Complete within 72 hours of discovery.
10. Notify prime contractor security contact if applicable.
11. Assess decryption options (backup restoration preferred; ransom payment requires legal and insurance authorization).
12. Conduct forensic analysis before reimaging.
13. Reimage from known-good backups; restore from clean backup.
14. Verify clean state before reconnecting to network.
15. Complete post-incident documentation; update playbook.

---

Appendix B: Phishing / Credential Compromise

1. Receive alert or user report of suspicious email or unauthorized account activity.
2. Classify: did the phishing succeed? Was a payload delivered, or did the user just receive the email?
3. If credential compromise confirmed: disable the account immediately.
4. Check which systems the compromised account has access to, including CUI systems.
5. Review authentication logs for the past 30 days for the compromised account — look for logins from unusual IPs, times, or locations.
6. Identify whether CUI was accessed. If yes, start the 72-hour DC3 clock.
7. If payload was delivered: isolate the endpoint (same steps as ransomware step 2).
8. Pull the phishing email from any other mailboxes it was delivered to (admin email sweep).
9. Reset credentials for the compromised account and any accounts with the same password (check with the user).
10. Assess whether MFA was bypassed. If yes, determine how and patch the gap.
11. Complete post-incident documentation.

---

Appendix C: Unauthorized Access to CUI Systems

1. Confirm unauthorized access — review access logs, identify the access path and the user/system involved.
2. Determine whether the access was intentional (insider threat) or accidental (misconfigured permission).
3. Revoke the access path immediately.
4. Assess which CUI was accessible and whether it was viewed, copied, or modified.
5. If exfiltration is suspected: start the 72-hour DC3 clock.
6. Preserve forensic artifacts — logs, access records, system images if the compromised system was used as an intermediary.
7. If insider threat: notify HR and legal before any employee confrontation. Preserve logs before account modification.
8. Notify prime contractor if CDI was potentially exposed.
9. Complete DC3 report if required.
10. Review access control policies and least-privilege assignments after incident closure.

---

Appendix D: Malware Detection (Non-Ransomware)

1. Confirm malware detection via EDR, antivirus, or SIEM alert.
2. Identify the malware type (use EDR behavioral data, file hashes against VirusTotal, vendor intelligence).
3. Isolate affected endpoint.
4. Assess lateral movement — did the malware communicate with other internal systems? Check firewall and SIEM logs.
5. Check for C2 communications — outbound connections to unusual external IPs or domains.
6. If C2 connections are confirmed, CUI may have been exfiltrated. Start DC3 clock.
7. Capture forensic image before remediation.
8. Remediate: remove malware, patch the vulnerability that allowed entry, reimage if necessary.
9. Block identified indicators of compromise (IOCs) at the firewall and email gateway.
10. Complete post-incident documentation.

---

Testing the Playbook

IR.L2-3.6.3 requires testing your IR capability. The playbook is only useful if your team has practiced using it.

Run a tabletop exercise at least annually. A facilitator presents a scenario — ransomware found on a file server at 6 p.m. on a Thursday — and walks your team through the decision points. Does everyone know their role? Does anyone hesitate on whether to call DC3? Is the 72-hour window well understood?

Tabletop exercises with an external facilitator cost $5,000–$15,000 and take a half day. They consistently surface more issues than any amount of document review. The most common discovery: team members don't know which incidents require DC3 reporting, and the playbook's reporting threshold language is unclear. Fix that before your assessor finds it.

After every tabletop or real incident, update the playbook. Document the changes and the date. Your assessor will ask when the playbook was last reviewed and what prompted the update.

Common Mistake: The Generic Playbook

The most common IR playbook failure is importing a template from the internet and calling it done. Generic templates cover incident classification, containment, eradication, recovery — the standard NIST SP 800-61 phases. They don't mention DC3, DIBNet, DFARS 252.204-7012, CDI, forensic preservation windows, or prime contractor notifications.

Your assessor is specifically looking for evidence that you understand the defense contractor obligations. A playbook with zero defense-specific content is a signal that the organization is applying generic IT compliance practices to a CMMC requirement, rather than actually building IR capability for a CUI environment.

Fix this by adding a "Defense Contractor Obligations" section to your general playbook that explicitly covers the DFARS reporting requirements, preservation requirements, and notification chain. Then make sure every applicable scenario appendix references those obligations with a specific step that says: "Determine whether CDI is involved. If yes, initiate DC3 reporting within 72 hours."

What Your Assessor Expects

For IR.L2-3.6.1, the assessor will review your IR plan and playbook. They'll confirm it's been communicated to relevant personnel and that the personnel you interview can describe their roles and the notification chain.

For IR.L2-3.6.2, they'll look for evidence of incident tracking. Show your incident log — even if it only contains exercises. They'll also probe whether you know how to report to DC3, when reporting is required, and what the 72-hour window means operationally.

For IR.L2-3.6.3, show your tabletop documentation: the scenario, attendance list, findings, and evidence that you updated the playbook after. If you've had a real incident in the past few years, that counts as testing — document the after-action review.

The playbook that passes isn't the longest one. It's the one your team has read, practiced, and can execute without consulting a lawyer or a compliance advisor at 1 a.m.

---

CTA: If your current IR playbook doesn't include DC3 reporting steps and forensic preservation requirements, it's missing the elements your assessor will specifically check. Update it before you schedule your C3PAO assessment.