Controlled Unclassified Information (CUI) Rule: Moderate Categorization Requirement Critique

Last reviewed: November 16, 2025

Summary

This article argues that the federal Controlled Unclassified Information (CUI) rule (“CUI Rule”), which requires that all federal systems processing CUI must implement at least the moderate National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 security control baseline, deviates from the standard risk-based approach used within the federal government and often results in a misallocation of scarce security resources to low-sensitivity information away from high-sensitivity information. This is because numerous defined categories of CUI, such as the General Privacy category, have definitions that sweep non-sensitive information under the banner of CUI. It is concluded that the portion of the CUI Rule containing the moderate categorization requirement should be rescinded, returning the ability for federal agencies to make risk-based decisions — as informed (but not mandated) by the CUI Program — to appropriately secure information.

Argument

Preface: A brief overview of the CUI Rule and its moderate-categorization security requirement.

The federal Controlled Unclassified Information Program (“CUI Program”), as described in the initial Federal Register notice containing the Program’s regulatory implementation (“CUI Rule”), was created by a 2010 Executive Order to “standardize the way the executive branch handles information that requires safeguarding or dissemination controls” but is not classified national security information.1 The purpose for this was simplification: as the Federal Register notice observes, prior to the CUI Program, “more than 100 different markings for such information existed across the executive branch.”2

Included in the CUI Rule (as codified in the Code of Federal Regulations) is section 32 CFR 2002.14(g), the focus of this article. This section states, in relevant part:

In accordance with FIPS PUB 199 (incorporated by reference, see § 2002.2), CUI Basic is categorized at no less than the moderate confidentiality impact level.

The section above states that “CUI Basic” must be categorized at no less than the moderate confidentiality impact level. CUI Basic is defined in the same Code of Federal Regulations (CFR) part as “the subset of CUI for which the authorizing law, regulation, or Government-wide policy does not set out specific handling or dissemination controls.” This is in contrast to “CUI Specified,” which is CUI that has requirements outside of the CUI Rule (e.g., via law or other regulation) that requires distinct handling methods.

The implication of the above is that federal information systems that process, store, or transmit (henceforth “process”) any data that can be labelled as CUI Basic must implement the NIST SP 800-53 moderate security control baseline.3 This is because by categorizing the confidentiality impact level at moderate, the overall system categorization becomes moderate. And, per mandatory NIST guidance, federal systems categorized at the overall moderate-impact level must implement the moderate security control baseline.4

While this is not an issue for systems already categorized overall at the moderate- or high-impact level, it is a significant change for systems otherwise categorized as low-impact that implement only the low security control baseline. The table below lists the number of controls in each security control baseline individually (low, moderate, and high).5

Security Impact Level (Overall)Controls in Baseline
Low149
Moderate287
High370

As shown above, a federal information system that is categorized as low-impact but is required to be recategorized as moderate-impact must implement an additional 138 controls — nearly as many as the low baseline itself. Thus, the CUI Rule requires federal systems categorized as low but found to contain any information falling into a CUI category upgrade to the moderate security control baseline. While the CUI Rule contains verbiage indicating that “risk-based tailoring decisions” can be made, it is clear from the context and all subsequent guidance that the intent of the CUI Rule is to require any federal system processing CUI to adhere to at least the moderate security control baseline.6

Many public comments to the CUI Rule were skeptical of the moderate-baseline requirement. The requirement was ultimately retained.

Given the CUI Rule requires systems containing CUI Basic to be categorized at the moderate-impact level, and given that the moderate-impact level imposes a near-double NIST control burden for federal systems, it should be asked whether this is an appropriate application of risk-based security.

When the public comment period was opened for the initial draft of the CUI Rule, some commenters wondered the same. For example, one comment from the MITRE Corporation states:

Taking a “straight line” approach to categorizing all CUI as moderate is counter to the risk-based approach agencies should be taking to protect their information. […] NIST SP 800-122 [NIST’s guidance on protecting Personally Identifiable Information (PII)] provides guidance for how to determine the confidentiality impact level for PII, and in many cases systems containing PII with a low confidentiality risk where protecting them at a moderate confidentiality level would extend well beyond what is required.

Another commenter provides a similar observation, noting that a truly risk-based approach would imply the CUI Rule’s always-moderate requirement is too broad:

[W]e suggest that the regulation not specify the “Moderate Confidentiality” level when agencies design systems to be “consistent” with NIST standards as specified in the Executive Order. The published NIST standards require a risk management approach to protecting information systems. Given the serious data losses from USG [United States Government] systems due to hacking, it is more appropriate to have agencies determine the risk depending on the amount of and sensitivity of the specific information rather than trying to promulgate a “one-size-fits-all” standard.

As required under the Administrative Procedure Act, the authors of the CUI Rule responded to the above comments by reaffirming their belief that the moderate-categorization requirement was appropriate:

The purpose of the CUI Program is to provide a uniform and consistent system for protecting CUI throughout the executive branch. The baseline standard for protecting CUI Basic is moderate confidentiality. Given the need to protect CUI, a baseline of moderate confidentiality makes sense, because such protection is greater than low, the minimum requirement for all systems under the FISMA.

Further responding to such concerns in a CUI Program Blog post on October 31, 2017 — around a year after the CUI Rule was formally finalized — the CUI Rule’s moderate-categorization requirement was again emphasized as the right choice, noting that “arguing for changing the moderate confidentiality baseline level for CUI” is “clearly on the wrong side of history”:

In an age of weekly breaches, anyone arguing for changing the moderate confidentiality baseline level for CUI and reducing these information systems protections is clearly on the wrong side of history. The effects of the largest Government breach of CUI in history – the OPM data breach – continue to cost the taxpayer hundreds of millions of dollars – and some of its costs can never be quantified including the exploitation of the information for its intelligence value and the effects on the Government’s reputation for safeguarding any information.

It is true that the Office of Personnel Management (OPM) data breach was a significant, costly security failing.7 But a reference to the OPM’s security failure does not address the ultimate issue brought up by those who believe the CUI Rule is flawed: the breaking away of the federal government’s traditional risk-based security program to a one-size-fits-all approach that frequently allocates scarce security resources to low-importance data while sapping the same resources from data requiring heightened security.

The CUI Rule’s moderate-categorization requirement often takes scarce security resources away from high-sensitivity data and allocates them to low-sensitivity data.

The simplest way to show the error of the CUI Rule’s moderate-baseline requirement is by way of reviewing a specific category of CUI: privacy data. The National Archives and Records Administration (NARA), the agency administering the CUI Program, maintains a webpage called the CUI Registry that lists the different types of data considered CUI for purposes of the CUI Rule. Privacy data is in the General Privacy category of CUI.

On the CUI Registry, General Privacy data is defined as follows:

[General Privacy CUI] refers to personal information, or, in some cases, “personally identifiable information,” as defined in OMB M-17-12, or “means of identification” as defined in 18 USC 1028(d)(7).

To determine what information falls into the General Privacy category, we must first review the two referenced sources: an Office of Management and Budget (OMB) memorandum and a statutory source.

In the OMB memorandum source, M-17-12, personally identifiable information is defined as:

[I]nformation that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual. Because there are many different types of information that can be used to distinguish or trace an individual’s identity, the term PII is necessarily broad.

In the statutory source, 18 U.S.C. 1028(d)(7), a more exampled list of privacy data is provided:

The term “means of identification” means any name or number that may be used, alone or in conjunction with any other information, to define a specific individual, including any (A) name, social security number, date of birth, official State or government issued driver’s license or identification number, alien registration number, government passport number, employer or taxpayer identification number; (B) unique biometric data, such as fingerprint, voice print, retina or iris image, or other unique physical representation; (C) unique electronic identification number, address, or routing code; or (D) telecommunication identifying information or access device (as defined in section 1029(e))

Taking both sources together, anything that identifies an individual — directly or as combined with other information — is considered General Privacy information.

But this clearly covers large swaths of data that few would consider sensitive, let alone data that requires a doubling of security controls on the side of federal security practitioners. Nearly every federal system, including those that would be broadly agreed to need a low amount of security mechanisms, has some sort of “General Privacy”-type data. For example, consider if the White House’s Briefings & Statements webpage were treated as a federal information system. This webpage clearly contains data that identifies individuals: names. Does the page providing the Presidential Message on the Birthday of President Theodore Roosevelt require additional security controls because it has an identifying name in the title? The General Privacy category of CUI does not take into account the fact that information can definitionally fall under its umbrella but still not be sensitive. And if this example seems trivial, the fact that the CUI Rule contains no accounting for such a trivial issue should raise an alarm.

Here, context matters. If a list of names and email addresses are attached to a federal mailing list for some kind of health care research updates relevant only to those with a certain disease, then it is plausible that the names and email addresses could constitute sensitive privacy data, even if the information emailed out is not intrinsically sensitive (i.e., the association itself implies the sensitivity). On the other hand, a National Park’s trash bin filled with the receipts of attendees, with each receipt listing attendee names and whether they received a military discount, may or may not qualify as sensitive. In either example, the CUI Rule and its broad-strokes categories currently do not allow for such a risk-based analysis.

Conclusion: The CUI Rule’s moderate-categorization requirement should be rescinded and replaced with a statement that federal systems processing CUI should be categorized based on current federal guidance on risk-based security.

The CUI Rule’s moderate-categorization requirement stems from good intentions. Unclassified information that is still sensitive enough to require heightened control should be secured more than information that is not sensitive. However, the federal government addressed this in the 2000s with the NIST guidance on security categorization.8 This framework takes into account the sensitivity of information and allows for risk-based decision making when determining the level of security information should receive.

The CUI Registry’s near-exhaustive list of types of information that require heightened controls provides a good way for the federal government to recognize information that may fit that bill.9 But it’s not always the case that information meeting one of the CUI category definitions will be sensitive.

To treat non-sensitive data as significant enough to require a near-doubling of the security controls implemented to protect such data is a choice that misallocates limited federal security resources and siphons off such resources from information and federal systems whose security is more important. Accordingly, the CUI Rule’s moderate-categorization requirement should be rescinded, restoring the standard risk-based approach to federal information security already provided in federal guidance.

  1. More specifically, the CUI Program does not apply to “sensitive information […] that does not qualify as classified under Executive Order 13526, Classified National Security Information, […] or the Atomic Energy Act[.]” See the Proposed Rule. ↩︎
  2. The General Services Administration (GSA) CUI Program Guide gives the following examples of markings that the CUI Program was intended to replace: Sensitive But Unclassified (SBU), For Official Use Only (FOUO), and Personally Identifiable Information (PII), the last of which is to be considered a subset of CUI. ↩︎
  3. Starting with Revision 5 of NIST SP 800-53, the document containing the control baselines has been split into its own document, SP 800-53B. For simplicity, “800-53” in this article will be used to refer to both documents. ↩︎
  4. While agencies have latitude to “tailor” a baseline, there is a presumption all controls be implemented absent justification. For example, see OMB Circular A-130, Appendix I – 18 (“Security Control Baselines”); also see Federal Information Processing Standards Publication 200 (FIPS 200) (the mandatory guidance requiring the implementation of baselines based on a system’s security categorization). ↩︎
  5. There similarly exists a privacy control baseline, which contains 96 controls (many overlapping with the three security control baselines). For simplicity, this is not discussed. ↩︎
  6. This can be seen in more examples than the ones included in the body of this article. For example, on NIST’s Protecting Controlled Unclassified Information FAQs page, there is a recognition that the National Archives and Records Administration (NARA) and NIST both “[a]sserted the full moderate impact baseline [be] required for protection of CUI,” which eventually resulted in NIST creating a separate baseline, based on the NIST SP 800-53 moderate security control baseline (with controls removed that are either federal-specific or not related to confidentiality protection) for non-federal CUI-processing systems in NIST SP 800-171. ↩︎
  7. Also see the Wikipedia page regarding the OPM data breach. ↩︎
  8. See Federal Information Processing Standards Publication 200 (FIPS 200). ↩︎
  9. In fact, NIST has guidance serving a similar function in NIST SP 800-60 Volume 2. Similar to the CUI Program’s CUI Categories, this NIST document contains a collection of various “information types” and provides assumed security impact levels (low, moderate, or high) for each. ↩︎