Audit Logging for CMMC: What to Collect, How Long to Keep It, and How to Show It
If You Cannot Produce the Log, the Control Does Not Exist
CMMC Level 2 requires audit logs from every in-scope system — collected, centralized, retained, reviewed, and producible on demand. For most defense contractors, the problem is not that logging is turned off. The problem is that nobody has decided what to log, where to send it, how long to keep it, or who reviews it. That ambiguity is where assessment findings live.
Which Systems Matter Most for Logging
NIST SP 800-171 control AU.L2-3.3.1 requires organizations to create and retain system audit logs and records sufficient to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. The word "system" is not limited to servers. It means every asset in the assessment boundary that stores, processes, or transmits CUI — and every Security Protection Asset that defends or monitors those CUI assets.
In practice, the systems that generate the most compliance-relevant audit data fall into five categories. Missing any one of them creates a gap an assessor will find.
| System Category | Key Log Sources | Priority |
|---|---|---|
| Identity & Authentication | Azure AD / Entra sign-in logs, MFA challenge results, conditional access evaluation logs, failed authentication attempts, account lockouts, privilege escalation events | Critical — log first |
| Administrative Activity | Azure AD audit logs, Exchange admin actions, SharePoint admin changes, Intune policy modifications, firewall rule changes, GPO edits, PowerShell execution on servers | Critical — highest-risk events |
| File & Data Access | SharePoint/OneDrive file access and sharing events, sensitivity label changes, DLP policy matches, file server access auditing (Windows Security Log Event IDs 4663, 4656) | Critical — CUI tracking |
| Security Tools | Endpoint detection alerts (Defender for Endpoint), antivirus scan results, vulnerability scan outputs, DLP incident reports, email filtering logs (Defender for Office 365) | High — Security Protection Data |
| Network Devices | Firewall traffic logs, VPN authentication and session logs, DNS query logs, IDS/IPS alerts, wireless access point authentication events | High — perimeter visibility |
Authentication, Admin Activity, File Access, Security Tools, and Network Devices
Knowing which systems to log is the first step. Knowing what events to log within each system is the second — and the one where contractors most often fall short. Turning on "auditing" at the system level is not enough. The audit policy must capture the specific event types that satisfy the assessment objectives.
Authentication Events
Successful and failed sign-ins. MFA success and failure. Conditional access policy evaluations — especially denials. Account lockouts. Password resets and changes. Service principal authentications. Token refresh events. The assessor needs to verify AU.L2-3.3.2: that actions of individual users can be uniquely traced. If your authentication logs do not include the user principal name, the source IP, the device, and the timestamp, they do not satisfy that objective.
Administrative Activity
Every configuration change made by an administrator to an in-scope system. In Azure AD: role assignments, group membership changes, app registrations. In Exchange: transport rule modifications, mailbox permission changes. In Intune: compliance policy edits, configuration profile deployments. In firewalls: rule additions, deletions, and modifications. Admin actions are the highest-risk events because they can alter the control environment itself — changing a conditional access policy can remove a control that the SSP describes as implemented.
File and Data Access
CUI file opens, edits, downloads, deletions, sharing events, and sensitivity label changes in SharePoint and OneDrive. On-premises file server access events (Windows Event IDs 4663 for object access, 4656 for handle requests). DLP policy matches — when a rule triggers because CUI content was detected in a file or email. These events are critical for demonstrating AC.L2-3.1.3 (control CUI flow) and MP.L2-3.8.2 (limit access to CUI on system media).
Security Tool Events
Malware detections and remediation actions from Defender for Endpoint or your AV product. Email quarantine events from Defender for Office 365 or your email gateway. Vulnerability scan results and remediation tracking. These logs constitute Security Protection Data under CMMC scoping guidance — meaning the logs themselves, and the systems that store them, are in scope. They feed directly into SI.L2-3.14.6 (monitor organizational systems) and SI.L2-3.14.7 (identify unauthorized use).
Network Device Logs
Firewall connection logs — allowed and denied traffic, especially to and from the CUI enclave. VPN session logs: who connected, from where, for how long. IDS/IPS alerts. DNS query logs, if your architecture uses DNS-layer filtering. Wireless authentication events if Wi-Fi is in scope. Network logs are the perimeter layer of your audit trail — they show what reached the boundary and what was stopped. Without them, the assessor cannot evaluate SC.L2-3.13.1 (monitor communications at system boundaries).
Centralization, Integrity, and Review Workflows
Collecting logs is step one. Centralizing them, protecting their integrity, and reviewing them on a defined schedule is where most organizations fail — and where the assessment objectives actually live.
Collect
Logs generated at each source. Forwarded to central aggregation point via syslog, API, or agent.
Centralize & Protect
Stored in SIEM, log aggregator, or M365 Unified Audit Log. Tamper-protected. Access restricted to authorized personnel.
Review & Respond
Reviewed on documented schedule. Anomalies investigated. Findings fed into incident response process.
Centralization satisfies AU.L2-3.3.5 (correlate audit review, analysis, and reporting). Logs from different systems must be queryable in a single place — or at minimum, reviewable through a defined process that connects events across sources. If your firewall logs are on the firewall, your Azure AD logs are in the portal, and your file server logs are in Windows Event Viewer, there is no correlation. There is just a collection of disconnected islands.
Integrity satisfies AU.L2-3.3.4 (alert in the event of an audit logging process failure). Logs must be protected from modification and deletion. If a compromised admin account can delete the audit trail that recorded its own actions, the logging control is defeated. Practical measures include forwarding logs to a write-once repository, using immutable storage in cloud platforms, restricting log deletion to a separate admin role, and alerting when logging stops unexpectedly.
Review satisfies AU.L2-3.3.1 in its operational dimension and feeds SI.L2-3.14.6 (monitor organizational systems). The review must happen on a defined schedule — daily or weekly, documented in policy. It must be performed by a named individual or team. And it must produce a record: a completed checklist, a closed ticket, a report with the reviewer's name and date. An assessor will ask for review records from the past 90 days. If you cannot produce them, the control is Not Met.
Retention Strategy Versus Storage Cost
NIST SP 800-171 does not specify a minimum retention period for audit logs. The requirement is to retain logs in accordance with the organization's records management policy. In practice, this means the contractor chooses the retention period — but the choice must be defensible, documented, and consistently applied.
Most contractors and compliance practitioners converge on the same set of benchmarks:
| Retention Tier | Typical Duration | Rationale |
|---|---|---|
| Active / hot storage | 90 days | Searchable, queryable, available for real-time investigation. Covers the DFARS 7012 requirement to preserve images and logs for 90 days after a cyber incident is reported. This is the tier assessors will query during the assessment. |
| Warm / archive storage | 1 year | Retrievable within hours. Covers the typical assessment lookback period and aligns with annual self-assessment and affirmation cycles. Most M365 Unified Audit Log retention policies default to or can be configured for one year. |
| Cold / long-term archive | 3–6 years | For organizations that want to match the CMMC certification validity period (3 years) or the False Claims Act statute of limitations (6 years). Stored in low-cost immutable cloud storage. Not required by the controls but provides legal defensibility. |
Storage cost drives retention decisions. A SIEM ingesting 5 GB of logs per day at a commercial rate of $2.50/GB/month accumulates a meaningful bill over 12 months. The mitigation is tiered storage: keep 90 days of hot, searchable data in the SIEM, and archive everything beyond 90 days to lower-cost storage — Azure Blob Archive, AWS S3 Glacier, or an equivalent. The archived data must still be retrievable — just not instantly. Document the tiering strategy in the SSP and verify that the archive is actually receiving data.
How to Demonstrate Log Review Is Real, Not Theoretical
This is the section that separates contractors who pass from contractors who fail. Log collection is technical. Log review is operational. And assessors spend more time evaluating the operational side — because that is where the gaps are widest.
An assessor evaluating your log review process will ask for three things:
Weekly review with dated checklist
Every Friday, the IT security lead exports a summary of failed logins, admin changes, and DLP alerts from the past week. They complete a checklist documenting what they reviewed, whether anything was anomalous, and any actions taken. The checklist is saved to the evidence vault with a date stamp. On March 7, they noted three failed MFA attempts from an unusual IP range, verified the user was traveling, and documented the determination as benign.
"We check the logs when something seems off"
No defined schedule. No assigned reviewer. No record of what was checked. No evidence of any review in the past 90 days. The SIEM is deployed and collecting data, but nobody looks at it regularly. The assessor asks for review records and the contractor cannot produce any. The control is Not Met — even though the logs exist.
The review does not need to be sophisticated. It does not need to take hours. For a small environment, a 30-minute weekly review that follows a consistent checklist and produces a dated record is sufficient. What matters is that it happens consistently, is documented consistently, and connects to the incident response process when something is found.
Common Gaps Assessors Find
The Audit and Accountability control family is one of the most frequently failed in CMMC assessments. The gaps are not exotic. They are predictable — and they appear in the same patterns across organizations of every size.
Logging Enabled but Not Collected
Windows Security auditing is turned on, but the logs are only stored locally on each workstation. Nobody aggregates them. Nobody reads them. The events rotate out after the local log file reaches capacity. For assessment purposes, the logs do not exist — because they cannot be queried, correlated, or retained.
Retention Mismatch
The SSP states a 12-month retention period. The SIEM is configured for 90-day retention. The M365 Unified Audit Log is on a license tier that provides 180 days. Nobody verified that the technical settings match the policy. The assessor exports the configuration, reads the numbers, and scores the control Not Met.
No Review Records
The contractor has a SIEM. The SIEM has dashboards. Nobody can produce a dated record showing that a human reviewed those dashboards on a specific date and documented what they found. The SIEM is a tool. The review is a process. The tool exists. The process does not.
Firewall and VPN Logs Missing
The contractor collects Azure AD and M365 logs but does not forward firewall syslog or VPN session logs to the central aggregation point. Network perimeter events are invisible. The assessor asks how communications at the system boundary are monitored (SC.L2-3.13.1) and there is no data to show.
No Log Integrity Protection
Logs are centralized but stored in a file share that any administrator can modify or delete. There is no write-once repository, no immutable storage tier, and no alerting on log deletion. AU.L2-3.3.4 requires alerting when the audit logging process fails — and an attacker deleting logs to cover their tracks is the exact scenario the control is designed to address.
Logs Exist but Cannot Be Correlated
Authentication logs are in Azure AD. File access logs are in SharePoint. Firewall logs are on the firewall. Each is retained independently. Nobody can connect a suspicious login to a subsequent file download to an outbound data transfer. AU.L2-3.3.5 requires correlation — and scattered logs in separate consoles do not satisfy it.
Minimal Viable Logging Architecture for SMBs
Not every defense contractor needs a six-figure SIEM deployment. A 15-person company with all CUI in GCC High, managed endpoints, and a single firewall can build a logging architecture that satisfies every AU and SI assessment objective — if the architecture is designed deliberately and the process around it is documented.
Here is what a minimal viable logging architecture looks like for a small Microsoft-centric environment:
The Bottom Line
Audit logging is not a technology problem for most defense contractors. The technology exists — often already licensed and partially configured. It is an operational discipline problem. The logs must be collected from every in-scope system, centralized so they can be correlated, retained for at least as long as the SSP states, protected from tampering, and reviewed on a defined schedule by a human being who documents what they find.
Every one of those verbs is an assessment objective. Every one of them must produce evidence. And the most expensive SIEM in the world does not satisfy a single one of them if nobody operates it.
The assessor will not ask what product you use. The assessor will ask: "Show me a log from last week. Show me who reviewed it. Show me what they found. Show me how long you keep these. Show me what happens when something looks wrong." Build the process that answers those questions. Then choose the tools that make the process sustainable.