CUI spillage is one of those compliance terms that every defense contractor knows exists and hopes they never have to apply. Until it happens.
When CUI lands on an unauthorized system — a personal Gmail account, an unencrypted laptop, a Dropbox folder a subcontractor set up informally, a machine outside your assessed boundary — you have a spillage event. The question is no longer whether it happened. The question is what you are now required to do, how quickly, and whether your documentation can prove you did it correctly.
This post covers what CUI spillage is under the DoD framework, the specific reporting and response obligations it triggers, and the architectural decisions that determine whether a spillage event is a contained inconvenience or a documented compliance failure.
What Is CUI Spillage?
CUI spillage occurs when Controlled Unclassified Information is introduced into an information system that is not authorized to handle it. This includes:
- CUI transmitted to a personal email account (the sender's or anyone else's)
- CUI saved to personal cloud storage (Google Drive, Dropbox, iCloud, OneDrive personal)
- CUI accessed on a device outside your CMMC system boundary (a personal laptop, a subcontractor's unmanaged endpoint)
- CUI forwarded to a recipient whose system is not authorized to receive it
- CUI found in an environment after an unauthorized access event — a credential compromise, a phishing incident, or a misconfigured sharing permission
Spillage is not the same as a breach in the traditional sense. It does not require a malicious actor. A cleared engineer who emails a CUI-containing drawing to their personal account for convenience has caused a spillage event. An administrative assistant who attaches an export-controlled specification to a reply that goes to an uncleared distribution list has caused a spillage event. The unauthorized destination is what defines spillage, not the intent behind the transfer.
DoD's governing framework for CUI comes from the National Archives and Records Administration (NARA) CUI Registry, DoD Instruction 5200.48, and CMMC Level 2's implementation of NIST 800-171. What CMMC Level 2 encryption requirements actually mean in practice establishes the foundational control set, but when controls fail and spillage occurs, a separate response framework kicks in.
What Are the Immediate Reporting Obligations Under DFARS?
DFARS 252.204-7012 establishes the reporting framework for cyber incidents affecting CUI. When a spillage event qualifies as a cyber incident — which it frequently does, particularly when it results from unauthorized access — the following requirements apply:
72-hour reporting window: Defense contractors must report the cyber incident to DoD via the DIBNet portal within 72 hours of discovery. This is not a business-day window. It runs from the moment the incident is identified, regardless of weekends or holidays.
Preservation of images: Contractors must preserve images of all systems believed to be affected for 90 days following the report, to support potential DoD forensic investigation. System sanitization cannot begin until DoD either completes its review or authorizes the contractor to proceed.
Contract number and system identification: The DIBNet report requires the specific contract numbers covered by DFARS 252.204-7012, the company's CAGE code, and identification of the systems or networks where the incident occurred.
DoD notification of individuals: If the spillage event involves CUI whose unauthorized disclosure could harm individuals, DoD may require notification. The specific obligation depends on the category of CUI involved.
Contractors often discover that their 72-hour clock started earlier than they realized. The discovery date — when someone in the organization first became aware of the event — is the starting point, not when the formal incident response process was initiated. Documentation of when the event was discovered, by whom, and what initial steps were taken in the first hours is part of the compliance record.
🚨 Contain Spillage Before the 72-Hour Clock Runs Out
Portals and container permissions can't stop a downloaded file from leaking plaintext CUI. Learn how persistent per-file encryption limits your blast radius.
What Does a CUI Spillage Response Require?
DoD Instruction 5200.48 provides the governing framework for CUI spillage response. The response process has four required phases:
1. Contain: Stop the spread of spilled CUI immediately. This means revoking access to the unauthorized system or location, removing the CUI from accessible locations where possible, and preventing further transmission. If the spill was via email, quarantine the message if your mail system permits it. If the spill was to a cloud storage service, revoke sharing permissions.
2. Assess the scope: Determine exactly what CUI was spilled, to which systems or individuals, and whether those recipients have transmitted it further. The scope assessment is what the DoD forensics review will examine. Your documentation of this process needs to be thorough.
3. Sanitize: Once authorized to proceed, sanitize the affected systems or storage locations according to NIST Special Publication 800-88 guidelines. Sanitization means clearing, purging, or destroying the media where the spilled CUI resided — depending on the sensitivity of the CUI and the type of media. A file deletion is not sanitization. Overwriting, physical destruction, or cryptographic erasure (for encrypted systems) are sanitization methods.
4. Document and report: Produce a complete incident report that covers discovery timeline, scope assessment, containment steps, sanitization actions, and any DoD notifications. This report becomes part of your compliance record and may be reviewed in future CMMC assessments.
The DoD also reserves the right to conduct its own damage assessment. Contractors may receive a request from the Defense Contract Management Agency (DCMA) or another DoD component to participate in or support that assessment.
What Is the Relationship Between Spillage and Your CMMC Compliance Posture?
A CUI spillage event does not automatically disqualify a contractor from CMMC certification. What it reveals is whether your implemented controls — and your response capability — match what your System Security Plan says they are.
Three areas of your CMMC posture are directly implicated in a spillage event:
Access control (AC domain): AC.L2-3.1.1 and related practices require that CUI access is limited to authorized users and systems. If spillage occurred because a sharing permission was misconfigured, an access control was insufficient, or a user could route CUI to unauthorized destinations, your AC implementation has a documented gap.
Encryption coverage (SC domain): SC.L2-3.13.10 requires FIPS-validated cryptography for CUI. If the spilled files were not encrypted at the file level — if they were plaintext on the unauthorized system — the spillage event produced actual unauthorized disclosure. If the files were persistently encrypted with FIPS 140-3 validated cryptography and the recipient had no access to the decryption keys, the spillage event produced a compliance notification obligation but no actual data exposure. These two scenarios have materially different regulatory and business consequences.
Incident response (IR domain). IR.L2-3.6.1 and IR.L2-3.6.2 require that contractors have and exercise an incident response capability. A spillage event is one of the scenarios your incident response plan must cover. If you are building the response process from scratch during the event, that is itself a compliance gap that an assessor will note.
What Is the Architectural Difference Between Contained and Catastrophic Spillage?
This is the part most spillage guidance omits.
Not all spillage events have the same consequence. The consequence depends almost entirely on whether the spilled files were protected at the file layer before they left your authorized environment.
When a file protected with per-file FIPS 140-3 validated encryption leaves your assessment boundary — forwarded to a personal email address, saved to an unauthorized Dropbox folder, copied to an unmanaged laptop — the spillage event triggers the same reporting obligations. But the unauthorized recipient cannot open the file. The encryption persists. The access policy is still enforced. The decryption keys are not on the unauthorized system.
Your 72-hour report to DoD still needs to be filed. Your scope assessment still needs to be completed. But the damage assessment looks completely different when the response includes: "The files were protected with AES-256 per-file encryption using a CMVP-validated module. The recipient had no access to the decryption keys. No plaintext CUI was exposed on the unauthorized system."
When a file protected only at the container level — by SharePoint permissions, a secure portal, or a VPN — leaves your environment, the recipient's system has the file in plaintext. There is no encryption to report, no key isolation to document. Your blast radius in that scenario is the file's contents, fully readable by whoever received it. The response process is the same, but the damage is not.
The architectural question that determines your spillage consequence is not "did the file leave?" It is "what happens to the file after it arrives somewhere it wasn't supposed to go?"
How Do You Prevent CUI Spillage, and What Controls Actually Help?
Spillage prevention is addressed across multiple CMMC practice domains. The most effective controls are:
User awareness and training (AT domain): The majority of spillage events are not malicious. They are convenience-driven — a file sent to a personal account so it can be worked on from home, a quick attachment to the wrong distribution list. Training that addresses the specific mechanics of spillage — not just "protect CUI" but "these are the specific actions that constitute a spillage event" — reduces the frequency of these events.
Data loss prevention integration: DLP policies can detect and block CUI transmission to unauthorized destinations — personal email addresses, unapproved cloud services, external USB devices. DLP reduces spillage frequency. It does not eliminate it, particularly for spillage that occurs through channels your DLP policies don't monitor.
Per-file encryption at creation: Protecting the file at the point of creation means the encryption travels with the file everywhere it goes — inside your environment and outside it. When spillage occurs despite other controls, persistently encrypted files convert a plaintext disclosure event into a ciphertext possession event. The reporting obligation remains; the damage does not.
Access revocation capability: In a well-implemented file-level encryption architecture, access can be revoked after a file has been shared. When you discover that a CUI file has been forwarded to an unauthorized destination, you can revoke access to that specific file — from any device, in any location — without needing to retrieve or delete it. This is the containment capability that converts spillage response from a physical recovery problem into an access management operation.
📁 Is Your CUI Protected at the File Layer or Only at the Container?
When spillage occurs, the answer to that question determines your regulatory exposure. Validate per-file FIPS 140-3 encryption across your actual environment in 14 days and get the documentation your spillage response requires.
FAQs: CUI Spillage & DFARS Incident Response
Does every accidental CUI disclosure require a DFARS report?
DFARS 252.204-7012's reporting obligation applies to "cyber incidents" — events that compromise or potentially compromise CUI in a contractor's system. Not every accidental disclosure meets this threshold. An email sent to the wrong internal recipient who is already cleared to handle CUI may not constitute a reportable cyber incident. An email sent to an external, uncleared recipient almost certainly does. When in doubt, report. The penalty for filing a report that turns out to be unnecessary is far less than the penalty for failing to file one that was required.
What happens if we miss the 72-hour reporting window?
Late DFARS reporting is a contract compliance failure. DCMA tracks reporting timelines and late reports can trigger contract-level review, affect past performance ratings, and create liability for future contract awards. If you miss the window, file immediately with documentation of why the report was delayed — system issues, discovery timeline ambiguity, or reporting tool access failures can be mitigating factors.
Is CUI spillage the same as a classified information spillage?
No. Classified information spillage is governed by a separate and more stringent framework. CUI spillage follows the NARA and DoD CUI program requirements and DFARS 252.204-7012. The response obligations are different, the notification chains are different, and the sanitization requirements are different. Do not apply classified spillage procedures to CUI spillage events or vice versa.
How do we demonstrate that our spilled files were protected at the file layer for the DoD damage assessment?
This is where your encryption architecture documentation matters. The DoD damage assessment will ask what protection was in place on the affected files. If your system security plan documents per-file FIPS 140-3 validated encryption with zero-knowledge key management, and your access logs show that the recipient's system never authenticated to obtain a decryption key, you can make a documented, evidence-backed case that the spillage event did not produce plaintext disclosure. That case requires the architecture to have been in place before the event, the documentation to exist before the event, and the access logs to be available as artifacts.