CMMC Level 2 Risk Assessment Template For Microsoft 365 Shops

If you run Microsoft 365 for a defense contractor, risk assessment can’t be a once-a-year box check. In February 2026, CMMC Level 2 is in the enforcement phase for many contracts, and assessors expect you to show repeatable work, not just good intentions.

In this post, I’m sharing a practical CMMC risk assessment template approach I use for Microsoft 365 environments, plus a copy/paste risk register you can drop into your SSP and POA&M workflow. It’s written for MSPs and small teams that need clarity fast, without hand-wavy language.

Step 1: Lock the CUI boundary in Microsoft 365 before you rate risk

My first move is scoping, because a sloppy boundary makes every risk score meaningless. I treat the tenant like a building. If you can’t point to which rooms hold CUI, you can’t prove who had access, or what controls apply.

To stay aligned to Level 2 expectations, I keep the DoD’s wording close at hand, especially the control intent and assessment objectives in the CMMC Level 2 Assessment Guide (DoD PDF). Then I document the boundary in plain terms.

Here’s the scoping checklist I use for Microsoft 365 shops:

• CUI locations: SharePoint sites, Teams channels, OneDrive libraries, mailboxes, and any synced endpoints.
• Identity plane: Entra ID users, admins, guests, service principals, and MFA methods.
• Endpoints in scope: corporate laptops, BYOD, VDI, and mobile devices that can touch CUI.
• External sharing: guest access rules, cross-tenant settings, approved partner domains, and blocked domains.
• Third-party connections: backup tools, signature tools, Teams apps, and SIEM connectors.
• What’s out of scope: marketing sites, public web, non-CUI collaboration, or a separate commercial tenant.

Gotcha: I don’t assume Microsoft 365 “is compliant.” I write down what Microsoft provides and what my client must configure, operate, and prove with evidence.

For shared-responsibility conversations, I’ve found matrices helpful as a sanity check, for example the Managed Microsoft 365 compliance support matrix.

Also, a quick reality check from the field: many small contractors aren’t only “defense.” MSPs supporting Small Business IT often straddle mixed needs like Restaurant POS Support and Kitchen Technology Solutions, while still handling CUI in Microsoft 365. That mix is fine, as long as your Secure Cloud Architecture keeps boundaries clean and your Business Continuity & Security plan matches your actual operations.

Step 2: Use a simple, repeatable CMMC Level 2 risk method (RA-1, RA-2, RA-3)

For CMMC Level 2, I keep the mechanics simple: policy, periodic assessment, and vulnerability management. The Risk Assessment family is small, but it connects to everything else (access control, audit, configuration, incident response). If you need a quick map of how Microsoft positions CMMC alignment, Microsoft’s own reference pages help with context, including the CMMC offering overview on Microsoft Learn and implementation notes like CMMC 2.0 compliance with Microsoft 365.

My scoring rules (easy to defend in an assessment)

I use a 1 to 5 scale for Likelihood and Impact, then calculate risk as Likelihood × Impact.

• Likelihood (1 to 5): How probable is this in the current setup and user behavior?
• Impact (1 to 5): If it happens, what’s the realistic harm to CUI, operations, and contract performance?
• Inherent risk: Score before new mitigations.
• Residual risk: Score after mitigations, with evidence tied to each mitigation.

I like this model because it matches how small teams actually work. You can explain it in one minute, and you can maintain it quarterly.

Evidence sources I pull from Microsoft 365 (without assuming licenses)

I build every risk entry so it points to proof. Depending on your tenant and subscriptions, I usually reference:

• Microsoft Purview audit (if enabled): user and admin actions, file access, sharing changes.
• Entra sign-in logs: risky sign-ins, legacy auth attempts, MFA outcomes, conditional access results.
• Defender alerts: identity, endpoint, and email signals, plus investigation timelines.
• Intune compliance: device posture, encryption status, OS version, compliance policy results.
• Conditional Access: policy exports, named locations, authentication strength, session controls.
• DLP and sensitivity labels: label policies, auto-label rules, DLP incidents, rule tuning notes.
• eDiscovery: holds, case exports, and chain-of-custody notes for incidents.

This is where MSP discipline matters. Good Cybersecurity Services look boring on paper because they’re consistent. Strong Endpoint Security and Device Hardening show up as stable compliance reports, fewer exceptions, and clean logs. That’s also where Cloud Infrastructure choices, Cloud Management, and Infrastructure Optimization stop being buzzwords and start being audit evidence.

Step 3: Copy/paste risk register template (with an M365 BEC example)

Before the table, here’s how I use it: every “Recommended Mitigation” becomes either (1) a completed change with evidence attached, or (2) a tracked POA&M item with an owner and due date. No orphan tasks.

Risk Register (Markdown table)

Asset/Process	CUI involved (Y/N)	Boundary/Scope note	Threat	Vulnerability	Existing Controls	Control Owner	Likelihood (1-5)	Impact (1-5)	Inherent Risk	Recommended Mitigation	Target Control/Requirement (NIST 800-171 / CMMC L2)	Residual Likelihood	Residual Impact	Residual Risk	Treatment (accept/mitigate/transfer/avoid)	POA&M item ID	Due date	Evidence/Artifacts	Status
SharePoint/OneDrive (CUI library) + Entra ID sign-ins	Y	CUI stored in dedicated SharePoint site, synced to managed endpoints only	Business email compromise (BEC) and MFA fatigue leading to CUI exfiltration	Users can approve repeated MFA prompts, weak conditional access coverage, oversharing links	MFA enabled for users, basic CA policy, some DLP rules, audit logging enabled where available	IT/Security	4	5	20	Require phishing-resistant MFA for admins, tighten CA (device compliant, location, sign-in risk if available), block legacy auth, reduce sharing defaults, add sensitivity labels for CUI, tune DLP for exfil patterns, run user training and test, validate incident response playbook	AC.L2-3.1.1, AC.L2-3.1.2, AC.L2-3.1.20, IA.L2-3.5.3, AU.L2-3.3.1, SC.L2-3.13.8, SI.L2-3.14.1, RA.L2-3.11.2	2	4	8	mitigate	POAM-AC-001	2026-04-15	Entra sign-in logs export, CA policy export, Purview audit search results, DLP alert report, Defender incident, Intune compliance report, training roster	In progress

How assessors may review this (what I prepare for)

Assessors tend to follow a simple pattern. First, they check that the risk process exists (RA-1) and that leaders review it. Next, they look for a real risk assessment cadence (RA-2), usually at least annually and after major changes like an Office 365 Migration or identity redesign.

Then they test whether vulnerabilities and fixes are tracked (RA-3), not just scanned. That means your POA&M IDs should tie to tickets, change records, and evidence. I also expect questions about cloud responsibility splits, especially if your Data Center Technology footprint is hybrid and you’re in a broader Digital Transformation push.

If you want one sentence to guide your prep, it’s this: your register should read like a story, and your evidence should prove the ending.

Conclusion

A good CMMC Level 2 risk assessment isn’t a giant spreadsheet, it’s a repeatable habit backed by proof. When I run this template quarterly, I spend less time scrambling and more time acting like the Business Technology Partner my clients expect. If you want help tailoring this to your tenant, your contracts, and your IT Strategy for SMBs, I treat it like focused Technology Consulting with Tailored Technology Services, not a generic compliance project. The goal is simple: protect CUI, pass the assessment, and keep the work moving.