Table of Contents
CUI Explained: What It Is, Where It Lives, and Why Scoping Matters
Controlled Unclassified Information, CUI, is the data category that usually determines whether CMMC obligations apply under a DoD contract. For the full certification framework, see our complete CMMC compliance guide. If your organization processes, stores, or transmits CUI under a DoD contract, you are generally in scope for NIST SP 800-171 requirements under DFARS 252.204-7012 and may need CMMC certification when the contract includes DFARS 252.204-7021. If you do not handle CUI, confirm your contract clauses and data flows before assuming CMMC scope.
That makes identifying CUI, correctly, one of the most consequential steps in any CMMC readiness effort. Define it too narrowly and you leave actual CUI unprotected. Define it too broadly and you expand your compliance boundary unnecessarily, multiplying the cost and complexity of certification.
What CUI Actually Is
CUI is defined under 32 CFR Part 2002 and the National Archives CUI Registry. It refers to information the government creates or possesses, or that a contractor creates on behalf of the government, that requires protection or dissemination controls under law, regulation, or government-wide policy, but that doesn't rise to the level of classified information.
The key phrase is "law, regulation, or government-wide policy." CUI isn't a label an agency attaches arbitrarily. Each category of CUI is tied to a specific legal or regulatory authority. The CUI Registry lists over 100 categories organized under broad groupings like Critical Infrastructure, Defense, Export Control, Intelligence, Law Enforcement, and Privacy.
For defense contractors, the most commonly encountered categories include:
- Controlled Technical Information (CTI): Technical data with military or space application that is subject to controls on access, use, reproduction, modification, performance, display, or disclosure. Engineering drawings, specifications, and technical manuals for defense systems often fall here.
- Export Controlled: Information subject to ITAR (International Traffic in Arms Regulations) or EAR (Export Administration Regulations). If your work involves defense articles, defense services, or dual-use technology, ITAR/EAR-controlled data is likely CUI.
- Privacy/PII: Personally identifiable information collected or maintained in connection with federal programs, employee records on government contracts, beneficiary data, personnel files on cleared individuals.
- Procurement and Acquisition: Source selection information, contractor bid and proposal data, and certain contract terms that are marked as sensitive before award.
CUI is not classified. Handling it doesn't require a security clearance. But "unclassified" doesn't mean unprotected, it means a different protection framework applies, one defined by NIST SP 800-171 and enforced through DFARS and CMMC.
The Difference Between CUI and FCI
Defense contractors also encounter Federal Contract Information (FCI), a related but distinct category. FCI is information provided by or generated for the government under a contract, but not intended for public release. It doesn't meet the legal threshold for CUI designation.
FCI triggers CMMC Level 1 obligations (15 basic safeguarding requirements from FAR 52.204-21). CUI triggers CMMC Level 2 obligations (110 NIST SP 800-171 controls). The distinction matters: organizations handling only FCI have significantly lighter compliance requirements than those handling CUI. Misidentifying FCI as CUI, or vice versa, creates either unnecessary burden or actual compliance gaps.
How CUI Gets Into Your Environment
CUI doesn't always arrive with a label attached. Contractors receive it through multiple channels, and not all of it is obviously marked:
Contract deliverables and technical data packages. When the government provides specifications, drawings, or technical manuals for work under a contract, that material is often CUI. The DD Form 1423 (Contract Data Requirements List) and the contract's data rights clauses typically specify what is controlled.
Government-furnished information (GFI). Information the government provides to support contract performance, background data, access credentials, system configurations for government systems, may be CUI depending on its category and marking.
Information you generate under contract. Technical reports, test data, design documentation, and research findings created under a government contract may themselves constitute CUI if they fall within a CUI category. The contract's data rights clauses determine this.
Subcontract flow-down. If you're a subcontractor, CUI may flow to you from the prime. The prime is responsible for identifying CUI and marking it appropriately before passing it down. In practice, marking is inconsistent, which is why contractors can't rely solely on markings to identify CUI.
Unmarked CUI. Federal agencies are required to mark CUI, but compliance is imperfect. The DoD acknowledges that some CUI in the defense industrial base circulates without proper marking. Contractors have an obligation to identify CUI based on content and context, not just on whether something carries a CUI label.
Defining Your CUI Boundary
Your CUI boundary is the set of systems, locations, and people that process, store, or transmit CUI. Every system inside the boundary is in scope for NIST SP 800-171 controls and CMMC assessment. Every system outside the boundary is not.
Boundary definition is a strategic decision, not just a technical one. A few principles that apply in practice:
Minimize the boundary where possible. The smaller your CUI boundary, the fewer systems require NIST SP 800-171 controls and the less expensive your CMMC preparation will be. Isolating CUI handling to dedicated systems, a specific shared drive, a dedicated email domain, controlled workstations, reduces scope. Allowing CUI to flow freely across your entire IT environment means your entire environment is in scope.
CUI follows the data, not the system label. A system is in scope because CUI touches it, not because you designated it as a "CUI system." If CUI lands in a personal email account, on a personal device, or in an unapproved cloud storage service, those systems are in scope regardless of whether you intended them to be. This is why data flow mapping, tracing where CUI enters, moves, and rests in your environment, is the starting point for boundary definition, not the endpoint.
Cloud and SaaS require specific evaluation. CUI stored in cloud environments must be in a FedRAMP-authorized service at the appropriate impact level, or in a solution that meets equivalent requirements. Microsoft 365 GCC or GCC High, for example, are FedRAMP-authorized at levels appropriate for CUI. Standard commercial Microsoft 365 is not. Many contractors discover during gap assessments that CUI has been flowing through non-compliant cloud services without anyone realizing it.
Document the boundary explicitly. Your System Security Plan (SSP) must describe your CUI boundary, what systems are in scope, how CUI enters the environment, where it's stored, how it's transmitted, and who has access. An SSP that says "all of our systems" is too broad to be useful. An SSP that describes a clearly defined, minimized boundary is both more defensible and less expensive to maintain.
Common Scoping Mistakes
Assuming CUI only lives on servers. CUI exists wherever the data exists: laptops, mobile devices, email, collaboration tools, printed documents, USB drives. If an employee downloads a CUI document to their personal laptop to work remotely, that laptop is in scope.
Not reviewing contract language. CUI obligations are established by contract. The specific clauses, DFARS 252.204-7012, the data rights clauses, DD Form 1423, tell you what information is controlled and what handling requirements apply. Many contractors have never actually read this language in their contracts, which means they're guessing at their CUI scope.
Treating all government information as CUI. Not everything from the government is CUI. Over-scoping creates unnecessary compliance burden and can make CMMC preparation economically unviable for smaller contractors. Accurate identification, based on the CUI Registry categories and contract language, is the right approach.
Ignoring CUI in non-IT systems. Physical documents, printed technical drawings, and paper records can contain CUI. The physical security controls in NIST SP 800-171 (PE family) apply to facilities where CUI is physically present, not just digital systems.
For context on how CUI scoping fits into the full CMMC certification process, see our CMMC compliance guide for small defense contractors.
Reach out to Stratify IT to work through CUI identification and boundary scoping for your organization, getting this right is the foundation everything else in your CMMC program is built on.
Once your CUI boundary is defined, the controls that protect it are drawn from NIST SP 800-171 Revision 3, and the scope of your boundary directly determines how many of the 110 controls apply to your environment. The boundary definition also affects which CMMC level your contract requires: CMMC Level 2 vs Level 3 requirements hinges on the sensitivity of the CUI categories your programs involve.
Frequently Asked Questions
Ultimately, the government agency that originated the information makes that call, not your organization. If a contracting officer sends you a document without a CUI marking, that doesn't automatically mean it isn't CUI. It may be an unmarked legacy document, or the agency may have failed to mark it correctly. When in doubt, ask your Contracting Officer Representative directly. Getting that answer in writing protects you during an assessment.
You're not alone, and regulators know it's common. The more immediate concern is whether you have any documentation showing you've applied safeguards, even imperfect ones, during that period. A complete gap in controls is a bigger problem than imperfect controls with some evidence of intent. Start a gap assessment now, document what you find, and build a Plan of Action and Milestones. Retroactive awareness doesn't create liability on its own; unaddressed exposure does.
Yes, and this is where many small contractors get caught. If an employee downloads a CUI document to a personal laptop or forwards it to a Gmail account, that device and account technically become part of your CUI environment, even though you have no control over them. This is why acceptable use policies and technical controls that block unapproved transfer methods aren't optional niceties. They're what keep your compliance boundary from quietly expanding into places you can't remediate.
No, CMMC obligations flow with CUI. If you can structure a subcontractor's work so they genuinely never access, process, store, or transmit CUI, they don't need CMMC certification for that engagement. The practical challenge is enforcing that separation reliably. If there's any realistic scenario where CUI could reach them, shared systems, email threads, collaborative documents, they're likely in scope. Flow-down clauses in your subcontracts don't replace the need to actually verify the separation holds.
At minimum, whenever you take on a new contract, onboard a new system, or change how you deliver work, not just annually on a calendar schedule. CUI scope tends to drift quietly: a new collaboration tool gets adopted, a team starts using a shared drive, someone integrates a new cloud service. Each of those moments is a potential scope change. Organizations that treat CUI scoping as a one-time exercise almost always find surprises during a C3PAO assessment.
Yes, and this is one of the most effective cost-control strategies available. Limiting CUI access through role-based controls shrinks the number of systems, users, and locations in scope, which directly reduces the number of NIST 800-171 controls you have to implement and demonstrate. Some contractors have cut their assessed environment nearly in half just by tightening access policies and moving CUI handling to a dedicated enclave. The reduction in C3PAO assessment scope can translate to meaningful cost savings.