The most important rule for CMMC audit logging is short: the system has to actually do what your SSP says it does, and every time period in the SSP has to match what the system enforces. Audit logging fails at assessment more often than almost any other family, and the failure is almost always documentation drift, not a technical gap.
Make every time period in the SSP match what the system actually does
NIST SP 800-171 Rev 2 lets the OSA pick its own retention period, review cadence, and event list. That flexibility is also the trap. Whatever you pick has to match operating reality. Walk down this checklist before the assessment:
| What the SSP says | What the assessor will compare it against |
|---|---|
| Retention period for audit logs (3.3.1). | What the logging system actually retains. Open the system and confirm the oldest record on hand is at least the SSP-stated period. |
| Log review cadence (3.3.3, 3.3.5). For example, daily, weekly, monthly. | Whether you can produce review evidence at that exact cadence. If the SSP says weekly, you need weekly review records, not "whenever we get to it." |
| Frequency of review and update of the logged-events list (3.3.3). | Whether you can show the list was actually reviewed and updated on that cadence. |
| Time-sync interval and tolerance (3.3.7). | What the system is actually doing. If the SSP says clocks sync hourly within X seconds, that must match the configured interval and tolerance. |
| Alerting timeline for audit-process failure (3.3.4). | Whether an alert actually fires when logging stops. Test it. A SIEM that has been down for weeks without alerting is a 3.3.4 failure. |
| Event types captured (3.3.1, 3.3.2). | Whether the system is actually capturing every event type the SSP lists. Missing event types are 3.3.1 / 3.3.2 failures. |
The full AU family at Level 2
| Practice | Requirement |
|---|---|
| 3.3.1 (AU.L2-3.3.1) | Create and retain audit logs to the extent needed to enable monitoring, analysis, investigation, and reporting of unauthorized activity. |
| 3.3.2 (AU.L2-3.3.2) | Ensure the actions of individual users can be uniquely traced to enable accountability. |
| 3.3.3 (AU.L2-3.3.3) | Review and update logged events. |
| 3.3.4 (AU.L2-3.3.4) | Alert in the event of an audit logging process failure. |
| 3.3.5 (AU.L2-3.3.5) | Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. |
| 3.3.6 (AU.L2-3.3.6) | Provide audit record reduction and report generation to support on-demand analysis and reporting. |
| 3.3.7 (AU.L2-3.3.7) | Provide a system capability that compares and synchronizes internal system clocks with an authoritative source. |
| 3.3.8 (AU.L2-3.3.8) | Protect audit information and audit logging tools from unauthorized access, modification, and deletion. |
| 3.3.9 (AU.L2-3.3.9) | Limit management of audit logging functionality to a subset of privileged users. |
Retention: the OSA picks the period, then has to live with it
NIST SP 800-171 Rev 2 does not prescribe a specific number of days or months for audit log retention. The OSA picks the period based on:
- The OSA's own risk-based information security policy.
- Contract-specific requirements (a DoD contract may require longer retention than the rule's baseline).
- Operational considerations (incident investigation timelines, forensic readiness).
- Relevant regulatory or industry standards.
Pick a period you can hold to, document it in the SSP, and verify the system is actually retaining for that long. A retention period the system does not enforce is worse than a shorter period the system does enforce: the first one is a finding, the second one is just a short period.
What events to log
NIST SP 800-171A's assessment objectives for 3.3.1 and 3.3.2 require the events to be sufficient to support investigation and accountability. At minimum, the logged events typically need to cover:
- Authentication events (success and failure).
- Account management events (creation, modification, deletion, disabling).
- Privilege use and privilege changes.
- System start, stop, and audit subsystem changes.
- Object access for CUI Assets.
- Policy and configuration changes.
- Network connection events for boundary devices.
The specific event list is OSA-defined. Whatever list you write in the SSP, the system has to actually capture those events. List events the system does not capture and the SSP becomes a finding.
Log review, protection, and time sync
- Review (3.3.3, 3.3.5). The OSA reviews logs at a defined cadence and correlates across sources. The cadence is OSA-defined and must match the cadence the SSP states. Keep a review register or ticket trail you can show the assessor.
- Protection (3.3.8, 3.3.9). Audit logs and the logging tools themselves must be protected from unauthorized access, modification, and deletion. Administrative access to the logging system must be limited to a subset of privileged users. Logs writable by the same admins they monitor is a finding.
- Time synchronization (3.3.7). System clocks must synchronize with an authoritative time source so log events can be correlated across systems. The interval and tolerance configured on the system must match what the SSP says.
Common errors
- SSP says one year, the system retains 90 days. The most common audit-logging finding. Verify what the system actually does, not what the policy aspires to.
- SSP says weekly review, no weekly review evidence exists. Logs that no one reviews on the stated cadence do not satisfy 3.3.3 or 3.3.5.
- SSP names event types the system is not capturing. A specific list in the SSP is a commitment. Verify the system actually captures every event type listed.
- Audit logs writable by the same admins they monitor. Violates 3.3.8 and 3.3.9. Use immutable storage or separation of duties on the logging system.
- Missing or misconfigured time synchronization. Without 3.3.7, correlated review across systems is not reliable, and forensic timelines cannot be trusted.
- SIEM down for weeks without alerting. Violates 3.3.4. The audit-logging-process failure alert must be configured and tested.
Sources
Stand up audit logging that holds at assessment.
The CMMC Compliance Engine includes the AU-LOG-01_Log_Review_Register, plus environment-specific audit-logging guides (Microsoft 365 GCC High Sentinel and audit configuration, for example) for implementing the AU family end-to-end.
Get the CMMC Compliance Engine