Many defense contractors lose contracts, or face costly investigations, not because of a breach, but because they could not demonstrate they knew where their controlled unclassified information lived. For defense contractors operating in the Defense Industrial Base (DIB), CUI is not a bureaucratic technicality. It is the single data classification that triggers your DFARS 252.204-7012 obligations, defines the scope of your NIST 800-171 implementation, and determines whether CMMC certification applies to your organization at all.
If your compliance program has not started with a formal CUI identification exercise, it has not truly started. This guide explains what CUI is, how to identify it across your organization, how to handle and mark it correctly, and why a well-defined CUI boundary is the foundation of every defensible DoD cybersecurity program.
What Is Controlled Unclassified Information (CUI)?
Controlled Unclassified Information is government-owned or government-derived information that requires safeguarding or dissemination controls consistent with applicable laws, regulations, and government-wide policies, but does not meet the threshold for classification as Secret or Top Secret.
The CUI program is governed by 32 CFR Part 2002 and administered by the National Archives and Records Administration (NARA). It was established to replace a fragmented patchwork of legacy markings that had accumulated across federal agencies over decades, designations like For Official Use Only (FOUO), Sensitive But Unclassified (SBU), and Law Enforcement Sensitive (LES). Those labels are no longer valid. CUI is the unified standard.
Two important distinctions:
- CUI is not classified information. It does not require a security clearance to access. It does require formal handling controls.
- CUI is not just government data. Information you generate in the performance of a government contract, such as technical drawings, test results, and design specifications, can also be CUI if it falls within a recognized category.
Why CUI Matters for Defense Contractors
Understanding what CUI is matters because the moment you handle it, a chain of federal obligations is activated.
The DFARS connection. DFARS clause 252.204-7012, “Safeguarding Covered Defense Information and Cyber Incident Reporting,” applies to any contractor that processes, stores, or transmits covered defense information (CDI), the DoD’s contract-specific term for the CUI handled under a DoD contract. If you have accepted a contract with this clause, you are already obligated to implement the 110 security requirements in NIST SP 800-171 and report cyber incidents within 72 hours. Our DFARS 252.204-7012 compliance guide covers those requirements in detail.
The CMMC connection. CMMC Level 2 is scoped specifically to organizations that process, store, or transmit CUI. If your scoping exercise determines you do not handle CUI, Level 1 may apply instead. If it does, and the majority of DoD prime and subcontractors do handle it, Level 2 applies. Depending on the contract, Level 2 is met through either a self-assessment or a third-party C3PAO certification, with third-party certification becoming the standard for most CUI contracts as the CMMC rollout phases in.
The liability dimension. Contractors post NIST 800-171 self-assessment scores to the DoD Supplier Performance Risk System (SPRS), now under the CMMC framework. An inaccurate score, particularly one that overstates your compliance posture, creates exposure under the False Claims Act. The Justice Department has pursued civil actions against contractors whose SPRS submissions were found to misrepresent their actual security practices. An imprecise CUI scoping exercise is a direct path to this risk.
The bottom line: if you handle CUI and have not formally scoped your environment, your SPRS score and CMMC readiness are built on an unstable foundation, regardless of how many controls you have implemented.
CUI Categories: What Types of Information Qualify?
The CUI Registry, maintained by NARA at archives.gov/cui, is the authoritative index of all approved CUI categories and subcategories. It defines what qualifies, which authorities govern each category, and what handling requirements apply. Defense contractors should consult the registry directly when evaluating ambiguous data types.
The registry distinguishes between two tiers:
- CUI Basic requires standard handling controls defined by 32 CFR Part 2002 and the CUI policy. Most categories fall here.
- CUI Specified requires handling controls defined by the law, regulation, or policy authorizing the category, which may be more restrictive than CUI Basic. Examples include certain nuclear and intelligence-related categories.
The categories most relevant to defense contractors include the following.
Controlled Technical Information (CTI)
Technical information with military or space application that is subject to controls on access, use, reproduction, modification, performance, display, release, disclosure, or dissemination. CTI is one of the most common CUI types encountered by engineering firms, manufacturers, and R&D contractors in the DIB.
Export Controlled Information (ITAR/EAR)
Technical data, software, and services subject to the International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR). This category frequently overlaps with CTI and requires particular care, because mishandling can trigger export control violations in addition to CMMC findings.
Defense and Military Information
Information related to military operations, force structure, weapons systems, and logistics. Contractors supporting program offices or defense systems integrators regularly encounter this category.
Privacy and Financial Information
Personnel records, financial data, and personally identifiable information (PII) associated with government employees or contract performance. This category is often overlooked in technically focused organizations, but it applies broadly to HR, payroll, and contracting functions.
How to Identify CUI in Your Organization
Identifying where CUI exists in your environment is a structured, deliberate process, not a one-time interview or a checkbox on an intake form. Here is a practical approach.
Step 1: Conduct a data inventory. Catalog all data your organization receives from the government or creates in the performance of government contracts. This includes technical documents, emails, meeting notes, test data, drawings, specifications, and any derivative works.
Step 2: Map data flows. Trace where each data type goes: which systems store it, which users access it, how it is transmitted (email, file share, collaboration tools, cloud storage), and whether it flows to subcontractors or vendors. This data flow map becomes the foundation of your System Security Plan.
Step 3: Review your contract language. Your contracts are the primary source of truth. Review the DD Form 254 (Contract Security Classification Specification), any DFARS clauses incorporated by reference, and explicit CUI references in the Statement of Work. These documents often specify which categories of CUI are involved.
Step 4: Engage legal and compliance review for ambiguous categories. ITAR and EAR overlap, proprietary technical data, and certain privacy categories require careful legal analysis. When in doubt, treat the data as CUI until you have a documented, defensible determination otherwise.
Common mistakes organizations make during CUI identification:
- Assuming only digital files count. CUI exists in printed documents, whiteboards, and verbal discussions in unsecured environments.
- Overlooking email threads and meeting notes that reference or contain CUI-category information.
- Failing to account for subcontractor and vendor data flows.
- Treating CUI identification as a one-time project rather than an ongoing operational discipline.
CUI Handling Requirements: What You Are Obligated to Do
Once CUI is identified, specific handling obligations apply. These requirements stem from 32 CFR Part 2002, agency-specific policies, and, for defense contractors, the NIST SP 800-171 controls mandated by DFARS. Our NIST 800-171 compliance consulting guide maps these controls in detail.
Marking. CUI must be marked to alert recipients that it requires protection. Required elements include:
- A CUI banner marking at the top and bottom of each page
- A CUI designation indicator block on the first page, identifying the category, the office of origin, and applicable handling caveats
- Portion markings in documents where only certain sections contain CUI
Storage. CUI must be stored in systems and physical locations that restrict access to authorized personnel. Electronic storage must occur on systems covered by your System Security Plan and subject to access control, audit logging, and encryption requirements.
Transmission. CUI transmitted over networks must use FIPS 140-2 or 140-3 validated encryption. Sending CUI by unencrypted email or through unapproved collaboration tools is a common compliance gap and a frequent finding in assessments.
Destruction. CUI must be destroyed in a manner that renders it unrecoverable. For physical media, that means cross-cut shredding or burning. For electronic media, it means NIST SP 800-88 compliant sanitization.
Incident reporting. Under DFARS 252.204-7012, a cyber incident involving CUI must be reported to the DoD within 72 hours of discovery. This requires a mature incident detection and response capability, not something that can be stood up after a breach occurs.
CUI and Your CMMC Compliance Program
CUI scoping is not a prerequisite to CMMC compliance. It is CMMC compliance at its foundation. Everything else builds from it.
Your System Security Plan (SSP) documents the boundary of systems that process, store, or transmit CUI. That boundary defines the scope of your assessment. C3PAO assessors will test your ability to demonstrate not only that controls are in place, but that you can clearly articulate where CUI enters and exits your environment, who has access to it, and how it is protected at every point in its lifecycle.
A poorly defined CUI boundary creates two problems:
- Scope creep. If you have not clearly bounded your CUI environment, assessors may include systems you intended to exclude, expanding your assessment scope and cost.
- Control gaps. Systems or processes that touch CUI but were not included in your SSP become findings if discovered during assessment.
For organizations beginning their CMMC work, we recommend reviewing our CMMC Level 2 assessment guide alongside this article. To document your CUI boundary in a format assessors expect, start with our free System Security Plan (SSP) template. For organizations working against a deadline, the CMMC audit preparation roadmap provides a structured 90-day timeline.
CUI Identification Is an Ongoing Discipline, Not a One-Time Task
For defense contractors, protecting controlled unclassified information is not a project with a completion date. Every new contract may introduce new CUI categories. Every new vendor or subcontractor relationship creates new data flow paths. Every new collaboration tool or cloud migration potentially moves CUI into an unsanctioned environment.
The organizations that handle CUI compliantly over time are those that have embedded identification, marking, and handling into their standard operating procedures, not those that performed a scoping exercise once during a compliance engagement and moved on.
Getting CUI right is also a competitive differentiator. As the DoD accelerates CMMC enforcement across the supply chain, contractors who can demonstrate mature CUI handling practices will move through assessments faster, with fewer findings, and with greater confidence in their SPRS scores.
Understand Exactly Where Your CUI Lives, Before Your Assessor Does
Not sure whether your organization handles CUI, or whether your current controls meet DFARS and CMMC requirements? A CUI scoping exercise is the highest-leverage starting point for any defense contractor building or validating a compliance program.
Nexeris works with defense contractors to formally identify their CUI environment, map data flows, close DFARS handling gaps, and build a System Security Plan boundary that holds up under C3PAO scrutiny. We deliver a defensible foundation, not a checkbox exercise.
