Controlled Unclassified Information: The Basics for Software Teams

In This Article

  1. What CUI actually is
  2. Why it is not the same as classified
  3. CUI Basic and CUI Specified
  4. The markings your software has to carry
  5. Where CUI may be stored and processed
  6. What DFARS 252.204-7012 requires
  7. The 72-hour clock
  8. What this does to your architecture
  9. A first-week checklist
  10. Common questions

Someone on your program has just told you the system you are building will hold CUI. Maybe a contracting officer flagged it, maybe a prime sent down a clause list. Either way the word has landed on your sprint and nobody has explained what it means for the code.

Here is the short version. CUI is Controlled Unclassified Information. It is not a security classification, it does not require a clearance, and it is not a property of your system. It is a property of specific data, assigned by the government, that carries handling rules with it. Those rules change your architecture more than they change your day-to-day work, and they are far cheaper to honor before the first row of data lands than after.

Key Takeaways

What CUI actually is

Before 2010, every agency had its own label for sensitive-but-unclassified material: For Official Use Only, Sensitive But Unclassified, Law Enforcement Sensitive, and dozens more. Each carried its own informal rules, and none meant the same thing twice.

Executive Order 13556, signed on November 4, 2010, replaced that arrangement with a single program and named the National Archives and Records Administration as its Executive Agent. The implementing rule, 32 CFR Part 2002, took effect on November 14, 2016. It binds executive branch agencies, and it reaches contractors through the agreements and clauses those agencies write.

The definition at 32 CFR 2002.4 is narrower than most people assume. CUI is information the government creates or possesses, or that an entity creates or possesses for or on behalf of the government, that a law, regulation, or Government-wide policy requires or permits an agency to handle with safeguarding or dissemination controls. That phrase is the whole game. A program manager's discomfort is not a law. An internal sensitivity label is not a Government-wide policy.

Section 2002.10 establishes the CUI Registry, published at archives.gov/cui/registry, which lists every approved category, the authority behind it, and the marking that goes with it. Within the Department of Defense, DoD Instruction 5200.48 layers the department's own implementation on top of the NARA rule.

For an engineer, the takeaway is that CUI arrives from outside. The agency designates it; your job is to receive that designation, preserve it, and honor the rules attached to it.

Why it is not the same as classified

Classified national security information is governed by a different order entirely, Executive Order 13526, and it lives on accredited systems under a separate body of rules. Confidential, Secret, and Top Secret are classification levels. CUI is none of those. It is unclassified.

The practical consequences are large. Your developers do not need clearances to build a CUI system, and there is no CUI clearance to grant. Under 32 CFR 2002.16, access goes to authorized holders who have a lawful Government purpose for the information, a contract-and-need basis rather than a personnel security basis.

That does not make CUI casual. Sections 2002.54 and 2002.56 address misuse and sanctions, and the contract consequences of a mishandling event are real. But the control you are engineering is a data-handling control, not a facility clearance problem. Your team can do this work. You just cannot do it on the same infrastructure as your commercial product without thinking hard first.

CUI Basic and CUI Specified

Section 2002.12 splits CUI in two, and this split is the one most software designs get wrong.

CUI Basic applies when the underlying law or regulation says the information must be protected but does not spell out how. The default rules in Part 2002 fill the gap.

CUI Specified applies when the authority does spell out handling or dissemination controls that differ from the Basic defaults. Those controls take precedence.

Two Specified categories show up constantly in engineering work. Controlled Technical Information, marked CUI//SP-CTI, covers technical data with military or space application subject to access and dissemination controls. Export Controlled information, marked CUI//SP-EXPT, brings the export control regime with it, restricting who may access the data and constraining where the servers sit and who administers them.

This is why a single boolean column named is_cui is a design bug. The day an export-controlled record enters a system built on that flag, you cannot enforce a rule that applies to that record and not its neighbors. Store the full category marking as data and make your authorization layer read it.

The one-line summary

CUI is unclassified information the government has designated for protection under a specific legal authority. On your systems it means NIST SP 800-171 safeguarding, mandatory markings that survive every export path, a cloud stack at FedRAMP Moderate or equivalent, and a 72-hour incident reporting clock.

The markings your software has to carry

Marking rules live at 32 CFR 2002.20, and they have direct consequences for any code that renders a document.

The banner marking is the word CUI or CONTROLLED. Its content applies to the whole document and must be the same on each page that includes CUI. For CUI Specified, the banner carries the category, as in CUI//SP-CTI.

The designation indicator identifies who designated the information as CUI, at minimum by agency. It must be readily apparent to authorized holders and may appear only on the first page or cover.

Portion marking is permitted and encouraged, and it remains optional for CUI Basic under the NARA rule. Individual agencies frequently require it, so read the contract rather than the default.

Section 2002.16 also allows limited dissemination controls, but only the ones the CUI Executive Agent has approved and published in the Registry. An agency cannot invent a new distribution caveat, and neither can your product.

Now translate that into code. Any path that turns a record into a document is a marking obligation: PDF generation, spreadsheet export, print stylesheets, email notifications. A report generator that emits a clean, unmarked PDF full of CUI has produced an unmarked CUI document, and that is a handling failure no matter how well the database underneath was encrypted. Build marking into the render layer, store the marking string with the record, and disable any export path that cannot mark.

Where CUI may be stored and processed

Section 2002.14 sets the safeguarding floor. CUI Basic is categorized at no less than the moderate confidentiality impact level under FIPS Publication 199. Federal agencies meet that with controls from FIPS 200 and NIST SP 800-53. For everyone else the rule points at a different document: NIST SP 800-171 defines the requirements necessary to protect CUI Basic on non-federal information systems.

SP 800-171 Revision 2 contains 110 security requirements across 14 families. Revision 3, published in May 2024, reorganized the set and introduced organization-defined parameters. Which revision applies is a contract question, not a preference. As of mid-2026 CMMC Level 2 is scored against Revision 2, so a team reading Revision 3 can end up measuring against the wrong list.

110
Security requirements in NIST SP 800-171 Revision 2 that a non-federal system holding CUI must meet, and the maximum possible score in the DoD assessment methodology reported through SPRS.

Two related clauses set the paperwork. DFARS 252.204-7019 and 252.204-7020 require a current NIST SP 800-171 assessment score posted in the Supplier Performance Risk System before award and access to the results afterward. DFARS 252.204-7021 carries the CMMC requirement; the acquisition rule that puts that clause into contracts took effect on November 10, 2025 and phases in over several years, with the CMMC program itself defined at 32 CFR Part 170.

What DFARS 252.204-7012 requires

This is the clause that governs your system when the contract involves DoD covered defense information, which it defines as unclassified controlled technical information or other information requiring safeguarding or dissemination controls that is marked or otherwise identified in the contract. Four obligations matter to an engineering team.

1
Adequate security via SP 800-171. Paragraph (b)(2)(ii)(A) requires the contractor to implement NIST SP 800-171. Everything in the previous section flows from this sentence.
2
Cloud services at FedRAMP Moderate or equivalent. Paragraph (b)(2)(ii)(D) requires that an external cloud service provider used to store, process, or transmit covered defense information meet security requirements equivalent to the FedRAMP Moderate baseline. The DoD CIO memorandum of December 21, 2023 defines equivalency as an assessment by a FedRAMP-recognized third party assessment organization against 100 percent of the Moderate baseline, with no open plans of action and a full body of evidence available on request. Self-attestation does not satisfy it.
3
Rapid incident reporting. Covered in the next section, and the one most likely to be discovered mid-incident rather than during design.
4
Flow-down without alteration. The subcontract paragraph requires the clause be included, unaltered, in subcontracts that involve covered defense information or operationally critical support. If you are a sub, the obligation is yours directly, not your prime's.

Item two is where most software teams find their surprise. The clause does not say "your database." It says any external cloud service that stores, processes, or transmits the information. Read your dependency list with that sentence in hand: crash reporting, log aggregation, performance monitoring, hosted CI runners, container registries, feature flags, session replay, support ticketing, and any hosted model endpoint in the request path. Each either meets the bar, leaves the CUI path, or gets replaced by something inside the boundary.

The 72-hour clock

DFARS 252.204-7012 defines "rapidly report" as within 72 hours of discovery of any cyber incident. Reports go to https://dibnet.dod.mil. Three details around that sentence catch teams flat-footed.

First, submitting a report requires a DoD-approved medium assurance certificate. Obtaining one involves identity verification and lead time, so it belongs on the project setup checklist alongside SPRS registration. Nobody should be starting a certificate application on hour six of an incident.

Second, the clause requires you to preserve and protect images of all known affected information systems for at least 90 days from submission of the report. If your instances are ephemeral and snapshot retention is seven days, you cannot comply. Decide now how a forensic hold gets placed and where the images go.

Third, when malicious software is discovered and isolated, it is submitted to the DoD Cyber Crime Center, not sent to the contracting officer. Put that in the runbook, because the instinct to email the customer is strong and wrong.

Seventy-two hours is wall-clock time, weekends included. Working backward from it produces concrete requirements: detection good enough that discovery actually happens, an on-call path that reaches a decision-maker, a named certificate holder, and one rehearsal so the first attempt is not live.

What this does to your architecture

Draw the boundary before you write code. Every system that stores, processes, or transmits CUI is in assessment scope, and scope is the biggest cost driver in this work. A narrow enclave is assessable. A flat network where CUI can reach anything is not, and teams that discover this late end up rebuilding rather than re-documenting.

Logs are the most common leak. A debug statement that dumps a request body, a stack trace with parameters attached, an audit trail recording the field value rather than the field name, a prompt log from a model call. Each creates a second copy of CUI in a store governed more loosely than the database it came from, and often shipped to a vendor. Log identifiers, not payloads, and keep the logging pipeline inside the boundary.

Test and staging data. The moment someone restores a production snapshot into a development database to reproduce a bug, that environment holds CUI and joins the boundary. Synthetic fixtures and an enforced prohibition on production restores are cheaper than the alternative.

Derived stores are copies, and so are backups. A search index, a vector index, an analytics warehouse, a materialized view, a cache, a nightly report export, a cross-region replica. Each holds CUI-derived content and each needs the same protection, the same region constraints, and the same deletion path as the source. If you cannot trace a derived artifact back to its source record, you cannot honestly say you deleted anything.

Cryptography must be validated, not merely strong. SP 800-171 requirement 3.13.11 calls for FIPS-validated cryptography to protect the confidentiality of CUI. "We use AES-256" is not the same claim. What matters is the specific cryptographic module, its version, its certificate under the Cryptographic Module Validation Program, and running it in its approved mode. Check the certificate against the exact library your build pulls in.

Identity is not optional. Requirement 3.5.3 calls for multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. Shared service accounts, long-lived static API keys, and a break-glass admin login with a password in a wiki are all findings waiting to be written up.

Egress paths and retention. Webhooks, outbound email, chat integrations, and analytics beacons all move data out of the boundary; enumerate them and decide about each deliberately. And section 2002.18 covers decontrolling, so CUI status is not always permanent. Your data model should be able to represent that change.

A first-week checklist

  1. Find the clauses in the contract: DFARS 252.204-7012, 252.204-7019, 252.204-7020, 252.204-7021. Note which NIST SP 800-171 revision is named.
  2. Ask the customer or prime, in writing, exactly what information in this program is CUI and under which Registry category.
  3. Draw the data-flow diagram. Every component that touches the data, vendors included, gets a box.
  4. Draw the boundary around the smallest set of boxes that can do the job, and list what has to move out.
  5. Audit third-party services against the FedRAMP Moderate equivalency requirement, verifying status on the FedRAMP Marketplace rather than a vendor's marketing page.
  6. Grep the codebase for logging of request and response bodies, and fix what you find.
  7. Design the marking layer before the first export feature ships. Treat unmarked export paths as defects.
  8. Register in SPRS and complete the self-assessment. Someone owns the score.
  9. Obtain a DoD-approved medium assurance certificate, and name the person who holds it.
  10. Write the incident runbook with the 72-hour clock, the 90-day image preservation step, and the DC3 submission path in it. Then walk it once as a tabletop.

None of these steps is hard in isolation. What makes CUI work expensive is doing them in the wrong order, after the system exists, when every fix is a migration.

Sources: National Archives, Controlled Unclassified Information and the CUI Registry category list; 32 CFR Part 2002 §§ 2002.4, 2002.10, 2002.12, 2002.14, 2002.16, 2002.18, 2002.20, 2002.54, 2002.56; E.O. 13556 (Nov. 4, 2010); DoD Instruction 5200.48; DFARS 252.204-7012 ¶¶ (a), (b)(2)(ii)(A), (b)(2)(ii)(D), (c), (d), (e) and flow-down; DFARS 252.204-7021; DoD CIO memorandum on FedRAMP Moderate equivalency (Dec. 21, 2023); NIST SP 800-171 Rev. 2 and Rev. 3; FIPS 199; FAR 52.204-21.

Common questions

Does handling CUI require a security clearance? No. CUI is unclassified. Access under 32 CFR 2002.16 is granted to authorized holders with a lawful Government purpose, a contract-and-need determination rather than a personnel security one. Some CUI Specified categories, export-controlled information in particular, add their own access restrictions on top.

What is the difference between FCI and CUI? Federal Contract Information is non-public information generated for or provided by the government under a contract, protected by the fifteen basic safeguarding requirements in FAR 52.204-21. CUI is narrower, defined by a specific law or regulation, and on a non-federal system it is protected under NIST SP 800-171. All the CUI in a contract is also FCI; most FCI is not CUI.

Can we run CUI on a commercial cloud region? Only if that specific offering and region meets the FedRAMP Moderate baseline or the DoD equivalency standard. Authorization is granted to a named cloud service offering in a named boundary, not to a company, so a vendor holding an authorization elsewhere in its product line proves nothing about the service you are using.

Who decides whether something is CUI? The agency that owns the information, through an authorized designator, based on an authority listed in the CUI Registry. Contractors do not designate CUI. If your program is guessing, that is a question for the contracting officer, and a reasonable one to ask in writing.

What happens if CUI ends up somewhere it should not be? Treat it as a handling incident and follow the runbook. If it meets the clause definition of a cyber incident, the 72-hour clock applies. Quietly deleting the copy is the response that turns a manageable problem into a contract problem.

About Precision AI Academy

Precision AI Academy publishes plain-language tech news, practical AI guides, and free learning resources. It is a sister site of Precision Federal, a federal software and AI firm. Our guides are written for practitioners and checked against primary sources. This article is general information, not legal or compliance advice for a specific contract.