Controlled Unclassified Information (CUI) is unclassified information that requires safeguarding or dissemination controls under an applicable law, regulation, or government-wide policy. Sensitivity alone doesn't make something CUI. A contractor's internal sense that data is confidential carries no legal weight unless an actual authority says so.
This article walks through the full identification-to-documentation workflow: telling CUI Basic apart from CUI Specified, picking the right registry, verifying the source authority, finding where CUI actually lives in your environment, and documenting every decision so it holds up under audit.
Key Takeaways
- An applicable law, regulation, or government-wide policy determines CUI status—not a contractor's judgment call
- CUI Basic applies baseline protections; CUI Specified adds authority-driven requirements on top
- The ISOO CUI Registry is the government-wide reference; DoD contractors should also check the DoD CUI Registry
- Audit-ready programs tie every category to its source authority, markings, systems, users, and evidence
- Ambiguous or unmarked information still needs documentation and escalation, not a guess
Understanding CUI Categories and the Difference Between CUI Basic and CUI Specified
CUI sits in its own lane. It's not classified information, it's not Federal Contract Information (FCI), and it's not just "our company calls this confidential." Under 32 CFR 2002.4(h), CUI is information the government creates or possesses, or that a contractor creates or possesses on the government's behalf, where a law, regulation, or government-wide policy requires or permits safeguarding or dissemination controls. Information cleared for public release never qualifies, no matter how it's labeled internally.
The National Archives' glossary organizes CUI into index groupings like Defense, Export Control, Privacy, Procurement and Acquisition, Proprietary Business Information, and Critical Infrastructure. Individual categories and subcategories live inside those groupings. Always check the current registry structure, since entries get added, merged, or reclassified.
CUI Basic vs. CUI Specified
Within every category, the governing authority determines whether you're dealing with Basic or Specified controls:
- CUI Basic applies when the authorizing law or policy doesn't spell out specific handling rules beyond the baseline CUI program requirements. It's still protected information. Basic isn't a shortcut around safeguarding.
- CUI Specified applies when the underlying authority adds its own handling, dissemination, or marking requirements. "Specified" describes additional controls, not a higher classification tier.
Here's the part that trips up a lot of compliance teams: a single category can carry both statuses depending on which authority you're working under. General Privacy, for example, is Basic under 5 U.S.C. 552a(b) but Specified under OMB Memorandum M-17-12.
General Procurement and Acquisition flips the same way: Specified under certain FAR clauses, Basic under a separate statutory authority. You can't assume a category's status from its name alone; you have to trace it back to the specific authority cited in your contract or source document.
Operationally, the difference shows up in:
- Required banner markings (category/subcategory markings are mandatory for Specified, optional for Basic unless agency policy says otherwise)
- Dissemination restrictions tied to the authority
- System and access controls beyond the NIST baseline
- Whether export-control or privacy-specific rules layer on top
Controlled Technical Information is a Specified category tied to DFARS 252.204-7012, requiring distribution statements under DoDI 5230.24. Export Controlled Research, by contrast, registers as Basic under 15 CFR 734.8(b). Always confirm the current status in the official registry entry before marking or handling anything. Don't rely on a secondhand list.
What Is the CUI Registry and Which Registry Should You Use?
The ISOO CUI Registry, maintained by the Information Security Oversight Office within the National Archives and Records Administration, is the authoritative, public repository of approved CUI categories, their authorities, required markings, and handling guidance. Executive Order 13556 named NARA as the CUI Executive Agent, and the Archivist delegated day-to-day administration to ISOO.
A proper registry entry gives you:
- Category or subcategory name and its organizational grouping
- Definition of what the category covers
- Basic or Specified status, tied to a named authority
- Required markings, including any limited-dissemination controls
- Links to the governing law, regulation, or policy
National registry vs. DoD registry
If you work defense contracts, you need two resources, not one. DoDI 5200.48 establishes the official DoD CUI Registry, which mirrors the national registry's categories and adds DoD-specific descriptions, examples, and contract-level context. Use the ISOO registry for the authoritative category definition and marking requirements. Use the DoD registry for defense-specific implementation details or examples tied to a DFARS clause.
A practical lookup sequence looks like this:
- Start with the actual information type (a drawing, a report, a dataset)
- Search the likely category names in the registry
- Open the category detail page and read the authority cited
- Confirm whether that authority makes it Basic or Specified
- Record the result (category, authority, status) in your CUI inventory
Don't stop at a keyword match. Finding a category name that sounds right isn't the same as confirming it applies. The contract language, the source document, and the actual content all need to line up with the registry entry before you treat something as CUI.
How to Identify CUI in Contracts, Documents, and Systems
Identification starts at the source, not the file. Pull the prime contract, any subcontract flow-downs, the statement of work, technical instructions, and distribution statements. Look for clauses that mention safeguarding, reporting, or CUI handling obligations directly.
A practical decision sequence
- Rule out the extremes: confirm the information isn't classified, and exclude anything cleared for public release
- Check the government connection: did the government create, provide, require, or receive this information in connection with a contract or government function?
- Find the likely category: search the ISOO or DoD registry and confirm the authorizing law, regulation, or policy
- Determine Basic or Specified status: note any added dissemination, storage, transmission, or export-control requirements
- Document the decision: record the evidence, the responsible owner, and any unresolved questions instead of relying on a verbal assumption
CUI rarely stays in one place. Once you've identified it in a contract deliverable, map every location it touches:
- Engineering repositories and email
- Collaboration platforms and manufacturing execution systems
- Removable media, backups, and cloud storage
- Supplier exchanges, printed copies, and employee or subcontractor devices
Identifying the data and scoping the assets are two separate jobs: one tells you what you're protecting, the other tells you where and who.
Real violations tend to come from exactly this gap. One engineer forwarding a CAD file to a personal Gmail account, or one marked-up drawing sitting in an unencrypted shared drive, is enough to trigger a finding, and in at least one documented case, a contract termination. These aren't exotic failures. They happen when nobody traced the file back to its CUI category before it left the controlled environment.
Handling ambiguous or unmarked information
When markings are missing or inconsistent, don't guess either direction. Preserve the source document, limit distribution to people who already have access, write down the specific question, and request clarification in writing from the contracting officer.
A short example: a technical drawing referenced in a statement of work traces to Controlled Technical Information in the registry. That points to Distribution Statement B, authorized recipients limited to U.S. government agencies and contractors, storage on an approved system, and an entry in your SSP documenting all of it.
How to Handle CUI After You Identify It
Handling breaks into four operational areas: safeguarding, access and dissemination, marking and reproduction, and retention or destruction.
Safeguarding maps to your contract's cybersecurity requirements, typically NIST SP 800-171 and whatever CMMC obligations currently apply to your environment. Verify current rule status before assuming anything; the applicable requirement in your contract may not match the latest published revision.
Access and dissemination controls include:
- Least-privilege access limited to personnel with a legitimate need
- Documented awareness training so staff recognize CUI when they see it
- Secure transmission methods and approved storage locations
- Vendor and subcontractor flow-down of the same controls
- Any additional restriction imposed by the category's governing authority
Marking responsibilities don't stop at the original file
Derivative materials (extracts, presentations, screenshots, excerpted paragraphs) carry the same marking obligations as the source document. A banner marking (CUI or CONTROLLED) is distinct from category markings, limited-dissemination controls, and export-control markings. Mixing these up is one of the more common audit findings.
Retention and destruction follow the source authority
CUI retention periods and destruction methods come from the category's governing authority. When retention ends, use approved destruction methods and document disposition for audit evidence.
Incident response needs the inventory, not memory
When something gets exposed, responders shouldn't reconstruct what category of information was involved from memory or guesswork. A functioning CUI inventory lets them immediately identify the exposed category, the source authority, affected systems, impacted users, external recipients, and the correct escalation path.
Meeting NIST or CMMC requirements doesn't automatically satisfy category-specific obligations. Export-control, privacy, and other statutory requirements sit on top of the cybersecurity baseline. If a document carries export-controlled status, NIST 800-171 compliance alone won't cover you. You still need to check the specific authority behind that category.
How to Document CUI Categories and Build Audit-Ready Evidence
A defensible CUI inventory needs more than a spreadsheet of file names. At minimum, track:
- Information type, category, and subcategory
- Basic or Specified status and the governing authority
- Source contract and the clause that triggered the determination
- Required markings, storage locations, and systems involved
- Authorized users, vendors, and dissemination limits
- Responsible owner, review date, and any unresolved questions
That inventory only holds up if it connects to the rest of your compliance stack: your SSP, access reviews, training records, incident response procedures, supplier controls, and data-flow diagrams. Auditors want to see what you knew, when you made each determination, who approved it, and how you handled changes afterward.
Controlled documentation tools earn their place here as the evidence layer that ties everything together, not as a replacement for technical safeguards or legal review. QMS Learning's Document Management System, for example, keeps an append-only revision history, maps documents to specific clauses, and exports an indexed audit-evidence package on demand. It won't make a CUI determination for you, but it keeps the paper trail intact once you've made one.
For teams building related capability (developing an SSP, applying control families, or managing an ITAR Technology Control Plan), QMS Learning's Aerospace & Defense Audit-Ready pathway is a practitioner-led option covering AS9100D, ITAR, and Counterfeit Parts Avoidance. It builds operational skill; it is not a substitute for your own CUI determinations or legal counsel.
Conclusion: Turn CUI Identification Into a Repeatable Process
CUI identification isn't a one-time project you close out and forget. New contracts, new flow-downs, new suppliers, new technology, and regulatory updates can all shift what counts as CUI in your environment—sometimes without anyone flagging it.
Build the habit into a repeatable sequence:
- Verify the source
- Consult the correct registry
- Confirm the authority
- Classify the category
- Map where the information actually lives
- Apply the matching handling rules
- Document the decision
- Revisit it whenever conditions change
Teams that treat this as routine maintenance, rather than a one-off audit scramble, are the ones who walk into assessments with answers instead of guesses.
Frequently Asked Questions
How do I know if a document is CUI?
Trace it back to its contract or government source, check for an applicable law or policy, review any existing markings, and confirm the category in the ISOO or DoD registry. If anything is unclear, document the question and escalate rather than assuming.
What are the CUI requirements?
Baseline requirements cover safeguarding, access and dissemination controls, marking, secure storage and transmission, incident response, training, and recordkeeping. Specific categories may add requirements on top, such as export-control or privacy rules.
What is the CUI registry?
The ISOO CUI Registry is the government-wide, publicly accessible reference for approved CUI categories, subcategories, governing authorities, required markings, and handling guidance.
Where can I find the CUI registry?
The official National Archives ISOO CUI Registry lists all approved categories; DoD contractors should also check the official DoD CUI Registry for defense-specific context. Always verify current URLs and guidance rather than relying on third-party summaries.
What is ISOO?
ISOO stands for the Information Security Oversight Office, housed within the National Archives and Records Administration. It administers the government-wide CUI program and maintains the official CUI Registry on behalf of the CUI Executive Agent.