Track, document, and report incidents to designated officials
📖 What This Means
This practice requires organizations to systematically track, document, and report security incidents to designated officials. It ensures that incidents are properly recorded, analyzed, and escalated to the right people for timely response. For example, if an employee notices suspicious activity on their workstation, they must report it through the correct channels, and the incident must be logged with details like the date, time, and nature of the issue. Another example is a phishing email that bypasses filters—it should be documented, analyzed, and reported to prevent future occurrences. This practice helps maintain accountability and ensures incidents don’t go unnoticed or unaddressed.
🎯 Why It Matters
Failing to track and report incidents can lead to delayed responses, allowing threats to escalate and cause significant damage. For instance, in 2020, the SolarWinds breach went undetected for months, resulting in widespread data theft. Proper incident tracking could have mitigated the impact. For DoD contractors, this control is critical because it ensures that incidents affecting Controlled Unclassified Information (CUI) are promptly addressed, reducing the risk of data breaches and compliance violations. Without this practice, organizations risk financial losses, reputational damage, and losing DoD contracts.
✅ How to Implement
- Enable logging and monitoring in your cloud environment (e.g., AWS CloudTrail, Azure Monitor).
- Create a centralized incident tracking system (e.g., Jira, ServiceNow) with predefined workflows.
- Set up alerts for suspicious activities (e.g., unauthorized access attempts).
- Train staff to report incidents using the designated system.
- Regularly review and update incident reports for accuracy.
- Integrate cloud logs with SIEM tools (e.g., Splunk, Sumo Logic) for comprehensive tracking.
- Conduct quarterly incident response drills to ensure readiness.
📋 Evidence Examples
Incident Response Policy
Incident Logs
Training Records
Incident Report
SIEM Screenshot
📝 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.2 ("Track, document, and report incidents to designated officials"), 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
"IR.L2-3.6.2 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to track, document, and report incidents to designated officials. 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']."
"IR.L2-3.6.2 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to track, document, and report incidents to designated officials. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"IR.L2-3.6.2 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 track, document, and report incidents to designated officials 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.2
- 📄 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 policy?
Question 2: Are all incidents logged in a centralized system?
Question 3: Are designated officials notified of incidents promptly?
Question 4: Are incident logs reviewed regularly for completeness?
Question 5: Do you conduct incident response training annually?
⚠️ Common Mistakes (What Auditors Flag)
1. Incomplete incident logs.
2. Lack of escalation procedures.
3. Untested incident response process.
4. No centralized logging system.
5. Failure to notify designated officials.
📚 Parent Policy
This practice is governed by the Incident Response Policy