Every NIST SP 800-171 requirement applies to every system component in scope. That makes scoping the decision with the largest effect on your workload. A boundary drawn around three systems and a dozen laptops is a project. A boundary drawn around the whole company, because nobody knows where the controlled unclassified information (CUI) went, is a program.
The hard part is not drawing the boundary. It is finding out where CUI actually lives, which is rarely where people think. This article covers how to trace CUI through your environment, how to sort the assets you find into the categories CMMC uses, how to choose between an enclave and the whole enterprise, and how to document the result so an assessor accepts it. It assumes you know what 800-171 asks for.
What is in scope
800-171 applies to components that process, store, or transmit CUI, and to components that provide security protection for them. CMMC applies the same idea through its own scoping rules in 32 CFR Part 170, which sort assets into categories with different assessment treatment.
Two consequences follow. First, scope follows the data, not the org chart. A laptop in the finance team that holds one exported drawing is in scope. Second, scope includes the tools that protect in-scope assets. Your identity provider, endpoint protection, and log platform are in scope even if CUI never passes through them.
Where CUI enters
Start at the door. CUI arrives through a small number of channels, and listing them is the fastest route to finding where it goes.
Contract deliverables and data. Specifications, technical data packages, and statements of work from the government or a prime.
Email. Attachments from contracting officers, program offices, and primes.
File transfer and portals. Secure file transfer sites, prime contractor portals, and government systems you download from.
Engineering exchange. CAD models, drawings, and test data passed between engineers.
Work you create. Information you develop in performing the contract can itself be CUI, depending on what the contract says.
Markings help but do not settle the question. Documents should carry CUI markings, and DoD's CUI policy, DoD Instruction 5200.48, sets out how. In practice markings are missing, inconsistent, or stripped when a file is converted. Under DFARS 252.204-7012, covered defense information includes information that is marked or otherwise identified in the contract. Read the contract and ask the contracting officer or your prime where it is unclear.
Tracing where it goes
Once you know the entry points, follow each one. Work through these steps with the people who handle the data, not only IT.
Interview the handlers. Program managers, engineers, contracts staff, and quality teams know where they put things. Ask what they received last month and where it is now.
Follow each channel to storage. Email to mailboxes and archives. Portals to download folders. Engineering exchange to CAD, product life cycle management, and shared drives.
Look for copies. Sync clients, local downloads, exported PDFs, printed copies, screenshots in tickets, and attachments in chat tools.
Check the infrastructure underneath. Backups, replicas, file server snapshots, and archival storage all hold copies.
Check outbound flows. Who do you send CUI to: subcontractors, test labs, the government? Each path is a transmission, and the systems carrying it are in scope.
Draw it. A data flow diagram showing every entry, store, and exit, with the systems at each step.
Expect surprises. The usual ones are a shared mailbox that receives drawings, a quality system with attached specifications, a printer with a hard drive, and an engineer's personal sync folder.
Sorting assets into categories
CMMC's Level 2 scoping rules in 32 CFR Part 170 define five asset categories. Even if CMMC does not yet apply to you, the categories are a sound way to structure an 800-171 boundary.
| Category | What it is | How it is treated |
|---|---|---|
| CUI assets | Process, store, or transmit CUI | Assessed against all Level 2 requirements |
| Security protection assets | Provide security functions for the assessment scope | Assessed against the requirements relevant to the functions they provide |
| Contractor risk managed assets | Can, but are not intended to, handle CUI, because policy and practice prevent it | Documented in inventory, plan, and diagram; subject to limited checks |
| Specialized assets | Can handle CUI but cannot be fully secured, such as operational technology, test equipment, and government property | Documented and managed under your risk-based policies |
| Out-of-scope assets | Cannot handle CUI and provide no security protection for CUI assets | Not assessed, but must be separated from CUI assets |
The contractor risk managed category is the one to use carefully. It is for assets that could technically receive CUI but are prevented by documented policy and practice. If an assessor finds that the documentation or the practice does not hold up, the asset can be assessed as a CUI asset.
One detail from the rule is useful for boundary design. An endpoint that connects to a virtual desktop configured to allow only keyboard, video, and mouse traffic, with no ability to store or transfer CUI locally, can be treated as out of scope. Check the current rule text before you design around it.
Enclave or the whole enterprise
With the map in hand, choose a boundary. There are two broad options.
The whole enterprise. Every system is in scope. Users work as they do today, and there is no separate environment to maintain. The cost is that every laptop, every SaaS tool with access to CUI, and every administrator account must meet all applicable requirements.
An enclave. CUI is confined to a separate environment with its own accounts, devices or virtual desktops, storage, and controls. The rest of the company stays out of scope. The cost is the separation itself: users switching environments, duplicated tooling, and the discipline to keep CUI inside.
Say a hypothetical 80-person precision machining shop finds that CUI reaches only its engineering team, its quality team, and two shop-floor workstations. An enclave covering those people and systems is far smaller than the whole company. If instead CUI reached most staff through email and shared drives, an enclave would fight how the business works, and the enterprise approach may be simpler.
The enclave only works if the separation is real. If people routinely move files from the enclave to their regular laptop to print them, the enclave boundary is fiction, and an assessor who finds it will widen your scope. This is the same lesson as reducing PCI DSS scope: segmentation has to be enforced technically, not only by instruction.
Documenting the boundary
An assessor will ask how you know your scope is right. Have these ready:
- Not done:
An asset inventory with each asset's category, owner, and location
- Not done:
A network diagram showing the boundary and every connection across it
- Not done:
A data flow diagram showing how CUI enters, moves, and leaves
- Not done:
A boundary description in the system security plan
- Not done:
The rationale for each contractor risk managed and specialized asset
- Not done:
A list of external service providers and what each does in scope
Keep the inventory current. New SaaS tools, a new file share, or a new subcontractor can each move the boundary without anyone noticing. Add a scoping question to your change and procurement processes: does this touch CUI, or protect something that does?
Commonly missed in-scope systems
Backups and archives, including offsite and cloud copies.
Help desk and remote support tools, which can reach every in-scope endpoint.
Managed service providers' tooling, which acts as a security protection asset when it manages your in-scope systems.
Mobile phones receiving email with CUI attachments.
Multifunction printers and scanners with storage.
Logs and tickets that capture CUI in screenshots or attachments.
Our CMMC framework page and NIST 800-171 framework page cover how scope feeds into assessment.
How TrustLynce helps
TrustLynce collects evidence on a schedule from connected cloud, identity, HR, and code systems, timestamped and attributed, so the configuration behind each scoping decision has a dated record. When an assessor asks how you know the boundary holds, the history is already there. See evidence collection.