If I’m a DoD contractor handling CUI, I can’t treat CMMC logging auditing like a checkbox. Turning logs on is easy. Proving I can detect odd behavior, investigate it fast, and report what happened is the real work.
CMMC Level 2 pushes me to show repeatable habits: what I log, how I protect it, how often I review it, and what I do when something looks wrong. That’s why Microsoft 365 is a practical path for many small and mid-sized contractors. It’s already where my email, files, Teams chats, and devices live, especially after an Office 365 Migration that moved daily operations into the cloud.
Done right, this supports Business Continuity & Security, steady Cloud Management, and a secure cloud posture I can defend in an assessment, without turning my team into full-time log babysitters.
What CMMC 2.0 expects for logging and audit review (Level 2 focus)
For Level 2, the plain-English goal behind AU.L2-3.3.1 is straightforward: I must create and retain audit logs so I can monitor, analyze, investigate, and report unlawful or unauthorized activity. In January 2026, the pressure is rising because the CMMC program is moving from early self-assessment flexibility toward more third-party scrutiny on the Level 2 side as the rollout progresses (and I don’t want to be “almost ready” when an assessor asks for evidence).
When an assessor looks at my logging program, they’re not impressed by volume. They want relevance and traceability. “Good” logs answer:
- Who did it (user, service account, admin role)
- What they did (read, delete, share, change policy)
- When it happened (time-stamped, consistent time zone)
- Where it came from (location, source IP when available)
- Result (success, failure, blocked, allowed)
- Object touched (mailbox, file, site, device, admin setting)
CMMC also cares that I run logging like a process, not a one-time setup. That means I define:
What I log: identity events, activity events, device events, and security alerts tied to CUI systems.
How I protect logs: least-privilege access, strong admin controls, and tamper resistance.
How often I review: a schedule plus proof it happens.
How I respond: log review connects to incident response steps.
Level 1 vs Level 2 is where teams get tripped up. Level 1 is basic safeguarding. Level 2 expects maturity and evidence around CUI.
| CMMC Level | Practical logging expectation | What I must be ready to show |
|---|---|---|
| Level 1 | Limited logging, basic accountability | Basic security events and admin accountability where feasible |
| Level 2 | Audit logs that support investigation and reporting | Documented log scope, protected storage, regular review, retained evidence exports |
Retention is the other pain point. CMMC doesn’t hand me a single magic number. It’s risk-based, but it must support investigations and accountability. So I need a written retention plan (by system and log type), plus proof that older events are still searchable when I claim they are.
What I must log to investigate incidents (access, changes, security events)
When I’m preparing for a Level 2 assessment, I make sure these categories are covered and easy to demonstrate:
- Authentication success and failure: suspicious login attempts at 2 a.m., or repeated failures from a new location.
- Privileged admin actions: a Global Admin adds an account, changes roles, or edits Conditional Access.
- Security setting changes: MFA disabled, audit logging altered, retention policy adjusted.
- Access to CUI locations: SharePoint/OneDrive site access tied to CUI, including downloads.
- File sharing and permission changes: someone shares a folder externally, or broadens access.
- Mailbox access and rule changes: inbox rule that forwards mail out, or mailbox items deleted.
- Device enrollments and policy changes: a lost laptop gets enrolled, wiped, or marked non-compliant.
- Malware and phishing detections: phishing email delivered, user clicks, payload blocked.
These aren’t abstract. A “mass file download” event can be my early warning before CUI walks out the door.
How I prove ongoing log review (cadence, alerts, written procedures)
I plan log review like I’d plan preventative maintenance on a vehicle. If I only check the oil after the engine seizes, it’s too late.
A cadence that works for many Small Business IT teams looks like this:
Daily: high-risk alerts (impossible travel, admin role changes, malware detections).
Weekly: trend review (repeated login failures, risky sign-in patterns, new external sharing).
Monthly: executive summary (top incidents, response times, changes to logging scope).
Evidence matters as much as the review itself. I keep tickets, notes, and sign-offs. I also document time sync (NTP), an escalation path, and how a log finding becomes an incident response action.
Which Microsoft 365 logs and alerts give me the evidence CMMC assessors ask for
Microsoft 365 can cover identity, activity, threat, and device signals, but only if I configure it intentionally. The places I spend most of my time are Microsoft Purview Audit, Entra ID, the Defender portals (Defender XDR), and Intune.
I also treat admin access like a controlled substance. If anyone can search audit logs, export them, or change retention, my evidence chain gets shaky. Good Device Hardening and Endpoint Security work isn’t only about endpoints, it’s also about locking down who can touch the proof.
This is the reality for most contractors today: Cloud Infrastructure is the operating environment, and Secure Cloud Architecture choices decide whether audits are painful or predictable. Even if I still run some Data Center Technology on-prem, Microsoft 365 is often where CUI collaboration happens, so it must be audited well.
Identity logging: Entra ID sign-in logs and audit logs
Entra ID sign-in logs tell me who signed in, from where, and whether it succeeded. When risk signals are available, they help me explain why a login was flagged.
Entra audit logs show who changed what. That includes role assignments, app consent, Conditional Access policy edits, and directory changes. This is where I prove control over privileged activity.
I use role-based access for log visibility, and I separate duties when I can: one person configures, another reviews, and a third approves changes.
Activity logging: Microsoft Purview Audit (Unified Audit Log)
Purview Audit captures user and admin actions across Exchange, SharePoint, OneDrive, Teams, and more. When an assessor asks “Show me what this user did to that file,” this is often where the story comes from.
Examples I rely on:
- A file was accessed, downloaded, or deleted in SharePoint/OneDrive
- A file was shared externally, or permissions changed
- A mailbox rule was created (classic business email compromise move)
- A Teams message was deleted
- An eDiscovery search was run (important for accountability)
Retention is where many teams get burned. Audit (Standard) is often short by default. Audit (Premium) can extend retention and add higher-value events, and in GCC or GCC High planning, I validate what’s available in my tenant early. I don’t want to discover a retention gap during an assessment.
Threat and endpoint signals: Defender for Office 365, Defender for Endpoint, Defender XDR
Audit events tell me “what happened.” Security alerts tell me “this looks bad.”
Defender for Office 365 covers phishing, malware, suspicious inbox rule behavior, and risky link clicks. Defender for Endpoint covers endpoint detections, device isolation actions, and investigation timelines. Defender XDR ties signals together so I can show a single incident story instead of five disconnected logs.
This is the part of my Cybersecurity Services offering that assessors feel right away. If I can detect and respond with evidence, CMMC conversations go smoother.
Device and data protection events: Intune plus Purview DLP and Insider Risk
Intune gives me the device management trail: enrollments, compliance results, configuration and policy changes, remote wipe, and other device actions. When a laptop is lost, those events become my timeline.
Purview DLP helps me prove data controls in motion, like CUI leaving in an email or being shared the wrong way. I can show DLP matches, user overrides, and resulting alerts.
Insider Risk can add behavior indicators, but I treat it carefully. I document policy scope, restrict reviewer access, and keep least privilege tight so it doesn’t become a privacy and trust issue.
Centralize, retain, and present auditor-ready evidence with Microsoft Sentinel (and practical reporting)
CMMC assessments get easier when I centralize. Investigations get faster too. When I aggregate identity, activity, device, and alert data, I can correlate events and keep them longer than default portal views.
This is also where Infrastructure Optimization and IT Strategy for SMBs start to look real. Instead of guessing, I can prove patterns, response times, and control.
Centralization options: Microsoft Sentinel, Defender XDR, built-in connectors
A simple architecture works well:
- Microsoft 365 sources (Entra, Purview Audit, Defender, Intune) feed Sentinel
- Defender XDR incidents can also feed Sentinel for correlation and long-term storage
- Sentinel rules create cases I can track like any other operational workflow
Correlation examples I like because they tell a clean story: an impossible travel sign-in, followed by a DLP alert, followed by a mass download from a CUI site.
Retention, eDiscovery, and immutability basics
My retention plan has two layers: portal retention (what Microsoft 365 keeps by default) and SIEM retention (what I keep for investigations and accountability).
If I need to preserve evidence, eDiscovery holds can help for content, but AU.L2-3.3.1 is about audit logs, so I still plan long-term log storage separately. I also control who can export logs and I document that access. Tamper resistance and auditability matter.
For DoD contractors, GCC or GCC High feature availability can change the plan. I confirm capabilities early and write it down.
Auditor-ready artifacts, a short checklist, and common pitfalls
Here’s what I export and keep ready:
- Purview Audit search results (CSV)
- Entra sign-in log exports
- Defender alert lists and incident timelines
- Intune device action history and policy change records
- Sentinel incidents, analytic rule outputs, and key queries
- Screenshots of settings (audit enabled, role assignments, retention policies)
Configuration checklist I use:
- Turn on audit logging and validate it’s producing events
- Set roles for log search and export, avoid excess Global Admins
- Enforce MFA and Conditional Access for admins
- Set retention targets, confirm Standard vs Premium impact
- Connect M365 sources to Sentinel where needed
- Create alert rules and a log review ticket template
- Define review cadence and escalation steps
- Run monthly evidence exports and store them securely
Common pitfalls I watch for: assuming defaults meet retention goals, licensing gaps, too many global admins, no documented review trail, not testing exports before the assessment, and mixing test and production tenants.
CMMC audit and logging mapping (Microsoft 365 features and evidence)
| CMMC logging and audit outcome (Level 2) | Microsoft 365 feature(s) I use | Evidence I export or capture |
|---|---|---|
| Create and retain audit logs to support investigation (AU.L2-3.3.1) | Purview Audit (Unified Audit Log), Entra ID logs | Audit search CSV, retention policy screenshots, sample searches over older dates |
| Review and analyze logs on a schedule | Sentinel incidents/workbooks, Defender XDR incidents, documented SOP | Ticket records, reviewer sign-off, monthly summary report |
| Detect suspicious activity and alert the right people | Defender XDR alerting, Defender for Office 365, Sentinel analytics rules | Alert list exports, incident timeline screenshots, notification rule settings |
| Protect logs from unauthorized access or changes | RBAC in Purview/Defender/Sentinel, admin MFA and Conditional Access | Role assignment screenshots, access review records, audit of admin changes |
| Track device actions tied to CUI access | Intune device logs, Defender for Endpoint device timeline | Device action history export, compliance reports, isolation/wipe records |
Conclusion
CMMC logging auditing is a repeatable program, not a switch. When I set Microsoft 365 up with the right audit sources, retention plan, roles, and review workflow, I can cover identity, activity, device, and threat evidence in one place. That’s how I move from “we think we’re secure” to we can prove it.
If you want help getting assessment-ready, I offer Technology Consulting and Tailored Technology Services through RVA Tech Visions for Microsoft 365 audit readiness, Cloud Management, and Managed IT for Small Business. The same approach also supports Restaurant POS Support and Kitchen Technology Solutions when those environments share identities, devices, or networks that touch CUI.
Discover more from Guide to Technology
Subscribe to get the latest posts sent to your email.
