Step 1 Goal: Identify CUI (without guessing)
Executive Order 13556 establishes a government-wide program for managing unclassified information that requires safeguarding or dissemination controls under law, regulation, or Government-wide policy. Importantly, the Order excludes both classified information under Executive Order 13526 and information protected under the Atomic Energy Act. The goal of Step 1 is not to label information broadly as “sensitive,” but to identify Controlled Unclassified Information (CUI) based on an explicit legal or policy authority and document that determination. This distinction matters because only information that meets the CUI definition triggers CUI handling and, for nonfederal systems, NIST SP 800-171 safeguarding requirements.
Why the CUI Registry matters: The “exclusive designation” concept
Executive Order 13556 introduces a critical concept for identifying CUI: exclusive designation. Under the Order, only categories and subcategories approved through the CUI program may be used to identify unclassified information that requires safeguarding or dissemination controls across the executive branch.
The regulation further describes the CUI Registry as the publicly accessible and authoritative repository for CUI guidance, other than the Order itself and 32 CFR Part 2002. The Registry provides:
- approved CUI categories and subcategories
- citations to the underlying legal or policy authorities
- marking guidance and handling notes
In practice, this means organizations should not invent internal CUI labels or rely on legacy terms alone. To properly identify CUI, information must map to a Registry category or subcategory with a documented basis.
CUI Basic vs CUI Specified (the compliance fork in the road)
Once information is mapped to the CUI Registry, the next determination is whether it is CUI Basic or CUI Specified. This distinction directly affects handling requirements.
CUI Basic is the subset of CUI for which the authorizing law, regulation, or Government-wide policy does not impose any specific handling or dissemination requirements. In these cases, CUI is handled according to the uniform requirements set forth in 32 CFR Part 2002 and the guidance provided in the CUI Registry.
CUI Specified, by contrast, applies when the authorizing law, regulation, or Government-wide policy includes explicit handling, dissemination, or protection requirements that differ from those applicable to CUI Basic. The CUI Registry identifies which categories are subject to these authority-specific requirements and points to the controlling citations.
CUI Specified is not a higher “level” of CUI. It is simply different.
The controls associated with CUI Specified may be more stringent than those for CUI Basic, or they may just be different in form or application. Because CUI Specified requirements are grounded in law, regulation, or Government-wide policy, they cannot be ignored or treated as optional.
This distinction matters in practice. Treating CUI Specified as if it were CUI Basic can result in under-protection and compliance exposure, while assuming all CUI is Specified can create unnecessary operational burden. Correctly identifying which type applies is a key step in building a defensible CUI compliance program.
Step 1 checklist: prove it’s CUI
A defensible CUI identification process should be repeatable, evidence-based, and documented. At a minimum, Step 1 should include the following actions:
- Confirm the information is unclassified and not excluded by statute, such as classified national security information or Atomic Energy Act data.
- Identify the law, regulation, or Government-wide policy that requires or permits safeguarding or dissemination controls for the information.
- Map the information to the appropriate CUI Registry category or subcategory, including the cited authority.
- Determine whether the Registry designates the information as CUI Basic or CUI Specified, based on whether the authorizing authority includes specific controls.
- If you are a non-executive branch organization, recognize that 32 CFR Part 2002 applies indirectly through contracts, agreements, or other binding instruments.
The output of this step should not just be a label, but a recorded rationale that explains why the information qualifies as CUI and how it was categorized.
Why Step 1 sets the tone for the rest of CUI compliance
Organizations that struggle with CUI compliance often discover that the root cause traces back to Step 1. Misidentifying information as CUI, or failing to identify it at all, leads to confusion around marking, scope, system boundaries, and security controls later in the lifecycle.
By taking the time to correctly identify CUI and map it to the CUI Registry, organizations establish a foundation that supports accurate scoping, appropriate safeguards, and defensible audit outcomes.
Up next: Step 2: inventory CUI and define the system boundary
The next entry in the series is Post 3, Step 2: inventory your CUI and define the system boundary. Once you know what information is CUI, the next challenge is determining where it actually lives and which systems and processes fall within scope.
About RegDOX
At RegDOX Solutions Inc., we help defense contractors and high-security organizations simplify compliance with ITAR, EAR, DFARS, and CMMC requirements. Our secure, cloud-based platforms combine end-to-end encryption, access controls, and audit-ready documentation to keep your data—and your contracts—safe.
Need help navigating evolving cybersecurity regulations?
Request a Compliance Demo
Or contact us directly at info@regdox.com
See the enclave in action.
The Compliant Computing Enclave keeps CUI inside one boundary, with your endpoints out of scope and the evidence trail already built.
Talk to an Expert →