Misidentify CUI and the consequences ripple outward: contract flow-downs break, IT systems get scoped wrong, suppliers receive data they shouldn't have, and audit evidence falls apart under review.
This article gives you a practical path: how to determine whether data is CUI, classify it against authoritative requirements, handle it through its full lifecycle, and protect it with the right safeguards.
One distinction matters more than any other. Information isn't CUI just because it's sensitive, government-related, confidential, or labeled that way by an employee. It requires a specific combination: an applicable law, regulation, government-wide policy, contract requirement, and a CUI category.
Key Takeaways
- CUI is unclassified information requiring safeguarding or dissemination controls under a specific authority
- Classification decisions need the contract, agency guidance, and the NARA CUI Registry together, never format or sensitivity alone
- Handling CUI spans people, systems, suppliers, markings, sharing, retention, and disposal
- Audit readiness means proving personnel understand and apply controls, not just that policies exist
What Is CUI? Definition, Scope, and Key Distinctions
Under 32 CFR 2002.4(h), CUI is information the government creates or possesses, or that an entity creates or possesses for or on behalf of the government, that requires safeguarding or dissemination controls under applicable law, regulation, or government-wide policy.
That's the official wording. In practice, it breaks into a two-part test:
- Category match: the information must fall within an established CUI category or subcategory listed in the Registry
- Authority match: that category must connect to an applicable safeguarding or dissemination authority and a relevant government relationship
Both parts have to be true. A document can touch a government program and still not be CUI if no authority requires protection.
CUI Is Not a Classification Level
CUI sits entirely outside the classified world. It is not a new tier between unclassified and classified information. It is a standardized control framework for certain unclassified records.
NARA's CUI FAQ confirms this directly, and DoD policy reinforces it: CUI access generally doesn't trigger the same "need-to-know" determination required for classified material, unless the governing authority specifically demands it, according to DoDI 5200.48.
One small language habit matters here: say information is "designated" or "controlled" as CUI. Avoid "classified as CUI"; it muddies a distinction your auditors and contracting officers expect you to understand.
CUI Basic vs. CUI Specified
- CUI Basic applies when the authorizing law or policy doesn't prescribe specific handling rules; the uniform Part 2002 controls and Registry defaults apply
- CUI Specified applies when the underlying authority sets its own controls—sometimes stricter, sometimes just different
Controlled Technical Information under DFARS 252.204-7012 is a common Specified example in defense contracting. Don't assume a generic "security level" covers category-specific requirements. Check the Registry entry.
Who May Handle CUI
CUI applies to information, not to people. Government personnel, contractors, subcontractors, suppliers, and other authorized recipients may handle it when they have a lawful government purpose and a genuine need to perform an authorized function. There's no separate class of "CUI-cleared" employees the way there is for classified access.
What Counts as CUI? Examples and Non-Examples
In aerospace and defense environments, CUI commonly shows up as:
- Engineering drawings, technical specifications, test data, and source code created under a government program
- Procurement and acquisition data, including cost/pricing information and contract terms covered by 48 CFR 3.104-4
- Export-controlled technical data overlapping with ITAR
- Certain privacy, personnel, and proprietary business information held by or for the government
Context determines status, not appearance. None of these alone establish CUI status:
- An ordinary commercial drawing, even if your company also does government work
- A "confidential" stamp on a file
- The folder a file sits in, or who authored it
CUI can live anywhere: email threads, spreadsheets, CAD files, cloud drives, paper records, photographs, even meeting notes. QMS Learning's internal case data flags two recurring violations worth remembering:
- An engineer emailing a CAD file to a personal Gmail account
- A marked-up drawing sitting in an unencrypted shared drive
Neither requires malicious intent to become a reportable incident.
A quick scenario: Your team designs the same bracket for a commercial customer and for a government deliverable. Same part, different treatment. Before concluding either way, check the contract clause, confirm the CUI category, and identify the safeguarding authority. Don't guess from the drawing alone.
When a case is genuinely unclear, escalate it to the contract owner, your security or compliance lead, or the contracting officer. This article is educational; it can't substitute for a contract-specific or legal determination.
How to Classify Data as CUI
Start With a Decision Process
Every time someone receives, creates, or shares potentially sensitive government information, walk through this sequence:
- Is it classified? If yes, stop. Follow classified-information procedures instead.
- Is it unclassified? Confirm whether the government created, possesses, provided, or requires your organization to create or possess it on the government's behalf.
- Does it match a Registry category? Check the current NARA CUI Registry for category and subcategory fit.
- Is there an applicable authority? Identify the law, regulation, or government-wide policy requiring or permitting controls.
Verify the Governing Authority
Review the solicitation, statement of work, data item descriptions, security clauses, and flow-down terms. Research current official guidance rather than leaning on legacy labels like FOUO, SBU, or LES. DoD explicitly states that FOUO-to-CUI isn't an automatic one-to-one swap.
Record your reasoning as you go: data source, program connection, applicable authority, CUI category, system location, and required controls. This record becomes your audit trail later.
Avoid These Common Errors
- Treating all government-adjacent information as CUI by default
- Assuming a document in a CUI-scoped system is automatically CUI without a documented decision
- Reading an absence of markings as proof something isn't CUI
- Accepting an existing marking as proof the underlying designation is correct. Escalate suspected over- or under-marking
QMS Learning's CMMC & NIST 800-171 course builds this exact workflow into practice, including data inventories and enclave outlines teams can adapt to their own contracts.
CUI Markings, Sharing, and Common Handling Errors
Markings exist to communicate handling requirements: category, originating office, point of contact, and any dissemination restrictions.
Marking Essentials
- Apply the correct banner, footer, and portion markings per the governing agency or DoD instruction
- Preserve markings when reproducing, extracting, or converting CUI documents
- Train staff to recognize CUI across email, drawings, screenshots, and physical media
For Specified categories, the banner should include the Registry abbreviation (for example, CUI//SP-CTI for Controlled Technical Information).
Lawful Sharing
Share CUI only with authorized recipients for a lawful government purpose, following contract terms and any limited dissemination controls. Supplier and subcontractor flow-downs need verification too. don't assume a vendor understands their handling obligations just because they signed a contract.
Errors That Create Risk
| Error | Consequence |
|---|---|
| Missing or outdated markings | Unauthorized disclosure, employee confusion |
| Overly restrictive dissemination controls | Delays lawful access, distorts sharing records |
| Copying CUI into personal email or consumer apps | Breaks the organization's security boundary |
A DoD Inspector General's audit found one contractor's training skipped required learning objectives entirely, while another couldn't produce completion certificates when asked. Markings only work if the people applying them were actually trained, and can prove it.
How to Handle and Protect CUI Throughout Its Lifecycle
CUI protection spans the full lifecycle: receive, create, access, process, store, transmit, share, retain, and dispose.
Governance and Access
Assign clear ownership for CUI identification, marking decisions, supplier oversight, and incident response. Define procedures that trigger on:
- New contracts or contract modifications
- Employee onboarding, role changes, and offboarding
- New software tools or supplier changes
Apply least-privilege access based on job responsibility, not convenience. Review access periodically and remove it immediately when someone leaves or changes roles. This isn't only a network permissions question. It covers physical access, visitors, printers, and mobile devices too.
Systems, Transmission, and Contractual Alignment
Use approved systems with current patching, logging, and backup controls. Protect CUI at rest and in transit with organization-approved encryption. Prohibit personal accounts, unmanaged endpoints, and consumer file-sharing tools for CUI handling.
DFARS clauses, NIST SP 800-171, and CMMC requirements shape which controls apply to your specific environment. These frameworks are related but distinct:
- DFARS 252.204-7012 governs covered defense information and cyber incident reporting
- NIST SP 800-171 sets the control baseline for protecting CUI in nonfederal systems
- CMMC is an assessment framework verifying those controls. It doesn't create CUI designations itself
Confirm which contract revision and implementation timeline applies before you build your environment around it; these requirements shift.
Incidents and Disposal
Define clear reporting steps for suspected misdelivery, lost media, phishing, or transmission through an unapproved system. Preserve logs, notify the appropriate contacts per contract requirements, and document corrective action. When CUI reaches end of life, dispose of it so it's unreadable and unrecoverable, whether that's paper, backups, or devices.
Building an Audit-Ready CUI Program
Audit readiness means proving your process works in practice, not just that a policy document exists somewhere.
Evidence That Actually Holds Up
Maintain a current CUI data inventory, data-flow diagrams, contract and clause register, access reviews, supplier records, and training completions. Connect each record to an owner, date, and review status.
A policy revision alone rarely satisfies an auditor. Records, interviews, and observations that show the change actually happened carry far more weight.
Role-Specific Training Changes Outcomes
Generic training produces generic results. Engineers, program managers, IT administrators, and shop-floor employees each need scenario-based practice relevant to their work:
- Receiving an unmarked drawing
- Emailing a supplier
- Discovering an outdated dissemination control
This is where QMS Learning's approach fits naturally into a CUI program. The platform's CMMC & NIST 800-171 pathway is built for defense contractors, quality managers, and contracts teams, producing working outputs like data inventories, SSP outlines, and POA&Ms rather than just completion certificates.
The Manager Dashboard tracks who completed which scenarios and when, exporting one PDF as objective evidence. The Audit-Evidence Package bundles training records, completed scenarios, and time-stamped activity, the exact kind of documentation that DoD IG findings suggest many contractor programs lack.
QMS Learning complements your technical safeguards and formal assessments. It does not replace legal advice, contract interpretation, or an authorized CUI environment. It functions as the training and evidence layer underneath those decisions.
A Practical Implementation Sequence
- Identify applicable contracts and authorities
- Inventory existing CUI and map its flow
- Define system boundaries and handling rules
- Train personnel by role
- Implement technical controls
- Collect evidence and review whenever contracts, systems, or regulations change
Frequently Asked Questions
How do I determine if data is CUI?
Confirm the information is unclassified, has the required government connection, fits a CUI Registry category, and is covered by an applicable law, regulation, or contract requirement. Check the contract, agency guidance, and the current NARA Registry together.
What are examples of CUI data?
Common examples include engineering drawings, test data, procurement information, and export-controlled technical data tied to a government program. Context and legal authority—not the subject matter alone—determine whether a specific document qualifies.
Who is "controlled unclassified" in CUI?
CUI applies to information, not people. Authorized government employees, contractors, subcontractors, and suppliers may handle it when they have a lawful government purpose and follow the applicable controls.
What is CUI data?
CUI is sensitive but unclassified government-created, government-held, or government-related information that requires safeguarding or dissemination controls under an applicable authority—not a judgment call based on sensitivity alone.
Is CUI a new level of classification?
No. CUI is not classified information and isn't a new classified tier. It's a standardized, government-wide control framework for certain unclassified information that needs protection.