Preventing CUI Spill Into the Wrong Cloud Tenant
The Operational Failure That Assessors Are Trained to Find
A CUI spill into a non-compliant cloud tenant is one of the fastest ways to fail a CMMC assessment — and one of the hardest to detect until an assessor finds it for you. Here is how spills happen in practice, and the enforceable controls that actually stop them.
What a "Spill" Is in Practice
In CMMC, a spill is not a data breach. It is not an attack. It is far more ordinary than that — and far more common.
A CUI spill occurs any time Controlled Unclassified Information moves from a system or environment that is authorized to handle it into one that is not. The data doesn't have to leave the organization. It doesn't have to reach an adversary. It just has to land somewhere outside the accreditation boundary defined in your System Security Plan.
DFARS 252.204-7012 requires that cloud services storing, processing, or transmitting CUI meet FedRAMP Moderate or equivalent standards. When CUI lands in a non-compliant environment — Commercial Microsoft 365, an unmanaged personal cloud, a third-party SaaS tool — it violates that requirement. The contractor's obligation is to prevent the spill from happening and, when it does happen, to detect and remediate it within a documented timeline.
Spills are not theoretical. They are the default outcome of any environment where compliant and non-compliant systems coexist and users are expected to navigate both. Without enforceable technical controls, spills are a certainty — the only variable is whether you catch them before the assessor does.
Email Forwarding, Guest Sharing, Sync Clients, Copy/Paste, and Exports
Spills rarely happen because someone decides to break a rule. They happen because the path of least resistance routes CUI into the wrong place. These are the vectors that account for the overwhelming majority of spills in organizations running split or hybrid Microsoft 365 environments.
Email Forwarding
A user in GCC High receives a CUI-marked email and forwards it to a colleague whose mailbox is in Commercial — or to an external address outside the organization entirely. The message, its attachments, and its metadata are now stored in an unauthorized Exchange Online instance. Auto-forwarding rules and distribution lists make this worse: a single rule can route every inbound message to a non-compliant mailbox indefinitely.
Guest Sharing in SharePoint and OneDrive
SharePoint and OneDrive allow guest access links by default. A user shares a CUI file with a subcontractor by generating an "Anyone with the link" URL. That link is accessible from any browser, any device, any tenant — none of which are within the assessment boundary. Even "People in your organization" links can reach users in a parallel Commercial tenant if they share the same Azure AD directory.
Sync Clients
The OneDrive sync client mirrors cloud content to the local file system. If a user syncs a GCC High library to a personal device — or worse, to a device enrolled in a Commercial Intune instance — the CUI is now at rest on an endpoint outside the accreditation boundary. The sync client does not distinguish between compliant and non-compliant destinations. It will copy whatever it is told to copy.
Copy/Paste and Screen Capture
A user opens a CUI document in a browser-based GCC High SharePoint session and copies the content into a Word document stored in Commercial OneDrive — or pastes it into a Teams message in the Commercial tenant. No file was transferred. No attachment was created. But the CUI is now in the wrong environment. The same applies to screenshots, print-to-PDF, and any local clipboard operation.
Exports and Downloads
SharePoint list exports, Power BI data downloads, Excel exports from Dynamics — any feature that lets a user extract data from a compliant cloud and save it locally or into another service creates a spill vector. These export functions are enabled by default in most Microsoft 365 configurations and are frequently overlooked during hardening.
Shadow IT and Unmanaged Identities
Not every spill happens through Microsoft 365. Some of the most dangerous spills happen through tools and identities that IT never provisioned and never monitors.
Shadow IT is any technology used for work purposes that is not sanctioned or managed by the organization's IT department. In the context of CUI, shadow IT includes personal Dropbox accounts, Google Drive, WeTransfer, Signal groups, personal email, and any SaaS application a user signs up for with a corporate or personal email address. None of these services have FedRAMP authorization. None are within the assessment boundary. All of them can receive CUI in seconds.
Unmanaged identities compound the problem. If employees have Azure AD accounts in both a Commercial and GCC High tenant — and many split-tenant organizations do — there is nothing in the default configuration that prevents a user from signing into either environment from the same device, opening two browser tabs side by side, and dragging content from one to the other. The user doesn't think of this as crossing a compliance boundary. They think of it as doing their job.
Personal devices present a separate class of risk. If a user authenticates to GCC High Exchange from a personal phone's native mail client, that client may cache email locally, sync contacts, and download attachments to unmanaged storage. Mobile Application Management policies in Intune can mitigate this — but only if the device is enrolled and the policies are configured. For personal devices, that enrollment often doesn't exist.
Technical Controls That Actually Reduce Spill Risk
There are dozens of controls a contractor can implement to reduce spill risk. Not all of them are equally effective. The following are the controls that have the highest impact on actual spill prevention — the ones that change the default behavior of the environment rather than relying on users to remember a policy.
| Control | What It Does | Impact |
|---|---|---|
| Sensitivity Labels (Microsoft Purview) | Tags CUI content with a persistent label that travels with the file. Enforces encryption, access restrictions, and watermarks regardless of where the file moves. | High — follows the data |
| DLP Policies (Data Loss Prevention) | Blocks or warns when CUI-labeled content is shared externally, emailed to unauthorized domains, uploaded to non-compliant services, or printed. | High — blocks at point of action |
| Conditional Access Policies | Restricts GCC High access to compliant, managed devices only. Blocks sign-ins from unmanaged endpoints, personal devices, or untrusted networks. | High — prevents endpoint spill |
| External Sharing Restrictions | Disables "Anyone with the link" sharing in SharePoint and OneDrive. Limits guest access to pre-approved domains. Requires authentication for all shared links. | High — closes default vector |
| Mail Flow Transport Rules | Blocks outbound email containing CUI markers to non-GCC High recipients. Can quarantine or reject messages that match CUI patterns or sensitivity labels. | Medium — can be circumvented by rewording |
| Endpoint DLP (Microsoft Purview) | Monitors and restricts copy/paste, screen capture, print, and USB transfers of CUI-labeled content on managed Windows endpoints. | Medium — Windows-only, requires Intune enrollment |
| OneDrive Sync Restrictions | Limits sync client access to domain-joined or Intune-compliant devices only. Prevents syncing GCC High libraries to unmanaged machines. | Medium — does not cover browser downloads |
| Cloud App Discovery / CASB | Identifies unsanctioned SaaS applications receiving corporate data. Flags shadow IT usage in real time. | Medium — detection, not prevention |
Policies Versus Enforceable Controls
Every organization has a policy that says employees should not store CUI in unauthorized locations. Almost no organization can prove that policy is enforced.
Under NIST SP 800-171, there is a critical distinction between a policy — which describes what should happen — and a control — which makes it happen. Assessors evaluate both, but they assign vastly different weight to each. A policy without a corresponding technical enforcement is, from an assessment standpoint, an aspiration. It is not evidence of implementation.
"Users shall not share CUI externally."
This statement in your Acceptable Use Policy does not prevent a user from generating a public SharePoint link. It documents your intent. The assessor will ask what stops the action from happening — and "we told them not to" is not a satisfying answer.
External sharing disabled at the tenant level.
SharePoint admin settings restrict sharing to authenticated users within the organization only. Guest access is disabled globally and enabled only for specific, pre-approved sites with documented business justification. The control is auditable. The setting can be shown to an assessor.
"CUI must not be emailed to personal accounts."
Without a transport rule enforcing this restriction, users can forward CUI to any email address in the world. The policy exists. The control does not.
Transport rule blocks CUI-labeled outbound mail.
A mail flow rule in Exchange Online detects the sensitivity label on outbound messages and blocks delivery to any domain not on the approved list. Blocked messages are quarantined and logged. The rule, the quarantine logs, and the approved domain list are all evidence an assessor can examine.
The pattern is consistent: for every CUI-related policy in your documentation, the assessor will look for a corresponding technical mechanism that makes the policy enforceable. Where the mechanism is missing, expect the assessment objective to be scored Not Met — regardless of how well the policy is written.
How to Prove Spill Prevention During Assessment
Assessors evaluate spill prevention across multiple NIST SP 800-171 control families. The controls are not grouped under a single "spillage" domain — they are distributed across Access Control (AC), Media Protection (MP), System and Communications Protection (SC), and Audit and Accountability (AU). Here is what an assessor will actually ask for.
Incident Response When a Spill Has Already Happened
Prevention is the goal. But spills will happen. The question an assessor asks is not whether your organization has ever experienced a spill — it is whether you have a documented, tested process for detecting, containing, and remediating one when it occurs.
Detect
DLP alert, audit log trigger, user self-report, or Content Search discovery identifies CUI in a non-compliant location
Contain
Revoke access to spilled data. Quarantine the file or message. Disable sharing links. Preserve evidence before deletion.
Remediate
Permanently delete CUI from unauthorized location. Confirm deletion via Content Search. Document root cause and corrective action.
A spill response procedure should include the following documented steps:
- Detection mechanism — How the spill was identified: DLP alert, audit log query, user report, or Content Search sweep
- Scope determination — Which files, messages, or records were affected. Which users accessed the spilled data. Which systems stored it.
- Containment actions — Immediate steps taken to stop further exposure: revoking access, disabling links, quarantining mailboxes
- Evidence preservation — Screenshots, export of audit logs, and hash of affected files before deletion — the spill itself becomes evidence
- Permanent deletion and verification — Use Microsoft Purview Content Search to confirm CUI has been removed from all affected locations, including Recoverable Items folders and retention holds
- Root cause analysis — What control failed or was absent. What configuration change, policy update, or training gap allowed the spill.
- Corrective action — The specific technical or procedural change implemented to prevent recurrence — documented in the POA&M if the fix is not immediate
- 72-hour reporting assessment — Documented determination of whether the spill constitutes a reportable cyber incident under DFARS 7012(c)
The Bottom Line
CUI spills are not edge cases. In any environment where compliant and non-compliant systems coexist — split tenants, overlay architectures, BYOD endpoints — spills are the expected failure mode. The question is not whether they will happen. The question is whether your environment is configured to make them difficult, your monitoring is configured to detect them quickly, and your incident response is configured to contain and remediate them completely.
An assessor will evaluate all three layers. A policy alone — no matter how well-written — does not satisfy any of them.
The most defensible position during an assessment is not "we have never had a spill." It is "we have controls that make spills difficult, monitoring that detects them when they occur, and a tested process that resolves them within a documented timeline." That is what compliance looks like in practice.