How to Build an Incident Response Plan for CMMC Compliance

An incident response plan transforms chaos into coordinated action when security incidents strike. For CMMC compliance, a documented plan is not optional—assessors will verify you have operational incident handling capability, and your plan is the foundation of that capability.

An incident response plan (IRP) is a documented set of procedures for detecting, responding to, and recovering from security incidents.

This guide walks you through building an incident response plan that meets CMMC requirements and actually helps during real incidents.

What Your Plan Must Cover

CMMC requires incident handling capability covering six phases. Your plan must address each:

1. Preparation

Activities before incidents occur:

• Establishing the incident response team
• Defining roles and responsibilities
• Training and exercises
• Acquiring tools and resources
• Creating communication templates
• Building relationships with external resources

2. Detection

Identifying that incidents have occurred:

• Monitoring and alerting mechanisms
• Log analysis procedures
• User reporting channels
• Threat intelligence integration
• Detection tool configuration

3. Analysis

Understanding incident scope and impact:

• Initial assessment procedures
• Classification and prioritization
• Scope determination
• Impact analysis
• Evidence collection

4. Containment

Stopping incidents from spreading:

• Short-term containment actions
• Long-term containment strategies
• Isolation procedures
• Communication during containment
• Decision criteria for containment approaches

5. Recovery

Restoring normal operations:

• Eradication of threats
• System restoration procedures
• Verification of recovery
• Return to normal operations
• Enhanced monitoring post-incident

6. User Response

Supporting affected users:

• Notification procedures
• Support resources
• Credential resets
• Training reinforcement
• Communication updates

Incident Response Plan Structure

Organize your plan logically:

Section 1: Introduction and Purpose

• Plan purpose and objectives
• Scope (what systems and incidents are covered)
• Plan maintenance and review schedule
• Document control information

Section 2: Roles and Responsibilities

Define who does what during incidents:

Role	Responsibilities	Primary Contact	Backup Contact
Incident Response Lead	Overall coordination, decisions	[Name, phone, email]	[Backup info]
Technical Lead	Technical investigation, containment	[Name, phone, email]	[Backup info]
Communications Lead	Internal/external communication	[Name, phone, email]	[Backup info]
Management Sponsor	Resource authorization, escalation	[Name, phone, email]	[Backup info]

For small organizations, one person may fill multiple roles. Document this explicitly.

Section 3: Incident Classification

Define incident categories and severity levels:

Categories:

• Malware infection
• Unauthorized access
• Data breach/exposure
• Denial of service
• Phishing compromise
• Lost/stolen device
• Insider threat
• Physical security incident

Severity Levels:

Level	Definition	Response Time	Examples
Critical	Immediate threat to CUI or operations	Immediate	Active data exfiltration, ransomware
High	Significant impact, requires urgent response	Within 4 hours	Confirmed unauthorized access
Medium	Moderate impact, timely response needed	Within 24 hours	Contained malware
Low	Minimal impact, routine response	Within 72 hours	Blocked attack attempts

Section 4: Detection and Reporting

How incidents are identified and reported:

• Security monitoring tools and alerts
• User reporting procedures
• Help desk escalation criteria
• External notification sources
• Initial documentation requirements

Section 5: Response Procedures

Step-by-step procedures for each incident category:

Example: Malware Infection Response

1. Isolate affected system from network
2. Notify Incident Response Lead
3. Document initial observations
4. Preserve system state (memory, disk)
5. Identify malware type and behavior
6. Determine scope of infection
7. Assess potential CUI exposure
8. Remove malware or rebuild system
9. Restore from clean backup
10. Verify system integrity
11. Return to production with monitoring
12. Complete incident documentation

Create similar procedures for each incident category.

Section 6: Communication

Who to notify and when:

Internal Communication:

• Incident response team notification
• Management escalation criteria
• Employee communication guidelines
• Status update frequency

External Communication:

• DoD DC3 notification (72-hour requirement)
• Prime contractor notification
• Law enforcement contact
• Legal counsel engagement
• Customer/partner notification criteria
• Media response (if applicable)

Include contact templates to save time during incidents.

Section 7: Evidence Handling

Preserving evidence for investigation:

• Evidence collection procedures
• Chain of custody documentation
• Preservation requirements (90 days minimum for DoD)
• Forensic imaging procedures
• Secure evidence storage

Section 8: Recovery Procedures

Restoring normal operations:

• System restoration from backup
• Rebuild procedures
• Verification and testing
• Enhanced monitoring post-recovery
• Return to production criteria

Section 9: Post-Incident Activities

Learning from incidents:

• Incident documentation requirements
• Lessons learned meetings
• Plan updates based on findings
• Control improvements
• Training updates

DoD-Specific Requirements

Your plan must address defense contractor obligations:

72-Hour Notification

Document your procedure for reporting to DC3:

• Who is authorized to submit reports
• DIBNet portal access credentials
• Information gathering checklist
• Report submission process
• Evidence preservation requirements

Prime Contractor Notification

If you are a subcontractor:

• Notification requirements per contracts
• Contact information for primes
• Information to include in notifications
• Coordination procedures

Evidence Preservation

DFARS requires 90-day preservation:

• What to preserve (images, logs, malware)
• How to preserve (forensic standards)
• Where to store evidence
• Chain of custody documentation

Testing Your Plan

An untested plan provides false confidence:

Tabletop Exercises

Walk through scenarios verbally:

• Gather incident response team
• Present realistic scenario
• Discuss response step by step
• Identify gaps and improvements
• Document findings

Sample Scenario: “Friday at 4:30 PM, your EDR alerts to suspicious PowerShell activity on three workstations in engineering. Initial analysis shows data being copied to an external cloud storage service. Two of the affected users have access to CUI. Walk through your response.”

Functional Tests

Test specific capabilities:

• Can you restore systems from backup?
• Do communication trees work?
• Can you access DIBNet portal?
• Do isolation procedures work?
• Can you collect forensic images?

Full Exercises

Simulate actual incident response:

• More resource-intensive
• Tests end-to-end capabilities
• Reveals integration issues
• Best for mature programs

Testing Frequency

• Tabletop exercises: At least annually
• Functional tests: Quarterly for critical capabilities
• Full exercises: Every 2-3 years or after major changes

Document All Testing

Keep records of:

• Exercise date and participants
• Scenario or capabilities tested
• Observations and findings
• Identified improvements
• Follow-up actions taken

Plan Maintenance

Keep your plan current:

Review Triggers:

• Annual scheduled review
• After significant incidents
• After exercises reveal gaps
• When personnel change
• When systems or tools change
• When contracts or requirements change

Version Control:

• Date all versions
• Track changes between versions
• Maintain change history
• Archive previous versions

Distribution:

• Ensure the current version is accessible
• Distribute updates to all team members
• Consider both electronic and physical copies
• Accessible during incidents (not just on compromised systems)

Common Plan Mistakes

Mistake 1: Too Long and Complex

A 100-page plan nobody reads is useless during incidents. Keep procedures concise and actionable.

Mistake 2: Generic Boilerplate

Plans copied from templates without customization do not reflect your environment. Customize everything.

Mistake 3: Missing Contact Information

Outdated phone numbers and emails waste critical time. Update contacts quarterly.

Mistake 4: No DoD Reporting Procedures

Plans that do not address 72-hour DC3 notification miss a critical CMMC requirement.

Mistake 5: Never Tested

Plans that have never been exercised often fail during real incidents. Test regularly.

Mistake 6: Only Accessible on the Network

If ransomware encrypts your network, can you access your plan? Keep offline copies.

Sample Incident Response Plan Outline

Use this outline as a starting point:

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Plan Review and Maintenance
2. Incident Response Team
2.1 Team Structure
2.2 Roles and Responsibilities
2.3 Contact Information
2.4 External Resources
3. Incident Classification
3.1 Incident Categories
3.2 Severity Levels
3.3 Classification Criteria
4. Incident Handling Phases
4.1 Preparation
4.2 Detection and Analysis
4.3 Containment
4.4 Eradication and Recovery
4.5 Post-Incident Activities
5. Incident-Specific Procedures
5.1 Malware Response
5.2 Unauthorized Access Response
5.3 Data Breach Response
5.4 Phishing Response
5.5 Lost/Stolen Device Response
6. Communication
6.1 Internal Notification
6.2 External Notification
6.3 DoD Reporting (72-Hour)
6.4 Communication Templates
7. Evidence Handling
7.1 Collection Procedures
7.2 Chain of Custody
7.3 Preservation Requirements
8. Testing and Training
8.1 Testing Schedule
8.2 Exercise Procedures
8.3 Training Requirements
Appendices
A. Contact Lists
B. Communication Templates
C. Checklists
D. Forms and Logs

Key Takeaways

Your incident response plan must cover preparation, detection, analysis, containment, recovery, and user response. Include specific procedures for common incident types and address DoD 72-hour reporting requirements explicitly.

Keep the plan practical and concise—responders need actionable guidance, not lengthy documents they will not read during crises. Test the plan at least annually and update it when gaps are discovered.

Maintain multiple copies, including offline access, so your plan is available even when systems are compromised.

Related Articles:

• CMMC Incident Response Requirements
• 72-Hour DoD Breach Notification Requirements
• SIEM Solutions for CMMC Compliance
• Backup and Disaster Recovery for CMMC Compliance
• NIST SP 800-61 Rev 2 – Computer Security Incident Handling Guide
• NIST SP 800-171 Rev 2
• DFARS 252.204-7012

Official Sources: This article is based on NIST SP 800-61 Rev 2 (Computer Security Incident Handling Guide), NIST SP 800-171 Revision 2, and DFARS 252.204-7012 requirements.

Building an incident response plan from scratch can be overwhelming. Contact Greypike for expert help developing a plan tailored to your organization. For Level 1 certification, Obolix includes incident response templates and walks you through compliance in a week or less—so you’re prepared before incidents happen.