CUI Explained: Why It’s Critical for CMMC Compliance

Table of Contents

CUI Explained: What It Is, Where It Lives, and Why Scoping Matters

Controlled Unclassified Information — CUI — is the data category that triggers CMMC compliance obligations for DoD contractors. If your organization processes, stores, or transmits CUI, you're in scope for NIST SP 800-171 requirements under DFARS 252.204-7012, and for CMMC certification under DFARS 252.204-7021. If you don't handle CUI, those obligations don't apply.

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.

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.

Learn more about our CMMC compliance services to see the full range of what we offer.

Stratify IT — compliance built around your business, not a template.

For more on CMMC readiness and DFARS compliance, explore our leadership blogs.