Mapped to NIST 800-171 Requirement: 3.6.2
CMMC Assessment Objective: IR.L2-3.6.2[c]
What This Objective Means
This control ensures that your organization has taken the definitions identified (IR.L2-3.6.2[a]) and documented (IR.L2-3.6.2[b])—and made them real and operational. It verifies that there’s a shared understanding of:
• What is reportable
• How incidents are categorized
• When and how users must escalate potential incidents
The control applies to all users—not just security or IT teams.
Why It Matters
If your organization hasn’t truly defined what counts as a reportable incident:
• Security events may go unreported or misclassified
• Detection and response timelines may suffer
• Compliance obligations may be missed (especially with CUI or DFARS)
• Employees may rely on personal judgment instead of standardized criteria
Clear definitions = consistent, accurate reporting.
How to Implement It
1. Use a Consistent Framework
• Align your definitions with NIST SP 800-61 or similar
• Ensure terms like “incident,” “event,” “anomaly,” and “breach” are defined
2. Categorize Incident Types
• Break down incident types into:
◦ Unauthorized access
◦ Malware
◦ Data exfiltration
◦ Insider misuse
◦ Physical device loss
◦ Suspicious login activity
3. Document in IR Policies and Training
• Include definitions in:
◦ The Incident Response Plan
◦ Access Control or Acceptable Use Policies
◦ Annual Security Awareness Training
4. Use in Reporting Tools
• Label incidents consistently in ticketing systems, SIEMs, or email reporting templates
5. Validate with Your Team
• Ask: Can a typical employee describe what they should report?
Evidence the Assessor Will Look For
• Clearly defined and categorized incident types in IR documentation
• Policy language that specifies what should be reported and why
• Training records showing users were exposed to definitions
• Reporting forms, portals, or ticketing tools that reflect these definitions
• Interviews or real-world incidents that align with the documented definitions
Common Gaps
• Definitions exist but are inconsistent across documents
• Users and technical staff have different interpretations of what’s “reportable”
• Incidents are reported ad hoc due to lack of guidance
• The IR plan uses terms like “major” or “critical” with no clear definition
How Cuick Trac Helps
Cuick Trac supports this control by:
• Providing standardized incident categories and definitions that align with CMMC
• Embedding definitions into incident templates, ticketing forms, and alert workflows
• Supporting organization-wide awareness through training and onboarding content
• Helping ensure consistency between real-world incident logs and policy language
• Offering a centralized knowledge base so users know what to report and how
With Cuick Trac, incident definitions are built into your system—not just your handbook.
Final CTA
Everyone should know what a reportable incident looks like.
Schedule a Cuick Trac demo to ensure your definitions are clear, consistent, and driving real action.