What Is CUI? Controlled Unclassified Information Explained for Defense Contractors
- Brandon Alsup
- May 6
- 11 min read
If your organization is preparing for CMMC, one of the first questions you need to answer is simple but surprisingly difficult:
Do we handle CUI?
CUI stands for Controlled Unclassified Information. It is information that is not classified, but still requires safeguarding or dissemination controls under law, federal regulation, or government-wide policy.
For defense contractors, CUI matters because it is one of the key triggers for CMMC Level 2. If your organization processes, stores, or transmits CUI in performance of a Department of Defense contract, you may need to implement the 110 security requirements in NIST SP 800-171 Revision 2 within the applicable CMMC assessment scope.
But identifying CUI is not always obvious. Some information is clearly CUI. Some is clearly not. And some sits in a gray area that requires contract review, data-flow analysis, and clarification from the government customer or prime contractor.
This guide explains CUI in plain English, with examples, non-examples, and practical decision points for defense contractors.
CUI in Plain English
Controlled Unclassified Information is sensitive government-related information that is not classified, but still must be protected.
That distinction matters.
CUI is not “Secret” or “Top Secret” information. It is lower than classified information, but it is still controlled. It may include technical data, engineering drawings, specifications, research data, export-controlled information, certain sensitive personal information, or other information that falls within an official CUI category.
In practical terms:
CUI is information the government has identified as requiring special handling, even though it is not classified.
For CMMC, the important question is not simply whether your company has sensitive information. The question is whether you handle information connected to a government contract that falls under an official CUI category or safeguarding requirement.
A useful rule of thumb:
All CUI is sensitive, but not all sensitive information is CUI.
Why CUI Matters for CMMC
CUI matters because it is one of the clearest dividing lines between basic cybersecurity obligations and more advanced compliance requirements.
For many defense contractors:
FCI leads to CMMC Level 1.
CUI leads to CMMC Level 2.
FCI stands for Federal Contract Information. It generally refers to non-public information provided by or generated for the government under a contract.
CUI is different. CUI is information that requires safeguarding or dissemination controls under specific legal, regulatory, or government-wide policy authority.
CMMC Level 2 uses the security requirements in NIST SP 800-171 Revision 2. The current CMMC rule states that Level 2 security requirements are identical to NIST SP 800-171 Rev. 2 requirements.
This is why CUI identification is one of the first and most important steps in a CMMC readiness effort. If you do not know where CUI lives, you cannot accurately define the compliance boundary, build a reliable System Security Plan, or prepare defensible evidence.
Common Examples of CUI for Defense Contractors
CUI can take many forms. In the defense contractor context, it often appears as technical, operational, or contract-related information.
Examples that may be CUI, depending on source, contract language, markings, and applicable category, include:
Technical drawings
Engineering specifications
Manufacturing instructions
CAD files
Controlled technical reports
System architecture diagrams
Testing data
Research and development data
Maintenance procedures for defense systems
Export-controlled technical information
Certain sensitive program documents
Some government-provided datasets
Information marked as CUI by a government customer
One especially important CUI category for defense contractors is Controlled Technical Information. The CUI Registry defines Controlled Technical Information as technical information with military or space application that is subject to controls on access, use, reproduction, modification, performance, display, release, disclosure, or dissemination.
That category can be highly relevant to aerospace, advanced manufacturing, engineering, electronics, systems integration, software, testing, and technical services firms supporting defense work.
What Is Not CUI?
Not all sensitive information is CUI.
This is where many companies get confused. A document can be confidential, proprietary, valuable, or business-sensitive without being CUI.
Examples of information that is usually not CUI by itself include:
Your company’s internal pricing strategy
General sales proposals
Public marketing materials
Standard HR policies
Ordinary internal emails unrelated to controlled government information
Publicly available government information
General cybersecurity policies not tied to protected government data
Company financial documents
Commercial customer lists
Internal project management notes unrelated to government-controlled data
That does not mean this information should be ignored or left unprotected. It may still be confidential, proprietary, or sensitive. But CUI is a specific government-controlled category, not a general label for anything important.
The practical distinction is this:
CUI is controlled because of a law, regulation, government-wide policy, contract requirement, marking, or official CUI category—not merely because the information is valuable to your company.
The Gray Area: Information That Might Be CUI
Some information is not obviously CUI at first glance.
This gray area is where many organizations make mistakes. They either over-scope everything, which makes compliance unnecessarily expensive, or under-scope the environment, which creates assessment and contract risk.
Examples of possible gray-area information include:
Email threads discussing technical contract requirements
Meeting notes from a defense program review
Screenshots of a government-provided technical system
Supplier quotes that include controlled technical specifications
Internal analysis derived from government-provided CUI
A spreadsheet summarizing controlled test results
Design comments added to a government technical drawing
File names or metadata that reveal controlled program details
AI-generated summaries based on CUI source material
The key issue is often derivation.
If your organization creates a new document using CUI as the source, the new document may also need to be treated as CUI if it preserves, summarizes, transforms, or reveals the controlled information.
For example, if a government customer sends a controlled technical drawing and your engineering team creates an internal manufacturing worksheet based on that drawing, the worksheet may also require CUI-level handling.
That does not mean every derivative note automatically becomes CUI in every situation. It means the organization should evaluate the source, content, contract requirements, markings, and CUI category before treating the material as ordinary business information.
Does CUI Have to Be Marked?
CUI should be marked according to CUI program requirements, and markings are an important signal.
But contractors should be careful about relying only on markings.
Why? Because markings can be missing, inconsistent, incomplete, or lost as information moves through systems. A file may be renamed. An email may discuss controlled content without carrying an obvious banner marking. A prime contractor may pass along information without clear guidance. A screenshot or derived spreadsheet may preserve sensitive content even if the new file is not marked properly.
That does not mean contractors should guess. It means CUI identification should include a structured review process.
A practical CUI identification process may include:
Contract review
Customer or prime contractor clarification
CUI markings when present
CUI Registry category review
Data-flow mapping
Subject-matter review
Legal or compliance input when needed
The official CUI Registry exists to identify CUI categories and authorities. It should be used as a reference when evaluating whether information falls under a controlled category.
CUI vs. FCI: What Is the Difference?
FCI and CUI are related, but they are not the same.
FCI, or Federal Contract Information, generally means non-public information provided by or generated for the government under a contract.
CUI is information that requires safeguarding or dissemination controls under specific law, regulation, or government-wide policy.
A basic way to think about it:
FCI: contract-related information that is not intended for public release.
CUI: controlled information that requires stronger protection.
Example of FCI:
A non-public email from a government contracting officer about routine contract administration may be FCI.
Example of CUI:
A technical drawing for a defense component that falls under a CUI category may be CUI.
CMMC Level 1 focuses on safeguarding FCI. CMMC Level 2 focuses on protecting CUI.
CUI vs. Classified Information
CUI is not classified information.
Classified information includes categories such as Confidential, Secret, and Top Secret. Those categories are governed by separate rules and require different handling environments.
CUI sits below classified information, but above ordinary uncontrolled information.
A simple hierarchy looks like this:
Public information — intended for public release.
Uncontrolled unclassified information — not public necessarily, but not controlled under the CUI program.
FCI — non-public federal contract information.
CUI — unclassified information requiring safeguarding or dissemination controls.
Classified information — Confidential, Secret, Top Secret, or related categories.
For most CMMC Level 2 contractors, the concern is CUI, not classified data.
Practical Examples: Is This CUI?
The following examples are simplified. They are not a substitute for contract review or legal guidance, but they show how the thinking works.
Example 1: A public DoD press release
A public DoD press release is not CUI because it is intended for public release.
Example 2: A non-public contract email
A routine non-public contract email may be FCI, but not necessarily CUI. It depends on what the email contains and whether it includes controlled information.
Example 3: A defense component drawing
A technical drawing for a defense component may be CUI, especially if it contains controlled technical information with military or space application.
Example 4: A spreadsheet created from controlled test data
If the spreadsheet summarizes or reproduces controlled technical data, it may also need to be treated as CUI.
Example 5: A vendor invoice
A standard invoice is usually not CUI by itself. But if the invoice includes controlled program details, sensitive technical descriptions, or protected information, it may require closer review.
Example 6: Sensitive employee information
Some sensitive personal information can fall under CUI categories when the relevant authority applies. The correct answer depends on the type of information, the context, and the applicable CUI category.
Why Over-Scoping CUI Creates Problems
Some organizations respond to uncertainty by treating everything as CUI.
That may feel safe, but it can create major problems.
If everything is treated as CUI, then every system, user, process, vendor, and provider touching that information may be pulled into the compliance scope. That can increase cost, complexity, and assessment burden.
Over-scoping can lead to:
Larger compliance boundaries
More systems requiring controls
More users requiring training and access restrictions
More evidence to maintain
More vendors to review
Higher implementation costs
More difficult assessments
The goal is not to minimize scope artificially. The goal is to define it accurately.
A good CMMC program protects CUI where it actually exists and avoids dragging unrelated systems into scope unnecessarily.
Why Under-Scoping CUI Is Even Riskier
Under-scoping creates a different kind of problem.
If CUI is stored, processed, or transmitted through systems that are not included in your compliance boundary, your organization may appear more ready than it actually is.
Examples of under-scoping may include:
CUI stored in personal downloads folders
Engineers emailing CUI outside the approved environment
CUI copied into Teams, SharePoint, or OneDrive without proper controls
Vendors receiving CUI without being accounted for
Backup systems containing CUI but excluded from scope
Helpdesk or MSP tools accessing CUI systems but ignored in the boundary
CUI used in AI tools or third-party platforms without review
Under-scoping can weaken your System Security Plan, undermine assessment readiness, and create serious operational risk.
How to Identify CUI in Your Organization
A practical CUI review usually starts with these steps.
1. Review contracts and flow-down requirements
Start with your contracts, subcontracts, and prime contractor requirements. Look for references to CUI, DFARS clauses, NIST SP 800-171, CMMC, export controls, technical data, or safeguarding obligations.
2. Ask where government information enters the business
Identify how information comes in. Does it arrive by email, portal, secure transfer, customer system, shared drive, collaboration platform, or supplier exchange?
3. Map where it goes
Trace where that information is stored, processed, transmitted, copied, backed up, printed, or discussed.
4. Identify who touches it
Include employees, executives, engineers, administrators, IT staff, vendors, subcontractors, and external service providers.
5. Check the CUI Registry
Use the CUI Registry to understand whether the information fits an official CUI category.
6. Validate assumptions with the customer or prime
When classification, marking, or handling expectations are unclear, ask for clarification. Do not build a compliance program on assumptions.
CUI and the Compliance Boundary
Once you identify CUI, the next step is defining the compliance boundary.
The compliance boundary includes the systems, users, processes, vendors, and providers that process, store, transmit, protect, or support CUI.
This is where CUI identification becomes operational.
If CUI lives in email, file storage, engineering workstations, backups, and ticketing screenshots, those systems may all need to be considered. If your managed service provider administers the environment, that provider may also affect your compliance boundary.
That is why CUI discovery should happen before major technology decisions. You cannot decide whether to build an enclave, secure the whole environment, or segment certain workflows until you understand where CUI actually lives.
A Simple CUI Decision Framework
When reviewing a document, file, system, or workflow, ask:
Did this information come from the government or a prime contractor under a government contract?
Was it created for performance of a government contract?
Is it non-public?
Does it fit a CUI Registry category?
Is it marked as CUI or subject to safeguarding instructions?
Does it contain technical, operational, export-controlled, personal, or sensitive program information?
Was it derived from known CUI?
Would disclosure create contract, regulatory, security, or mission risk?
If several answers point toward control, the information should be reviewed carefully before being treated as ordinary business data.
This framework should not be treated as a legal determination. It is a practical starting point for structured review.
Common CUI Mistakes
Mistake 1: Assuming only marked files matter
Markings matter, but they are not the whole story. CUI can be copied, summarized, transformed, or stored in systems where markings are lost.
Mistake 2: Treating all contract data as CUI
Some contract data may be FCI or ordinary business information. Over-labeling everything as CUI can make compliance unnecessarily difficult.
Mistake 3: Ignoring email and collaboration tools
CUI often spreads through ordinary tools: email, chat, file sharing, shared drives, and project management platforms.
Mistake 4: Forgetting backups and logs
If systems contain CUI, backups may contain CUI. Logs may also reveal sensitive details depending on what they capture.
Mistake 5: Leaving vendors out of the review
If a vendor stores, accesses, supports, or secures systems that contain CUI, they may affect the compliance picture.
What to Do If You Are Not Sure
If you are not sure whether something is CUI, do not ignore it and do not automatically scope your entire company.
Instead:
Preserve the information securely.
Review the contract and data source.
Check markings and handling instructions.
Compare the information to CUI Registry categories.
Ask the government customer or prime contractor for clarification.
Document the decision.
Update your data-flow map and system boundary if needed.
CUI uncertainty is normal. The problem is not uncertainty. The problem is failing to resolve it in a structured way.
Final Takeaway
CUI is the information that drives many CMMC Level 2 obligations.
If your organization handles CUI, you need more than general cybersecurity. You need a defined compliance boundary, implemented controls, accurate documentation, and evidence that your protections are operating in practice.
The first step is not buying tools. The first step is understanding the information you are responsible for protecting.
Once you know where CUI lives, who touches it, and how it flows, you can build a compliance program that is focused, defensible, and realistic.
Sources and Official References
For current definitions and requirements, always verify against official sources and your specific contract documents.
National Archives — Controlled Unclassified Information Program
Defines the CUI program and explains that it standardizes handling of unclassified information requiring safeguarding or dissemination controls under law, federal regulation, or government-wide policy.
Main CUI program page: https://www.archives.gov/cui
National Archives — CUI Registry Category List
Official registry of CUI categories and subcategories used to evaluate whether information falls within a CUI category.
Main CUI Registry category list: https://www.archives.gov/cui/registry/category-list
National Archives — Controlled Technical Information Category
Defines Controlled Technical Information, an important CUI category for defense, aerospace, engineering, and manufacturing contractors.
Controlled Technical Information category: https://www.archives.gov/cui/registry/category-detail/controlled-technical-info.html
National Archives — CUI Glossary
Includes definitions such as uncontrolled unclassified information and other CUI program terminology.
CUI glossary: https://www.archives.gov/cui/registry/cui-glossary.html
NIST SP 800-171 Revision 2
Provides recommended security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations.
32 CFR Part 170 — Cybersecurity Maturity Model Certification Program
Establishes the CMMC Program rule. The regulation states that CMMC Level 2 security requirements are identical to NIST SP 800-171 Revision 2.
DoD CIO — CMMC Program Page
Official DoD CMMC page with implementation updates and program information.
Disclaimer
The information contained in this communication is intended for limited use for informational purposes only. It is not considered professional advice, and instead, is general information tha
t may or may not apply to specific situations. Each case is unique and should be evaluated on its own by a professional qualified to provide advice specifically intended to protect your individual situation. TK Compliance is not liable for improper use of this information.
This article explains the most important CMMC-related terms in plain English and points you directly to the official government sources that define them.
Comments