By William Price, Certified Lead CMMC Assessor (LCCA) — A³ Vallum CMMC Advisory
Microsoft 365 GCC High is the architecture most CMMC Level 2 contractors land on, and it is the architecture where scoping decisions hurt the most when they go wrong. The collaboration suite — Teams, SharePoint, OneDrive, Exchange — is sprawling by design. CUI sneaks in through every channel of it: an attachment in chat, a comment thread in a SharePoint document, a personal OneDrive folder a user uses for “just one file.” If you get the scope right, the assessment is contained. Get it wrong and you will discover at Phase 1 of the assessment that half your company is in scope.
The simplest and most defensible approach to controlling CUI in GCC High is to use the GCC High tenant as an enclave with the proper DLP controls such as sensitivity labels to control its flow.
The default configuration: GCC High is one big CUI Asset
The Microsoft 365 GCC High tenant — meaning the entire tenant, all its services — is a CUI Asset by the Scoping Guide’s definition the moment any service in that tenant processes, stores, or transmits CUI. And again, per the Level 2 Scoping Guide, CUI Assets are assessed against all 110 Level 2 security requirements and it must be stored in FedRAMP Moderate cloud applications if using the cloud.
The tenant-as-monolith reading is the conservative one and the one most C3PAOs default to. They will default to your entire tenant being in scope. To narrow the scope to specific services within the tenant, you have to do work — documentation and configuration. Each service that handles CUI gets specific scoping treatment in the SSP. Each service that does NOT handle CUI gets specific separation evidence.
SharePoint: the hub of CUI in M365
SharePoint is where most CUI lives in a GCC High deployment. The scoping question is rarely about whether SharePoint is in scope (it almost always is) — it is about how granularly you can carve up the SharePoint estate. This really comes into play if the entire organization is moving to GCC High but not all employees need to access CUI.
There are three common ways for doing this:
1. The CUI site collection model. A dedicated SharePoint site for CUI, protected by a Microsoft Purview sensitivity label tied to a Conditional Access authentication context. Only specific users in a specific Entra security group can access it. The site is a CUI Asset. Other site collections in the same tenant are CRMAs (capable of receiving CUI through misconfiguration).
2. The CUI document library model. A single library within a broader site. Tighter scope but harder to defend — assessors will probe the labeling discipline and the path for CUI to drift into adjacent libraries.
3. The dedicated CUI tenant model. Some contractors run a separate GCC High tenant exclusively for CUI work. This is the cleanest scope. It’s the most expensive but worth it for contractors with significant CUI volume.
The Purview sensitivity label may be the single most important technical control. It carries through to OneDrive, Exchange, and Teams, and it should be closely linked to Conditional Access policies. A site protected by a CUI label, with a Conditional Access policy requiring a managed device and MFA per IA.L2-3.5.3, is the architectural pattern most C3PAOs are familiar with. This doesn’t mean other methods won’t work; there’s just more evidence burden on your part.
Microsoft Teams: where CUI scope quietly expands
Teams is the M365 service where scope expands without anyone noticing.
Files shared in Teams chat. A file shared in a chat goes to the sender’s OneDrive by default. If the file is CUI and the recipient’s OneDrive is not in the CUI scope, you have a CUI flow into an out-of-scope OneDrive. Resolve this by enforcing CUI label inheritance on Teams chat attachments, or by blocking CUI labels from being shared in chat at all.
Files shared in Teams channels. Channel files go to the underlying SharePoint site. If the Team’s site is the CUI site, this works. If not, scope leaks again. Tie Team creation to the CUI site collection only for CUI-handling teams.
Meeting recordings. Teams meeting recordings save to OneDrive (1:1 meetings) or SharePoint (channel meetings). If a meeting discusses CUI and is recorded, the recording is now CUI. Most contractors disable recording for CUI-handling channels entirely; some enforce sensitivity label inheritance on recordings.
For most contractors, Teams ends up in scope as a CUI Asset because the integration with SharePoint and OneDrive makes scope leakage too difficult to control any other way.
OneDrive: the most common CUI scope failure
OneDrive is where users put files when they want them “out of the way.” It is also where CUI ends up when users drag a CUI document out of SharePoint to “work on it locally.” OneDrive sync to a personal endpoint can also pull CUI to a local hard drive, which is its own scoping problem.
Three controls that work:
1. Disable OneDrive sync for CUI-labeled content. Microsoft’s Endpoint DLP and Purview sensitivity labels can prevent CUI-labeled files from being saved to OneDrive at all, or from syncing to local devices.
2. Block CUI sensitivity labels from OneDrive sites. Tenant-level controls can prevent CUI-labeled content from being saved in personal OneDrive sites entirely. This is the cleanest path. CUI lives in dedicated SharePoint, never in personal OneDrive.
3. Treat OneDrive as in-scope by default. If the contractor cannot enforce one of the above, treat all OneDrive sites as CUI Assets. The scope expands but the assessment is defensible.
The contractor whose OneDrive is full of “just one file” CUI is the contractor whose assessment lengthens dramatically. The cleanest position is “no CUI in OneDrive, period,” enforced through Purview policies.
Exchange Online (email): the scoping ambiguity
Email is where the FCI/CUI question gets its most awkward expression. A USAF email arrives in your commercial mailbox marked “CUI.” Now what?
The Scoping Guide answer: Exchange Online in your GCC High tenant is a CUI Asset if it processes CUI. Most CMMC environments do receive CUI via email — agency communications, contracting documents, technical correspondence. Exchange is almost always in scope.
The harder question is mailbox boundary. A few options:
All mailboxes in scope. Simplest. Defensible. The whole Exchange organization is a CUI Asset.
CUI-labeled mailboxes only. Some mailboxes (technical staff, contracting team) handle CUI; others (HR, marketing) do not. Use sensitivity labels and Conditional Access to enforce — but be ready to defend the separation. Assessors will probe whether CUI can reach a non-CUI mailbox via reply-all or forwarding.
Encrypted CUI in transit only. Some contractors use encryption gateways (Virtru, PreVeil, etc.) so CUI never lands in Exchange in cleartext. The CUI is protected at the application layer. Exchange becomes a transport, not a CUI Asset, IF the encryption is FIPS-validated end-to-end.
How DIBFI handles this
DIBFI helps you map every M365 service against the Scoping Guide categories — SharePoint sites, OneDrive sites, Teams, Exchange — with the labeling, Conditional Access, and DLP policies populated into the SSP. The scope decisions for each service are documented and living.
What about the rest of the tenant?
Power Platform (Power Automate, Power Apps), SharePoint Lists, Forms, Stream, Yammer, Bookings — every M365 service can technically receive CUI. The scoping question for each service follows the same logic: does it process, store, or transmit CUI? If yes, in scope. If no, document why not.
Some contractors disable or restrict the lower-traffic services entirely for the CUI-handling user population. Power Automate flows that touch CUI become a scoping nightmare. They often run as system accounts, hit external services, and create CUI processing paths the SSP did not describe. The cleanest position is “Power Platform is disabled for the CUI user group” unless there is a specific business need.
The DLP layer that makes the whole thing work
Microsoft Purview DLP is the technical control that turns the labeling architecture into actual scope enforcement. A contractor with sensitivity labels but no DLP policies has a labeling system. A contractor with both has a scope-enforcement architecture.
Useful DLP rules for CMMC:
- Block CUI-labeled content from leaving the tenant
- Block CUI-labeled content from being shared with external users not on an allow-list
- Block CUI-labeled content from being saved to non-CUI SharePoint sites or OneDrive
- Block CUI-labeled content from being attached to Teams chat (vs. channels)
- Audit CUI-labeled content access by user, by site, by file
DLP findings end up in audit logs that the assessor will Examine under AU.L2-3.3.1 through 3.3.9. Strong DLP gives you both the technical control AND the evidence trail in one move.
Frequently Asked Questions about CUI in Microsoft 365
Is GCC High the only acceptable M365 tenant for CMMC Level 2 with CUI? Not strictly. GCC High is the most common path because it meets DoD Impact Level 5, ITAR alignment, and US-person personnel handling. Commercial M365 cannot host CUI for CMMC Level 2 in any defensible configuration. GCC (without the High) sits in between and has narrower applicability.
Can I keep some users in commercial M365 and CUI users in GCC High? Hybrid configurations are possible but require explicit boundary documentation. The two tenants must have controlled identity federation (or no federation), DLP that prevents CUI movement between them, and SSP language that describes the boundary. This is a very common approach for cost affectiveness.
Does Conditional Access alone narrow the scope? It strengthens the security posture but does not by itself remove services from scope. Per the Scoping Guide, scope is determined by whether the service processes/stores/transmits CUI. Conditional Access controls who can access — useful for AC.L2-3.1.1 — but does not change the asset categorization.
What about the Microsoft Customer Responsibility Matrix for GCC High? Microsoft publishes a CRM for GCC High that addresses the boundary between Microsoft’s responsibility (the platform) and the customer’s responsibility (configuration, users, data). For CMMC purposes, this CRM is a starting point, not a complete CRM. Your tenant configuration adds responsibilities Microsoft’s CRM does not cover. Your CMMC CRM for your assessment is your responsibility.
Are SharePoint sites that contain only FCI (not CUI) in scope for Level 2? A Level 2 environment satisfies the Level 1 requirements for the same scope per the Scoping Guide. FCI-only sites in a Level 2 tenant are in scope but do not require additional Level 2 assessment work beyond what is already done for the CUI sites.
How do I document this for the SSP? Per 32 CFR § 170.19(c)(2), each cloud provider is documented as an ESP (Microsoft) with the data-flow description, the labeling and Conditional Access architecture, the DLP policies, and the audit and access-review cadences. The SSP should describe the M365 architecture at the service level with cross-references to the relevant assessment objectives.
Closing thought
Contractors who keep their M365 scope manageable are the ones who picked one architecture pattern — dedicated CUI site collection, sensitivity labels with Conditional Access, DLP enforcement — and held the line against scope drift in OneDrive, Teams chat, and Power Platform. So when you next open your M365 admin center, can you point to the SharePoint site, the Conditional Access policy, and the DLP rule that together define your CMMC boundary inside the tenant?
A³ Vallum runs M365 GCC High scoping engagements that hold up to a C3PAO assessment. If your CUI is “somewhere in the tenant” and you need it concentrated into a defensible boundary, reach out.
About DIBFI
DIBFI is a guided CMMC readiness platform that takes contractors from scoping through certification on a phased, gated journey — real-time guidance, all 320+ Level 2 objectives tracked, an interactive SSP Builder, and “Ask an Assessor” when you need a CCA’s read on a specific control.
Sources
- 32 CFR Part 170 — § 170.19 (Scoping), § 170.19(c)(2) (ESP documentation in SSP)
- CMMC Assessment Scope – Level 2, v2.13 (September 2024), DoD CIO (DoD-CIO-00006)
- DFARS clause 252.204-7012 — Safeguarding Covered Defense Information
- DoD CIO Memo, December 21, 2023, “FedRAMP Moderate Equivalency for Cloud Service Providers”
- NIST SP 800-171 Revision 2
- NIST SP 800-171A — assessment objectives, particularly AC.L2-3.1.1 (Authorized Access Control), AC.L2-3.1.20 (External Connections), AU.L2-3.3.1 through 3.3.9 (Audit & Accountability), IA.L2-3.5.3 (MFA), SC.L2-3.13.11 (FIPS-Validated Cryptography), MP.L2-3.8.9 (Backups)
- Microsoft Purview documentation (sensitivity labels, DLP, Conditional Access integration) — Microsoft Learn
