So what is CUI, in the words that actually matter? Controlled Unclassified Information, or CUI, has one real definition, and it comes from a single regulation: 32 CFR 2002.4(h). CUI is information the government creates or possesses, or that a contractor creates or possesses on behalf of the government, that a law, regulation, or government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls.
Read that definition again, slowly this time, because almost every mistake contractors make about CUI comes from skipping a word in it. It has to be information the government created, or information you hold on the government’s behalf, not your own proprietary data sitting on a shared drive. And there has to be an actual authorizing law, regulation, or government-wide policy that requires or permits dissemination controls pursuant to that authority. A gut feeling that something “seems sensitive” does not count, no matter how reasonable the instinct feels in the moment.
The two mistakes everyone makes
Contractors default to one of two errors when nobody walks them through this, and we have sat across the table from both kinds often enough to recognize them within the first ten minutes of a conversation. Some assume they have no CUI. They are usually wrong. Others assume everything even loosely connected to a government contract is CUI, and they scope their entire network into the compliance boundary as a result.
That second mistake is more common than the first, and it is considerably more expensive. A contractor who treats their whole environment as CUI will spend years, and often hundreds of thousands of dollars, protecting information that never needed that level of control in the first place. Both errors trace back to the same root cause. Nobody pulled the actual contract language, the actual data flows, and the actual laws, regulations, and government-wide policies that apply, so somebody made an assumption in one direction or the other and the assumption stuck.
CUI Basic versus CUI Specified
32 CFR 2002.4(h) actually describes CUI in three possible forms, and the distinction matters more than most contractors realize, at least in theory. If a law, regulation, or government-wide policy requires protection but does not specify how, that is CUI Basic. If it specifies exact controls, that is CUI Specified. If it specifies some controls and leaves the rest to the CUI Basic defaults, it is still CUI Specified, just with the gaps filled in by the more general rule.
For DoD contractors specifically, this distinction carries less practical weight than it sounds like it should. DoD’s own implementing directive, DoDI 5200.48, states that during the Department’s phased rollout of the CUI Program, no required distinction has to be made between Basic and Specified CUI. In practice, that means nearly all CUI in a DoD contracting environment gets protected to the same standard, the security requirements in NIST SP 800-171. You do not need to sort your CUI into Basic and Specified buckets before you can start protecting it correctly, which is one of the few places in this framework where the paperwork gets simpler rather than more complicated.
Where the CUI Program actually comes from
The CUI Program is not a CMMC invention, and it is not new. Executive Order 13556, signed in 2010, established a single, government-wide program to replace the patchwork of agency-specific “sensitive but unclassified” labels that existed before it, back when every agency had its own version of the same idea and none of them talked to each other.
That order designated the National Archives and Records Administration, NARA, as the Executive Agent responsible for the CUI Program across every federal agency. NARA maintains the CUI Registry, the official list of every category and subcategory of information that qualifies as CUI, along with the specific authorizing law, regulation, or policy for each one. Individual federal agencies, including the Department of War, then publish their own implementing guidance under that umbrella, and DoDI 5200.48 is the Department’s version, governing how CUI works specifically inside DoD contracts.
This matters because CUI is not one thing with one set of markings. It is a government-wide program covering dozens of categories, and Defense only deals with a subset of them. Beyond Controlled Technical Information, the categories that show up most often in DIB contracts include export-controlled data under ITAR or EAR, privacy-related information tied to personnel or dependents, proprietary business information the government holds on a contractor’s behalf, and general procurement-sensitive material tied to an active source-selection process.
Each category traces back to its own authorizing law, regulation, or government-wide policy in the CUI Registry, which is exactly why guessing at a single blanket label for “everything defense-related” fails so often. A contractor holding export-controlled technical data and a contractor holding procurement-sensitive proposal material are protecting genuinely different things, under genuinely different authorities, even though both would describe themselves, in casual conversation, as handling CUI.
We see this most often with mid-size manufacturers and engineering firms, the contractors who have a DFARS clause in at least one active contract and CUI somewhere in their environment, whether or not anyone has formally identified it yet. Nobody at these companies is being deceptive when they misjudge their CUI footprint. Nobody ever sat them down and walked through the actual categories that apply to their specific contracts. That conversation is usually the first thing that happens, not the last, once someone finally has it with them.
What “protect it” actually requires
Once you know what CUI you have, the safeguarding and dissemination controls that a law, regulation, or government-wide policy requires come from one place for DoD contractors: NIST SP 800-171. That is the same standard behind the Cybersecurity Maturity Model Certification (CMMC) program, and it applies the same way whether the CUI in question is CTI, program data, or anything else in the registry. CMMC verifies that you meet the standard. It does not add a second, separate set of controls on top of it.
This is exactly the sequence Real Compliance is built around. You cannot write a System Security Plan for a boundary you have not defined, and you cannot defend a boundary you defined by guessing. CUI Discovery, done properly, does not start with a checklist or a technology stack. It starts with the actual contract language, the actual data flows, and the actual deliverables your business produces, then traces the specific laws, regulations, and government-wide policies that apply to that specific data.
Two contractors building similar products for similar primes can end up with genuinely different CUI footprints, because the contract language, not the product category, is what actually triggers the obligation. Get this wrong and every phase that follows, scoping, documentation, technology, assessment, inherits the mistake. It is the answer to the only question that determines the size, cost, and shape of everything that comes after it.
It is also why Midwatch exists as a purpose-built enclave rather than a general IT contract. Once you know what CUI you are holding, it needs a home built to hold it, not a shared environment that happens to have some security controls turned on. None of this is a one-person job done from memory, either. Inside DCG, a CUI Discovery engagement runs on a two-person team: someone who owns the assessment-objective interpretation, paired with someone who owns turning that interpretation into a written, defensible record.
The record matters as much as the boundary itself, because “we know what our CUI is” is not an answer that survives an assessment, a prime’s questionnaire, or a new employee’s first week on the contract. A documented boundary, tied to specific contract language, is.
Two questions that come up immediately
Two follow-up questions surface in almost every CUI Discovery engagement we run, usually in the first meeting, and usually before we have finished explaining the definition above.
The first: is CUI automatically off-limits to foreign nationals? We’ve written a full answer on handling CUI and foreign national access here, and the actual governing rule is more permissive than most contractors assume it will be.
The second: does identifying CUI mean you need a login banner or a physical sign? The honest answer is that there is a limited regulatory mandate for one, and we recommend it anyway. We’ve laid out the specific language we suggest here.
Both of those are real, specific questions with real, specific answers once you know what you are protecting. Neither one is the starting point, though, and both become much easier once the CUI itself has been identified rather than assumed.
The takeaway for contractors
Start with the definition. CUI is government information, or information held on the government’s behalf, that a specific authorizing law, regulation, or government-wide policy requires or permits controlling. Then get specific. Pull the actual contract language, not the general impression your team has of what the contract probably requires.
Look at the actual data flowing through your systems, not a generic assumption about what a defense contractor probably handles. Name the CUI categories that apply to you, whether that’s CTI, export-controlled technical data, or something else in the registry, rather than reaching for a single label to cover your whole environment.
Everything else that follows, the CUI markings, the banners, the foreign-national question, the System Security Plan, depends on getting that first answer right. Federal agencies do not grade you on effort here. They grade you on whether the boundary you drew actually matches the CUI you actually have, not the boundary you assumed, and not the boundary a vendor told you to buy technology for.
That is what CUI Discovery is for, and it is the same first step regardless of which contract, which prime, or which category of CUI you end up dealing with.
We stand the watch for you. Come stand it with us, starting with the question everything else depends on.
