What is controlled unclassified information (CUI)

What is controlled unclassified information (CUI) and does it apply to your contract?

Controlled unclassified information is information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, which a law, regulation or Governmentwide policy requires or permits an agency to protect with safeguarding or dissemination controls. That definition appears in 32 CFR 2002.4(h), and it excludes classified information and information a non-executive branch entity keeps in its own systems that did not come from or was not created for an agency. For a contractor, the practical question is not whether the information feels sensitive. It is whether a contract, subcontract or agreement sends CUI into your systems or asks you to create it, because that is what brings NIST SP 800-171 into play for your environment.

Whether a specific contract involves CUI depends on two things: the authority behind the information and how the contract identifies it. Check the contract's specifications, statement of work, data rights clauses and any CUI markings or distribution statements, then compare what you will receive or generate against the categories in the CUI Registry. Information you create while performing the work can also qualify if the Government's requirements make it CUI. Where the contract is silent or ambiguous, ask the contracting officer in writing to identify the CUI and its handling requirements before you accept the data. Your organization owns its controls and the decisions about how to meet them. An implementation partner can help map systems and gather evidence, but only the contracting agency's requirements determine what the contract demands, and only an independent assessor determines compliance status.

CUI Basic and CUI Specified: how handling rules are set

CUI Basic is the subset of CUI whose authorizing law, regulation or Governmentwide policy sets out no specific handling or dissemination controls. Under 32 CFR 2002.4(j), that gap means the uniform controls in Part 2002 and the CUI Registry govern how the information is protected and shared. The authority establishes that the information is controlled, but the detailed rules for handling it come from the government-wide framework rather than from the statute or regulation behind the category.

No category-specific rules: The authorizing authority names the information but does not prescribe safeguards, so there is no separate rulebook to read.
Uniform Part 2002 controls apply: Marking, safeguarding, dissemination and decontrol follow the common government-wide requirements.
CUI Registry as the reference point: The Registry shows the category, its authority and whether any specific controls exist, which tells the reader whether the Basic path applies.
Federal agency expectations: For nonfederal systems, agencies reference NIST SP 800-171 as the baseline for confidentiality protection, unless the category authority or an agreement says otherwise.

Before relying on the Basic path, confirm in the Registry that the category's authority contains no specific controls, and check the contract for any added requirement.

The CUI Registry, decontrol and misuse: what contractors must track

Whether information is CUI, and whether it still needs protection, is set by the authorities and the designating agency rather than by the contractor. The cards below cover the parts of that picture a contractor must keep current: the Registry, decontrol, misuse and the marking decisions that tie them together.

The CUI Registry as the reference list

The CUI Registry is the government's list of CUI categories and the authorities behind them. For a contractor, it is the place to confirm whether a category in a contract is a CUI Basic or CUI Specified category, and whether a specific handling control applies on top of the general Part 2002 controls. Check the category named in the contract against the Registry before you build handling rules around it, and record the version you checked.

Confirm the category with the agency

The Registry describes categories in general terms, but the contracting agency or designating agency decides how a specific document is categorized and marked. Ask the contracting officer to identify the category, the controlling authority and any handling instructions in writing. Keep that answer with the contract file, since it tells your staff and subcontractors what they are protecting and why.

Decontrol under 32 CFR 2002.18

Decontrol removes safeguarding or dissemination controls from information that no longer needs them. It happens automatically when a listed condition occurs, or when the designating agency decides it. Agencies are expected to decontrol as soon as practicable, so a contractor should not assume information stays controlled indefinitely. Ask whether any decontrol condition applies to the contract's data and track any decision in writing.

Misuse under 32 CFR 2002.4(ee)

Misuse means handling CUI in a way that departs from Part 2002, the Registry, agency policy or the governing law. It includes unintentional safeguarding or dissemination errors, such as sending CUI to an unauthorized recipient by mistake. It also includes marking information as CUI when it does not qualify. Build checks into your process for both failure modes, because an error in either direction can create obligations you did not plan for.

Over-marking as a misuse risk

Marking information as CUI when no authority requires or permits the control is a form of misuse. It can impose handling costs on your team, restrict sharing with people who need the data, and dilute the protection on information that is controlled. Before you mark your own engineering or business records, confirm with the contracting agency that they fall within the contract's CUI definition. Record the basis for each marking decision.

Why CUI status decides whether NIST SP 800-171 applies

NIST SP 800-171 applies to your organization because a federal agency requires it, and the trigger is CUI in your possession. Under 32 CFR 2002.14(h)(2), agencies must use NIST SP 800-171 when they set requirements to protect CUI on nonfederal information systems. Two exceptions matter: the authority behind a particular CUI category may prescribe other safeguards, or an agreement may set protection above the moderate level. Read the contract's safeguarding clauses and any CUI category markings before assuming which baseline governs. NIST also states that application of SP 800-171, and any compliance issues, rest with the federal agency that holds the contract or agreement with you, regardless of your size.

Confirm the version your contract names. SP 800-171 Rev. 3 was published on 14 May 2024 and contains 97 requirements. Rev. 2, with 110 requirements, was withdrawn on the same date, yet DoD contractors are still assessed against Rev. 2 because 32 CFR 170.14(c)(3) ties CMMC Level 2 to it. For DFARS 252.204-7012, DoW Class Deviation 2026-O0025, Revision 3 (signed 3 September 2026) has contracting officers cite SP 800-171 Revision 2, and a 13 July 2026 DoW CIO memorandum requires baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. A FAR overhaul proposed rule would move civilian contracts to Rev. 3 with ODP values published by the DoW CIO, but it was not final as of October 2026. Ask the contracting officer in writing which revision and which organization-defined parameter values apply.

How to confirm whether your contract involves CUI

This sequence moves from the contract's own markings to a written determination from the agency, so the organization can state which information is CUI and document it in the system security plan before scoping systems.

Read the contract's markings and identifiers
Start with the contract document itself. Look for explicit CUI banner markings, category markings, distribution statements, and any clause or attachment that lists information to be safeguarded or identifies a CUI category. Someone on the contracts or program side should do this read, with a security lead in the room, because the question is what the government has marked or identified, not what the team assumes. The output is a written list of every marking, identifier and referenced attachment, each tied to its location in the contract or task order.
Review the CUI categories the contract cites
For each category or marking found, determine which CUI category it names and whether the contract points to a law, regulation or Governmentwide policy behind it. Under 32 CFR Part 2002, CUI Basic and CUI Specified differ in where their handling controls come from, so note whether the category carries specific handling controls. The output is a category table that records each cited category, its marking and the authority the contract names, with gaps flagged for follow-up.
Check the CUI Registry for each authority
Use the CUI Registry to confirm that each cited category exists, that the authority listed supports it, and whether any specific handling or dissemination controls apply. Registry entries also show whether the category is CUI Basic or CUI Specified. Record the registry entry and the date you checked it, since the Registry can change. The output is a verified category list that shows which authorities govern the information and which do not match anything in the Registry.
Ask the contracting officer or agency to confirm in writing
Where the markings, categories or authorities are unclear, or where the contract is silent on information the team will create or receive, send a written question to the contracting officer, and copy the program office when one is named. Ask directly whether the information in scope is CUI, which categories apply, and whether any agency-specific handling controls or ODP values must be followed. Only the agency can make this determination for its contract. The output is a written reply from the government that the organization files with the contract record.
Identify information created during performance
Work with the program team to list information the organization will create or generate while performing the contract, such as reports, designs, test data or technical drawings. The contract may not mark this material, but the organization still needs to know whether it qualifies as CUI under the agency's guidance. Ask the agency to confirm the treatment of created information in the same written exchange. The output is a list of created information categories, each with the agency's written position or an open item tagged for resolution.
Confirm flow-down and subcontractor obligations
If the organization will share CUI with subcontractors or suppliers, or receive it from a prime contractor, confirm in writing which information the prime will pass down and under which clauses. Record which parties hold which information and whether each recipient needs to meet the same safeguarding obligations. The output is a flow-down register that names each external party, the information shared, and the agreed safeguarding terms.
Document the determination for the system security plan
Combine the outputs from earlier steps into a single written CUI determination that states which information in the contract is CUI, its category and authority, what the agency confirmed, and what remains open. Attach the marked contract excerpts, the Registry check, and the agency reply. Link the determination to the system security plan so each system that stores, processes or transmits the identified information is named in the scope. The output is a signed, dated determination file that the security team can point to during scoping and any later assessment.

Common mistakes when scoping CUI

Most scoping problems come from treating the boundary as a question of who holds data rather than whether a law, regulation or Governmentwide policy requires or permits safeguarding. The five errors below push organizations to protect too much, or too little, and each one is easy to check before a contract is signed.

Treating all contractor data as CUI

CUI is defined by the government's authority to require safeguarding, not by the sensitivity of the data or the fact that a contractor created it. Information a non-executive branch entity keeps in its own systems that did not come from or was not created for an agency falls outside the definition. Before extending NIST SP 800-171 to every file, ask the contracting officer which information the contract actually identifies, and map your own business records separately.

Ignoring unmarked information created in performance

Work product generated under a contract can be CUI even when nobody has applied a marking. Engineers, analysts and project staff often produce drawings, reports or data sets during performance that the agency's requirements cover, yet the files carry no label. Build a short review step into document creation so that people ask whether the contract's identified categories apply, and record the answer for the file.

Relying on legacy markings

Older documents may carry markings such as For Official Use Only or Sensitive But Unclassified that no longer authorize safeguarding. Treating them as proof that a file is CUI, or assuming that a legacy label makes it out of scope, both produce bad scoping decisions. Inventory the markings in your repositories, identify which are current CUI markings, and confirm with the agency how legacy material should be handled.

Missing that mismarking is misuse

Under 32 CFR 2002.4(ee), misuse includes marking information as CUI when it does not qualify, not only mishandling information that does. Labeling everything as CUI to be cautious creates an obligation to protect material that the authority does not cover and can count as misuse. Mark only what the authorizing law, regulation or policy requires or permits, and correct markings that were applied in error.

Assuming FCI rules cover CUI

Federal contract information and CUI carry different safeguards. Meeting the basic FCI requirements in FAR 52.204-21 does not satisfy the NIST SP 800-171 requirements that apply once a contract involves CUI, so a team that stops at FCI controls may have an unscoped gap. Confirm which category each contract data set falls into, then choose the matching requirement set for each system that stores it.

Questions about CUI and NIST SP 800-171 scope

Who decides whether information is CUI?

The federal agency that creates or owns the information decides, based on a law, regulation or Governmentwide policy that requires or permits safeguarding or dissemination controls. A contractor does not decide this on its own. Under 32 CFR 2002.4(h), CUI covers information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government. The contract, its statement of work and any marking should identify it, but when they do not, the contractor should ask the contracting officer in writing rather than assume the answer. Marking information as CUI when it does not qualify is itself treated as misuse under the CUI rules, so the question matters in both directions.

Is federal contract information (FCI) the same as CUI?

No. Federal contract information is information provided by or generated for the Government under a contract that is not intended for public release, and it carries the lighter safeguards in FAR 52.204-21. CUI is a narrower, governed category defined in 32 CFR Part 2002 with a registry of categories, and it carries the NIST SP 800-171 requirements. A contract can involve both, and the same system may need to meet both sets of rules. The practical difference is that CUI brings the heavier set of requirements, so a contractor should confirm which label applies to each data set before scoping its environment. The sibling guide on CUI versus FCI covers the mapping to CMMC levels in more detail.

Does a small company still need to comply with NIST SP 800-171?

If a contract or agreement requires it, yes. NIST states that application and implementation of SP 800-171, and any compliance issues, are the responsibility of the federal agency that holds the contract or agreement with the nonfederal organization, irrespective of the organization's size. Company size does not remove the obligation, although it can change how much of the environment needs to be scoped and how the controls are staffed. A small firm should first confirm whether its contract actually involves CUI, then confirm which revision and which assessment method the contract names, because those answers change the work far more than headcount does.

What is CUI Specified, and does it change the requirements?

CUI Specified is a subset of CUI whose authorizing law, regulation or Governmentwide policy sets out its own handling controls that differ from the uniform CUI Basic rules. Those controls may be more stringent or simply different. Under 32 CFR 2002.4(r), CUI Basic controls fill any aspect the authority does not cover. For a contractor, CUI Specified can add obligations on top of NIST SP 800-171, so the contract and the CUI Registry entry are the places to check. Whether it changes the requirements depends on the specific authority, which is why each category should be reviewed rather than treated as one block. The sibling guide on CUI Basic versus CUI Specified sets out the differences.

How long does CUI scoping take, and what drives it?

The duration depends on what drives the work, and no fixed figure applies to every organization. The main drivers are the number of systems and locations that store, process or transmit CUI, how much information is mixed with non-CUI data, whether CUI is shared with subcontractors or cloud providers, how well current asset inventories and network diagrams match reality, and how many contracts involve CUI. Scoping is faster when data flows are documented and slower when CUI has spread through email, shared drives and personal devices. Ask any partner or assessor for a written scope and timeline that lists these drivers and the assumptions behind them.

Can we scope CUI ourselves, or do we need outside help?

Yes, an organization can scope its own CUI environment, and many do. The owner of the controls is the organization, so internal staff with knowledge of data flows, system inventories and contract terms should lead. Outside help is most useful when the environment is complex, when the team lacks time or experience with boundary decisions, or when the organization wants a second review before an assessment. An implementation partner such as DeployOpen can prepare systems, documentation and evidence in a fixed-scope engagement, but it does not decide what is CUI or issue any assessment result. Those decisions belong to the contracting agency and an independent assessor.

Primary sources for the CUI definition

The legal definition of CUI sits in 32 CFR Part 2002, which governs how the executive branch safeguards and disseminates controlled unclassified information. Read the definition in 32 CFR 2002.4(h) together with 2002.1(c), which states that CUI exists only where a law, regulation or Governmentwide policy requires or permits safeguarding or dissemination controls. As a contractor, your working question is narrower: does the information in front of you fall inside that definition, and does the contract say so? Start with the current eCFR text of Part 2002 at eCFR: 32 CFR Part 2002, and pair it with the CUI Registry entry for the category your contract cites, since the Registry shows which authorities attach specific handling controls.

Two more sources answer the practical questions. The NIST FAQ on SP 800-171 Rev. 3 and SP 800-171A Rev. 3 explains how NIST expects SP 800-171 to apply once CUI is identified, and it confirms that the federal agency holding the contract is responsible for how the requirements are applied. For defense work, the DFARS text in eCFR: DFARS subpart 204.73 defines the safeguarding obligations that DoD contracts attach to covered defense information. The DFARS and FAR texts change, and a class deviation or proposed rule may be in force for your contract even when the published eCFR text looks unchanged. Confirm the current edition and any deviation in force with your contracting officer, and record the version your contract incorporates in your compliance file.

How DeployOpen scopes CUI into a self-hosted enclave

DeployOpen works on the systems that store, process and transmit CUI, not on the legal question of whether a contract involves CUI. We plan and build self-hosted open-source platforms inside your own infrastructure, then prepare the documentation and evidence your assessor will ask for, and we hand the environment over to your team.

How we scope

Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts
The written scope names which systems, accounts and data flows hold the CUI being scoped into the enclave
Scope documents list the boundary, the owners of each control and the evidence each system must produce

How we build

Self-hosted open-source platforms are deployed in your cloud accounts, data centers or air-gapped networks
Access control, logging, encryption and configuration baselines are implemented and tested against the agreed requirements
Security testing of applications, APIs and infrastructure runs before handover, with findings tracked to closure

How we hand over

Operating procedures, system documentation and control descriptions are delivered for your staff to maintain
Evidence is collected in a form your independent assessor can examine, with your organization owning every control
Training for administrators and users covers the platforms and the handling rules set out in the scope

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers cover platform patching, backup checks and documentation updates when the environment changes
Confirm with DeployOpen in writing which support and testing items your contract includes and how they are priced

What is controlled unclassified information (CUI)