CUI Guide: CUI Basic vs CUI Specified, Marking and Handling

Controlled Unclassified Information (CUI) is sensitive US government information that is not classified but still must be protected, and the common mistakes come from not knowing which data is CUI, whether it is Basic or Specified, or which rules follow it into contractor systems. The CUI Program replaced dozens of agency-specific labels such as FOUO and SBU with one framework set by 32 CFR Part 2002 and the NARA CUI Registry. This guide explains CUI Basic versus CUI Specified, categories, banner and portion marking, limited dissemination controls, safeguarding, decontrol and incident handling, and how NIST SP 800-171 and CMMC apply to contractors as of October 2026. It is written for security, compliance and IT teams in federal agencies, defence contractors, universities and suppliers that receive CUI under contract.

Key takeaways

• CUI Basic and CUI Specified differ in where the rules come from. Basic follows the uniform controls in 32 CFR 2002; Specified follows extra or different controls written into the underlying law, regulation or policy, and must be named in the banner with an "SP-" marking.
• The authority decides, not the category. The same Registry category can be Basic under one authority and Specified under another: Export Controlled information is "CUI" under some authorities and "CUI//SP-EXPT" under others.
• Marking has a fixed grammar. Banner at the top of each page (CUI or CONTROLLED, then categories and dissemination controls separated by double slashes), a designation indicator on every document, and portion marks where used. Legacy markings like FOUO are void.
• Non-federal systems protect CUI with NIST SP 800-171. 32 CFR 2002 sets CUI Basic at no less than moderate confidentiality and points to SP 800-171. NIST has published Rev. 3, but CMMC still assesses DoD contractors against Rev. 2's 110 requirements.
• Scope is the biggest cost lever. An enclave that keeps CUI in a small, well-controlled set of systems, users and service accounts is far cheaper to protect and assess than an enterprise-wide boundary.

What CUI is, and what it is not

32 CFR 2002.4 defines CUI as information the government creates or possesses, or that an entity creates or possesses for the government, that a law, regulation or government-wide policy "requires or permits an agency to handle using safeguarding or dissemination controls". It states plainly that "CUI does not include classified information". The National Archives and Records Administration (NARA) is the CUI Executive Agent, and has delegated that role to the Director of the Information Security Oversight Office (ISOO). The CUI Registry is "the authoritative central repository" for categories, markings and guidance.

The Registry lists categories alphabetically within 20 organisational index groupings: Critical Infrastructure, Defense, Export Control, Financial, Immigration, Intelligence, International Agreements, Law Enforcement, Legal, Natural and Cultural Resources, NATO, Nuclear, Patent, Privacy, Procurement and Acquisition, Proprietary Business Information, Provisional, Statistical, Tax and Transportation. Each category page lists the authorities behind it and whether each authority makes it Basic or Specified.

CUI provided or generated under a federal contract generally also meets the FCI definition, but most FCI is not CUI. If a contract only involves FCI, the 15 FAR requirements apply; once CUI arrives, the SP 800-171 baseline applies to the systems that touch it.

CUI Basic vs CUI Specified

The difference is in the authority behind the information. 32 CFR 2002.4 defines CUI Basic as the subset where the authority "does not set out specific handling or dissemination controls", so the uniform controls in Part 2002 and the Registry apply. CUI Specified is the subset where the authority "contains specific handling controls that it requires or permits agencies to use". Those controls may be stricter than Basic or simply different, and Basic controls still apply to anything the specified authority does not address.

In practice, "Specified" does not automatically mean "more sensitive". It means "read the authority". Controlled Technical Information, for example, must also carry one of DoD distribution statements B to F under DoD Instruction 5230.24, which is a requirement Basic marking alone would not capture.

Marking CUI

32 CFR 2002.20 and ISOO's marking training set a consistent structure. Agencies must "discontinue all use of legacy or other markings", and where legacy markings remain on old documents, "the legacy markings are void". NARA's FAQ confirms FOUO and SBU "will no longer be used".

• Email: ISOO training treats the banner as mandatory, a subject-line indicator as best practice, requires the banner to carry forward when forwarded, and says email containing CUI must be encrypted.
• Contractors: agencies "are responsible for marking or identifying any CUI shared with non-federal entities", and NARA says contractors "should not follow CUI program requirements or markings until directed" by contract. Ask the contracting officer to identify CUI in the contract.
• Over-marking is misuse: 32 CFR 2002.4 includes "designating or marking information as CUI when it does not qualify" in its definition of misuse.

Dissemination and limited dissemination controls

An authorised holder may share CUI when doing so furthers a "lawful Government purpose", defined broadly as any activity "that the U.S. Government authorizes or recognizes". Agencies "should enter into written agreements or arrangements that include CUI provisions whenever feasible" with outside partners; contracts, grants, licences and memoranda of understanding all count. Agencies may narrow dissemination only through limited dissemination controls (LDCs), and "only the designating agency may apply" them.

For security teams, LDCs translate directly into access rules: NOFORN and REL TO need citizenship or nationality attributes on user accounts, and NOCON means contractor accounts must be excluded from the repository.

Safeguarding and handling

• Controlled environments: authorised holders "must take reasonable precautions" and establish controlled environments, meaning areas with "adequate physical or procedural controls" against unauthorised access. In practice: locked storage or offices, no CUI on screens in public spaces, clean desk for printed material.
• Federal systems: CUI Basic is "categorized at no less than the moderate confidentiality impact level", so agency systems apply the SP 800-53 moderate baseline.
• Non-federal systems: SP 800-171 "defines the requirements necessary to protect CUI Basic on non-Federal information systems". Rev. 3 (May 2024) has 97 requirements in 17 families numbered 03.XX.YY (for example 03.13.11 Cryptographic Protection), with organisation-defined parameters that agencies or the organisation must set.
• Cloud: under DFARS 252.204-7012, a cloud provider holding covered defence information must meet requirements equivalent to the FedRAMP Moderate baseline and support incident reporting, malware submission and media preservation. Outside DoD, check the agency's contract terms.
• Transmission: encrypt CUI in email, file transfer and on removable media. SP 800-171 Rev. 2 requirement 3.13.11 calls for FIPS-validated cryptography to protect CUI confidentiality; Rev. 3 makes the cryptography type an organisation-defined parameter.
• Destruction: CUI must be made "unreadable, indecipherable, and irrecoverable", using methods in SP 800-53 or SP 800-88 media sanitisation guidance.

Enclave or enterprise?

• Enclave: a separate tenant, VDI or segmented network holding CUI for a limited user group. Best for organisations where CUI is a small fraction of work (many universities, commercial firms with one defence programme). Scope, cost and assessment effort fall sharply, but users must be disciplined about not copying CUI out.
• Enterprise-wide: applying SP 800-171 everywhere suits defence-focused companies where CUI flows through engineering, email and collaboration daily. Simpler for users, more expensive to assess.
• Small organisations: a government-community cloud offering with documented FedRAMP Moderate equivalence, plus managed endpoints, is usually more achievable than building controls on-premises.
• Scoping vocabulary: 32 CFR 170 sorts assets into CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets and Out-of-Scope Assets. Security tooling that protects the enclave (identity provider, SIEM, EDR) is in scope even if it never stores CUI.

NIST SP 800-171 and CMMC: what applies in October 2026

CMMC Phase 1 began on 10 November 2025. According to the DoD CIO CMMC page, Phase II, due on 10 November 2026, was suspended on 13 July 2026 and a reform task force established; the programme "is paused in Phase 1 and may only require self-assessments at two levels", enforcement continues through self-assessments and "select government-led assessments", and the suspension "does not eliminate the requirement" to meet DFARS 252.204-7012. Practically, contractors should keep SPRS scores accurate, close POA&Ms, and build to Rev. 2 for DoD work while mapping to Rev. 3, which agencies outside DoD may adopt first.

Decontrol, incidents and training

• Decontrol: agencies "should decontrol as soon as practicable" information that no longer needs protection. Decontrol does not authorise public release, and "unauthorized disclosure of CUI does not constitute decontrol". Markings can be removed once information is decontrolled.
• Incidents and misuse: each agency's CUI senior agency official sets processes for reporting and investigating misuse; NARA reports findings back to the agency. Contractors follow their contract: for DoD, the 72-hour DFARS clock.
• Spillage: CUI placed on a system or sent to people not authorised for it (an unencrypted personal mailbox, a public repository, a non-enclave tenant) should be handled as an incident: contain, identify all copies, sanitise, and report through the agency or contract channel.
• Training: agency staff must be trained when they start and "at least once every two years thereafter". Contractors should mirror this cadence for anyone with enclave access, and include marking, LDCs and spillage reporting.

Where identity fits

CUI rules are written around the "authorised holder", which in a system means an account. Most SP 800-171 effort lands in access control and identification and authentication.

• Authorised holders as attributes: LDCs and export rules need citizenship, employer and contract attributes on identities so access policies can enforce NOFORN, FEDCON or NOCON. See the Public Sector Identity Security Guide.
• MFA and privileged access: SP 800-171 requires multi-factor authentication for access to systems handling CUI; prefer phishing-resistant methods for administrators. See the MFA Guide.
• Non-human identities in the boundary: backup jobs, sync connectors, CI/CD pipelines and AI tools that read CUI repositories are in scope and need owners, least privilege and rotated credentials. See the Service Account Security Guide.
• Contractor credentials: the CISA Private-CISA GitHub leak showed how a contractor's public repository exposed AWS GovCloud administrator keys for six months. Supplier accounts and keys that reach government environments need the same controls as staff. See the Third-Party Access Guide.

How to implement a CUI programme

1. Identify CUI by contract: collect every contract, grant and agreement; ask contracting officers which information is CUI and which categories and LDCs apply. Record Basic or Specified for each, by authority.
2. Map data flows: where CUI arrives (email, portals, removable media), where it is stored and processed, who and what touches it, including service accounts and integrations.
3. Decide the boundary: enclave or enterprise, and document assets using the 32 CFR 170 asset categories.
4. Write the system security plan: implement and document SP 800-171 requirements (Rev. 2 for DoD assessments), score yourself and record gaps in POA&Ms with dates.
5. Pilot marking and handling: roll out templates, email banners and sensitivity labels to one programme team; check that labels drive encryption and block external sharing, and that mislabelled content can be corrected without losing audit history.
6. Enforce in stages: run data loss prevention rules for CUI markings in audit mode first, review matches for false positives, then block. Keep the audit-only policy available to revert to if business flows break.
7. Train and test: train users before granting enclave access, run a spillage exercise, and test the 72-hour reporting path end to end, including the medium assurance certificate.
8. Assess and affirm: perform the self-assessment, enter results in SPRS where required, and set a calendar for annual affirmation and three-yearly reassessment.

Detection and measurement

Log and review: access to CUI repositories by user and service account, sharing and download events, DLP matches on CUI banners, failed access attempts against LDC-restricted locations, changes to enclave group membership, and privileged activity in the boundary.

• Coverage: percentage of contracts with CUI identified and categorised (target 100%).
• Marking quality: sample error rate in CUI documents (missing designation indicator, missing SP- category, legacy FOUO).
• Spillage: number of CUI spills per quarter and median time to contain.
• Access hygiene: share of enclave accounts, human and non-human, reviewed in the last 90 days.
• Training: percentage of enclave users with CUI training in the last two years.
• Compliance: open POA&M items and their age against the 180-day CMMC window.

Common failure patterns

• Treating every SP- category as top sensitivity, or ignoring it: both miss the point. Read the authority and apply its specific rules, such as export licensing or distribution statements.
• Waiting for markings that never come: legacy documents and unmarked deliverables still contain CUI. Ask the contracting officer and record the answer.
• Boundary drift: CUI copied from the enclave into general email, chat or personal cloud storage silently expands scope and creates spillage.
• Forgetting service accounts and tools: identity providers, backup services and integrations with access to CUI are in scope but often missing from the system security plan.
• Over-marking: labelling everything CUI to be safe is itself misuse under 32 CFR 2002 and makes sharing harder for no security gain.
• Exposed contractor keys: cloud credentials for government or CUI environments committed to code repositories, as in the CISA GitHub leak above.

Framework mapping

Practitioner checklist

• List every contract or agreement that involves CUI, with categories, Basic or Specified status by authority, and any LDCs.
• Look up each category in the CUI Registry and record the specific handling rules for every SP- category.
• Publish marking templates with banner, designation indicator and portion marks, and retire FOUO and other legacy labels.
• Choose an enclave or enterprise boundary and document every asset, including identity, security and integration services.
• Implement SP 800-171 (Rev. 2 for DoD assessments), keep the system security plan and POA&Ms current, and map to Rev. 3.
• Confirm cloud services holding DoD CUI meet FedRAMP Moderate equivalence under DFARS 252.204-7012.
• Enforce LDCs through identity attributes and access policies, and require MFA for every account in scope.
• Test the 72-hour incident reporting path, including the medium assurance certificate, and run a spillage drill.
• Train enclave users before access and at least every two years.

Standards and references

• eCFR: 32 CFR Part 2002 Controlled Unclassified Information
• NARA: CUI Registry category list
• NARA: CUI Registry limited dissemination controls
• NARA: CUI frequently asked questions
• NIST: SP 800-171 Rev. 3 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
• DoD CIO: About CMMC
• Acquisition.gov: DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting
• Acquisition.gov: FAR 52.204-21 Basic Safeguarding of Covered Contractor Information Systems

Related NHI Mgmt Group resources: Public Sector Identity Security Guide · Identity Security Regulatory Map · Third-Party Access Guide · Service Account Security Guide. This guide summarises 32 CFR Part 2002, the CUI Registry, NIST SP 800-171 and the CMMC programme as of October 2026 and is not legal advice.