Before an assessor ever looks at a single control, they look at your scope. Get the boundary wrong and everything downstream; your controls, your documentation, your assessment outcome is built on a shaky foundation. This guide answers the question directly: which document defines CMMC assessment scope, what the regulation actually requires, and how to document your boundary so it holds up on assessment day.
In This Guide
- 01
The Short Answer: What Document Defines CMMC Assessment Scope? - 02
What Is a CMMC Assessment Scope? - 03
CMMC Level 1 Scoping (FCI Assets) - 04
CMMC Level 2 Scoping: The 5 Asset Categories - 05
The Three Documents That Prove Your Scope - 06
External Service Providers (ESPs) and Security Protection Data (SPD) - 07
Reducing Scope with Enclave Architecture - 08
How Assessors Validate Your Scope - 09
Common CMMC Scoping Mistakes - 10
Why Scope Is a Legal Commitment, Not Just a Technical One - 11
How Nexeris Helps You Get Your CMMC Scope Right the First Time - 12
FAQs
The Short Answer: What Document Defines CMMC Assessment Scope?
There isn’t a single form you fill out and file away. CMMC assessment scope is defined through a combination of a federal regulation, official DoD guidance documents, and three pieces of your own documentation. Together, they establish exactly which people, systems, facilities, and third parties fall inside your assessment boundary. If you’re working with a CMMC compliance consulting partner, this is usually the very first thing they’ll help you nail down, because nothing else in the process can proceed reliably until scope is settled.
32 CFR § 170.19: The Regulatory Scoping Requirement
The legal foundation for CMMC scoping sits in 32 CFR § 170.19. Under this regulation, the CMMC Assessment Scope is defined as the set of all assets in the Organization Seeking Assessment’s (OSA) environment that will be assessed against CMMC security requirements. The regulation requires that scope be specified before any self-assessment or certification assessment can proceed, and it sets separate requirements for Level 1, Level 2, and Level 3 scoping. This isn’t optional guidance. It’s a binding requirement that has to be satisfied before an assessor will even begin evaluating your controls.
The DoD’s Official CMMC Scoping Guides (Level 1 and Level 2)
Alongside the regulation, the DoD CIO publishes separate scoping guides for each level. The Level 1 Scoping Guide is a short document focused on FCI Assets, the systems that process, store, or transmit Federal Contract Information. The Level 2 Scoping Guide is longer and more detailed, breaking assets into five distinct categories that determine what falls inside and outside your assessment boundary. These guides are the practical, how-to companion to the regulation itself, and they’re what most organizations actually reference day to day when scoping their environment.
How the SSP, Asset Inventory and Network Diagram Work Together
Regulation and guidance tell you the rules. Your own documentation is what proves you followed them. Three documents work together to demonstrate your scope: the System Security Plan describes how each in-scope asset is protected, the asset inventory lists every asset and categorizes it, and the network diagram shows the boundary visually, including how Controlled Unclassified Information flows through your environment. An assessor reviews all three before the assessment even begins, and any inconsistency between them is one of the fastest ways to derail an otherwise well-prepared engagement.
How Scope Connects to Your Gap Assessment (320 Assessment Objectives)
Scope isn’t just a compliance formality. It’s what determines the size of the gap assessment ahead of you. The 110 NIST SP 800-171 security requirements break down into 320 individual assessment objectives, and every one of them applies to the assets inside your documented boundary. A narrow, accurate scope means a narrower, faster gap assessment. A broad or poorly defined scope means more objectives to evaluate, more controls to implement, and a longer, more expensive path to certification.
What Is a CMMC Assessment Scope?
A CMMC compliance program starts with a simple but consequential decision: drawing the line around what actually gets assessed. Your CMMC Assessment Scope is that line. It’s the documented boundary containing every person, system, facility, and external service provider that touches Federal Contract Information or Controlled Unclassified Information, directly or in a way that supports its protection.
Why Scope Is Defined Before Controls Are Assessed
Controls can’t be evaluated in a vacuum. An assessor needs to know exactly which systems, accounts, and locations they’re checking multi-factor authentication on, which network segments they’re reviewing for boundary protection, and which personnel they need to interview. Scope answers all of those questions before a single control is tested. Skipping straight to control implementation without a defined boundary means implementing security measures in places that may not have needed them, while potentially missing places that did.
What Happens If Your Scope Is Defined Incorrectly
Scoping errors cut in two directions, and both are expensive. Scope too broadly, and you end up securing, documenting, and paying to assess systems that never handled CUI or FCI in the first place, inflating your cost and timeline for no security benefit. Scope too narrowly, and an assessor eventually finds an asset handling CUI that wasn’t included in your boundary, which can stall the assessment entirely or result in a failed engagement. Neither outcome is recoverable without going back and redoing the scoping work, so getting it right the first time matters more than almost any other early decision in the process.
CMMC Level 1 Scoping (FCI Assets)
Level 1 scoping is narrower than Level 2, but it still requires deliberate documentation, not a shortcut.
What Assets Are In Scope for a Level 1 Self-Assessment
For a Level 1 self-assessment, any information system that processes, stores, or transmits Federal Contract Information is in scope and must be evaluated against the applicable CMMC security requirements. This typically includes workstations, email systems, file storage, and any application handling contract-related data that isn’t intended for public release.
People, Facilities and External Service Providers to Consider
Scoping a Level 1 self-assessment isn’t limited to hardware. Organizations should also account for the people who interact with FCI, the physical facilities where that information is processed or stored, including satellite offices and shared workspaces, and any External Service Providers that process, store, or transmit FCI on the organization’s behalf.
What Level 1 Explicitly Excludes
Level 1 scoping guidance identifies Specialized Assets, such as Internet of Things devices, Operational Technology, government property, restricted information systems, and test equipment, as outside the Level 1 self-assessment scope. These assets aren’t assessed against CMMC practices at Level 1, though organizations should still be aware of where they sit relative to FCI, since guidance in this area has been described as somewhat inconsistent in practice.
CMMC Level 2 Scoping: The 5 Asset Categories
Level 2 applies once your organization handles Controlled Unclassified Information, and the scoping guidance for this level is considerably more detailed than Level 1. The DoD’s Level 2 Scoping Guide organizes every asset in your environment into one of five categories.
CUI Assets
CUI Assets are systems, people, or facilities that directly process, store, or transmit CUI. This is the most straightforward category and the one every other category exists to protect. CUI Assets are assessed against all 110 Level 2 security requirements, with no exceptions.
Security Protection Assets (SPA)
Security Protection Assets don’t necessarily handle CUI themselves, but they provide security functions that protect the CUI environment. Your SIEM, firewalls, identity and access management platform, and endpoint detection tools all fall into this category. They’re in scope and assessed against the requirements relevant to the security function they perform, precisely because a weakness in the tools protecting CUI is just as dangerous as a weakness in the systems holding it.
Contractor Risk Managed Assets (CRMA)
Contractor Risk Managed Assets are capable of touching CUI but are deliberately kept from it through documented policy and risk-based controls, rather than physical or logical separation. These assets must be documented in the asset inventory and SSP, with a clear written rationale for why they aren’t treated as CUI Assets. A collaboration tool your policy prohibits from carrying CUI, but that technically could, is a common example.
Specialized Assets
Specialized Assets include Internet of Things devices, Operational Technology, government-furnished equipment, restricted information systems, and test equipment. At Level 2, these are documented in the asset inventory and SSP and managed under risk-based policies rather than assessed against the full 110-requirement set. That treatment changes at Level 3, where Specialized Assets face fuller assessment scrutiny.
Out-of-Scope Assets
Out-of-Scope Assets have no connectivity to the CUI environment and provide no security function protecting it. A guest Wi-Fi network or a physically isolated lab can legitimately sit outside your assessment boundary, but only when backed by documented, enforceable separation. Simply asserting that an asset is out of scope isn’t sufficient; an assessor will expect to see the segmentation that makes the claim true.
The Three Documents That Prove Your Scope
Regulation and guidance define the rules of scoping. These three documents are how you prove, in writing, that you followed them.
System Security Plan (SSP)
Your System Security Plan template is the anchor document for your entire scope. It describes how every in-scope asset is protected, who’s responsible for each control, and, critically, the written rationale for any Contractor Risk Managed Assets excluded from full CUI treatment. Assessors review the SSP closely, and it needs to reflect the environment as it actually exists, not as it was planned to exist at some point in the past.
Asset Inventory
The asset inventory is the master list: every device, system, application, and service categorized into one of the five Level 2 asset categories, or documented as in scope for Level 1. It has to be complete and kept current, since a single undocumented asset handling CUI can undermine an otherwise strong assessment.
Network Diagram / CUI Data Flow Diagram
The network diagram shows your assessment boundary visually, mapping how CUI enters your environment, where it’s processed and stored, and where it exits or is disposed of. This diagram needs to match the asset inventory and the SSP exactly. When the three documents tell different stories about where the boundary sits, that mismatch is one of the most common reasons an assessment stalls before it even gets to control testing.
External Service Providers (ESPs) and Security Protection Data (SPD)
Many organizations assume that if a system is run by a vendor rather than their own IT team, it falls outside their responsibility. Under CMMC, that assumption is usually wrong.
When Your MSP, CSP or SOC Provider Is In Scope
If a managed service provider, cloud service provider, or security operations center touches, processes, or protects your CUI environment, that provider is a Security Protection Asset under your assessment scope. The assessor doesn’t evaluate the vendor directly, but you’re expected to demonstrate that the vendor’s controls satisfy the CMMC requirements relevant to the services they provide. A provider that can’t document their own security posture creates a gap that lands squarely on your assessment, not theirs.
FedRAMP Moderate Requirements for Cloud Service Providers
Any cloud service provider that stores, processes, or transmits CUI on your behalf is required to meet FedRAMP Moderate authorization, or provide a body of evidence from a certified FedRAMP third-party assessment organization demonstrating equivalent controls. Confirming this before you build your environment around a given cloud platform avoids a painful and expensive rework later.
What Belongs in a Customer Responsibility Matrix
A Customer Responsibility Matrix maps every applicable security requirement to who implements it: the provider, your organization, or both, jointly. Requesting this matrix from every in-scope ESP before your assessment gives you a clear picture of where your responsibility actually starts and ends, and it’s evidence an assessor will expect to see referenced in your SSP.
Subcontractor and Supply Chain Scope Obligations
Scope doesn’t stop at your own organization’s edge. If CUI flows to a subcontractor, that data pipeline stays within your responsibility, and your CMMC flow-down requirements mean you’re expected to confirm that subcontractor has appropriate CMMC status for the information they receive. Primes are increasingly requiring documented proof of this before allowing CUI to flow down at all.
Reducing Scope with Enclave Architecture
Not every organization needs to bring its entire network into CMMC scope. A well-designed enclave can shrink the boundary dramatically.
Enterprise-Wide Compliance vs. the Enclave Approach
Some organizations choose to bring their entire IT environment into compliance, consolidating everything under a single, uniformly secured infrastructure. Others take the enclave approach: building a focused, isolated environment specifically for CUI-related work, while keeping the broader corporate network outside the assessment boundary. The enclave approach is typically less disruptive and less expensive, since it avoids extending CMMC-level security requirements to systems that never needed them.
What “Logical Separation” Actually Requires
Logical separation is frequently misunderstood. A VLAN or a firewall rule alone doesn’t create it. According to CMMC FAQ guidance, encryption by itself does not establish logical separation either. What’s required is enforced network segmentation that genuinely prevents data transfer between the enclave and the rest of the environment, something an assessor can verify technically, not just read about in a policy document.
Using GCC High, Azure Government or AWS GovCloud to Shrink Scope
Purpose-built government cloud environments like Microsoft GCC High, Azure Government, and AWS GovCloud are designed with this kind of separation already in place, backed by FedRAMP High authorizations. Organizations that host their CUI enclave in one of these environments often find their remaining on-premises assessment scope shrinks substantially, since the infrastructure-level separation and controls are largely inherited rather than built from scratch.
How Assessors Validate Your Scope
Scope isn’t something you declare and move past. It’s formally checked before the rest of the assessment can proceed.
Scope Validation as a Formal Step Before Assessment Begins
A Lead Certified CMMC Assessor validates your documented CMMC Assessment Scope before the substantive assessment activities begin. If the assessor disagrees with how you’ve categorized an asset, or believes something is missing from your boundary, that disagreement has to be resolved before control testing starts. This makes scope validation less of a formality and more of a gate the rest of your assessment has to pass through.
What Happens When Your SSP, Diagram and Inventory Don’t Match
Assessors cross-reference your SSP, asset inventory, and network diagram against each other, and against what they observe in your actual environment. An asset that appears on the network diagram but isn’t in the asset inventory, or a CRMA justification in the SSP that doesn’t match the segmentation shown on the diagram, are the kinds of inconsistencies that turn a straightforward assessment into a lengthy discovery exercise, and sometimes into a failed one.
Common CMMC Scoping Mistakes
Most scoping failures follow a small number of recognizable patterns.
Scope Creep: When the Boundary Expands Mid-Process
Scope creep happens when the assessment boundary quietly expands beyond what was originally planned, often because new tools, cloud tenants, or vendors get adopted without being checked against the existing scope documentation. The result is inflated remediation costs, delayed timelines, and sometimes a failed assessment, and it’s rarely the result of a deliberate decision. It’s usually the byproduct of weak scoping discipline early in the process.
Assuming “We Don’t Store CUI” Means You’re Exempt
A surprising number of organizations assume they’re exempt from Level 2 scoping because they don’t formally store CUI, while overlooking that their email system routinely processes CUI flowing through contract correspondence. Processing and transmitting count just as much as storage.
Treating Shared Drives and Collaboration Tools as Someone Else’s Problem
Shared drives and collaboration platforms often get excluded from scoping discussions on the assumption that they belong to IT rather than the team handling the contract. If CUI moves through those tools in practice, they’re in scope regardless of who administers them.
Overlooking Personal Devices Used for MFA or Email
Personal smartphones used for accessing email containing CUI are frequently left out of asset inventories entirely. If a personal device touches CUI, it needs to be evaluated against your scoping documentation, not assumed to be outside of it.
Ignoring Break-Glass Accounts and Remote Access Infrastructure
A break-glass emergency account that bypasses standard multi-factor authentication isn’t a separate, exempt category. It’s a privileged credential capable of reaching the CUI environment, which puts it fully in scope under access control and identification requirements. The same logic applies to VPN gateways, jump servers, and remote desktop infrastructure, all of which function as Security Protection Assets and are commonly underestimated during scoping.
Why Scope Is a Legal Commitment, Not Just a Technical One
Scope isn’t purely an IT exercise. Someone in your organization signs their name to it, and that signature carries legal weight.
The Affirming Official and What They’re Signing
Under CMMC program requirements, a designated Affirming Official must attest to your organization’s continuing compliance at assessment completion, at POA&M closeout, and annually thereafter, submitted electronically in SPRS. That person is affirming that all applicable security requirements have been implemented and will be maintained for every system within the documented assessment scope. It has to be someone senior enough to bind the organization and informed enough to know the statement is true, which is why this designation is a governance decision, not simply an administrative one.
Scope Drift Between Assessments
An organization that was accurately scoped on the day of its assessment can drift out of alignment within months. New SaaS tools get adopted, teams change roles, cloud environments get spun up without review. The only real defense is tying scope review to your change management process, so every new tool, vendor, or cloud tenant gets checked against the existing boundary before it goes live, rather than being discovered during the next assessment.
False Claims Act Risk of an Outdated Scope
Signing an annual affirmation while knowingly ignoring gaps in an outdated scope isn’t just a compliance oversight. It can constitute the kind of knowing misrepresentation or reckless disregard for the truth that the False Claims Act was built to address, with per-claim penalties and treble damages attached. Enforcement in this area has been increasing, and it has reached into the subcontractor tier of the defense supply chain, not just prime contractors. The Affirming Official’s name is on that claim, which is exactly why scope has to be treated as a living, continuously maintained program rather than a document produced once and filed away.
How Nexeris Helps You Get Your CMMC Scope Right the First Time
Scope is the foundation every other part of your CMMC assessment depends on. Get it wrong, and no amount of technical control implementation will save the rest of the process. Getting it right the first time means starting with an accurate picture of how CUI actually flows through your organization, categorizing every asset correctly against the five Level 2 categories, and producing an SSP, asset inventory, and network diagram that all tell the same consistent story. A structured approach to CMMC audit preparation makes scope the first thing addressed, not an afterthought discovered during a mock assessment. Nexeris works with defense contractors to define, document, and defend their CMMC assessment scope from the earliest stages of readiness, so the boundary holds up under assessor scrutiny and stays accurate long after the certificate is issued.
FAQs
What document officially defines CMMC assessment scope?
There’s no single form. Scope is defined by 32 CFR § 170.19, the DoD’s official Level 1 and Level 2 Scoping Guides, and your organization’s own System Security Plan, asset inventory, and network diagram, which together document and prove your boundary.
What are the 5 asset categories in CMMC Level 2 scoping?
CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, and Out-of-Scope Assets. Each category carries different documentation and assessment requirements under the DoD’s Level 2 Scoping Guide.
Is my MSP or cloud provider in scope for my CMMC assessment?
If your MSP, cloud service provider, or SOC touches, processes, or protects your CUI environment, they’re treated as a Security Protection Asset under your scope. The assessor doesn’t evaluate them directly, but you need to demonstrate their controls align with the applicable CMMC requirements.
Can I reduce my CMMC scope with a CUI enclave?
Yes. Isolating CUI processing into a logically or physically separated enclave, often built on a platform like GCC High, Azure Government, or AWS GovCloud, is one of the most effective ways to keep the rest of your corporate network outside the assessment boundary.
What happens if my SSP and network diagram don’t match during assessment?
Assessors cross-check all three scoping documents against each other and against your actual environment. Inconsistencies between them are a common reason assessments stall or turn into extended discovery exercises, so keeping the SSP, asset inventory, and network diagram aligned is essential before the assessor arrives.
