Mapped to NIST 800-171 Requirement: 3.6.2
CMMC Assessment Objective: IR.L2-3.6.2[b]
What This Objective Means
After defining what constitutes a security incident (in IR.L2-3.6.2[a]), this control checks whether that information is properly documented and available to users, responders, and auditors.
That documentation should:
• Categorize different types of reportable incidents
• Provide real-world examples
• Indicate severity or priority levels
• Be included in your Incident Response Plan and other relevant policies
This makes it easy for team members to recognize when an issue should be escalated.
Why It Matters
If your definitions are not documented:
• Users may overlook or delay reporting
• Response efforts could be misaligned or misprioritized
• You may miss compliance triggers (e.g., DFARS or contractual reporting requirements)
• Assessors will flag the lack of formalized guidance
Clarity starts with documentation.
How to Implement It
1. Update Your IR Plan
• Include a section that lists the types of incidents to be reported
• Break them into categories (e.g., system compromise, data breach, physical theft)
2. Create an Incident Matrix or Table
• Include:
◦ Incident type
◦ Example
◦ Severity level
◦ Required response time or escalation path
3. Align With Risk and Compliance Requirements
• Highlight incident types that require regulatory reporting (e.g., incidents involving CUI)
4. Distribute and Train
• Ensure all relevant staff know where to find this documentation
• Review examples during security awareness training and IR exercises
Evidence the Assessor Will Look For
• Incident Response Plan with clearly defined reportable incident types
• Tables, matrices, or classification frameworks in documentation
• Security training materials covering types of incidents
• Policy references to DFARS/CUI-specific incident reporting triggers
• Alignment between training, documentation, and live response activity
Common Gaps
• No formal listing of incident types
• Definitions exist verbally or in training only—no documentation
• Incident Response Plan is too generic or focused only on technical threats
• Documentation doesn’t address CUI-specific incidents or regulatory triggers
How Cuick Trac Helps
Cuick Trac supports this requirement by:
• Providing pre-built documentation templates that list reportable incident types
• Customizing incident definitions to align with DFARS and CMMC expectations
• Integrating these definitions into training and awareness programs
• Ensuring documentation is centralized, version-controlled, and accessible
• Supporting alignment between incident logging tools and reportable categories
With Cuick Trac, your incident definitions aren’t just clear—they’re documented, visible, and enforceable.
Final CTA
Don’t just say what counts as an incident—write it down.
Schedule a Cuick Trac demo to document your incident types and strengthen your response posture.