Create and retain system audit logs and records
📖 What This Means
This control requires organizations to create and keep detailed records of system activities, known as audit logs. These logs capture events like who accessed the system, what changes were made, and when these actions occurred. The purpose is to provide a trail of evidence that can be reviewed to detect unauthorized access, troubleshoot issues, or investigate security incidents. For example, if an employee accidentally deletes a critical file, the audit log can help identify when and how it happened. Similarly, if a hacker gains access to your system, the logs can help trace their activities and understand the extent of the breach. These logs must be securely stored and retained for a specific period, usually at least 90 days, to meet compliance requirements.
🎯 Why It Matters
Without audit logs, organizations have no visibility into what’s happening on their systems, making it nearly impossible to detect or respond to security incidents. For example, in the 2017 Equifax breach, the lack of proper logging delayed the discovery of the breach, exposing sensitive data of 147 million people. The financial and reputational damage was immense, costing Equifax over $1.4 billion. From a DoD/CMMC perspective, this control is critical for protecting Controlled Unclassified Information (CUI). Audit logs provide accountability and are essential for forensic investigations, compliance audits, and ensuring that systems are not misused or compromised.
✅ How to Implement
- Enable logging services: In AWS, activate AWS CloudTrail; in Azure, enable Azure Monitor Logs; in GCP, use Cloud Logging.
- Configure log retention: Set retention policies to store logs for at least 90 days (e.g., AWS S3 lifecycle rules, Azure Log Analytics retention settings).
- Centralize logs: Use a SIEM tool like Splunk or Datadog to aggregate logs from multiple cloud services.
- Secure log storage: Encrypt log data using cloud provider encryption services (e.g., AWS KMS, Azure Key Vault).
- Monitor log integrity: Enable alerts for log tampering or deletion (e.g., AWS CloudTrail alerts, Azure Sentinel).
📋 Evidence Examples
Audit Log Retention Policy
Log Configuration Screenshots
SIEM Log Reports
Log Integrity Monitoring Alerts
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.1 ("Create and retain system audit logs and records"), 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.1 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to create and retain system audit logs and records. 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.1 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to create and retain system audit logs and records. 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.1 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 create and retain system audit logs and records 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.1
- 📄 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: Are audit logs enabled on all systems handling CUI?
Question 2: Are logs retained for at least 90 days?
Question 3: Are logs centralized in a SIEM tool?
Question 4: Are logs encrypted and protected from tampering?
Question 5: Are logs reviewed regularly for anomalies?
⚠️ Common Mistakes (What Auditors Flag)
1. Not enabling logging on all systems.
2. Insufficient log retention period.
3. Failing to centralize logs.
4. Not encrypting logs.
5. Not reviewing logs regularly.
📚 Parent Policy
This practice is governed by the Audit and Accountability Policy