Module 3: Controlled Unclassified Information (CUI) Basics

Step 1 – Why CUI Exists in the First Place

In earlier modules, you saw two big buckets of federal information:

• Classified (Confidential / Secret / Top Secret)
• Unclassified (everything else)

For decades, agencies invented their own labels for sensitive but unclassified information: FOUO, SBU, LES, SSI, OUO, and many more. This caused problems:

• IT systems had to guess what each label meant
• Contractors saw different rules from different agencies
• Inconsistent protection led to both over‑protection (slowing work) and under‑protection (data leaks)

To fix this, the US government created Controlled Unclassified Information (CUI) as a single, standardized category for sensitive but unclassified information.

Key milestones (relative to today – December 2025):

• 2010 – Executive Order 13556 established the CUI Program
• 2016 – NARA (National Archives and Records Administration) issued implementing rule 32 CFR Part 2002, which still governs CUI today
• 2016–2025 – Agencies gradually implement CUI policies; CUI is now the standard term across the federal government and major contractors

Big idea: CUI is unclassified, but not just regular unclassified. It’s unclassified information that must be safeguarded or disseminated with controls because of laws, regulations, or government‑wide policies.

Step 2 – Formal Definition of CUI (32 CFR Part 2002)

Under 32 CFR Part 2002, CUI is:

> Information that 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 using safeguarding or dissemination controls.

Breakdown in simpler terms:

1. Who’s information?

• Created/owned by the US federal government, or
• Held by non‑federal entities (like contractors, universities, state/local governments) for or on behalf of the federal government

1. Why is it controlled?

• Because specific legal authorities require or allow special handling.
• Examples of such authorities:
• Privacy Act of 1974 – personal data in federal systems
• HIPAA (when applicable to federal programs) – health information
• Export control laws – e.g., ITAR, EAR
• Critical infrastructure protection rules

1. What kind of controls?

• Safeguarding controls – e.g., access limits, encryption
• Dissemination controls – e.g., No Foreign (NOFORN), Law Enforcement Sensitive (LES) (now mapped into CUI categories)

For IT and cybersecurity work, the key takeaway is:

> If a law, regulation, or government‑wide policy says “protect this kind of information”, that information is probably CUI, not just generic unclassified.

Step 3 – CUI vs Classified vs "Just Unclassified"

You now have three main buckets to keep straight:

1. Classified Information

• Defined by Executive Order 13526 (and related guidance)
• Levels: Confidential, Secret, Top Secret
• Damage test: unauthorized disclosure could cause damage (up to exceptionally grave damage) to national security
• Requires security clearances, secure facilities, and specialized systems (e.g., SIPRNet, JWICS)

2. Controlled Unclassified Information (CUI)

• Unclassified (does not meet the national security damage test)
• But still sensitive and protected by law/regulation/policy
• Governed by 32 CFR Part 2002 and NARA’s CUI Registry
• Requires specific safeguards (e.g., NIST SP 800‑171 controls on non‑federal systems)

3. General Unclassified / Public / Non‑CUI

• No special legal or policy requirement to restrict access
• Often public or low‑risk internal information
• Still may need basic protection (e.g., to keep systems running), but not CUI

You can visualize it as three nested circles:

• Outer circle – All unclassified info
• Inside that, a smaller circle – CUI (unclassified but controlled)
• Separate from both: a different circle – Classified (governed by national security rules)

Why this matters for IT service design:

• Systems handling classified info must meet very strict national security standards
• Systems handling CUI must meet moderate‑level protections (we’ll tie this to FIPS 199 soon)
• Systems handling only non‑CUI unclassified can often use lighter controls

Correctly identifying which bucket your data belongs to is the first design decision for any federal‑facing IT service.

Step 4 – Concrete Examples: Which Bucket?

Read each scenario and see how it maps to Classified / CUI / Non‑CUI Unclassified.

1. Troop movement plans for an overseas operation

• Likely Classified (Secret or Top Secret)
• Reason: Unauthorized disclosure could harm national security

1. Names and Social Security Numbers of federal employees stored in an HR system

• CUI (typically under the CUI//Privacy category)
• Reason: Privacy laws (e.g., Privacy Act) require protection

1. Technical drawings of a controlled military component subject to ITAR

• CUI (e.g., CUI//Export Control)
• Reason: Export control laws require strict handling and limit foreign access

1. Public press release on a new government grant program

• Non‑CUI Unclassified (public information)
• Reason: Intended for public distribution

1. Detailed vulnerabilities of a federal power grid monitoring system

• Often CUI (e.g., CUI//Critical Infrastructure or CUI//Controlled Technical Info depending on context)
• Reason: Specific laws/policies on critical infrastructure security

1. Internal agency lunch menu posted on the intranet

• Non‑CUI Unclassified (low sensitivity)

As an IT provider, you don’t just ask “Is it classified?” – you ask:

> Is it CUI, and if so, which CUI category (and which authority) applies?

Step 5 – CUI Categories and the CUI Registry

The CUI Registry is the official catalog of CUI. It is maintained by NARA’s Information Security Oversight Office (ISOO) and is current as of today (late 2025).

You can explore it at: https://www.archives.gov/cui (check the CUI Registry section).

What the CUI Registry provides

For each CUI category, the Registry lists:

• Category name and marking (e.g., CUI//Privacy, CUI//Export Control)
• Description of what fits in the category
• Authorizing laws, regulations, or government‑wide policies (e.g., specific US Code sections)
• Handling and dissemination requirements
• Whether it is Basic CUI or Specified CUI

Basic vs Specified CUI

• CUI Basic
• Only the general CUI requirements apply
• Still must be protected, but no extra category‑specific rules beyond the CUI Program

• CUI Specified
• A law, regulation, or government‑wide policy adds more specific or stricter controls
• Example: Export controlled technical data may restrict foreign nationals more tightly than generic CUI

For IT design, the CUI Registry is like a requirements map:

> Data type → CUI category → legal authority → handling rules → system/security requirements.

You don’t have to memorize all categories; you need to know where to look and how to interpret what you find.

Step 6 – Thought Exercise: Reading the CUI Registry

Imagine you’re designing a cloud service for a federal agency that will store:

• Medical records of veterans in a pilot program
• Contact info and health history
• Some data will be shared with approved research partners

Task: Without looking it up right now, answer these questions in your own words:

1. Which broad CUI categories are likely involved?

(Hint: think privacy and health.)

1. What kinds of laws or regulations might appear in the CUI Registry entry for those categories?

1. For your IT design, list three things you would want to know from the CUI Registry before finalizing your architecture.

Write down brief answers. Then compare with this sample reasoning:

• Likely categories: CUI//Privacy, possibly CUI//Health Information (depending on how the agency maps it)
• Likely authorities: Privacy Act, possibly HIPAA or VA‑specific health data rules
• You’d want to know:
• Whether the category is Basic or Specified
• Any foreign access restrictions (e.g., no foreign nationals on support team)
• Any special transmission or storage requirements (e.g., encryption, US‑only data centers)

This is exactly how professionals use the CUI Registry when scoping a new system.

Step 7 – Minimum Confidentiality Impact: FIPS 199 Moderate

For CUI, the federal government standardized not just the label, but also the minimum security impact level.

FIPS 199 (Federal Information Processing Standard 199) defines security impact levels for:

• Confidentiality – protection from unauthorized disclosure
• Integrity – protection from unauthorized modification
• Availability – protection from disruption

Each can be Low, Moderate, or High impact.

For CUI, the CUI Program and related guidance (including NIST SP 800‑171 and 32 CFR Part 2002) effectively treat Confidentiality as at least Moderate impact:

• Minimum confidentiality impact level for CUI: _Moderate_

What this means in practice:

• A breach of CUI is assumed to have serious adverse effects on operations, individuals, or assets
• Systems handling CUI (especially on non‑federal systems, like contractor networks or commercial clouds) must implement controls aligned with Moderate confidentiality
• This is why NIST SP 800‑171 (Protecting CUI in Nonfederal Systems and Organizations) is built around a moderate‑level baseline of security controls

For IT service providers, a quick rule of thumb:

> If your system processes or stores CUI, plan for Moderate confidentiality controls at a minimum, even if integrity and availability might be Low or Moderate.

This affects choices like:

• Encryption (at rest and in transit)
• Identity and access management
• Incident response and logging
• Physical and personnel security assumptions

Step 8 – Designing a System for CUI vs Non‑CUI

Consider two SaaS products you might offer to a federal agency:

Product A – Public Information Portal

• Hosts public laws, regulations, press releases, FAQs
• No login required for most content
• No sensitive personal data

Likely data type: Non‑CUI unclassified

Design implications:

• Basic web security (TLS, patching, WAF) is important
• FIPS 199 might rate Confidentiality = Low, Integrity = Moderate, Availability = Moderate/High
• No need to implement the full NIST SP 800‑171 CUI control set

---

Product B – Secure Grant Application System

• Applicants submit:
• SSNs, bank info, contact info
• Proprietary research proposals
• Used by a federal science agency to award grants

Likely data type: CUI (privacy + possibly proprietary business information)

Design implications:

• Treat Confidentiality as at least Moderate
• Implement controls comparable to NIST SP 800‑171 (or 800‑53 Moderate in federal environments)
• Strong identity and access management, role‑based access, detailed audit logging
• Encryption of data at rest and in transit
• Documented incident response and breach notification procedures

Both systems are unclassified, but only one handles CUI. That difference drives very different security expectations, contracts, and compliance checks.

Step 9 – Quick Knowledge Check

Answer this question to check your understanding of CUI basics.

Step 10 – Flashcard Review: Core CUI Concepts

Use these flashcards to reinforce key terms before moving on.