top of page
TKC showing customer.jpg

CMMC Scoping & Compliance Boundary Guide

If you get scoping wrong, everything downstream gets harder.

CMMC scoping is the process of defining which people, systems, software, locations, and service providers are part of the environment that will be assessed. At CMMC Level 2, that means mapping your environment into the DoD’s asset categories, documenting those assets in your inventory and SSP, and drawing a boundary you can actually defend during pre-assessment and assessment. The DoD’s Level 2 scoping guidance and 32 CFR § 170.19 are explicit that the assessment scope must be defined before the assessment begins.

Man holding a laptop. Woman behind and on the side. Another man on the other side dressed as a soldier.

The short version

A workable CMMC boundary does four things:

  1. It identifies where CUI is actually processed, stored, or transmitted. 

  2. It classifies the rest of the environment correctly: security tools, contractor-risk-managed systems, specialized assets, and truly out-of-scope assets. 

  3. It accounts for MSPs, MSSPs, SIEM tools, VPNs, cloud services, and any other external providers that touch CUI or security protection data. 

  4. It is documented well enough that an assessor can follow the logic without guessing. The DoD guidance repeatedly points to the asset inventory, SSP, network diagram, and—when ESPs are involved—the service description and customer responsibility matrix. 

man self assess cmmc.jpg

Why scoping matters so much

Under current DFARS policy, contractors must have the required current CMMC status at the level specified in the solicitation for all information systems used in contract performance that process, store, or transmit FCI or CUI. Contracting officers are not supposed to award to an offeror that lacks the required current status. 

That is why scoping is not just a technical exercise. It affects:

  • what systems are assessed,

  • what documentation you need,

  • which providers become part of your boundary,

  • how much remediation work you take on,

  • and how expensive your path to readiness becomes. 

 

Organizations consistently underestimate how much scoping affects cost, speed, and audit outcomes. Scoping errors are one of the most common reasons readiness efforts stall or expand unexpectedly.

What “scoping” means at Level 2

For Level 2, the DoD says your environment should be mapped into five asset categories. Those categories define what is assessed, what is only partially checked, and what can stay out of scope.

These are assets that process, store, or transmit CUI. They are fully in scope and are assessed against all Level 2 security requirements. The scoping guide says CUI can be processed, stored, or transmitted digitally or physically, including paper documents. 

2) Security Protection Assets

These are assets that provide security functions or capabilities to the in-scope environment. Think SIEM, hosted VPN, cloud-based security tools, SOC functions, certain administrators, and similar protections. They are in scope, but they are assessed against the Level 2 requirements relevant to the capabilities they provide.

3) Contractor Risk Managed Assets

These are assets that can process, store, or transmit CUI, but are not intended to because of the security policies, procedures, and practices you have in place. They are still part of the Level 2 assessment scope. If they are well documented in the SSP and supporting material, they may avoid a full assessment against all other requirements; if not, the assessor can perform a limited check. 

4) Specialized Assets

These are assets that can process, store, or transmit CUI but are not able to be fully secured in the conventional way. The rule and guide call out examples such as IoT, IIoT, OT, government-furnished equipment, restricted information systems, and test equipment. They are in the Level 2 assessment scope, but the scoping guide says the assessor reviews the SSP rather than assessing them against the full set of Level 2 requirements. 

5) Out-of-Scope Assets

These are assets that cannot process, store, or transmit CUI and do not provide security protections for CUI assets. They also must be physically or logically separated enough to justify that status. Out-of-scope assets have no assessment requirements, but the organization should be ready to justify why they are out. A VDI client that is configured so no CUI is processed, stored, or transmitted beyond keyboard/video/mouse is specifically identified as out of scope.

How to define your compliance boundary

Step 1:
Identify where CUI enters, lives, moves, and exits

Start with the data, not the tools. The DoD scoping guide defines “process,” “store,” and “transmit” broadly enough that many organizations miss assets when they think only about servers and laptops. Physical handling counts too. Industry practitioners are also stressing that assessors want to understand real data movement, including paper and hand-carried media.

Step 2:
Classify every relevant asset

Once you know where CUI touches the business, assign each asset to the correct Level 2 category: CUI Asset, Security Protection Asset, Contractor Risk Managed Asset, Specialized Asset, or Out-of-Scope Asset. The official rule and guidance are built around these categories.

Step 3:
Document the boundary

The Level 2 scoping guide says the organization must document in-scope categories in an asset inventory, document treatment in the SSP, and provide a network diagram of the assessment scope for pre-assessment scoping discussions.

Step 4:
Validate your providers

Do not assume your MSP, MSSP, SOC, SIEM, backup vendor, or cloud provider is out of scope. If a provider processes CUI or security protection data, or provides security functions to the assessed environment, it can pull services or assets into scope.

Step 5:
Use separation intentionally

The DoD says effective separation can limit the CMMC assessment scope. It can be physical, logical, or both. Examples include subnetworks, firewalls, boundary protection devices, VLANs, VPNs, and manual transfer for physically separated systems. Separation is required for assets you want to defend as truly out of scope.

Step 6:
Re-check the scope when the environment changes

The scoping guidance notes that assessments are valid for a defined assessment scope. If the environment or boundary changes materially, the scope logic needs to be revisited. 

External Service Providers, MSPs, MSSPs, and cloud

This is where many organizations get surprised.Under 32 CFR § 170.19, the organization has to determine whether an external service provider is a CSP and whether that provider processes, stores, or transmits CUI and/or Security Protection Data (SPD).

If the provider processes CUI
  • If the provider is a cloud service provider, it must meet the FedRAMP requirements in DFARS 252.204-7012. 

  • If the provider is not a CSP, the services are in the organization’s assessment scope and are assessed as part of the organization’s assessment. 

Enclave or full-enterprise scope?

Sometimes the right answer is not “bring the whole company into scope.”

The DoD’s scoping guide says separation can be used to limit the assessment scope. Many organizations use enclave strategies to create a smaller, more controlled boundary. A CUI enclave is typically a defined environment with a clear perimeter that separates sensitive data and systems from the rest of the business.

A narrower boundary often makes sense when:

  • only a small portion of the organization interacts with CUI

  • reducing assessment scope is a priority

  • or a faster path to readiness is required

 

A broader scope may make more sense when:

  • CUI is deeply embedded across operations,

  • multiple business units touch the same data,

  • or maintaining an enclave would create too much process friction.

 

The key point is this: scope should follow real data use, not wishful thinking. The boundary has to be both operationally workable and defensible to an assessor. 

Drone Flying Outdoors

Common scoping mistakes to avoid

Treating scoping as an IT-only project

Industry practitioners keep warning that IT alone will miss where CUI actually lives. Contracts, business development, engineering, program teams, and even physical handling workflows can affect scope.

Missing platforms and asset types

A common issue during scoping is discovering late-stage assets—such as Linux systems or specialized platforms—that were not originally included in the environment definition.

Over-classifying everything as CUI

Not everything should become a CUI Asset. Over-classification expands scope and burden unnecessarily. The asset categories exist so organizations can classify assets more precisely.

Forgetting paper, printers, and hand-carried media

Physical handling of CUI—such as printed documents, shared spaces, and manual transfer—can expand the compliance boundary if not properly accounted for.

Ignoring backup behavior and cloud defaults

Backup systems and cloud defaults can unintentionally expand scope if CUI or related data is stored or replicated without clear controls.

What good scoping evidence looks like

A defensible scoping package usually includes:

  • a current asset inventory,

  • an SSP that explains how each in-scope category is treated,

  • a network diagram of the assessment scope,

  • documentation for contractor-risk-managed and specialized assets,

  • and, where relevant, ESP service descriptions and customer responsibility matrices. 

 

That documentation should tell a coherent story:

  • where CUI is,

  • how it moves,

  • which protections support it,

  • which providers are involved,

  • and why out-of-scope claims are justified.

 

This is also where human readability matters. If an assessor cannot follow the story of your boundary, your scope is probably not mature enough yet.

CMMC Scoping FAQ

What is the CMMC compliance boundary?

It is the defined set of assets in your environment that will be assessed against CMMC requirements. At Level 2, that boundary is built by classifying assets into the DoD’s Level 2 categories and documenting them appropriately. 

 

Are MSPs automatically in scope for CMMC?

No. But if an MSP or other provider processes CUI, handles security protection data, or provides security functions to the assessed environment, some or all of its services may fall into the organization’s assessment scope. 

 

Does a cloud provider need FedRAMP for CMMC?

If the CSP processes, stores, or transmits CUI for the organization, the DoD says it must meet the FedRAMP requirements in DFARS 252.204-7012. If the cloud service does not handle CUI, that FedRAMP requirement is not triggered in the same way. 

 

Do printers, paper files, or physical locations count in scoping?

Yes. The DoD’s Level 2 scoping guidance explicitly recognizes physical forms of CUI such as paper documents, and practitioners warn that printouts and physical handling workflows can pull locations into scope. 

 

What is a Contractor Risk Managed Asset?

It is an asset that can, but is not intended to, process, store, or transmit CUI because of the security policies, procedures, and practices in place. It is still part of the Level 2 assessment scope. 

 

Can separation reduce my CMMC scope?

Yes. The DoD says physical and logical separation can be used to limit scope, especially for defining what is truly out of scope. But the separation has to be real, documented, and defensible. 

Stay Ahead With Expert CMMC Knowledge

CMMC requirements continue to evolve, and staying informed is critical to maintaining compliance. Our insights provide practical guidance, regulatory updates, and real-world perspectives to help organizations navigate CMMC with confidence.

bottom of page