My CMMC Internal Audit Checklist for Microsoft 365 Controls

A weak internal audit shows up late, usually when a contract is on the line and the evidence binder is thin. When I build a CMMC internal audit checklist for Microsoft 365, I don’t start with licenses or marketing claims. I start with scope, control intent, and proof.

Microsoft 365 can support Level 2 well, but it doesn’t make an organization compliant on its own. Your tenant, your configurations, your users, your devices, and your daily operating habits decide the result. That is where the audit has to begin.

Start with scope, CUI, and the tenant you actually use

CMMC Level 2 aligns to the 110 requirements in NIST SP 800-171 Rev. 2. In 2026, many contractors handling CUI need a C3PAO assessment, not a simple self-attestation. Because of that, I treat the internal audit as a pre-assessment, not a casual health check.

My first review point is simple: where does CUI live, move, and get copied? In Microsoft 365, that usually means Exchange Online, SharePoint, OneDrive, Teams-connected storage, endpoints, mobile devices, and backup or archive tools. It also includes identities in Entra ID and security events in audit logs. If the organization can’t trace CUI through those paths, the rest of the audit gets shaky fast.

For most CUI workloads, Microsoft 365 Commercial is not the safe default. In practice, GCC High is usually the starting point for Level 2 work unless a qualified compliance review supports another approach. Microsoft’s own Technical Reference Guide for CMMC 2.0 is one of the best reality checks I use during planning.

Microsoft 365 can support compliance, but no license, add-on, or preset creates compliance by itself.

I also verify the assessment boundary. That means documented system diagrams, a current asset list, a defined list of in-scope users, third-party integrations, email security tools, remote support tools, and managed services. If an MSP touches admin functions, that relationship belongs in the audit. If an MSSP monitors Defender alerts, that belongs there too.

The evidence I want at this stage is foundational: SSP excerpts, data flow diagrams, tenant details, licensing records, responsibility matrices, and documented CUI handling rules. Common findings start here. I often see teams with a clean tenant but no written boundary, or a strong SSP that doesn’t match live Microsoft 365 settings. That gap creates trouble because auditors test both the words and the working system.

Identity and access controls in Entra ID get reviewed first

If I had to predict where an internal audit will uncover the most risk, I would pick identity every time. Entra ID is the gate to email, files, administration, remote access, and often line-of-business apps. When identity is loose, every other control weakens.

I review MFA coverage for all users first, then I look harder at privileged accounts. Break-glass accounts must be rare, documented, monitored, and excluded only where there is a written reason. Conditional Access policies should block risky sign-ins, require strong authentication, and restrict legacy protocols. I also confirm that administrators use separate admin accounts and, where possible, dedicated admin workstations.

Next, I review how access gets granted and removed. Group-based access is easier to audit than one-off direct assignments. Guest accounts deserve extra attention because external sharing often expands quietly over time. For Level 2, I want clear approval paths, regular access reviews, and proof that terminated users lost access quickly.

The evidence I collect here is concrete. I want exported Conditional Access policy settings, privileged role assignments, MFA registration reports, sign-in logs, access review records, and screenshots with dates when exports are not available. I also want the written procedure that explains who approves access, how often reviews occur, and what happens when exceptions appear.

Common audit findings show up in familiar patterns. A service account gets excluded from MFA and nobody compensates for that risk. A global admin account stays active for daily email use. Legacy authentication remains enabled for one old device and opens a broad path around stronger controls. Guest users pile up in SharePoint sites because no one owns the review cycle.

This is also where I remind teams that convenience can hide real exposure. A smooth sign-in experience is not the same as a controlled one. If I can’t tie Entra ID settings to written policy and recurring review, I mark the control as weak even when the dashboard looks healthy.

Device hardening and endpoint security need proof, not assumptions

CMMC auditors do not stop at cloud settings, because users work on devices. If CUI lands on a laptop, phone, or virtual desktop, endpoint control matters. That is why Intune, Defender, and device configuration reviews sit near the top of my checklist.

I start with inventory. Every in-scope device should have a known owner, known status, and a reason it is allowed to reach Microsoft 365. Then I review Intune enrollment, compliance policies, device configuration profiles, BitLocker settings, OS update posture, local admin restrictions, screen lock timing, and removable media controls. If the organization uses Windows LAPS, I verify rotation and access controls for local admin passwords.

Defender for Endpoint adds another layer. I check endpoint detection coverage, antivirus status, attack surface reduction rules, tamper protection, web protection, and alert triage. A good control set on paper means little if half the devices never report in or if alerts sit untouched for weeks.

The evidence I want is operational. That includes Intune compliance reports, policy assignment records, encryption status, patch reports, Defender exposure scores, incident tickets, and exception approvals. If a device fails policy but still accesses SharePoint or OneDrive, I want the reason in writing.

Many organizations ask for help here under broader Cybersecurity Services, and that makes sense because device control crosses policy, deployment, and support. In my experience, Endpoint Security and Device Hardening work only when the security team and the operations team share the same view of what “managed” means. For many contractors, that also ties into Managed IT for Small Business, Cloud Management, and Business Continuity & Security, because a weak device can trigger both a security event and a work stoppage.

Common findings are easy to spot. BYOD phones access Exchange Online without full controls. A remote laptop is encrypted, but nobody verifies recovery key handling. Old devices stay in Entra ID long after retirement. An engineer syncs CUI into OneDrive on an unmanaged workstation during travel. Each of those issues weakens control families well beyond endpoint protection.

Protecting CUI in Exchange Online, SharePoint, OneDrive, and Purview

Once identity and devices are in shape, I move to the places where CUI actually sits. This part of the audit is where a lot of teams discover that file sharing habits grew faster than governance.

In Exchange Online, I review mailbox auditing, transport rules, auto-forwarding restrictions, external recipient controls, and encryption practices. In SharePoint and OneDrive, I check external sharing settings, anonymous link rules, default link types, sync controls, and site-level exceptions. In Purview, I want to see sensitivity labels, label publishing, DLP policies, retention settings, and alerting tuned to how the business handles CUI.

This is also where old project decisions matter. A rushed Office 365 Migration often leaves broad permissions, stale sites, or inherited folders that no longer fit the control set. The same is true when Cloud Infrastructure decisions were made for convenience first and security second. I have also seen problems spill over from Data Center Technology projects where hybrid identities and file paths stayed half-migrated for years.

A quick audit map helps keep the review grounded:

Microsoft 365 area	What I review	Evidence I collect	Common finding
Exchange Online	Mail forwarding, transport rules, mailbox audit status	Admin settings, message trace samples, policy screenshots	Auto-forwarding to personal email
SharePoint	Site sharing, guest access, permission inheritance	Sharing reports, site admin list, exception approvals	Anonymous or overly broad links
OneDrive	Sync behavior, unmanaged device restrictions	Sync settings, device access reports	CUI synced to untrusted devices
Purview	Labels, DLP, retention, alert handling	Policy exports, incident logs, label publishing records	Labels created but never enforced

The table shows a pattern I see often. Controls exist, but deployment is partial. A tenant may have good Purview labels, yet users can still create broad SharePoint links. Or DLP alerts may fire, but nobody triages them.

When I need a practical cross-check on Microsoft 365 options and CMMC alignment, I compare my findings with this Microsoft 365 and CMMC 2.0 overview. It reinforces a point I see in audits every week: product choice matters, but execution matters more.

A strong review here includes sample records. I want to inspect a few labeled files, test sharing behavior, confirm message protections, and verify that policy exceptions are both rare and approved. Common findings include labels that users don’t understand, SharePoint sites with inherited permissions nobody can explain, and OneDrive sync allowed on devices outside the managed baseline.

Audit logs, monitoring, and response evidence must hold up under pressure

Logging is where internal audits move from “configured” to “provable.” If a security event occurs, I need to know who can find it, interpret it, escalate it, and preserve evidence. Microsoft 365 gives strong tooling for that, but only if the organization keeps it turned on, scoped well, and tied to written process.

I review Microsoft 365 unified audit logging first. Then I verify retention, mailbox audit settings, sign-in logs, Entra ID risky sign-ins, Defender incident history, and alert routing. A mature team also maps key events to procedures, such as impossible travel alerts, mass download activity, failed admin sign-ins, mailbox rule changes, or suspicious file sharing.

My audit file for this section always includes more than screenshots. I collect ticket samples, incident response records, after-action notes, alert tuning decisions, escalation contacts, and proof of regular review meetings. If a third-party SIEM or SOC is involved, I document the handoff. Shared responsibility matters because a missed alert is still a missed alert.

I usually follow a short internal process before I mark these controls ready:

1. I confirm that logging is enabled for the required Microsoft 365 sources and that the team knows where to retrieve records.
2. I sample recent alerts and verify that someone reviewed, classified, and closed them.
3. I match live events to the incident response procedure and see whether the documented steps mirror reality.
4. I check retention and evidence handling so records remain available when an assessor asks for them.

The common mistakes are painfully consistent. Logs exist, but nobody reviews them on a schedule. Alert rules produce noise, so analysts ignore them. Incident records lack timestamps or ownership. Audit logs are available, yet the organization cannot show how monitoring ties back to policy. Those issues produce findings because CMMC expects both technical and procedural control.

For MSPs and MSSPs, this section is where client trust either strengthens or slips. If I claim to monitor Microsoft 365, I need evidence that I monitored it, responded to it, and documented it.

How I apply this checklist for SMBs, MSPs, and mixed environments

Most organizations I work with are not massive primes. They are manufacturers, subcontractors, field teams, and support firms that need clear guardrails and a realistic path to readiness. That is why I build this checklist so it works for compliance managers, internal IT, and outside providers.

In the SMB space, the work often overlaps with broader Small Business IT, Technology Consulting, and IT Strategy for SMBs. A contractor may also depend on a trusted Business Technology Partner for Tailored Technology Services, Infrastructure Optimization, and ongoing Secure Cloud Architecture support. Those terms sound broad, but in a CMMC audit they become concrete. I need to know who owns Entra ID, who manages Intune, who approves Purview changes, and who keeps evidence current.

That matters even more when an MSP supports more than one vertical. I have seen providers that handle defense clients while also delivering Restaurant POS Support, Kitchen Technology Solutions, and other operational systems. The service model can still work, but segregation, documentation, and role control have to be tight. Mixed practice areas do not excuse weak admin hygiene.

I also see CMMC work tied to broader Innovative IT Solutions and Digital Transformation projects. Those projects can help if they reduce shadow IT and tighten control. They can also create risk if migrations happen faster than policy updates.

The most useful audit packet is simple:

• A live system boundary and data flow record
• Current policy and procedure documents
• Microsoft 365 configuration evidence tied to each control area
• Exception logs, approvals, and review dates

When those four pieces stay current, internal audits get faster and external assessments get less painful.

Conclusion

A strong Level 2 review in Microsoft 365 is never about one dashboard, one license, or one perfect screenshot. It is about whether I can prove that identities, devices, data, and logs work together under a controlled process.

The best internal audits are honest enough to catch weak spots before an assessor does. If I can trace CUI, verify control operation, and produce clean evidence on demand, the environment is far closer to CMMC readiness than any marketing claim could ever make it.