M365 Audit Log Retention: Meeting CMMC AU Family Requirements

CMMC Level 2 expects you to create and retain audit logs long enough to support investigations, and Microsoft 365 can meet that need when you configure Purview Audit retention to match your policy, scope, and licensing. The standard does not mandate a fixed number of days. Assessors look for policy-backed retention that supports monitoring, analysis, investigation, and reporting.

CMMC AU retention requirements

The AU family centers on generation, coverage, and retention. AU.L2-3.3.1 tells you to create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity. AU.L2-3.3.5 tells you to retain those logs in line with your policy so investigations and regulatory needs do not stall due to missing records.

DoD CIO’s Level 2 Assessment Guide directs assessors to verify that you generate and retain logs for defined events and durations that support investigations. The guide does not impose a universal minimum. DoD CIO’s CMMC resources also anchor Level 2 to NIST SP 800-171, which takes a needs-based posture on retention. That linkage matters for setting durations that fit your risk, incident response process, and legal drivers.

Assessors read your policy and SSP, then ask you to produce evidence that matches those documents. They expect to see the plan, the configuration, and the proof that the environment retains the data as written.

Microsoft 365 Purview Audit retention

Microsoft Purview Audit records user and admin operations across Microsoft 365 in the Unified Audit Log. Administrators use the Purview portal to enable auditing, search audit records, and define audit log retention policies. Purview supports retention durations of 90 days, 365 days, and up to 10 years for selected record types.

Licensing drives default retention and options. Microsoft documents that:

Purview Audit Standard retains audit records for about 90 days for most users.
Advanced Audit with eligible E5 licensing retains audit records for one year for supported workloads, and allows creation of TenYears audit log retention policies for selected record types.

Microsoft’s guidance also states that extended retention up to one year applies to audit records generated by users who hold Microsoft 365 E5, Office 365 E5, or an E5 Compliance or E5 eDiscovery and Audit add-on. Without that license on the actor who generated the event, the record falls under the shorter retention.

You control who gets recorded for how long through license assignment and audit log retention policies. Purview enforces the policy once you create and scope it to record types. You validate the outcome by running Audit search over a date range that crosses your intended window and by exporting results.

Retention configuration that matches policy

A policy that says one thing while the tenant retains another will not hold up in an assessment. Close the gap with a short sequence.

Define scope and duration in policy. Name the record types, the user populations, and the target durations that support your investigations and regulatory posture.
Configure and validate in Purview. Assign the right E5 or E5 add-on licenses to in-scope users, create audit log retention policies for 365 days or TenYears as needed, then confirm search results cover the entire period.

Carry those decisions into your SSP. Map AU.L2-3.3.1, AU.L2-3.3.3, and AU.L2-3.3.5 to the Purview Unified Audit Log, Advanced Audit, and the policies you created. Reference the exact policy names, scopes, and durations. Screenshots age fast, so include both screenshots and exported policy objects or cmd output where possible.

You may also centralize logs in a SIEM for correlation and alerting. That move does not replace Purview retention. Keep both in view, and document how they complement each other for AU.L2-3.3.2 and AU.L2-3.3.3.

For a control map across CMMC Level 2, review our NIST 800-171 to CMMC Level 2 mapping. For documentation structure, use the patterns in System Security Plan basics.

Assessment evidence for AU practices

Assessors follow the Cyber AB’s CAP and the DoD Assessment Guide. They ask for policy, plan, and proof.

Governance artifacts. Provide your Audit and Accountability policy with durations, your SSP sections that map AU controls to Purview, and your procedure for reviewing and updating audited events per AU.L2-3.3.4.
Technical evidence. Provide Purview Audit settings that show auditing enabled, audit log retention policies with durations and scopes, license assignment reports for E5 and add-ons, and Audit search exports that span the stated retention window.

Teams that prepare evidence early avoid rework. The policy points to the tenant config, the config delivers search results that reach back to the declared date, and the outputs tie to incident response reports that show the logs supported an investigation. That chain makes AU.L2-3.3.1 and AU.L2-3.3.5 straightforward to assess.

Shared responsibility across Microsoft 365 and your environment

Microsoft records platform events in the Unified Audit Log and honors the retention policies you create. You decide which users receive E5 or E5 add-ons, create retention policies, and verify coverage across in-scope systems.

Some activity lives outside Microsoft 365. If you move CUI across non-Microsoft services, you extend your logging and retention to those systems and to identity, device, and network controls that gate access. Microsoft Entra ID can add sign-in and audit logs that help you reconstruct access and administrative actions tied to M365 activity. You still decide what to retain, where to store exports, and how to retrieve them during an assessment.

Government cloud variants can differ. Confirm features and retention behavior against the current Microsoft Learn pages for your tenant. Capabilities change, and auditors will expect you to align the configuration with the version you operate.

Picking a duration that stands up

CMMC does not fix a number, but your environment needs a number, written in policy and enforced in Purview. Two drivers set the floor.

Investigations. Incident response needs enough history to trace lateral movement, privilege changes, and exfiltration patterns. Longer windows help you spot slow campaigns and validate eradication.
Regulatory and contract duties. DFARS 252.204-7012 incident reporting and related disclosures depend on audit trails that prove system behavior. Short retention can undercut those reports.

Many DIB teams set at least 90 days of searchable M365 audit data, with one year for core workloads through E5 and Advanced Audit, and longer retention through TenYears policies for sensitive record types. Treat those durations as risk-based targets, not as a rule from CMMC. Set a number that you can afford, manage, and defend. For DFARS context, review our post on DFARS 252.204-7012 requirements.

Document a review cadence under AU.L2-3.3.4. The threat field shifts, Microsoft adds or changes record types, and your incident response lessons will surface gaps. Update the list of audited events, the policy durations, and the retention policies based on that review.

Practical configuration notes

Licensing alignment matters as much as policy text. If you grant E5 to administrators but not to high-risk users, you may retain a year of admin actions but only 90 days of end-user actions. That split weakens reconstruction work after a breach. Match license assignment to the user populations that drive risk.

Record type scope also needs attention. Purview supports TenYears for selected record types. If your policy calls for TenYears across the board, verify Microsoft supports that ask for each record type you care about, then size storage and export controls to match.

Export and disclosure procedures close the loop. During assessments and incident response, your team must produce records on demand. Build and test a repeatable extract process from Purview Audit search. Tie that process to case tracking in your incident response plan, so exports line up with case numbers and time ranges.

Common pitfalls to avoid

Two failure patterns surface in assessments.

Mismatch between policy and configuration. The policy says one year, the tenant keeps 90 days for most users. Fix that with license assignment and retention policies that scope to the right record types and users.
Gaps in scope. The SSP boundary includes systems that never feed centralized logging. Fix that by mapping in-scope systems to the Unified Audit Log where possible, and by integrating other sources into your SIEM with clear retention controls.

Teams that treat audit retention as an afterthought pay for it during incident response and in front of a C3PAO. Teams that treat it as a control with owners, measures, and tests can show both design and operation.

Bottom line for M365 tenants in the DIB

Purview Audit gives you the knobs to meet AU retention expectations when you set, license, and enforce durations that match your policy. The DoD Assessment Guide and the CAP direct assessors to test that chain end to end. Write the policy, configure Microsoft 365 to the letter, and keep proof that your search results reach back as far as you say. That approach supports AU.L2-3.3.1, AU.L2-3.3.3, AU.L2-3.3.4, and AU.L2-3.3.5 without guesswork.

Microsoft offers a Product Placemat for CMMC that maps platform capabilities to practices. Treat it as a guide to features and shared responsibility. It does not certify your environment, and it does not replace your policy or your evidence.