3.6.1 — Have a Plan

The One-Liner

If your IR plan is “figure it out when it happens,” you fail — and when a breach hits, you’ll prove it.

What It Says

Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.

What It Actually Means

You need a documented, tested incident response plan that covers six phases — each one assessed independently:

1. Preparation. Roles and responsibilities defined. Contact lists current. Tools ready. The team knows the plan exists and has read it. Includes the DFARS 252.204-7012 requirement to report cyber incidents to DIBCAC within 72 hours.

2. Detection. How incidents are identified — SIEM alerts, user reports, EDR detections, vendor notifications. Feeds from your monitoring capabilities (3.14.6) and logging (3.3.1).

3. Analysis. How you determine scope, severity, and impact. Who triages. What classification system you use (e.g., severity levels). How you determine whether CUI was affected.

4. Containment. How you stop the bleeding — isolating affected systems, blocking malicious IPs, disabling compromised accounts. Short-term and long-term containment strategies.

5. Recovery. How you restore systems to normal operation — reimaging, restoring from backups, verifying integrity. Includes validation that the threat is eliminated before reconnecting.

6. User response activities. How you communicate with affected users, management, and external parties. Includes the 72-hour DIBCAC notification and any contractual notification requirements to the prime contractor.

The plan must be more than a document — it must be an operational capability. The team must know it exists, understand their role, and have practiced it.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Is an operational incident-handling capability established?	Documented IR plan with assigned team, tools, and procedures
2	Does it include preparation?	Roles, contacts, tools, DIBCAC reporting procedure documented
3	Does it include detection?	Detection sources identified — SIEM, EDR, user reports
4	Does it include analysis?	Triage procedure, severity classification, CUI impact assessment
5	Does it include containment?	Short-term and long-term containment procedures
6	Does it include recovery?	System restoration, backup recovery, integrity verification procedures
7	Does it include user response activities?	Communication plan: internal notifications, 72-hour DIBCAC reporting, prime contractor notification

---

What to Have Ready on Assessment Day

Documents they’ll review: Incident response policy; incident response plan; contact lists; escalation procedures; DIBCAC reporting procedures; system security plan; training records for IR team; tabletop exercise records; any past incident records

People they’ll talk to: Personnel with incident handling responsibilities; information security personnel; management with IR oversight; anyone on the IR contact list

Live demos they’ll ask for: “Walk me through what happens when you detect a potential breach.” “Show me your IR plan. Who knows about it?” “How do you report to DIBCAC within 72 hours? Show me the procedure.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Show me your incident response plan. When was it last updated?”
• “Walk me through the six phases — preparation through user response.”
• “Who is on your IR team? Do they know their roles?”
• “How do you report to DIBCAC within 72 hours? Show me the procedure and the DIBNet portal access.”
• “Does the plan specifically address incidents involving CUI?”
• “Has the IR team been trained on this plan?”
• “Show me your escalation path — who gets notified at each severity level?”

Real-World Example

A defense contractor maintains a 15-page IR plan covering all six phases. The IR team: IT Security Lead (incident commander), two system administrators (technical response), company attorney (legal/contractual), and the CEO (executive authority). Contact list includes personal phones for after-hours. Detection feeds from Sentinel alerts, Defender for Endpoint, and a user reporting email (security@company.com). Severity levels: Low (policy violation), Medium (malware contained), High (active intrusion), Critical (CUI breach). For Critical incidents: the IT Security Lead activates the full team within 1 hour, initiates containment, begins evidence preservation, and the attorney starts the 72-hour DIBCAC reporting clock. The company has DIBNet portal credentials tested annually. The plan is reviewed annually and updated after every tabletop exercise. All IR team members have signed acknowledgment that they’ve read and understand the plan.

---

Where Companies Trip Up

No written plan. The team knows what to do informally but nothing is documented. The assessor needs a document covering all six phases. Write it down.

Plan doesn’t address CUI. A generic IT incident response plan that never mentions CUI, DFARS 252.204-7012, or the 72-hour reporting requirement. The plan must specifically address CUI-related incidents.

Nobody knows the plan. The document exists in a SharePoint folder but the IR team hasn’t read it. Distribute it, train the team on it, and get signed acknowledgments.

No 72-hour reporting procedure. The plan covers detection through recovery but doesn’t address DIBCAC notification. Include the procedure, the DIBNet portal URL, login credentials, and who is authorized to file the report.

---

How to Talk About This

To a CEO or Board

We have a documented IR plan with clear roles, a trained team, and a tested 72-hour DoD reporting procedure. Every team member knows their role. The plan is reviewed annually and updated after every exercise.

To an Engineering Team

IR plan: 6 phases, RACI matrix, severity classifications, CUI-specific procedures. 72-hour DIBCAC procedure with DIBNet access verified annually. Contact list with personal phones. Evidence preservation checklist. Plan reviewed annually, updated after tabletops and real incidents. All IR team members: signed acknowledgment.

---

Connected Requirements

Requirement	Why it matters here
3.6.2 — Track and Report	Incident tracking and reporting procedures are part of this capability
3.6.3 — Test the Plan	The plan established here must be tested
3.14.6 — Watch the Network	Network monitoring feeds the detection phase
3.3.1 — Log Everything	Audit logs provide evidence for the analysis phase

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: IR.L2-3.6.1 | SPRS Weight: 5 points | POA&M Eligible: No