ControlSolid
Defense Contracting

CUI Scoping for CMMC: A Practical Guide

Published September 24, 2026

By Kelvin O. Medina

A CUI boundary includes the people, processes, technology, facilities, and services that create, receive, process, store, transmit, or protect Controlled Unclassified Information. Controls, evidence, and remediation all depend on defining it well.

Not every federal contractor handles CUI. Start with contract requirements and flow-downs, then validate the information with the contracting party and current CUI guidance. Ordinary business data is not CUI merely because it supports federal work.

Start with the obligation, not the tools

Review contract clauses, the statement of work, data requirements, and handling instructions. Identify marked or categorized CUI and information you must handle. The official NIST Protecting CUI project and FAQ explain the governing program and point to the NARA CUI Registry for categories and markings.

If language, markings, or ownership is unclear, ask the contracting officer, prime, or customer. A consultant can map the boundary but cannot make the government's CUI determination.

Rev. 3 is published; current CMMC uses Rev. 2

NIST published SP 800-171 Revision 3 in May 2024. Its requirements apply to nonfederal components that process, store, or transmit CUI and to components that protect them. However, as of September 24, 2026, NIST's current CUI FAQ says CMMC currently leverages NIST SP 800-171 Revision 2 and SP 800-171A. Current official CMMC guidance keeps assessments against Revision 2. Revision 3 is planned for future rulemaking, with no stated change date.

Confirm the contract's required version and current CMMC guidance. Rev. 3 can inform planning, but does not automatically demonstrate the current Rev. 2 baseline. NIST's SP 1318 small-business primer introduces Rev. 3 but does not replace contract review or current CMMC requirements.

Map where CUI actually moves

Trace real workflows: where CUI enters, who accesses it, what transforms it, where copies persist, and where it leaves. Include support, recovery, and administration paths.

Illustrative CUI data flow and system boundaryCUI enters from a contract or customer, moves through authorized people and systems, may depend on protective services and external providers, then leaves through approved sharing, retention, or disposal. Scope depends on actual access, protection, and requirements.Trace the actual CUI lifecycleIllustrative only. Scope follows actual access, protection,and applicable requirements.Contract or customerCUI received or createdComponents that handle CUIPeople and identitiesAuthorized accessProcessing systemsApps and endpointsStorage and backupCopies and archivesTransmission pathsEmail, API, networkApproved outflowShare, retain, disposeComponents that protect the environmentIdentity, endpoint management, logging, monitoring,network controls, administration, and recoveryExternal dependenciesCloud, MSPs, suppliers, support access, hosted backups,and connected business systems
An illustrative CUI lifecycle. A component belongs in the boundary only when its actual access, protective function, connections, and applicable requirements support that determination.
  1. Identify the information. Record its contract source, category or marking, owner, format, and business process.
  2. Trace the lifecycle. Map creation or receipt, processing, storage, transmission, sharing, archiving, backup, and disposal.
  3. Identify relevant components. Include systems that handle CUI and systems that protect them, such as identity, endpoint management, monitoring, and boundary controls.
  4. Map access. Include users, administrators, support staff, service accounts, privileged identities, and remote access.
  5. Follow dependencies. Review networks, endpoints, backups, logging, cloud services, managed service providers, and suppliers.
  6. Document the boundary. Keep a current diagram, inventory, data-flow narrative, service list, and reviewable assumptions.

Systems that protect CUI can be in scope too

A component need not hold a CUI document to matter. Identity controls access, logs may contain details from protected workflows, backups retain copies, and management tools may administer in-scope hosts. Scope these dependencies according to access, protective function, and impact.

For cloud and managed services, document CUI handling, administration, data locations, identity federation, and provider obligations. A vendor inventory alone is insufficient.

A compact CUI scoping checklist

  • Contract, solicitation, and subcontract flow-downs reviewed.
  • CUI categories, markings, owners, and open classification questions recorded.
  • CUI creation, receipt, processing, storage, transmission, and disposal mapped.
  • Users, administrators, service accounts, and privileged access paths identified.
  • Technical and protective dependencies inventoried.
  • Cloud, MSP, and supplier responsibilities documented.
  • Boundary and data-flow diagrams agree with the inventory and SSP.
  • System exclusions have a documented technical and operational basis.
  • Assumptions validated with the customer, contract owner, or CUI authority.
  • The applicable NIST revision and assessment basis are confirmed before testing.

Common scoping mistakes

  • Starting with products. An enclave does not identify which information and workflows belong inside it.
  • Trusting markings alone. Missing or inconsistent markings require clarification, not an unsupported exclusion.
  • Ignoring protective systems. Identity, management, monitoring, and backup systems may affect CUI security without looking like data stores.
  • Forgetting informal copies. Email, chat, downloads, tickets, and support exports often expand the boundary.
  • Assuming suppliers are excluded. A provider that handles or protects CUI needs explicit analysis and documented responsibilities.
  • Designing only for the assessment. The documented boundary must match how work is performed after the assessor leaves.

What a useful scope package contains

A defensible package includes assumptions, inventories, access groups, diagrams, dependencies, supplier responsibilities, and decisions. Align it with the System Security Plan and update it when contracts, suppliers, workflows, or architecture change.

ControlSolid's CMMC and NIST 800-171 readiness service helps contractors map CUI flows, define boundaries, review evidence, and prioritize remediation. For wider context, read why NIST 800-171 readiness still matters when CMMC timelines change and review our application and cloud security work for architecture and configuration concerns.

References

This article provides readiness and scoping guidance. It is not an official CMMC assessment, certification, legal determination, or substitute for reviewing the applicable contract and current government guidance. ControlSolid is not a C3PAO and does not issue CMMC certifications.

Contact Us