Audit Log Sources Required for a CMMC Level 2 Assessment

CMMC Level 2 assessors expect complete audit coverage across your CUI boundary. You need evidence that your system generates, protects, retains, and reviews audit logs across in-scope components, and that your team uses those logs to detect and investigate unauthorized activity.

NIST 800-171 AU requirements

NIST SP 800-171 drives the Level 2 Audit and Accountability expectations. The AU controls define what you log, how you protect it, how long you retain it, and how your team reviews it.

AU.L2-3.3.1 through AU.L2-3.3.2 set the foundation. You create and retain audit records that support monitoring, analysis, investigation, and reporting. You include event type, time, source, outcome, and the subject identity.
AU.L2-3.3.3 links identity to accountability. You trace actions to unique users or service principals.
AU.L2-3.3.4 through AU.L2-3.3.7 drive operations. You define the events you review on a set cadence, correlate records across systems, generate reports for analysis, and provide records to responders.
AU.L2-3.3.8 through AU.L2-3.3.11 protect the audit function. You size storage, alert on logging failures, protect audit data and tools, and retain records for a defined period to support investigations.

NIST SP 800-171A provides the assessment procedures. Assessors examine audit records and settings, interview the people who run auditing, and test mechanisms that generate and retain logs. You plan to show settings, sample logs, queries or reports, alerts, and procedures that match the AU objectives.

DFARS 252.204-7012 sets incident reporting expectations that rely on logging. When you report, you preserve images of affected systems and relevant monitoring or packet data. Your log and capture strategy must support that preservation.

Assessment expectations and scope

The DoD CIO CMMC Level 2 Assessment Guide and the Cyber AB CMMC Assessment Process v2.0 describe how teams assess practices. Teams scope the system that processes, stores, or transmits CUI and assess practices across that boundary. You include all components that support CUI handling in the evidence pool. That scope drives the required audit sources.

Assessment teams use examine, interview, and test methods to gather objective evidence. You prepare artifacts that show configuration, output, and operational use. You demonstrate that your team reviews logs on the schedule you defined, investigates anomalies, and escalates incidents.

You avoid treating this as a product checklist. The model is capability based. You align log sources to the functions in your in-scope architecture. You cover identity and access, endpoints, network paths, applications and data stores, cloud control planes, and security tooling that guards CUI workflows. That coverage connects to AU controls and to related families such as Incident Response and Access Control.

Scope drives success. If you still frame the boundary, read our primer on CMMC scoping for the CUI boundary.

Core audit log sources across the CUI boundary

Assessors look for complete coverage across the in-scope system. You do not need a specific brand, but you do need the right classes of evidence.

Identity and access. Your identity provider and domain controllers record authentication, authorization, group and role changes, policy changes, service principal use, and admin consent. You tie those records to unique identities to meet AU.L2-3.3.3. You also capture privileged activity in admin portals and control planes.

Endpoints. Your servers and workstations that handle CUI produce OS security logs, process creation, account use, and change events. Your endpoint security platform records detections and response actions. Those records feed AU.L2-3.3.5 and AU.L2-3.3.6 when you correlate and reduce events for analysis.

Network paths. Your firewalls, VPN concentrators, and proxies record connections, session starts and stops, blocked and allowed traffic, and admin changes. These records help you reconstruct data paths that involve CUI and support incident triage.

Applications and data stores. Your business apps, file services, repositories, and databases that handle CUI log access, permission changes, data movement, and admin actions. Your data protection stack, including DLP and classification tools, records policy matches and enforcement.

Cloud services and control planes. Your SaaS platforms, collaboration suites, and cloud subscriptions produce audit trails for tenant configuration, mailbox or site access, sharing actions, and administrative changes. You capture logs that show who changed what, when, and from where.

Security tools. Your SIEM collects logs from the sources above. Your SOAR or alerting workflows record correlation, enrichment, and response actions. Your vulnerability scanners, EDR, and email security systems record detections and status. You keep those outputs and the reports you run from them.

You do not stop at generation. You show that your team reviews and updates the set of audited events on a set cadence to meet AU.L2-3.3.4. You correlate records across sources for analysis to meet AU.L2-3.3.5. You provide audit reduction and reporting to meet AU.L2-3.3.6, and you route audit records to responders to meet AU.L2-3.3.7. You size storage, monitor log health, and protect audit data and tools to meet AU.L2-3.3.8 through AU.L2-3.3.10. You follow your documented retention to meet AU.L2-3.3.11.

Microsoft 365 and Entra audit evidence

Many DIB contractors run Microsoft cloud services inside the CUI boundary. You can meet AU objectives with Microsoft logs, provided you design coverage and retention across in-scope components and you protect the audit plane.

Microsoft Entra ID produces Audit logs for directory changes and admin actions. Entries include the actor’s immutable object ID, which supports traceability to a unique identity. The Entra standards page documents the content and use of these logs for Level 2.
Microsoft 365 produces the Unified Audit Log that records user and admin activity across Exchange Online, SharePoint, OneDrive, Teams, Purview, and related workloads. The Microsoft Technical Reference Guide for CMMC 2.0 describes how customers use these logs as evidence and how teams set review cadence to align with compliance goals.

You can collect and correlate these records in a SIEM. Microsoft Sentinel can collect, query, and alert on Entra ID, Microsoft 365, Defender, firewall, and host logs. That aggregation supports AU.L2-3.3.5 through AU.L2-3.3.7. You still need to protect the SIEM, monitor data pipeline health, and size storage to meet AU.L2-3.3.8 through AU.L2-3.3.10.

Environment matters. GCC, GCC High, and DoD tenants follow different compliance and boundary rules. Microsoft’s public sector comparison explains the differences that affect where logs land, who can access them, and how data residency works. You confirm features and data paths for your target cloud before you build your evidence plan.

Microsoft also publishes a CMMC offering overview and a Product Placemat that map features to practices. Treat those as informational guides. You still test your control design and present evidence that meets AU objectives. No product mapping serves as a certification.

If you process CUI in Microsoft 365, document Purview signals in your evidence set. The Unified Audit Log includes Purview activity such as DLP policy matches and label application. Those entries show data access and enforcement at the application layer. Our note on Microsoft Purview for CUI explains how teams plan those controls and their audit footprints.

Evidence and retention planning

You win AU determinations with coverage and operations, not tool names. Build a set of artifacts that show end-to-end control of the audit function.

Evidence set. You produce current configuration exports, sample audit records from key sources, SIEM queries or workbooks, alert definitions, and tickets that show review and response. You include examples that cover user actions, admin changes, endpoint events, and network traffic that touch CUI workflows.
Procedures and cadence. You present documented procedures for audit review, event tuning, incident handoff, and audit tool access control. You show calendars or tickets that prove your team followed the schedule you committed to.

Retention supports after-the-fact investigations and DFARS 252.204-7012 incident reporting. You set retention by source based on your investigative needs and storage capacity. You also cover chain of custody for audit data, access approvals, and break-glass steps for investigations.

The System Security Plan (SSP) ties this together. Document which audit sources exist, where you collect them, who can access them, how you protect them, and how long you retain them. Map each part to AU.L2-3.3.x objectives. If you need a reference frame, review our post on SSP structure for NIST 800-171.

Gaps happen. If you miss sources inside the CUI boundary or you lack retention to support investigations, record the gap, track it, and close it. Our guide to POA&M management outlines a clean path.

Expect assessors to trace a thread. They start with a user or system action that affects CUI, follow the logs across identity, endpoint, network, and application layers, and end with a SIEM alert or a human review record. Design your evidence to support that trace.

A practical source map to prepare

Use this short map to seed your coverage review. Treat it as a starting point, then align it to your architecture.

Identity and access

Entra ID audit and sign-in logs, including admin actions and app consent.
Domain controller security logs for account use, group changes, and policy changes.

Endpoints

Server and workstation OS security logs for process and account events.
Defender for Endpoint alerts, device timeline, and response actions.

Network paths

Firewall and VPN logs for sessions, blocks, and admin changes.
Web proxy or secure web gateway logs for egress tied to users or devices.

Applications and data

Microsoft 365 Unified Audit Log for user and admin activity across in-scope workloads.
Line-of-business application and database audit logs for access and permission changes.

Security operations

SIEM ingestion and queries that correlate identity, endpoint, network, and app events.
Alerting, case records, and incident response tickets that show review and action.

Protect the audit plane. Restrict admin access to log tools and storage. Monitor collectors and agents and alert on failures to meet AU.L2-3.3.9. Size storage and roll hot and cold tiers to meet AU.L2-3.3.8 and AU.L2-3.3.11. Back up audit stores and test restores.

Finally, keep the scoring model in view. AU gaps affect your NIST SP 800-171 score that you report to SPRS. Our note on SPRS scoring explains how assessors anchor determinations to objectives.

Bottom line

You do not need a fixed vendor list to pass the AU family. You need audit coverage across the full CUI boundary and proof that your team runs the function. Scope the system, confirm sources, collect in one place, protect the audit plane, and run reviews on the cadence you set. Then keep the artifacts close and ready for the assessment team.