IR.L2-3.6.1: Establish an operational incident-handling capability

📖 What This Means

This CMMC practice requires organizations to create a structured process for detecting, analyzing, and responding to cybersecurity incidents. It involves setting up a dedicated team or assigning roles responsible for handling incidents, documenting procedures, and ensuring that incidents are managed effectively. For example, if an employee clicks on a phishing link, the incident-handling team should quickly identify the threat, isolate affected systems, and mitigate the risk. Another example is responding to unauthorized access attempts by blocking the source IP and investigating the breach. This capability ensures that incidents are addressed promptly to minimize damage and maintain compliance.

🎯 Why It Matters

Without an operational incident-handling capability, organizations risk prolonged exposure to threats, leading to significant data breaches, financial losses, and reputational damage. For instance, the 2021 Colonial Pipeline ransomware attack caused widespread disruption and cost millions in recovery. The DoD emphasizes this control to ensure contractors can swiftly respond to incidents, protecting sensitive defense information. A robust incident-handling capability reduces downtime, limits data exfiltration, and demonstrates compliance with CMMC requirements.

✅ How to Implement

1. Assign an incident response team with defined roles (e.g., AWS Security Hub Administrator).
2. Enable cloud-native monitoring tools like AWS CloudTrail or Azure Sentinel for incident detection.
3. Create automated playbooks for common incidents (e.g., unauthorized access) using tools like AWS Lambda or Azure Logic Apps.
4. Configure alerts for suspicious activities (e.g., failed login attempts).
5. Conduct regular incident response drills using cloud environments.
6. Document cloud-specific incident procedures in your IR plan.
7. Integrate cloud logs with a SIEM (e.g., Splunk or QRadar) for centralized analysis.

⏱️

Estimated Effort

2-3 days for initial setup (intermediate skill level), ongoing maintenance (1-2 hours/week).

📋 Evidence Examples

Incident Response Plan

Format: PDF/DOCX

Frequency: Annual updates or after major changes.

Contents: Detailed procedures for handling incidents, roles/responsibilities, escalation paths.

Collection: Export from document management system.

Incident Logs

Format: CSV/Log File

Frequency: Continuous logging.

Contents: Timestamps, incident descriptions, actions taken, resolution status.

Collection: Export from SIEM or incident management tool.

Incident Reports

Format: PDF/DOCX

Frequency: Per incident.

Contents: Post-incident analysis, root cause, lessons learned.

Collection: Generate after each major incident.

Training Records

Format: Excel/PDF

Frequency: After each training session.

Contents: Names, training dates, topics covered.

Collection: Export from HR or training management system.

SIEM Configuration Screenshot

Format: PNG/JPEG

Frequency: After configuration changes.

Contents: Alert rules, log sources, integration settings.

Collection: Capture from SIEM dashboard.

📝 SSP Guidance

Use this guidance when writing the System Security Plan (SSP) narrative for this control.

How to Write the SSP Narrative

For IR.L2-3.6.1 ("Establish an operational incident-handling capability"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your incident response capability, including the IR plan, team structure, detection mechanisms, response procedures, reporting obligations (DIBNET), and testing schedule. Be specific -- name your actual products, settings, and responsible personnel.

Example SSP Narratives

Cloud (Azure/AWS)

"IR.L2-3.6.1 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to establish an operational incident-handling capability. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."

On-Premise

"IR.L2-3.6.1 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to establish an operational incident-handling capability. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."

Hybrid

"IR.L2-3.6.1 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."

System Boundary Considerations

• Identify detection capabilities monitoring the CUI boundary
• Document incident communication channels and escalation paths
• Specify DIBNET reporting process for CUI incidents
• Ensure this control covers all systems within your defined CUI boundary where establish an operational incident-handling capability applies
• Document any systems where this control is not applicable and explain why

Key Documentation to Reference in SSP

📄 Incident Response Policy and Plan
📄 IRT roster and contact information
📄 Tabletop exercise reports
📄 Incident reports (if any)
📄 Evidence artifacts specific to IR.L2-3.6.1
📄 POA&M entry if control is not fully implemented

What the Assessor Looks For

The assessor will review your IR plan for completeness, verify the IRT can be assembled, check for evidence of regular testing (tabletop exercises), and confirm DIBNET reporting capability.

💬 Self-Assessment Questions

Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.

Question 1: Do you have a documented Incident Response Plan?

✅ YES → Proceed to Q2.

❌ NO → GAP: Draft an IR plan using templates from NIST SP 800-61 (complete within 2 weeks).

Question 2: Is an incident response team assigned and trained?

✅ YES → Proceed to Q3.

❌ NO → GAP: Assign team roles and schedule training (complete within 1 month).

Question 3: Are monitoring tools configured to detect incidents?

✅ YES → Proceed to Q4.

❌ NO → GAP: Deploy a SIEM and configure alert rules (complete within 3 weeks).

Question 4: Are incidents logged and documented consistently?

✅ YES → Proceed to Q5.

❌ NO → GAP: Implement a logging process and train staff (complete within 2 weeks).

Question 5: Are incident response drills conducted regularly?

✅ YES → Compliance confirmed.

❌ NO → GAP: Schedule quarterly drills (start within 1 month).

⚠️ Common Mistakes (What Auditors Flag)

1. Missing incident response plan.

Why this happens: Lack of awareness or prioritization.

How to avoid: Use NIST SP 800-61 as a guide and assign a dedicated team.

2. Incomplete incident logs.

Why this happens: Manual logging processes.

How to avoid: Automate logging with a SIEM tool.

3. Untrained incident response team.

Why this happens: Training not prioritized.

How to avoid: Schedule regular training sessions and drills.

4. No post-incident analysis.

Why this happens: Focus only on immediate resolution.

How to avoid: Document lessons learned and update the IR plan.

5. Failure to test IR plan.

Why this happens: Lack of resources or time.

How to avoid: Conduct tabletop exercises quarterly.

📚 Parent Policy

This practice is governed by the Incident Response Policy

View IR Policy →

📚 Related Controls

IR.L2-3.6.2 - Develop and implement incident response procedures IR.L2-3.6.3 - Test incident response procedures SI.L2-3.3.1 - Monitor system alerts and advisories