If you're a federal contractor or subcontractor, you've heard the term CUI—Controlled Unclassified Information. You've probably seen the orange boxes and bars on documents, sat through training slides about marking requirements, and wondered whether your company is handling it correctly. The truth is, most contractors struggle with CUI not because the regulations are impossibly complex, but because they treat it as a compliance checkbox rather than the operational foundation it actually is.

CUI controlled unclassified information isn't just another acronym in the alphabet soup of federal contracting. It's the entire reason CMMC exists. It's what NIST 800-171 was written to protect. And if you can't identify what CUI you have, where it lives, and who touches it, every other security control you implement is theater.

I've worked with dozens of contractors who spent months implementing technical controls, building system security plans, and preparing for CMMC assessments—only to discover during the assessment that they'd fundamentally misidentified what information qualified as CUI. That's not a technical failure. It's a definitional one, and it's expensive to fix after the fact.

What Controlled Unclassified Information Actually Is

CUI is information the government creates or possesses, or that an organization creates or possesses on behalf of the government, that requires safeguarding or dissemination controls pursuant to law, regulation, or government-wide policy. It's not classified, but it's not public either.

The CUI Program was established by Executive Order 13556 in 2010 and implemented by the National Archives and Records Administration (NARA) through 32 CFR Part 2002. Before this, agencies used different terms—For Official Use Only, Sensitive But Unclassified, Law Enforcement Sensitive—creating confusion across the federal enterprise. CUI was meant to standardize protection requirements across all agencies.

Here's what matters for contractors: if you handle information under a federal contract or agreement and that information falls into one of the CUI categories listed in the CUI Registry, you're required to protect it according to federal standards. That means NIST 800-171 controls at a minimum, and increasingly, CMMC certification for Department of Defense work.

The CUI Registry and Categories

The CUI Registry, maintained by NARA, lists all approved CUI categories and subcategories. As of this writing, there are 24 categories ranging from "Critical Infrastructure" to "Proprietary Business Information" to "Controlled Technical Information." Each category has an authorizing law, regulation, or policy that explains why the information requires protection.

For defense contractors, the most common CUI category is Controlled Technical Information (CTI). This includes technical data with military or space application that's subject to controls on the access, use, reproduction, modification, performance, display, release, disclosure, or dissemination. If you're building something for DoD or providing engineering services, you're almost certainly handling CTI.

The second most common category for defense work is Export Controlled information that doesn't rise to the level of classified but is controlled under the International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR). The overlap between CUI requirements and ITAR compliance creates confusion I see repeatedly—contractors assume they can handle both the same way, but the marking and handling requirements differ in important ways.

How to Identify CUI in Your Environment

The pattern I see most often: contractors assume CUI is only what comes to them already marked. That's wrong. If you're creating deliverables, reports, designs, or technical data under a federal contract, you're generating CUI. You're responsible for identifying it and marking it correctly.

Start with your contracts. Look for clauses that reference CUI, Federal Acquisition Regulation (FAR) 52.204-24, or Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012. These clauses require you to protect CUI and flow down protection requirements to subcontractors. If those clauses are in your contract, you have CUI whether you've marked it or not.

Next, look at what information you're receiving from the government or prime contractor. Technical data packages, specifications, statements of work with performance details, design drawings, test data, and security-related information are likely CUI. Even if they're not marked—and in my experience, a shocking percentage of government-provided information arrives without proper markings—you need to treat them as CUI if they meet the definitional criteria.

Finally, examine what you're producing. Deliverables that contain technical data about items or processes developed with government funding are CUI. Communications with government personnel that discuss contract performance details, technical approaches, or proprietary methods are CUI. Even internal documents like engineering notebooks and test logs that capture federally-funded work can be CUI.

The Gray Areas That Trip People Up

Some information genuinely sits in gray areas. Financial information related to contract costs might be CUI under the Proprietary Business Information category, or it might not, depending on the specific data and contract terms. Information that's publicly available isn't CUI, but determining what's truly public can be tricky when you're dealing with incremental technical improvements.

When you're uncertain, the conservative approach is to treat it as CUI until you get clarification from the contracting officer or designated CUI authority. That's not paranoia—it's risk management. The downside of over-protecting information is minimal. The downside of under-protecting it ranges from contract violations to criminal penalties under 18 U.S.C. § 1924.

Inline article illustration

CUI Marking Requirements That Matter

CUI must be marked to alert holders that the information requires safeguarding. This isn't optional. The marking requirements are detailed in 32 CFR Part 2002 and the CUI Marking Handbook published by NARA.

At a minimum, CUI Specified (the category that requires specific handling under the authorizing law or regulation) must be marked with the designation "CUI" or "Controlled" at the top and bottom of each page. The marking can appear as a banner ("CUI") or within a block that includes category markings.

The full marking includes the CUI designation indicator, category markings, and limited dissemination controls if applicable. It looks like this: "CUI//SP-CTI/SP-PRVLG//FED ONLY". That tells you it's CUI, it contains Controlled Technical Information and information subject to attorney-client privilege, and it's limited to federal employees.

Banner vs. Block Markings

Documents can use banner markings (the simple "CUI" at top and bottom of pages) or block markings that indicate specific portions contain CUI. Block markings are more precise but require more effort to apply correctly. In my experience, most contractors start with banner markings for simplicity, then move to portion markings as they mature their CUI program.

Email subject lines containing CUI must include the designation. Email bodies are treated like documents—mark them at the top and bottom, or at least in the body if your email system makes headers and footers impractical.

One marking mistake I see frequently: contractors mark everything as CUI to be safe. This creates the opposite problem—when everything is marked, nothing is treated with appropriate care. Desensitization is real. Mark what's actually CUI, and your workforce will take the markings seriously.

Speaking on CMMC and Federal Contractor Cybersecurity

Carl delivers keynotes and workshops helping defense contractors, industry associations, and government agencies understand CMMC requirements, CUI handling, and the security programs that support them. Real experience, not vendor marketing.

Book Carl to Speak

How CUI Must Be Handled and Protected

Marking CUI is the first step. Protecting it is the ongoing operational requirement that most contractors underestimate. The baseline protection standard for CUI is NIST 800-171, which specifies 110 security controls organized into 14 families. These aren't recommendations—they're requirements if you handle CUI.

The controls cover access control, awareness and training, audit and accountability, configuration management, identification and authentication, incident response, maintenance, media protection, personnel security, physical protection, risk assessment, security assessment, system and communications protection, and system and information integrity. That's the entire security program you need to protect CUI controlled unclassified information in non-federal systems.

For DoD contractors, CMMC takes this further. CMMC Level 2 requires you to implement the NIST 800-171 controls and prove it through a third-party assessment. The assessor will verify not just that you have policies, but that you're following them. They'll test your system configurations, interview your staff, and review your artifacts to confirm operational maturity.

The Scoping Problem

One question determines how much infrastructure you need to protect: where does CUI flow in your environment? If CUI touches a system, that system must meet NIST 800-171 requirements. If CUI is stored on a network segment, that segment needs the full control set. If users with CUI access authenticate through an identity system, that identity system is in scope.

The most effective approach I've seen is to limit CUI to a defined enclave—a separate network segment with dedicated systems where all federal contract work happens. This creates a clear boundary. Everything inside the enclave meets NIST 800-171. Everything outside doesn't need to.

The least effective approach: letting CUI spread across your entire enterprise because users email it to their regular accounts, save it to shared drives, or work on it from laptops that also access corporate systems. That puts your entire IT environment in scope, multiplies your compliance costs, and creates a sprawling attack surface you can't defend.

Scoping is a business decision dressed up as a technical one. It determines what you spend on compliance, how quickly you can move, and how defensible your security posture is under audit. Get scoping wrong, and nothing else matters.

Inline article illustration

Why CUI Identification Is the Foundation of CMMC

CMMC assessments start with a simple question: what CUI are you protecting? If you can't answer that specifically—not generically, not theoretically, but with actual identification of the data assets under protection—the assessment can't proceed. You can't scope systems without knowing where CUI lives. You can't test controls without knowing what assets those controls are protecting.

I've seen contractors spend six figures on technology and consultants preparing for CMMC, only to realize during the assessment kickoff that they couldn't produce a CUI asset inventory. That's not an audit failure. That's a program failure. The assessment is just the moment when it becomes visible.

The reason CUI identification matters so much: every NIST 800-171 control exists to protect CUI. Access controls limit who can see CUI. Encryption protects CUI in transit and at rest. Incident response plans spell out what happens when CUI is compromised. If you don't know what you're protecting, how can you prove your controls are working?

The System Security Plan Depends on It

Your System Security Plan (SSP) documents how you've implemented each NIST 800-171 control. It describes your security boundary, the systems in scope, the data those systems process, and the controls that protect them. The entire document is built on the foundation of CUI identification.

If your SSP says you protect "technical data related to defense contracts" but can't specify what that data is, where it's stored, or which systems process it, you don't have a compliant SSP. You have a template you filled out. Assessors can tell the difference immediately.

The SSP should reference your CUI asset inventory, explain how you identify CUI as it enters your environment, describe your marking procedures, and document how you ensure CUI doesn't leave the protected enclave without authorization. That level of specificity requires you to actually know your CUI.

Common CUI Handling Failures I See Repeatedly

After working with contractors at every level of the supply chain, the patterns are consistent. First, treating CUI marking as an administrative task that gets delegated to junior staff without training or oversight. Marking is a decision that requires understanding what information qualifies as CUI, which categories apply, and what dissemination controls are necessary. It's not data entry.

Second, assuming that CUI protection is an IT problem. Technology is part of the solution, but CUI handling is an organizational capability. It requires policy, training, process, and culture. I've seen companies with excellent technical controls fail CMMC assessments because their employees didn't understand what CUI was or how to handle it.

Third, failing to control CUI at the boundaries. Users forward CUI to personal email accounts to work from home. Contractors send CUI to subcontractors without verifying the subs have adequate protection. Engineers download CUI to unmanaged devices because it's more convenient. Every boundary violation is a control failure and a potential security incident.

The Subcontractor Flow-Down Gap

DFARS 252.204-7012 requires you to flow down CUI protection requirements to subcontractors at all tiers. That means verifying your subs can protect CUI before you send it to them, including the requirement in subcontracts, and conducting periodic verification that they're maintaining adequate security.

Most primes don't do this well. They include the DFARS clause in subcontracts but don't verify the sub's actual capability. They send CUI via email without confirming the recipient has a compliant environment. They assume the sub knows what to do because they're in the industry.

That assumption creates liability. If your sub mishandles CUI, you're responsible under your prime contract. If the sub suffers a breach, you're on the hook for notification and reporting. The government doesn't care that you delegated the work—you delegated responsibility, not accountability.

Industry Keynotes on Defense Contractor Cybersecurity

Carl speaks regularly at industry conferences, association meetings, and company events about CMMC, CUI handling, supply chain security, and building defensible compliance programs in regulated environments. See all keynote speaking topics or reach out about your event.

Book Carl for Your Event

Building a CUI Program That Holds Up

A functional CUI program has five components: identification procedures, marking standards, handling requirements, training, and verification. Each component reinforces the others. You can't have effective handling without accurate marking. You can't have accurate marking without proper identification. And none of it works without trained personnel who understand why it matters.

Start with written procedures that define how your organization identifies CUI. Who makes the determination? What references do they use? How do they document the decision? The procedure should reference the CUI Registry, explain how to interpret contract clauses, and provide examples specific to your business.

Your marking standard should specify what tools you use (document templates, email footers, labels for physical media), what markings apply to which categories of CUI, and how employees request guidance when they're uncertain. Include examples. Most people learn marking by seeing it done correctly.

Training That Changes Behavior

CUI training fails when it's generic compliance content delivered annually and forgotten immediately. Effective training is specific to your environment, uses real examples from your contracts and deliverables, and includes practical exercises where employees practice identifying and marking CUI.

The training should answer the questions your workforce actually has: Is this technical data CUI? Do I mark internal emails about the project? What do I do if a customer sends me unmarked information that looks like CUI? Can I discuss this on a Teams call? Give them decision criteria, not just rules.

Training is also where you explain the consequences—not to scare people, but to build understanding of why CUI protection matters. Contract termination, civil penalties, criminal liability, and security clearance revocation are all possible outcomes of mishandling CUI. Most employees have never thought about the stakes.

Verification and Continuous Improvement

Your CUI program needs feedback loops. Periodic reviews of marked documents to verify accuracy. Spot checks of systems to confirm CUI isn't leaking outside the protected environment. Interviews with staff to assess understanding and identify gaps. Metrics that track marking compliance, training completion, and incident rates.

When you find problems—and you will—treat them as process failures, not individual failures. If multiple people are making the same mistake, your training or procedures are unclear. If CUI keeps appearing outside the enclave, your technical controls aren't effective. Fix the system, not just the symptom.

The best CUI programs I've seen treat this as operational discipline, not compliance overhead. They integrate CUI identification into contract review processes, marking into document creation workflows, and handling into standard operating procedures. It becomes how the organization works, not something extra that security requires.

What Happens When You Get CUI Wrong

The consequences of CUI mishandling range from corrective action plans to contract termination to criminal prosecution under 18 U.S.C. § 1924, which makes it a crime to knowingly remove CUI without authority and retain it at an unauthorized location. The statute was written for classified information but applies to CUI as well.

More commonly, contractors face administrative consequences. If a CMMC assessment reveals you don't have adequate CUI identification and protection, you'll fail the assessment. That means you can't bid on contracts requiring CMMC certification. For DoD contractors, that's an existential business risk.

Even without formal assessments, contract performance issues arise. If you deliver unmarked CUI to the government, you're not meeting contract requirements. If you send CUI to unauthorized recipients, you've created a security incident that triggers reporting requirements under DFARS 252.204-7012. Those reports go to DoD, get investigated, and become part of your contractor performance record.

The pattern I see in serious CUI incidents: they don't start with sophisticated attacks. They start with sloppiness. Someone emails CUI to a personal account. A laptop with CUI gets left in a car. A terminated employee walks out with files on a USB drive. These are process failures that technology can't solve.

The Strategic Implications for Contractor Leadership

CUI protection is often treated as a compliance requirement that gets delegated to the security team or IT department. That's a mistake. CUI identification and handling are operational capabilities that affect every part of the business—contracts, engineering, program management, human resources, finance, and IT.

Leadership needs to understand that CMMC certification isn't a one-time project. It's an ongoing operational state that requires organizational commitment, resource allocation, and cultural change. The foundation of that state is knowing what CUI you have and protecting it consistently. If you can't do that, you can't compete for federal contracts that require CMMC readiness.

The companies that handle this well integrate CUI considerations into business development, contract reviews, and make-or-buy decisions. They ask whether they have the infrastructure to protect CUI before they bid. They flow down requirements to subs and verify compliance. They invest in training and tools that make CUI handling manageable rather than treating it as a burden.

The companies that struggle treat CUI as someone else's problem until an assessment forces them to face it. By then, they're behind schedule, over budget, and trying to retrofit security into processes that were designed without it. That's expensive and risky.

If you're a contractor leader and you can't articulate what CUI your company handles, where it lives, and how you protect it, that's the first problem to solve. Everything else in your compliance program depends on getting that right. The good news: it's solvable. It requires clarity, discipline, and commitment, but it's solvable. And once you solve it, everything else about CMMC becomes more manageable.

📖
CMMC Readiness: What You Need Before Starting an Assessment → What Is NIST 800-171? The 110 Controls Federal Contractors Must Know →