Review and update logged events
📖 What This Means
This control requires organizations to regularly review and update the events they log to ensure they capture the right information for security monitoring and compliance. It means that logs should be checked to confirm they are accurate, complete, and aligned with current security needs. For example, if new software is installed, logs should be updated to include events from that software. Similarly, if certain events are no longer relevant, those logs should be removed. This ensures that when auditors or security teams look at logs, they see meaningful and useful data. For instance, a company might update logs to include failed login attempts after a phishing attack, or remove outdated logs from decommissioned systems.
🎯 Why It Matters
Failing to review and update logged events can leave gaps in security monitoring, making it harder to detect and respond to incidents. For example, in the 2017 Equifax breach, inadequate log monitoring contributed to delayed detection of the attack, resulting in the exposure of 147 million records. Outdated or incomplete logs can also lead to compliance failures during audits, potentially costing organizations fines or losing contracts. The DoD emphasizes this control to ensure that CUI is protected through effective logging practices. Regular review and updates help organizations stay ahead of evolving threats and maintain accurate records for forensic analysis.
✅ How to Implement
- Enable logging services (e.g., AWS CloudTrail, Azure Monitor, GCP Logging).
- Configure log retention policies to meet CMMC requirements (e.g., 90 days).
- Set up alerts for critical events (e.g., failed logins, unauthorized access).
- Regularly review logs using cloud-native tools or SIEM integrations.
- Update logging configurations when new services or applications are added.
- Automate log export to a secure storage bucket for long-term retention.
- Document changes to logging configurations in a change management system.
📋 Evidence Examples
Logging Policy
Log Configuration Screenshots
SIEM Reports
Change Management Records
Training Records
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For AU.L2-3.3.3 ("Review and update logged events"), 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 audit logging infrastructure, including which events are logged, the SIEM/log management platform, retention periods, log protection mechanisms, and review processes. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"AU.L2-3.3.3 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to review and update logged events. 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']."
"AU.L2-3.3.3 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to review and update logged events. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"AU.L2-3.3.3 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 all systems generating audit logs within the CUI boundary
- • Document log flow from sources to centralized SIEM
- • Specify log storage locations and retention tiers
- • Ensure this control covers all systems within your defined CUI boundary where review and update logged events applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Audit and Accountability Policy
- 📄 SIEM architecture documentation
- 📄 Log retention configuration
- 📄 Evidence artifacts specific to AU.L2-3.3.3
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify that required events are logged, check log completeness (all required fields present), test log protection mechanisms, and review evidence of regular log reviews.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do you have a documented logging policy?
Question 2: Are logs reviewed weekly for anomalies?
Question 3: Are logging configurations updated when new systems are deployed?
Question 4: Are logs protected from unauthorized access?
Question 5: Do you have evidence of log reviews and updates?
⚠️ Common Mistakes (What Auditors Flag)
1. Missing logs from critical systems.
2. Outdated log retention policies.
3. Inconsistent log formats.
4. Unauthorized access to logs.
5. No evidence of log reviews.
📚 Parent Policy
This practice is governed by the Audit and Accountability Policy