StealthTech
Before a defense contractor can build a CMMC compliance program, they need to know what they’re protecting. This sounds obvious until you try to do it systematically — and then it becomes clear why CUI identification is where so many compliance programs quietly go wrong before they’ve really started.
The organizations that build overly broad CMMC compliance programs — bringing systems, users, and environments into scope that don’t need to be there — almost always trace that problem back to an imprecise CUI identification exercise. The same is true of organizations that build under-scoped programs, where assessors find information being handled outside the compliance boundary that should have been inside it. In both cases, the root cause is the same: the organization didn’t have a clear, accurate picture of what CUI exists in their environment, where it comes from, how it moves, and what it looks like when it arrives.
CUI identification and marking isn’t a compliance checkbox. It’s the foundational analytical work that everything else in a CMMC program depends on. Getting it right before building the compliance program prevents the scope errors, the remediation rework, and the assessment findings that consistently affect contractors who built their programs on an incomplete or inaccurate CUI picture. A strong cybersecurity foundation means nothing if it’s protecting the wrong environment.
What CUI Actually Is — and What It Isn’t
CUI is a government-wide information category established by Executive Order 13556 and governed by the National Archives CUI program. It covers information that law, regulation, or government-wide policy requires to be safeguarded — not because someone decided it was sensitive, but because it meets specific criteria established by the relevant authority. The complete framework is defined in 32 CFR Part 2002, which all defense contractors working with sensitive government information should be familiar with.
What makes CUI identification genuinely challenging is that the category is not monolithic. The National Archives CUI Registry defines more than 100 specific CUI categories across 20 category groups, each with its own authority, handling requirements, and in some cases specific marking standards. In the defense sector, the CUI categories contractors most commonly encounter include controlled technical information, export-controlled information, privacy-sensitive information, acquisition-sensitive information, and various program-specific designations. Each of these has different characteristics, different source documents, and different handling requirements that affect how they need to be managed within a CMMC-compliant environment.
What CUI is not is every document that the government provides. Federal Contract Information — information provided by or generated for the government under a contract, but not designated as CUI — is a separate category that triggers only CMMC Level 1 requirements. The distinction between FCI and CUI matters enormously for scoping: an organization that treats all government-furnished information as CUI will over-scope its compliance environment significantly, while one that treats CUI as FCI will under-scope it in ways an assessor will find.
CUI also isn’t necessarily marked at the document level by the time it reaches a defense contractor. Government agencies and prime contractors are supposed to mark CUI before transmitting it, but in practice, CUI frequently arrives unmarked or incorrectly marked. A subcontractor who assumes that information without a CUI marking isn’t CUI is making an assumption that the framework doesn’t support — and one that creates real compliance exposure when the information turns out to meet CUI criteria regardless of how it was labeled when it arrived.
The CUI Registry: Your Starting Point for Category Identification
The CUI Registry maintained by the National Archives is the authoritative source for determining whether specific information qualifies as CUI and, if so, what handling requirements apply. Defense contractors who haven’t reviewed the CUI Registry categories relevant to their work — and who are operating on a general intuition about what sensitive government information looks like — are working with an incomplete picture.
The categories most frequently relevant to defense contractors are worth examining specifically.
Controlled Technical Information (CTI) is the CUI category that applies to technical information with military or space application that is subject to controls on access, use, reproduction, modification, performance, display, release, disclosure, or dissemination. CTI is perhaps the most commonly encountered CUI type in the defense sector — design specifications, engineering drawings, test reports, technical manuals, and similar documents frequently carry CTI designation. The authority for CTI is DoDI 5230.24, and the specific documents that qualify as CTI are defined in the Distribution Statements that appear on technical documents — Distribution Statement B through F all indicate some form of controlled status.
Export Controlled information is CUI designated under export control regulations — primarily the International Traffic in Arms Regulations (ITAR) and the Export Administration Regulations (EAR). Defense contractors working on programs involving weapons systems, military technologies, or dual-use items with export control implications frequently handle export-controlled CUI that carries handling requirements beyond standard CMMC controls. The intersection of export control compliance and CMMC compliance creates a specific complexity for affected contractors that generic compliance programs don’t always address.
Privacy-sensitive CUI covers personally identifiable information and protected health information that meets CUI criteria. Defense contractors who have access to personnel records, medical information, or other PII in connection with defense contracts may be handling CUI in this category without recognizing it as such.
Acquisition-sensitive CUI covers procurement-sensitive information including source selection information, contract cost and pricing data, and acquisition strategy documents. Contractors involved in the acquisition process — particularly those who have access to pre-award information or source selection materials — may handle this category of CUI without formal designation documents making the CUI status obvious. Legal and finance teams within defense contractor organizations are often the staff closest to acquisition-sensitive CUI, and building them into the CUI identification process is essential for capturing this category accurately.
How CUI Enters a Defense Contractor’s Environment
Understanding where CUI comes from — the specific channels through which it enters the organization — is the practical starting point for CUI identification in a real organizational environment. CUI doesn’t announce itself. It arrives through multiple channels, in multiple formats, and often without the marking that would make its status immediately obvious.
Email is the most common CUI entry point. Technical data attachments, contractual documents containing sensitive specifications, program schedules with restricted distribution, and communications from government customers or prime contractors containing controlled information all arrive via email. The challenge is that email is also the channel through which enormous volumes of non-CUI information flows, and distinguishing the two requires both policy clarity about what constitutes CUI and user awareness sophisticated enough to apply that policy consistently.
Government portals and collaboration platforms are a second major CUI entry point. Systems like the DoD Safe system, AMRDEC SAFE, or program-specific SharePoint environments that prime contractors establish are channels through which technical data, drawings, specifications, and program information flow to subcontractors. Information downloaded from these systems frequently carries CUI designation — though the designation may appear only in the metadata or distribution statement rather than prominently on the document face.
Physical media — CDs, USB drives, hard copy documents — remains a CUI entry channel for contractors on programs with specific information security requirements or where electronic transfer isn’t appropriate. Physical CUI has specific marking requirements and handling requirements that digital CUI sometimes doesn’t, and contractors who handle physical CUI need to ensure their physical protection controls address it specifically. Organizations handling significant volumes of CUI on physical media should also ensure their backup and data recovery capabilities account for that media in continuity planning.
Internal generation is a fourth CUI entry path that organizations consistently overlook. When a defense contractor uses government-furnished CUI to produce derivative work — an engineering analysis based on classified drawings, a test report that incorporates controlled technical specifications, a design document that references government-provided parameters — the derivative work may itself constitute CUI even if it was generated entirely within the contractor’s own environment. The contractor is the CUI creator in this scenario, which creates marking and handling obligations that are distinct from those that apply to CUI received from external sources.
Conducting a CUI Identification Exercise
A formal CUI identification exercise — a structured process for systematically identifying what CUI exists in the organization, where it comes from, and where it lives — is the practical mechanism for building the accurate CUI picture that scope definition requires.
The identification exercise has several components that need to be addressed in sequence.
Contract and data requirements review comes first. The contracts under which the organization performs work, the data requirements lists (DRLs) attached to those contracts, and the security classification guides or CUI designation guides associated with the programs are the authoritative sources for what CUI the organization should be receiving. Reviewing these documents with knowledge of the CUI Registry categories they implicate identifies the categories of CUI that the organization should expect to handle under each contract. This top-down view tells you what CUI should be coming in — the next step verifies what’s actually there.
Information asset inventory is the bottom-up complement to the contract review. What documents, files, and information assets currently exist in the organization’s systems? File share audits, email content analysis, collaboration platform reviews, and physical document inventories are all mechanisms for identifying information assets that may meet CUI criteria regardless of how they arrived or whether they were properly marked. The gap between what the contract review says should be CUI and what the information asset inventory finds is itself a useful diagnostic — it reveals both untracked CUI that was received without proper marking and derivative CUI that was generated internally without being recognized as such. Organizations using managed IT services providers should loop those providers into the inventory process — they often have visibility into file system usage and data locations that internal staff may not.
Personnel interviews with the people who do the work are the third component. Contracts managers, program managers, engineers, and operations staff who are closest to the technical work have the most granular view of what information they handle and how it flows through their operations. Structured interviews that ask specifically about the types of information they receive, the channels through which it arrives, the tools they use to work with it, and where they store it produce a detailed picture of CUI flows that document review alone doesn’t capture.
The output of this exercise — a documented inventory of CUI types, sources, locations, and data flows within the organization — becomes the foundation for scope definition, for the data flow diagram in the SSP, and for the user training that teaches staff to recognize and handle CUI correctly. It’s also the reference against which marking compliance can be evaluated: once you know what CUI exists in the environment, you can assess whether it’s been marked correctly.
CUI Marking Requirements: What They Are and Why They Matter
CUI marking requirements establish how CUI must be identified on documents, files, and containers — the physical and digital labels that communicate CUI status to anyone who encounters the information. Marking serves both a protection function (ensuring CUI is recognized and handled accordingly) and an accountability function (creating a record that specific information carries CUI designation).
The basic marking standard for CUI documents and files is the CUI designation indicator — the word “CUI” prominently displayed on the document, typically in the header and footer. Documents with specific limited dissemination controls carry additional markings that specify what limitations apply — “CUI//SP-CTI” indicates CUI with the Specified category of Controlled Technical Information, for example. The National Archives marking guidance provides the authoritative standard for how CUI should be marked in various contexts.
For defense contractors, the practical marking challenge is twofold. First, they need to correctly mark CUI that they generate as derivatives of government-furnished information — ensuring that documents produced using CUI are themselves marked as CUI and handled accordingly. Second, they need to manage the receipt of unmarked or incorrectly marked CUI from external sources — identifying it as CUI based on content rather than relying on external marking, and applying appropriate marking within their own systems.
The failure to mark CUI correctly creates specific CMMC compliance problems. If CUI isn’t marked, users don’t know they’re handling it and don’t apply the handling requirements. Information that should stay within the compliance boundary moves outside it. Access controls that should apply to CUI systems aren’t applied because the CUI status isn’t recognized. The entire protection regime that CMMC establishes depends on the organization and its personnel knowing what is and isn’t CUI — and marking is the primary mechanism for maintaining that knowledge at the document level.
For electronic files, marking requirements extend to the file-level metadata where technically feasible, and to the system-level controls that apply to repositories containing CUI. A SharePoint site containing CUI files should have system-level access controls consistent with CUI handling requirements — not because every file in the site necessarily carries CUI marking, but because the site as a whole contains CUI and the system-level controls need to reflect that. Organizations migrating to cloud environments through a cloud transformation engagement should specifically address how CUI marking and repository controls will be maintained in the new environment before migration occurs.
Why Misidentifying CUI Produces Scoping Errors
The connection between CUI identification errors and CMMC scope errors is direct. The CMMC assessment boundary is defined as the systems, environments, and people that process, store, or transmit CUI. If the CUI identification exercise produces an inaccurate picture — either because CUI was missed or because non-CUI was identified as CUI — the scope definition built on that picture will be correspondingly inaccurate.
Over-identification of CUI — treating information as CUI that doesn’t actually meet the criteria — produces an over-scoped compliance environment. Systems that handle only non-CUI information get brought into the compliance boundary, requiring controls they don’t actually need. Users who work only with non-CUI get included in the user population subject to CUI handling training and access controls. The compliance program costs more and is harder to maintain than it needs to be, with no corresponding security benefit.
Under-identification of CUI — failing to recognize information that actually meets CUI criteria — produces an under-scoped compliance environment with the opposite and more serious problem. CUI that isn’t recognized as such doesn’t get handled with the controls CMMC requires. It may exist on systems outside the compliance boundary, be transmitted through channels without appropriate protection, be accessed by users who aren’t subject to CUI handling requirements, or be stored in environments that aren’t subject to the access controls and monitoring that the compliance program maintains. When an assessor discovers CUI outside the documented compliance boundary — in email archives, in shared drives that weren’t included in scope, in tools that were considered out of scope — it’s a scope finding with immediate remediation implications.
The most common under-identification pattern is derivative CUI — information that the organization generated using government-furnished CUI but didn’t recognize as itself constituting CUI. An engineer who produces a technical analysis using government-provided specifications may not think of their analysis as CUI because they produced it themselves, even though the analysis incorporates controlled information and likely meets CTI criteria as a derivative work. Without a CUI identification framework that specifically addresses derivative information, this category of CUI routinely ends up outside the compliance boundary in documents and files that the compliance program never addressed.
Our guide on how to scope your CMMC environment correctly covers how CUI identification feeds into scope definition and why getting the identification right before building the scope prevents the costly rework that an inaccurate identification produces. For organizations that need both technical and compliance expertise working together on this, a co-managed IT model brings that combined capability without requiring separate advisory and technical vendor relationships.
Building a CUI Awareness Program That Prevents Misidentification
CUI identification isn’t a one-time exercise. As contract portfolios change, as programs mature and generate new derivative documents, and as personnel turn over, the organizational understanding of what constitutes CUI in the specific environment needs to remain accurate and operational. The mechanism for maintaining that accuracy is a CUI awareness program that keeps personnel equipped to recognize and handle CUI correctly as part of their normal work.
CMMC’s Awareness and Training requirements (3.2.1 and 3.2.2) explicitly require that personnel be made aware of the security risks associated with their activities and that they be trained on applicable policies, standards, and procedures. A CUI awareness program that specifically addresses how to recognize CUI in the organization’s specific contract and work context — not just generic CUI training — satisfies these requirements in substance rather than just in format.
Effective CUI awareness training for defense contractors covers several specific elements. It explains what CUI categories appear in the organization’s specific contracts and what those categories look like in practice — not as abstract policy but as concrete examples from the actual work personnel perform. It explains how CUI arrives in the organization and through what channels — so that a technical document received via email from a prime contractor is recognized as likely CUI before it’s forwarded to an unprotected file share. It explains the marking requirements and what correct CUI marking looks like — so that personnel receiving unmarked or incorrectly marked information know to treat it as potentially CUI based on content rather than assuming non-CUI status from the absence of marking.
The training also needs to cover what personnel should do when they’re uncertain whether something is CUI. The default position — treating ambiguous information as CUI pending clarification — needs to be understood and practiced, not just stated in policy. Personnel who encounter information that might be CUI and who don’t have a clear protocol for handling that uncertainty are the source of many inadvertent CUI handling failures.
A compliance partner with specific CMMC training program experience can help build CUI awareness training that’s calibrated to the organization’s specific contract portfolio and work context — which is significantly more effective than generic government CUI training that doesn’t address the specific categories and workflows relevant to the organization’s actual operations.
CUI Identification and the System Security Plan
The CUI identification work that precedes scope definition feeds directly into the System Security Plan — specifically into the system description, the data flow documentation, and the scope narrative that anchors the entire document. An SSP built on an accurate, detailed CUI identification exercise is more specific, more internally consistent, and more credible to assessors than one built on general assumptions about what CUI the organization handles.
The data flow section of the SSP — or the data flow diagram referenced in it — should reflect the specific CUI categories that enter the organization, the channels through which they arrive, the systems and storage locations where they reside, the tools and processes through which they’re worked, and the channels through which they leave the organization. This level of specificity is only achievable if the CUI identification exercise produced that granular picture.
The scope narrative should specifically identify what CUI categories are in scope and why — connecting the scope definition to the CUI identification findings that drove it. An assessor who reads a scope narrative that says “the CUI environment encompasses the systems through which Controlled Technical Information and Export Controlled information flow, as identified through the data flow analysis documented in [reference]” understands both what’s in scope and why, in a way that a scope narrative claiming generic “CUI” without specificity doesn’t provide.
When CUI identification reveals derivative CUI that wasn’t previously recognized as such — information generated internally using government-furnished CUI — the SSP needs to reflect those data flows and the handling requirements they trigger. Our detailed guide on creating a System Security Plan covers how CUI identification outputs translate into SSP documentation standards.
Conclusion: Get the Identification Right Before Building the Program
CUI identification is unglamorous work. It doesn’t involve deploying security tools, configuring access controls, or producing the documentation artifacts that feel like compliance progress. But it’s the work that determines whether all of the subsequent security investments are directed at the right systems, applied to the right information, and documented in a way that accurately reflects what the compliance program is actually protecting.
Defense contractors who invest in accurate CUI identification before building their CMMC compliance programs build more efficient programs, with smaller scopes, lower remediation costs, and fewer assessment findings than those who proceed on incomplete or inaccurate CUI pictures. The identification exercise isn’t a prerequisite that gets completed and then set aside — it’s the analytical foundation that the entire compliance program builds on, and its accuracy determines the quality of everything that follows. Whether you’re based in the Boston defense corridor or operating across multiple regions, building CUI identification into your compliance program before scope decisions are made is the single most cost-effective investment a defense contractor can make.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
