CUI just arrived in your product. Now what?

The sentence that starts this

A clause in a subcontract. A line in a customer's security questionnaire. A program manager mentioning, almost in passing, that the data set you are about to receive is CUI. For a commercial team that has never worked a federal requirement, that sentence lands as a vocabulary problem — one more acronym to look up. It is not. It is a boundary problem, and boundary problems are architectural, which means getting it wrong costs rework rather than paperwork.

Start with what CUI is not. It is not a classification. Executive Order 13556, signed 4 November 2010, created the Controlled Unclassified Information Program and made the National Archives and Records Administration its Executive Agent. NARA's own definition is the one to hold onto: information that "requires safeguarding or dissemination controls pursuant to and consistent with applicable law, regulations, and government-wide policies but is not classified under Executive Order 13526 or the Atomic Energy Act." Nobody needs a clearance to read it. What it needs is handling.

The second thing to hold onto is that CUI is a property of the information, not of your company. There is no such thing as a CUI-certified firm. There are systems permitted to process, store, or transmit particular information, and systems that are not. Every useful question downstream reduces to one: which of our systems does this information touch?

Basic, Specified, and the registry that decides

The implementing rule is 32 CFR part 2002, issued by the Information Security Oversight Office, which establishes policy for designating, safeguarding, disseminating, marking, decontrolling, and disposing of CUI. It splits the world in two. CUI Basic is the subset for which the authorizing law, regulation, or government-wide policy sets no specific handling controls, so the uniform controls in part 2002 apply. CUI Specified is the subset where the authorizing authority does impose its own handling or dissemination controls — and those controls govern.

Which one you have is not a judgment call; it is a lookup. The CUI Registry at archives.gov/cui is the public, authoritative list of every approved category and subcategory, each tied to the specific law, regulation, or government-wide policy that authorizes it. When a customer tells you "it's CUI," that is not yet something you can build against. What you can build against is the category and subcategory as they appear in the registry, plus any limited dissemination control attached.

One line in the rule does most of the engineering work. Under 32 CFR 2002.14(g), CUI Basic "is categorized at no less than the moderate confidentiality impact level." And 2002.14(h)(2) names the standard directly: "NIST SP 800-171 defines the requirements necessary to protect CUI Basic on non-Federal information systems in accordance with the requirements of this part." That is the hinge: a handling regime written by an archives agency becomes a control set your engineers implement.

You do not get to decide what is CUI

This surprises commercial teams more than anything else, in both directions. Under 32 CFR 2002.20(a)(4), "the designating agency determines that the information qualifies for CUI status and applies the appropriate CUI marking when it designates that information as CUI." On the defense side, DoD Instruction 5200.48 keeps that determination with the information's owner. You cannot self-designate, and marking your own commercial data "CUI" does not make it CUI — it just invents obligations nobody asked you to take on.

The inverse is what actually bites. Marking practice across the government has been uneven for years, so information that plainly meets a registry category often arrives unmarked, from someone who assumed you already knew. Do not guess in either direction. Ask the contracting officer or the information owner, in writing, and keep the reply. Under 32 CFR 2002.20(d) a document containing CUI is supposed to carry a designation indicator naming at minimum the designating agency — so if you cannot tell who designated it, that is the question to ask. The written answer is what protects you in an assessment two years later.

Which rule actually attaches to you

"CUI requirements" is shorthand for a stack of separate instruments with different owners. They arrive in a contract in combinations, and the combination is what determines your obligations — not the acronym.

Sources: EO 13556 (4 Nov 2010); 32 CFR part 2002 §§ 2002.14, 2002.20; FAR 52.204-21; DFARS 252.204-7012, -7019, -7020, -7021; 32 CFR part 170. The CMMC Program rule at 32 CFR part 170 took effect 16 December 2024; the acquisition-side rule that lets contracting officers insert 252.204-7021 took effect 10 November 2025, beginning a phased rollout.

Rev 2 or Rev 3 — read the contract, not the standard

Here is a trap worth knowing about before you buy anything. NIST published SP 800-171 Revision 3 as final on 14 May 2024, and it supersedes Revision 2. Revision 3 reorganizes the material — 17 families and 97 requirements, against Revision 2's 14 families and 110 requirements — and adds families for planning, system and services acquisition, and supply chain risk management.

DoD did not follow. On 2 May 2024, twelve days before Revision 3 was published, the Department issued Class Deviation 2024-O0013, directing that DFARS 252.204-7012 continue to point at Revision 2 until the deviation is rescinded. So on the same afternoon, a defense contract and a civilian-agency contract can obligate you to two different editions of the same standard. The number of requirements you owe is a contract question, not a standards question. Read the clause you actually signed.

What changes the day CUI arrives

• Your boundary becomes a document — an asset inventory, a network diagram, and a system security plan. If your team cannot draw where the data lives, no assessor can confirm it.
• Copies inherit — CUI in a backup is CUI. So is CUI in a log, a crash dump, a screenshot in a ticket, or a fine-tuning corpus.
• Your cloud provider becomes a contract dependency — DFARS 252.204-7012 requires a cloud service provider that meets the FedRAMP Moderate baseline or equivalent, which narrows the menu considerably.
• Incident response becomes a clock — 72 hours from discovery, reported through DIBNet, which requires a DoD-approved medium assurance certificate you have to obtain in advance.
• Evidence must be preserved — the clause requires preserving and protecting images of affected systems and relevant monitoring data for at least 90 days after a report.
• The obligation flows down — any subcontractor whose systems touch the same information inherits the same clause, which makes your vendor list part of your boundary.

The practices that matter first

Nobody implements 110 requirements simultaneously, and the rule tells you what to sequence first because it tells you what can never be deferred. Under 32 CFR 170.21, only requirements worth 1 point under the scoring methodology are eligible for a Plan of Action and Milestones. Three- and five-point requirements must be implemented before the assessment, with one narrow exception: the CUI encryption requirement (SC.L2-3.13.11) may go on a POA&M where encryption is in use but not yet FIPS-validated. That exception does not apply where there is no encryption at all.

Six requirements may never go on a POA&M at any score: two access-control requirements covering external connections and control of publicly accessible information, the system security plan requirement (CA.L2-3.12.4), and three physical-protection requirements. And Conditional status is gated on arithmetic — the assessment score divided by the total number of Level 2 requirements must be at least 0.8, which is 88 of 110, with a closeout assessment inside 180 days of the Conditional status date or the status expires.

• Get the designation in writing — category, subcategory, and who designated it
• Draw the boundary before purchasing any tooling
• Multi-factor authentication and access control on everything inside it
• FIPS-validated cryptography for CUI at rest and in transit
• Audit logging you can actually produce on request
• A written system security plan — this one is never deferrable
• Incident response rehearsed, and the DIBNet certificate obtained in advance

On scoring: the NIST SP 800-171 DoD Assessment Methodology, version 1.2.1, starts you at 110 and subtracts 5, 3, or 1 point per unimplemented requirement, with a floor of −203. A deeply negative first self-assessment is ordinary. Posting a flattering one you cannot evidence is a different kind of problem, because the affirmation attached to it is a statement to the government.

The enclave: shrink what gets assessed

The single highest-leverage decision available to a commercial team is where the boundary goes, and the reason is written into 32 CFR 170.19. Level 2 scoping sorts every asset into one of five categories, and they are not assessed the same way.

CUI Assets — assets that "process, store, or transmit CUI." Fully assessed against the Level 2 requirements, and documented in the inventory, the SSP, and the network diagram.

Security Protection Assets — assets providing security functions to the assessment scope. In scope, but assessed against the requirements relevant to what they protect. Your identity provider, your logging platform, and your device management sit here even if they never hold a CUI file.

Contractor Risk Managed Assets — "assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures, and practices in place." Assessed by documentation review, with limited checks only if deficiencies are suspected.

Specialized Assets — government furnished equipment, IoT and industrial IoT, operational technology, restricted information systems, test equipment. Documented in the SSP, not separately assessed against the requirements.

Out-of-Scope Assets — assets that "cannot process, store, or transmit CUI; and do not provide security protections for CUI Assets." No assessment, no documentation. The rule is blunt about the escape hatch: assets falling into any in-scope category cannot be reclassified as out of scope.

One caution belongs next to every enclave conversation. Where the environment comes from an external service provider that is a cloud service provider handling CUI, 32 CFR 170.19 points back at the FedRAMP requirements in DFARS 252.204-7012 — the provider's authorization posture becomes part of yours. External service providers that are not cloud service providers get different treatment: their services come into your assessment scope and are assessed as part of it.

The failure mode is almost never technical. An enclave is a promise about where data goes, and every convenience added afterward is a hole in it. A file forwarded to personal mail. A screenshot pasted into a general-purpose chat assistant for a summary. A ticketing system outside the boundary holding a customer's log excerpt. Enclaves collapse because the boundary was inconvenient and people routed around it. Design the workflow, not just the tenancy, and budget for that friction up front.

If your product ships into someone else's boundary

There is a second case, increasingly the common one: you may never hold the customer's CUI at all. If your model or application installs headless inside an environment the customer has already had accredited, you are a component inside their authorization package, assessed by their assessor against their control set. The work becomes producing evidence that package can absorb — dependencies installed from a mirror rather than a public index, evaluation that runs fully offline and reproducibly inside the enclave, logs their tooling can read, and control-implementation narrative their SSP can take in without a rewrite. Two adjacent pieces go further: headless deployment into a customer-controlled sandbox and what impact levels actually change for an AI workload.

What matters in the first meeting is not "are we CUI compliant." It is: whose authorization package does this land in, which control set applies, and who signs. If nobody on the call can answer that, the schedule everyone is working to is a guess.

Where our scope ends

Stating the boundary is more useful than claiming breadth, so here is ours on this subject.

How this starts

The first conversation is short. Which information, from which contract clause, in which registry category. Which of your systems it touches today, drawn on one page. What the customer's schedule actually requires — a posted self-assessment score, a certification, or evidence that fits inside somebody else's package. The boundary sketch comes before any tooling decision, because tooling is downstream of the boundary and expensive to reverse. Reach us through the contact form; a one-paragraph description of the situation is plenty to start.

Where to check all of this yourself

Every claim above is traceable to a primary document. These are the documents, not summaries of them.

• CUI Registry and program materials — categories, subcategories, Basic versus Specified, marking guidance. archives.gov/cui
• 32 CFR part 2002 — safeguarding at §2002.14, marking at §2002.20. archives.gov (PDF)
• NIST SP 800-171 Rev. 3, final 14 May 2024, superseding Rev. 2. csrc.nist.gov
• DoD Class Deviation 2024-O0013 — keeps DFARS 252.204-7012 on Rev. 2 until rescinded. acq.osd.mil (PDF)
• DFARS 252.204-7012 — 72-hour reporting, medium assurance certificate, 90-day preservation, cloud requirements. acquisition.gov
• 32 CFR part 170 — scoping at §170.19, POA&M limits at §170.21. eCFR
• CMMC Scoping Guide, Level 2, version 2.13, September 2024 — the asset categories worked through with examples, aligned to 32 CFR 170.19. dodcio.defense.gov (PDF)
• NIST SP 800-171 DoD Assessment Methodology, v1.2.1, 24 June 2020 — the 5/3/1 scoring. acq.osd.mil (PDF)
• DoD Instruction 5200.48 — the DoD CUI program, marking and designation. esd.whs.mil (PDF)

Related reading on this site: CUI handling for federal AI systems, NIST 800-171 and CMMC for AI firms, federal cyber incident reporting for contractors, and what we build and what we decline.

Frequently asked questions