CMMC environments get built around an assumption about what counts as CUI. Not every assumption survives a C3PAO review.
What we commonly see is a Controlled Unclassified Information (CUI) scope decision made in a single meeting, by whoever happens to be in the room when the question comes up. Someone points to the contracts referencing DFARS 252.204-7012, someone else names the systems that seem to touch (store, process, or transmit) that data, the environment and assessment scope get built around that answer, and the documentation gets written afterward to match it.
Everything in your assessment scope is being reviewed, but the scope may not be correct. If there are other systems or pieces of your ecosystem that store, process, or transmit CUI, but they’ve not been added to the assessment scope, then there’s an issue.
That gap doesn’t surface during normal operations. It surfaces during a review, when someone with the authority to ask expects a boundary that was justified before the environment existed, not one reconstructed to match whatever the environment already supports.
The Government Decides What Qualifies as CUI
Controlled Unclassified Information is defined by 32 CFR Part 2002 and categorized in the NARA CUI Registry, but neither document decides whether a specific piece of data an organization holds qualifies. That determination belongs to the designating agency: the executive branch agency with the authority to designate or approve the designation of a specific item of information as CUI, not the contractor storing it.
That distinction gets flattened in practice. “Sensitive,” “proprietary,” and “controlled” get used interchangeably, and CUI becomes whatever a program manager or contract officer decides feels risky enough to protect. That definition isn’t the contractor’s to write. It belongs to the designating agency, communicated through contract language, a DD Form 254, or explicit markings on the material itself.
An organization will need to protect CUI once it’s identified. It cannot decide what qualifies. A document referencing an active weapons platform’s technical specifications either meets a CUI category or it doesn’t, and that fact is set by the designating agency’s determination, not by how sensitive the contents feel to whoever received them.
Treating that authority as something contracts and IT can settle internally is the same error as treating scope as a matter of preference. Both end with a boundary the organization invented instead of one it can point to in a registry entry or contract clause.
The designation doesn’t stop at the prime. A subcontractor several tiers removed from the designating agency can receive CUI without ever seeing the contract language that designated it. DFARS flow-down requirements move the designation down the supply chain along with the data, and the subcontractor inherits the same boundary the prime was given, regardless of whether anyone re-explained the reasoning at each handoff. A subcontractor that assumes CUI status resets, or softens, once the data changes hands is applying a rule that doesn’t exist. The designation travels with the information, not with the relationship that delivered it.
Scope Follows Data, Not Departments
Once CUI is identified, the next question is where it moves inside the environment. That’s answered by data flow, not by department, team, or which system feels central to the contract.
CUI scope is every system, application, and user account that processes, stores, or transmits CUI, along with anything providing security functions for those systems. DFARS 252.204-7012 establishes the safeguarding and flow-down obligations tied to that data. FAR 52.204-21 sets a parallel baseline for federal contract information. Neither clause cares which team owns a system. Both care whether CUI passes through it.
Informal definitions do the most damage here. A file share used by three people on one contract gets excluded from scope because it “isn’t really part of the program,” but if a CUI-marked deliverable was saved there once, it’s in scope regardless of how the team categorizes its own usage. A collaboration channel used for daily coordination gets treated as low-risk because it feels informal, and informality has no bearing on whether CUI moved through it.
Inside a Microsoft environment, that flow rarely stays in one place. A CUI-marked attachment forwarded through Exchange Online, saved to a personal OneDrive folder, or referenced in a Teams channel with an external guest account has moved into every one of those services, whether or not any of them were part of the original scoping conversation. Backup jobs, mobile sync, and export functions extend that boundary further, whether or not anyone accounted for them when the environment was built.
Scope is a factual question about where data moves. It isn’t a question about intent or how central a system feels to the mission.
The Environment Follows the Boundary
Once the CUI boundary is defined, it determines which Microsoft environment is required to support it. That sequence doesn’t run the other way.
Commercial Microsoft 365 wasn’t built to meet the compliance requirements tied to CUI handling under CMMC. GCC High and Azure Government exist specifically to support ITAR, export-controlled, and CUI-relevant workloads, with data residency and access restrictions commercial tenants don’t carry. Which environment an organization needs is a direct output of where its CUI boundary sits, evaluated against CMMC assessment scoping requirements, not a separate decision made on cost, familiarity, or existing licensing.
Organizations get this backward when the environment decision comes first. A tenant gets selected based on existing licensing agreements or IT preference, and the CUI boundary gets drawn afterward to match whatever that environment can support. That reversal is why commercial M365 so often turns out to be structurally insufficient once the real scope gets mapped: the environment was never evaluated against the data it needed to hold.
The gap isn’t cosmetic. Commercial M365 support and engineering access isn’t restricted to screened U.S. persons, and the underlying infrastructure isn’t segregated to the standard CUI handling requires. An organization can layer conditional access policies and data loss prevention rules on top of a commercial tenant indefinitely and still not close that gap, because the gap sits below the configuration layer, in who can reach the infrastructure and where it physically resides.
GCC High and Azure Government also answer different questions, not competing ones. GCC High is the Microsoft 365 productivity layer, covering Exchange, SharePoint, Teams, and OneDrive. Azure Government is the infrastructure layer underneath it, for custom applications and hosted workloads, and GCC High itself runs on top of Azure Government. An organization operating both collaboration tools and custom cloud infrastructure typically needs both environments, evaluated against where CUI flows through each, not selected as alternatives depending on how sensitive the data feels. Whether ITAR-controlled technical data is present affects whether standard GCC is sufficient or GCC High is required within that productivity layer. It doesn’t decide between GCC High and Azure Government, because those two aren’t sitting on the same decision axis.
The CMMC program rule and its scoping guidance treat environment selection as downstream of scope, not a substitute for it. Defining scope after the environment is already in place inverts the sequence assessors expect to see.
Drift Is Expensive Once Remediation Starts
Scope drift rarely announces itself early. It accumulates in small decisions: a system excluded because it “probably doesn’t count,” a data flow left undocumented because no one owned the question, a contract added mid-year without revisiting whether it introduced a new CUI category. None of those decisions feel consequential when they’re made. They become consequential when a C3PAO asks for the justification behind the boundary and no single, consistent answer exists.
Remediation built on top of an undefined or inconsistently applied CUI boundary doesn’t fail because the technical controls were wrong. It fails because the boundary itself was never defensible: never justified in writing, tied to registry categories and contract language, and consistent across everyone who could be asked to explain it.
Unwinding an incorrect scope boundary after remediation has started isn’t a documentation fix. Access controls, logging configurations, user provisioning, and network segmentation built around the wrong boundary often require rework, not adjustment. The earlier the boundary is defined correctly, the less of that work has to happen twice.
The Boundary Has to Hold Before Anything Is Built on It
CUI identification isn’t the contractor’s call to make from internal judgment. The marking of CUI is based on the NARA CUI Registry, 32 CFR Part 2002; the contracting officer or designating agency is who makes the decision on whether the information will be officially marked CUI. How the CUI flows through a system determines whether that system is in scope. Scope determines which Microsoft environment, commercial, GCC High, or Azure Government, is structurally capable of supporting the requirement. None of that sequence runs in reverse.
Getting the boundary right before building around it is the difference between a scope that holds up under assessment or gets rebuilt at a cost and timeline informal definitions never accounted for.
A strategy session is where we determine what your CMMC path looks like from here, based on where you are, not a template. For an organization uncertain whether its current CUI boundary would hold up under review, that determination is more useful before remediation starts than after.
FAQ: What Counts as CUI in Microsoft 365 and Azure Government
Who decides what qualifies as CUI?
Controlled Unclassified Information is defined by 32 CFR Part 2002 and categorized in the NARA CUI Registry, but neither document decides whether a specific piece of data an organization holds qualifies. That determination belongs to the designating agency — the executive branch agency with the authority to designate or approve the designation of a specific item of information as CUI, not the contractor storing it.
Does CUI status change once data moves to a subcontractor?
No. A subcontractor several tiers removed from the designating agency can receive CUI without ever seeing the contract language that designated it. DFARS flow-down requirements move the designation down the supply chain along with the data, and the subcontractor inherits the same boundary the prime was given. The designation travels with the information, not with the relationship that delivered it.
What determines whether a system is in scope?
Scope is answered by data flow, not by department, team, or which system feels central to the contract. CUI scope is every system, application, and user account that processes, stores, or transmits CUI, along with anything providing security functions for those systems.
Does environment selection come before or after scope is defined?
Scope is defined first. Which environment an organization needs is a direct output of where its CUI boundary sits, evaluated against CMMC assessment scoping requirements — not a separate decision made on cost, familiarity, or existing licensing. Organizations get this backward when the environment decision comes first and the CUI boundary gets drawn afterward to match whatever that environment can support.
Why is commercial Microsoft 365 often insufficient for CUI handling?
Commercial Microsoft 365 wasn’t built to meet the compliance requirements tied to CUI handling under CMMC. Commercial M365 support and engineering access isn’t restricted to screened U.S. persons, and the underlying infrastructure isn’t segregated to the standard CUI handling requires. Conditional access policies and data loss prevention rules layered on top of a commercial tenant don’t close that gap, because the gap sits below the configuration layer.
What’s the difference between GCC High and Azure Government?
GCC High is the Microsoft 365 productivity layer, covering Exchange, SharePoint, Teams, and OneDrive. Azure Government is the infrastructure layer underneath it, for custom applications and hosted workloads, and GCC High itself runs on top of Azure Government. An organization operating both collaboration tools and custom cloud infrastructure typically needs both environments, evaluated against where CUI flows through each.
What happens if scope drift isn’t caught early?
Remediation built on top of an undefined or inconsistently applied CUI boundary doesn’t fail because the technical controls were wrong. It fails because the boundary itself was never defensible. Unwinding an incorrect scope boundary after remediation has started isn’t a documentation fix — access controls, logging configurations, user provisioning, and network segmentation built around the wrong boundary often require rework, not adjustment.
