Technical Guide #4: How to Map Your CUI Boundary. What's In Scope and What Isn't

By Josh Hammer

That boundary determines what you must secure, what you must document, what an assessor may examine, and how much evidence your team must produce. Scope too broadly, and you may spend money securing systems that never touch CUI. Scope too narrowly, and you may leave an in-scope asset undocumented.

This guide walks through the actual scoping exercise.

It follows the CMMC asset categories in 32 CFR § 170.19 and the DoD’s CMMC Scoping Guide for Level 2. If you are working at Level 1, also review the DoD CMMC Scoping Guide for Level 1.

This guide assumes you have already worked through the distinction between FCI and CUI in Technical Guide #3. Now the question is more specific:

Where does CUI actually go, and which assets can touch it, protect it, or affect its confidentiality?

Start with the definition

Under 32 CFR § 170.19, the CMMC Assessment Scope is the set of all assets in your environment that must be assessed against CMMC security requirements.

The scope must be specified before the assessment. That means scoping is not a judgment call you make privately and explain only if someone asks. It is a documented decision that you must be prepared to defend.

Your scope should answer questions such as:

• Which systems process, store, or transmit CUI?
• Which security tools protect those systems?
• Which systems could affect CUI confidentiality even though they are not intended to handle CUI?
• Which operational technology, building systems, or test equipment requires special treatment?
• Which assets are genuinely separated and can be treated as out of scope?

The classification is what determines your obligation. Every asset should have a documented classification and a reason for that classification.

The five CMMC asset categories

For a Level 2 assessment, use these five categories. Do not begin by deciding what you hope will be out of scope. Begin by identifying what exists and how it interacts with CUI.

1. CUI Assets

What they are:

CUI Assets are assets that process, store, or transmit CUI.

The DoD uses these terms in a practical way:

• Process: The asset accesses, enters, edits, generates, manipulates, or prints CUI.
• Store: CUI is at rest on the asset, whether on electronic media, in system memory, or in physical form.
• Transmit: CUI moves from one asset to another through digital or physical means.

Are they in scope?

Yes. CUI Assets are fully in scope.

What do you owe for them?

You must:

• Record each asset in the asset inventory.
• Document its treatment by documenting it in your System Security Plan.
• Include it in the CMMC assessment-scope network diagram.
• Prepare for assessment against all applicable CMMC Level 2 security requirements.

Example:

A file server holding controlled technical drawings is a CUI Asset. So is the laptop used to open and review those drawings. If a mobile device downloads the drawings, that device is also in scope. If a cloud application stores the drawings, the relevant service and environment must be addressed as part of the scope.

Do not limit your inventory to servers. Email systems, collaboration platforms, CAD applications, virtual machines, removable media, mobile devices, and cloud tenants can all become CUI Assets.

2. Security Protection Assets

What they are:

Security Protection Assets provide security functions or capabilities to the CMMC assessment scope.

They may not process CUI themselves, but they protect, monitor, authenticate, manage, or defend systems that do.

Are they in scope?

Yes.

What do you owe for them?

You must:

• Record each asset in the asset inventory.
• Document its role and treatment in the SSP.
• Include it in the scope network diagram.
• Prepare for assessment against the CMMC requirements relevant to the security capabilities it provides.

Example:

A firewall protecting your CUI enclave is a Security Protection Asset. A SIEM collecting logs from the enclave is another. An identity provider managing authentication for CUI systems, or an endpoint management platform enforcing security settings, may also belong in this category.

A common mistake is to say, “The SIEM does not store CUI, so it is out of scope.” That is incomplete. Security logs and configuration data can be Security Protection Data, and the security service may provide capabilities directly supporting the assessment scope.

3. Contractor Risk Managed Assets

What they are:

Contractor Risk Managed Assets, or CRMAs, are assets that can, but are not intended to, process, store, or transmit CUI because of the organization’s security policies, procedures, and practices.

They are not required to be physically or logically separated from CUI Assets under the Level 2 scoping model. However, your documentation must explain how you prevent their intended use from becoming actual CUI handling.

Are they in scope?

Yes, for Level 2.

What do you owe for them?

You must:

• Record them in the asset inventory.
• Document their treatment in the SSP.
• Include them in the scope network diagram.
• Maintain risk-based policies, procedures, and practices that explain how they are managed.

An assessor will review the SSP. If the documentation is sufficient, the assessor generally does not assess the asset against every other CMMC requirement. If the documentation or other findings raise questions, a limited check may be performed.

Example:

A general-purpose workstation on the same network segment may be a CRMA if policy prohibits it from handling CUI, but its technical capabilities mean it could do so. The classification must be supported by actual policies and practices, not merely by what users are supposed to do.

A label is not a control. If users routinely download CUI to that workstation, it is no longer enough to describe the workstation as “not intended” to handle CUI.

4. Specialized Assets

What they are:

Specialized Assets are assets that can process, store, or transmit CUI but cannot be fully secured using ordinary information technology controls. The category includes assets such as:

• Internet of Things (IoT) and Industrial Internet of Things (IIoT) devices
• Operational Technology (OT)
• Government-furnished equipment
• Restricted information systems
• Test equipment

Are they in scope?

Yes, when they are part of the assessment environment.

What do you owe for them?

You must:

• Record them in the asset inventory.
• Document their treatment in the SSP.
• Show how they are managed using risk-based security policies, procedures, and practices.
• Include them in the scope network diagram.

They are not simply ignored because they cannot support every conventional security control. The scoping guides direct organizations to document and manage them based on their characteristics and risk. They are not assessed like ordinary CUI Assets against every applicable control in the same way.

Example:

A building automation system or machine tool controller connected to the production network may be a Specialized Asset. It may run an old operating system, have limited logging, or be difficult to patch without affecting safety or operations.

This is where facility related control systems cybersecurity becomes part of the CMMC discussion. Building management systems, fire control systems, physical access control systems, industrial control systems, and other OT can affect the confidentiality or security of the environment, especially when you are also configuring Microsoft 365 for compliance to protect the systems that hold CUI.

This is also the category most contractors misclassify. “It is just the building” is not a scoping analysis.

5. Out-of-Scope Assets

What they are:

An Out-of-Scope Asset is an asset that:

1. Cannot process, store, or transmit CUI; and
2. Does not provide security protections for CUI Assets; and
3. Is physically or logically separated from the CUI environment where separation is required to support the determination.

Are they in scope?

No.

What do you owe for them?

Out-of-Scope Assets are not assessed under the Level 2 CMMC assessment scope. However, you must be prepared to justify why the asset cannot handle CUI and does not provide security protection for CUI Assets.

The regulation does not require the same formal documentation for an Out-of-Scope Asset as it does for in-scope categories. In practice, you should still maintain an internal asset register with the classification and rationale for every asset. Otherwise, your organization cannot explain how the boundary was drawn.

Example:

A marketing team’s cloud-hosted project management tool may be out of scope if it genuinely cannot process, store, or transmit CUI, does not provide protection for CUI systems, and is genuinely separated from the CUI environment.

“Genuinely” matters. A service is not out of scope simply because the marketing team uses it. If someone uploads a controlled contract document, or if the service provides a security function for the CUI environment, the classification changes.

The step-by-step scoping exercise

Step 1: Inventory first, classify second

Build the asset list before assigning categories.

Include:

• Servers and workstations
• Network devices, firewalls, routers, and wireless access points
• Cloud services, cloud tenants, and hosted applications
• Mobile devices and tablets
• Virtual machines, hypervisors, and storage
• Email and collaboration platforms
• Identity and access management systems
• Security tools and logging platforms
• Manufacturing systems and control systems
• Building automation, physical access, and facility systems
• Contractor-managed infrastructure
• SaaS tools used by employees or project teams

Do not leave out shadow IT. Ask employees where they store contract documents, drawings, statements of work, schedules, and technical files. Review browser-based services, personal file-sharing accounts, and tools adopted by project teams without central approval.

Step 2: Follow the data, not the org chart

The boundary follows the data path, not the department structure.

Trace a realistic transaction:

1. A prime contractor makes CUI available through its portal.
2. An employee downloads it.
3. The file is sent through email or collaboration software.
4. The document is saved to a shared drive.
5. A CAD application opens or modifies it.
6. A subcontractor receives a copy.
7. Logs are sent to a SIEM.
8. Backup software copies the file or its associated data.

Each step raises a scoping question.

Do not draw the boundary around “the engineering department” or “the federal contracts team.” Draw it around the systems and people that actually touch, manage, transmit, protect, or can affect the CUI.

Step 3: Classify every asset and write down why

For each asset, record:

• Asset name and owner
• Location or cloud tenant
• Data handled
• Connections to other systems
• Asset category
• Classification rationale
• Applicable policies or restrictions
• Whether it appears in the SSP and network diagram

If you cannot write a short reason, the classification is not ready.

Step 4: Decide whether to use an enclave

An enclave concentrates CUI in a dedicated, isolated environment so the rest of the organization’s systems can remain outside the CUI boundary where the facts support that conclusion.

A properly designed enclave can reduce the number of systems you must secure and the volume of evidence you must maintain. For a small contractor, this is often the single highest-leverage cost decision in the entire program. It also only works if you begin by confirming what data you actually handle.

But an enclave is not a separate folder on a file server. It requires genuine logical or physical separation. That may include dedicated identity controls, network segmentation, boundary protection, restricted endpoints, controlled data transfers, and clearly defined administrative access.

It also changes how people work. Users may need to access CUI through dedicated workstations, a controlled virtual desktop, or a restricted application environment.

Make this decision before purchasing hardware, selecting a cloud architecture, or buying compliance tooling. Otherwise, you may spend money building controls around an environment you later redesign.

Step 5: Document the boundary in the SSP and a network/data-flow diagram

The SSP should explain:

• What is inside the assessment scope
• Which category applies to each asset
• How CUI enters, moves through, and leaves the environment
• How Specialized Assets are managed
• How CRMAs are restricted and risk-managed
• How external service providers support the environment
• What separation supports any out-of-scope determination

The network and data-flow diagram is not decoration. It is the artifact that makes your scoping decision reviewable.

A useful diagram should show systems, trust boundaries, data flows, security tools, external providers, remote access paths, and relevant facility or control-system connections. If you need a practical model for structuring that documentation, see how to write your SSP.

Step 6: Re-scope when the environment changes

Scoping is not a one-time exercise.

Trigger a review when you have:

• A new contract
• A new subcontractor
• A new cloud service
• A new control system
• A merger or acquisition
• A new office, plant, or facility
• A major network redesign
• A new method for exchanging CUI

Scope drift is the quiet way programs fail. The original diagram may have been accurate when created, but not after a new SaaS platform, facility system, or subcontractor enters the workflow.

What actually goes wrong

“The control system is just the building”

Problem: A building automation, physical access, or industrial control system is labeled out of scope because it is considered facilities equipment.

Fix: Determine whether it can process, store, or transmit CUI, provide security protections, connect to in-scope systems, or affect CUI confidentiality. If it cannot be fully secured using ordinary controls, evaluate it as a Specialized Asset and document the risk-based treatment.

“The cloud vendor is compliant, so the service is out of scope”

Problem: The organization assumes a vendor’s compliance statement removes the service from its own boundary.

Fix: Determine what the service processes, stores, or transmits and what security function it provides. Document the service, its responsibilities, its connection to your environment, and the relevant customer responsibility information. A vendor’s status does not eliminate your scoping obligation.

“Contractors and integrators are not on the diagram”

Problem: A subcontractor, managed service provider, or systems integrator is omitted because it is not an employee or internal system.

Fix: Follow the data. If the party touches CUI, manages a system that handles CUI, or provides security functions, include the relevant people, technology, facilities, and responsibilities in your analysis. Contractual obligations and flow-down requirements must match the actual data path.

“The boundary covers systems but not people”

Problem: The diagram shows a protected enclave, but privileged administrators can reach every system from ordinary workstations or accounts.

Fix: Map administrative access, remote support, identity providers, privileged accounts, help-desk tools, and service accounts. A boundary that ignores people with access is incomplete.

“Nobody can draw the boundary on a whiteboard”

Problem: The organization has spreadsheets and policy documents, but no one can explain the scope clearly.

Fix: Practice a five-minute explanation. Show where CUI enters, where it is stored, who can access it, which tools protect it, and where the boundary ends. If the explanation requires contradictory assumptions, your scope is not documented well enough to defend.

Printable: scope your boundary checklist

1. Identify the required CMMC level and confirm whether the environment handles FCI, CUI, or both.
2. Build a complete asset inventory before assigning any classifications.
3. Include servers, endpoints, networks, cloud tenants, SaaS tools, mobile devices, virtual infrastructure, security tools, facilities, and control systems.
4. Trace CUI from the prime contractor or government source through every system, user, provider, and storage location.
5. Classify every asset as a CUI Asset, Security Protection Asset, CRMA, Specialized Asset, or Out-of-Scope Asset.
6. Write the reason and supporting facts for each classification.
7. Decide whether a genuinely separated CUI enclave is appropriate before buying hardware or compliance tooling.
8. Confirm administrative, contractor, integrator, and external service provider access paths.
9. Record the boundary in the asset inventory, SSP, and network/data-flow diagram.
10. Set trigger events for re-scoping after contract, vendor, facility, system, or organizational changes.

Keep the boundary current

The boundary is not a one-time decision. It drifts whenever a contract, vendor, facility, application, or control system changes. That is exactly where manual tracking begins to break down.

Sources

• 32 CFR § 170.19 - CMMC assessment scoping categories and requirements
• DoD CMMC Scoping Guide for Level 2 - official Department of Defense scoping guide
• DoD CMMC Scoping Guide for Level 1 - official Department of Defense scoping guide

Read next in this series: Technical Guide #5: How to Write Your System Security Plan (SSP), Technical Guide #6: Configuring Microsoft 365 for Compliance, and the free compliance readiness check.

Complynt is an enterprise compliance automation platform for control mapping, evidence collection, continuous monitoring, pre-built content packs, and policy-as-code. It supports mapping across 150+ frameworks, including CMMC, NIST SP 800-171, NIST SP 800-53, RMF, SOC 2, HIPAA, and ISO 27001. Complynt runs on FedRAMP High and DoD IL5 authorized infrastructure on Palantir’s federal cloud, and H&V is EDWOSB certified.

The sequence still matters: audit first, plan second, tools third. A platform can help you track a boundary, but it cannot decide whether a building automation system belongs inside it. H&V does not issue certification and cannot guarantee any assessment outcome.

Start with the free compliance readiness check or visit hvfsusa.com.