What is CUI?
Controlled Unclassified Information is government information that is not classified but still cannot be treated as public. The category exists because the old alternative was chaos: before the CUI program, agencies invented their own markings — sensitive but unclassified, for official use only, dozens of variants — each with its own handling expectations and no consistent legal basis.
The CUI program replaced that with one framework. An executive order established it, a federal regulation implements it, and the National Archives maintains the authoritative registry of what categories exist and what authority makes each one controlled. If a category is not in the registry, it is not CUI.
For a technology company, CUI is the trigger. It is what makes NIST SP 800-171 apply to your systems, what makes CMMC Level 2 relevant rather than Level 1, and what turns a routine subcontract into a compliance program.
The categories are broader than people expect
The registry organizes CUI into groupings that reach well past defense:
- Controlled technical information — engineering data, specifications, and technical material with military or space application.
- Export control — information subject to export regulations, which catches a great deal of ordinary engineering work.
- Privacy — certain personal information held by or for the government.
- Procurement and acquisition — source selection material, contractor bid and proposal information.
- Critical infrastructure — information about the systems the country runs on.
- Law enforcement, financial, tax, and more.
A commercial SaaS company that never touches a weapons program can still find itself holding CUI because a customer uploaded procurement-sensitive material or export-controlled technical data into its product.
Why this is an architecture question first
The most consequential decision about CUI is made in product design, not in compliance: does government CUI have to enter your environment at all?
Three architectures produce three completely different obligations:
- CUI never enters your systems. The product runs in the customer’s tenant, or the deployment model keeps controlled data on the customer’s side of the boundary. Your compliance obligation is minimal because the trigger never fires.
- CUI enters a dedicated enclave. A distinct environment holds controlled data, with defined paths in and out. The requirement set applies to the enclave rather than to the whole company, which is the difference between a scoped project and an enterprise transformation.
- CUI flows through the general environment. Everything is in scope — corporate email, laptops, the commercial production estate, the support tooling. This is the expensive answer, and it is usually arrived at by accident rather than by decision.
The companies that handle CUI cheaply chose architecture two deliberately. The ones that handle it expensively discovered architecture three after the fact.
Marking, handling, and destruction
CUI carries handling obligations beyond storage security. It must be marked when it is created or received in a controlled context. Dissemination is limited to those with a lawful government purpose. Destruction has to be done in a way that makes reconstruction infeasible. Physical and electronic handling both count.
For a software vendor the practical implications are unglamorous and specific: can your product export data without stripping markings, can it enforce access restrictions that mirror the dissemination limits, and can it actually delete data when required rather than soft-deleting it forever.
The question worth answering early
Before your first defense-adjacent contract, answer this in writing: where in our product can government CUI end up, and what would it take to make sure it ends up in exactly one place we control?
Answering it early is a design exercise. Answering it after an award is a migration.