CMMC Scoping Explained: What Counts as “In-Scope” at Your Company
For CMMC Level 2, your scope is every asset that processes, stores, or transmits CUI, plus every asset that protects those systems or can connect to them. That boundary decides how much you build, what you pay, and what an assessor will test, so getting it wrong means either overspending or failing.
Last updated: October 2026
Scoping is the first decision in any CMMC program, before tools, policies, or a single control. This guide walks through the five asset categories in the DoD CMMC Scoping Guide for Level 2, how a CUI enclave shrinks your boundary, where outside providers fit, and the mistakes that cause failed assessments.
The five asset categories at a glance
32 CFR Part 170 and the DoD CMMC Scoping Guide (Level 2) sort every asset into one of five categories. Each one is treated differently in an assessment.
| Category | Definition | In scope? | Assessment treatment | Example |
|---|---|---|---|---|
| CUI Assets | Assets that process, store, or transmit CUI | Yes | Assessed against all 110 Level 2 security requirements | Engineering workstations, file servers, email, and printers or scanners that handle CUI |
| Security Protection Assets | Assets that provide security functions or capabilities for the CUI environment, whether or not they touch CUI | Yes | Assessed against the requirements relevant to the capabilities they provide | Firewalls, identity platforms, SIEM, EDR, VPN gateways, and an MSP or SOC that protects your environment |
| Contractor Risk Managed Assets (CRMAs) | Assets that can, but are not intended to, handle CUI because of your security policies, procedures, and practices | Yes | Documented in the inventory, SSP, and network diagram; the assessor reviews the SSP and may run limited checks | Corporate laptops on the same network that are blocked by policy and technical controls from handling CUI |
| Specialized Assets | IoT and industrial IoT, operational technology, government-furnished equipment, restricted information systems, and test equipment | Yes | Documented in the inventory, SSP, and network diagram; not assessed against other Level 2 requirements | CNC machines, PLCs, lab test rigs, and government-furnished laptops |
| Out-of-Scope Assets | Assets that cannot handle CUI and do not provide security protections for CUI assets, separated physically or logically | No | Not assessed, but the assessor may verify the separation | Guest Wi-Fi, an isolated corporate network with no path to the enclave, and a home PC that only runs a locked-down virtual desktop |
Scroll the table sideways on a phone to see every column.
A quick way to sort any asset
Work through these questions in order for every system, device, and service. Stop at the first yes.
| Ask this about the asset | If yes | If no |
|---|---|---|
| Does it process, store, or transmit CUI? | CUI Asset | Go to the next question |
| Does it protect, monitor, or control access to CUI assets? | Security Protection Asset | Go to the next question |
| Is it IoT, OT, test equipment, government-furnished, or a restricted system? | Specialized Asset | Go to the next question |
| Could it reach CUI, but policy and technical controls keep it from doing so? | Contractor Risk Managed Asset | Go to the next question |
| Is it physically or logically separated from the CUI environment? | Out-of-Scope Asset | Treat it as in scope until you can separate it |
CUI Assets
CUI Assets are any assets that process, store, or transmit Controlled Unclassified Information. They are always in scope and are assessed against all 110 security requirements in NIST SP 800-171 Rev 2.
The test is broad. If a device touches CUI at all, even by printing, scanning, caching, or passing it through, it counts. That includes:
- Laptops and workstations where people open CUI
- File shares, SharePoint sites, and collaboration tools that hold CUI
- Email systems that send or receive CUI
- Printers, scanners, and multifunction devices used for CUI
- Servers and applications, such as ERP or PLM systems, that store technical data
Security Protection Assets
Security Protection Assets provide security functions for your CUI environment, even if they never touch CUI themselves. They are in scope and assessed against the requirements that apply to what they do.
Common examples:
- Firewalls, VPN gateways, and jump servers
- Identity and access platforms such as Entra ID or Active Directory
- SIEM, logging, and endpoint detection and response tools
- Patch management and remote monitoring and management (RMM) tools
- People and services from outside providers, such as an MSP or managed SOC, that protect the environment
If one of these tools sits outside your enclave but manages assets inside it, it is still a Security Protection Asset. Plan for that when you choose tools.
Contractor Risk Managed Assets (CRMAs)
CRMAs can reach CUI, but are not intended to, because your security policies, procedures, and practices keep CUI off them. They are in scope, but they are not assessed against every requirement.
What you must do for a CRMA:
- List it in your asset inventory
- Explain in your SSP how you manage it and why it does not handle CUI
- Show it on your network diagram
The assessor reviews that documentation. If it does not hold up, the assessor can run limited checks, and an asset that turns out to handle CUI gets treated as a CUI Asset. A CRMA only works when real technical controls back up the policy.
Specialized Assets
Specialized Assets are systems that often cannot be fully secured to NIST SP 800-171, such as:
- Internet of Things and industrial IoT devices
- Operational technology, including CNC machines and PLCs on the shop floor
- Government-furnished equipment
- Restricted information systems
- Test equipment
At Level 2, you document them in the asset inventory, SSP, and network diagram, and show how you manage them. They are not assessed against the other Level 2 requirements. At Level 3, they are fully in scope. For manufacturers with CUI on the shop floor, this category matters a great deal.
Out-of-Scope Assets
Out-of-Scope Assets cannot process, store, or transmit CUI and do not protect CUI assets. They have to be physically or logically separated from the CUI environment, and the assessor may check that the separation is real.
Examples include guest Wi-Fi, a corporate network with no path into your enclave, and a separate business unit that never sees CUI. An endpoint that only connects to a virtual desktop configured to block any CUI from reaching the endpoint can also be out of scope.
Enclave strategy: shrink the boundary on purpose
A CUI enclave is a separated environment where all CUI work happens. Done right, only the enclave and the Security Protection Assets that support it fall under Level 2. The rest of your company can stay out of scope.
Why government cloud enclaves work well
Microsoft 365 GCC High, Azure Government, and AWS GovCloud are built for CUI. They carry FedRAMP High authorization, which meets the DFARS 7012 requirement of FedRAMP Moderate or equivalent. They also give you tenant isolation and U.S. data residency from day one.
Using one as the backbone of your enclave usually shrinks on-premises scope sharply. The usual pattern:
- CUI lives only in the government cloud tenant
- Users reach it through managed devices or a locked-down virtual desktop
- The everyday corporate network stays separate
Learn more in CMMC: what is a government cloud enclave, and compare Microsoft options in GCC High vs GCC vs Commercial Microsoft 365. For infrastructure workloads, see AWS GovCloud explained for defense contractors.
Encryption alone does not create separation
This is the most common enclave mistake. Encrypting CUI does not take the systems it passes through out of scope. Separation has to be enforced with network and access controls that actually stop CUI from moving between the enclave and everything else.
A VLAN with permissive firewall rules, a shared admin account, or a sync client that copies files to unmanaged laptops can all pull the wider network back into scope.
External service providers: in scope whether you like it or not
Cloud platforms, MSPs, and managed SOCs often surprise contractors. If a provider handles CUI or protects your CUI environment, its services fall inside your assessment scope.
The assessor does not assess your provider as a separate company. What they do assess is whether the controls your provider runs for you meet the requirements. If the provider cannot show that, the gap is yours.
| Provider type | When it is in your scope | Evidence to have ready |
|---|---|---|
| Cloud service provider (CSP) | It processes, stores, or transmits CUI | FedRAMP Moderate authorization or equivalent, a customer responsibility matrix, and DFARS 7012 terms for incident reporting |
| Managed service provider (MSP) | It administers, patches, or has remote access to in-scope systems | A service description, a customer responsibility matrix, and evidence for the controls it performs on your behalf |
| Managed SOC or SIEM provider | It monitors, logs, or responds to events in your CUI environment | Log sources and retention, an incident response handoff process, and evidence for audit and incident response controls |
| Other ESPs, such as a backup or help desk provider | Its service touches CUI or protects CUI assets | Contract terms, a responsibility split, and proof that its access is controlled, logged, and limited |
What to put in place with every provider
- A customer responsibility matrix. Spell out which controls the provider performs, which you perform, and which are shared.
- SSP entries. Describe each provider, the services it delivers, and how it connects to your environment.
- Contract terms. Make sure your agreements cover incident reporting, access, and evidence.
- Evidence on request. Know how you will get logs, screenshots, and policies from the provider during an assessment.
The CMMC rule does not require your MSP to hold its own CMMC certification, though some primes ask for it. VSO is CMMC Level 2 certified and builds CMMC-aligned controls and responsibility matrices into its managed services engagements, so clients are not left with a documentation gap.
Documenting your scope
Your scope has to be written down, and assessors review these documents before the assessment begins. Gaps or mismatches between them are a common failure point.
System Security Plan (SSP)
The SSP is where your scope decisions live. It should describe your boundary, list each asset category, explain how you manage CRMAs and Specialized Assets, and document your external service providers and what they do.
Asset inventory
List every in-scope asset with its category, owner, location, and function. Include cloud services and provider tools, not just hardware. Keep it current: an inventory that is a year old will not match what the assessor finds.
Network diagram
Show the assessment boundary clearly, along with how CUI flows in and out, where the security tools sit, and how out-of-scope networks are separated. The diagram, the inventory, and the SSP should all tell the same story.
These documents also drive your SPRS score and your annual affirmation. For how they connect to your contract obligations, see our DFARS 7012, 7019, 7020 and 7021 cheat sheet.
Common scoping mistakes
- “We don’t store CUI.” Email, file sharing, and Teams chats often carry CUI that came in with a contract.
- Treating encryption as separation. Encrypted CUI still puts the systems it passes through in scope.
- Trusting a VLAN alone. Segmentation needs enforced rules and controlled access, not just a separate subnet.
- Forgetting security tools. SIEM, EDR, RMM, backup, and identity systems are Security Protection Assets.
- Ignoring remote access. VPN gateways, jump servers, and remote desktop infrastructure are in scope.
- Overlooking printers and scanners. If they handle CUI, they are CUI Assets.
- Missing mobile devices. Phones used for CUI email or for access to CUI systems may be in scope, depending on how they are used and managed.
- Leaving providers out of the SSP. MSPs, SOCs, and cloud providers need to be documented with a clear split of responsibilities.
- Calling an asset a CRMA without controls. Policy alone is not enough to keep CUI off a system.
- Documents that disagree. The SSP, inventory, and diagram describe different environments.
Where CMMC stands in 2026
The Department of War suspended CMMC Phase 2 on July 13, 2026, pausing third-party certification requirements in new contracts while a reform task force reviews the program. Scoping still matters. Your NIST SP 800-171 self-assessment, SPRS score, and annual affirmation all depend on a defined boundary, and primes can still require certification.
Get your scope right the first time
A well-defined scope keeps your compliance program proportionate to your real risk, defensible under scrutiny, and sustainable for the life of your contracts. VSO helps defense contractors define, document, and defend their boundary, and we scope exactly what you ask for. Learn more about our CMMC services, call (888) 805-0510, email sales@vso-inc.com, or request a scoping review.
Comparing government clouds for your enclave? See Azure Government vs AWS GovCloud.
Official sources: 32 CFR Part 170 on eCFR and DoD CIO CMMC program and scoping guides.
Frequently asked questions
