Mapped to NIST 800-171 Requirement: 3.6.2
CMMC Assessment Objective: IR.L2-3.6.2[a]
What This Objective Means
This control is about clarity: your team must know which events count as reportable incidents and trigger your incident response process.
You need to establish categories or examples of reportable incidents, such as:
• Unauthorized access to systems or data
• Malware infections
• Ransomware or data encryption attempts
• Phishing or credential theft
• Loss or theft of a device containing CUI
• Configuration changes that expose sensitive systems
• Insider threats
• Failed or anomalous login attempts, if persistent or suspicious
The goal is to avoid ambiguity—and ensure that important incidents don’t go unreported.
Why It Matters
If staff don’t know what to report:
• Real incidents may be ignored or dismissed
• Response teams may learn about problems too late
• CUI breaches may go uncontained
• Required notifications (e.g., DFARS, DIBNet) may be missed
• Compliance gaps emerge during audits
Clear definitions enable fast, accurate, and consistent reporting.
How to Implement It
1. Create an Incident Taxonomy
• Define severity levels (e.g., Critical, High, Moderate, Low)
• Include both technical (e.g., malware, brute force) and non-technical (e.g., lost device) examples
2. List Reportable Incident Types
• Include real-world scenarios relevant to your environment
• Clarify what doesn’t need to be reported (e.g., false positives)
3. Embed Definitions Into Documentation
• Add definitions to your:
◦ Incident Response Plan
◦ Security Awareness Training
◦ Employee Handbook (if applicable)
4. Train Users
• Include examples in onboarding and annual security training
• Use real or hypothetical cases to test understanding
Evidence the Assessor Will Look For
• A list or table of reportable security incident types
• Documentation of severity levels or incident categories
• Training materials or guidance documents with examples
• Security awareness training logs confirming user exposure to definitions
Common Gaps
• Staff unsure of what counts as a reportable incident
• Over-reliance on IT to “decide” if something is important
• Incident Response Plan lacks specific examples
• Users fail to report early signs of compromise
How Cuick Trac Helps
Cuick Trac supports this requirement by:
• Providing pre-defined incident categories aligned with NIST and CMMC
• Helping define incident types tied to CUI protection concerns
• Including reportable incident lists in end-user security training modules
• Supporting policy documentation that outlines examples and severity levels
• Automating tagging and categorization during incident intake
With Cuick Trac, everyone knows what to report—and why it matters.
Final CTA
If your team isn’t sure what to report, they’ll report nothing—or everything.
Schedule a Cuick Trac demo to clarify your incident definitions and improve your response readiness.