CUI Scoping Methodology

Why Scoping Comes First

Every CMMC compliance decision downstream of CUI scoping depends on knowing what CUI you have. The architecture choice (whole-org compliance versus enclave) hinges on how much CUI you handle and how concentrated it is. The SSP boundary statement is a written description of where your CUI lives. The cost of remediation scales directly with the count of in-scope systems. The cost of the C3PAO assessment scales with the count of in-scope users, applications, and network segments.

An incomplete CUI inventory invalidates everything that follows. If you scope your enclave to a 10-person engineering team but program managers in a different department also receive CUI by email, your enclave does not actually contain all your CUI — and your SSP, your remediation plan, and your assessor's findings will all reflect that gap.

The good news: scoping is one of the few CMMC activities that is genuinely free. It costs time and discipline, not money. Done well, it can be the single largest cost-saving step in your entire compliance program — by ruling things out of scope as well as identifying what's in.

CUI vs. CDI vs. FCI: Resolve the Terms First

Three overlapping terms appear in the regulations and trip up nearly every new reader. Resolve them before you start the inventory.

• Federal Contract Information (FCI): Information not intended for public release, provided by or generated for the government under a contract. Broadest and least sensitive of the three. Triggers FAR 52.204-21 and CMMC Level 1.
• Controlled Unclassified Information (CUI): Government-created or government-owned information requiring safeguarding under a law, regulation, or government-wide policy. Categories are enumerated in the NARA CUI Registry. Triggers DFARS 252.204-7012 and CMMC Level 2.
• Covered Defense Information (CDI): The DFARS-specific subset of CUI. Defined in DFARS 252.204-7012 as unclassified controlled technical information or other CUI marked or otherwise identified in a contract that is collected, developed, received, transmitted, used, or stored in support of contract performance. All CDI is CUI; not all CUI is CDI (CUI on a non-DoD contract isn't called CDI).

For practical CMMC scoping work, treat any CUI you receive in connection with a DoD contract as CDI. The scoping exercise below applies to both terms.

Reading the NARA Registry as a Discovery Tool

The NARA CUI Registry is the authoritative list of CUI categories — over 100 categories grouped into 20 organizational indexes (Defense, Critical Infrastructure, Export Control, Privacy, Procurement and Acquisition, etc.). Most contractors approach it as a reference; treat it instead as a discovery tool.

Read every category in every index that could plausibly relate to your work. The categories most relevant to defense contractors include:

• Controlled Technical Information (CTI): Technical information with military or space application that is subject to controls on access, use, reproduction, modification, performance, display, release, disclosure, or dissemination. The most common CUI category for engineering and manufacturing contractors.
• Defense Information: Information about military operations, plans, or capabilities that does not rise to the level of classification.
• Export Controlled (EXPT): Information subject to ITAR or EAR. Carries US-person access restrictions in addition to CUI safeguarding. See the ITAR/EAR controls guide.
• Procurement and Acquisition: Source selection information, sealed bid information, and proprietary contractor information received during acquisition.
• Critical Infrastructure (PCII, CEII): Protected Critical Infrastructure Information and Critical Energy Infrastructure Information — relevant for contractors supporting defense facilities, energy, or transportation.
• Privacy (PII categories): Personnel records, medical records, and similar information often present incidentally in contractor environments.

Walk through the registry with the people in your organization who actually handle the work — engineers, program managers, contracts staff, HR. Ask them to identify what they receive and create. The registry will surface categories you would not have thought to look for.

Start From Your Contracts

The most reliable starting point for a CUI inventory is your contracts themselves. Every DoD contract under DFARS 252.204-7012 names the CUI categories the contractor will handle. The contract tells you what the government expects you to be safeguarding.

For each active and recent DoD contract:

1. Identify the CUI categories named in the contract or its attachments (DD-254, statement of work, security classification guide)
2. Identify the deliverables the contract requires you to produce — those deliverables will themselves be CUI in most cases
3. Identify the data the government will provide you (technical data packages, drawings, source selection information, etc.) — these are CUI on receipt
4. Note any flow-down obligations to subcontractors handling that CUI (see the DFARS flow-down guide)

Build a contract-by-contract table: contract number, CUI categories handled, government data inputs, contractor data outputs, points of contact for each, and the prime if you are the sub. This table becomes the spine of your CUI inventory and feeds directly into your SSP system overview section.

The Five Inventory Questions

For each CUI category identified in the contract review, work through five questions. Together they produce the inventory artifact that downstream activities depend on.

Work these questions for each CUI category your contracts identify. The result is a structured inventory: for each category of CUI, who handles it, where it lives, who has access, how it moves, and how it's labeled. This inventory is the prerequisite for every downstream activity.

The Shadow CUI Problem

Beyond the CUI you receive directly, most contractors create or accumulate CUI in ways that no contract review or system inventory will surface. This is shadow CUI — and finding it is the part of scoping that requires the most discipline.

Surfacing shadow CUI requires a combination of interview-based discovery (asking users what they actually do with CUI), technical discovery (DLP scans of file shares and email, search across endpoints, cloud storage audits), and process review (workflow walkthroughs). It is worth doing before — not after — you finalize your CUI boundary.

Documenting the Inventory

The CUI inventory is a working artifact, not a one-time deliverable. Document it in a form that can be maintained and reviewed.

One row per CUI category, per contract (or per program if the categories are shared across contracts). Update the inventory at least annually, and whenever a new CUI source enters your environment.

From Inventory to Boundary

The CUI inventory drives the boundary decision. With the inventory in hand, ask:

• How concentrated is the CUI? If most CUI lives in a small set of systems used by a small set of people, an enclave is feasible. If CUI is scattered across the enterprise (every engineer's laptop, the general SharePoint, the corporate email system), enclaving is harder and a whole-org compliance approach may be more honest.
• Can the boundary be enforced? An enclave is only as strong as the controls preventing CUI from crossing it. If shadow CUI patterns suggest CUI routinely crosses to personal email, BYOD, or commercial cloud, the boundary will not hold.
• What scope reduction is realistic? A common error is assuming an enclave will reduce scope by 90% when in practice it reduces it by 40% because half the organization continues to receive CUI by email. Build the inventory before estimating the scope reduction.

Once the inventory is solid, move to architecture: see the enclave architecture guide for the patterns and tradeoffs in detail.

Common Pitfalls

• Asking only IT. IT can tell you which systems exist; only the users can tell you what's in them. The inventory must be informed by the people who actually handle CUI in the course of their work — not derived from a network scan.
• Assuming "we don't have CUI." Many contractors who hold prime or subcontract relationships under DoD believe they don't handle CUI. Read the contracts before drawing that conclusion. CUI obligations attach by contract clause, not by self-assessment.
• Treating the inventory as a one-time document. CUI flows change as contracts start and end, as personnel change roles, as new tools are adopted. An inventory frozen at the time of your initial assessment will be stale within months.
• Missing the marking obligation. Receiving CUI is one obligation; creating derivative works (reports, analyses, drawings) carries the obligation to apply CUI markings to those derivatives. Your inventory should note marking status as a control item, not just an observation.
• Conflating CUI with all sensitive information. Trade secrets, internal financials, and other proprietary data are sensitive but are not CUI unless they meet the regulatory definition. Over-scoping by treating proprietary data as CUI inflates compliance cost without serving the regulatory purpose.

Authoritative References