What CMMC scoping actually means
CMMC scoping is the process of defining which systems, people, and assets are subject to CMMC requirements — and which are not. Under 32 CFR 170.19, every Organization Seeking Assessment (OSA) must define its CMMC Assessment Scope before any self-assessment or third-party certification.
Your scope is the set of assets a C3PAO will evaluate. It determines which systems need to implement all 110 NIST SP 800-171 controls (for Level 2), which people need training and background checks, and which infrastructure needs to be hardened, monitored, and documented.
The critical point most contractors miss: scope is not just about CUI. It's about every asset that can affect CUI. A system that never touches CUI but has a network connection to a system that does can still be in scope, because it represents an attack vector. Getting this right is what separates a clean assessment from an expensive failure.
The official definition: Per 32 CFR 170.19, CMMC Assessment Scope is "the set of all assets in the Organization Seeking Assessment's (OSA's) environment that will be assessed against CMMC security requirements." This includes assets that process, store, or transmit CUI as well as assets that provide security protection for those systems.
Why scoping is your biggest cost lever
CMMC compliance costs scale almost linearly with scope. Every system in scope needs to be hardened, documented, monitored, and assessed. Every person in scope needs training, background checks, and access controls. Every additional asset adds audit time, which means higher C3PAO fees.
The math is stark. A defense contractor with 200 employees and a broad scope might need to bring their entire corporate infrastructure into compliance — costing $500,000 or more and taking 18–24 months. The same contractor with a well-defined CUI enclave covering 15 employees and 20 systems could achieve Level 2 certification in 60–90 days for a fraction of that cost.
This is not a loophole. The DoD explicitly intended for contractors to scope their environments tightly. Reducing scope by isolating CUI is the designed approach for organizations that don't handle CUI across their entire operation.
But there's a hard limit: Underscoping is an automatic failure. If your scope says 10 people touch CUI but an assessor finds it's actually 12, those two additional people invalidate your enclave boundary. The DoD takes underdeclared scope seriously — it creates exactly the kind of security gap CMMC was designed to prevent.
The 5 asset categories you need to know
The CMMC scoping guides (released by DoD for Levels 1, 2, and 3) define five categories of assets. Every system in your environment falls into one of these. Your first job is to categorize everything.
CUI Assets — Always in scope
Systems that store, process, or transmit Controlled Unclassified Information. These are the heart of your compliance boundary. Every CUI asset must implement and demonstrate all applicable CMMC controls.
- File servers storing contract documents, technical drawings, or specs
- Email systems used to send or receive CUI
- Collaboration tools where CUI is shared (Teams, Slack with CUI content)
- Engineering workstations that access CUI files
- Cloud storage where CUI is uploaded (SharePoint, Google Drive, Dropbox)
Security Protection Assets — In scope
Systems that provide security services protecting CUI assets, even if they don't handle CUI directly. Because these assets can affect the security posture of your CUI environment, they're in scope.
- Firewalls and security appliances protecting the CUI enclave
- Identity providers (Okta, Azure AD) managing CUI system access
- SIEM and log management systems monitoring the enclave
- MDM systems managing CUI-accessing endpoints
- VPN infrastructure used to access CUI systems
Contractor Risk Managed Assets — Documented, may be in scope
Systems that are connected to the CUI environment but don't directly handle CUI or provide security services. These are assessed based on risk — contractors must document the risk and demonstrate it's managed.
- Corporate workstations connected to the corporate network (which connects to the enclave)
- Printers on a shared network that could theoretically receive CUI print jobs
- Corporate email used for non-CUI DoD communications
- IT management systems with network access to the enclave
Specialized Assets — Treated on a case-by-case basis
Assets that may require a tailored approach due to their nature: operational technology (OT), IoT devices, government furnished equipment (GFE), and restricted information systems. These are in scope but assessed differently.
- OT and industrial control systems in manufacturing environments
- IoT devices connected to the production network
- Government furnished equipment (GFE) provided by the contracting agency
- Test equipment connected to CUI systems
Out-of-Scope Assets — No documentation required
Systems with no pathway to CUI, no security function for CUI systems, and physical or logical separation from in-scope assets. These require no documentation and no CMMC controls — but you must be able to justify the exclusion.
- HR and payroll systems with no connection to CUI systems
- Accounting and ERP systems on isolated networks
- Marketing websites and public-facing infrastructure
- Personal devices with no CUI access and no network path to CUI
The connection trap: Any system with a direct or indirect connection to a CUI asset is potentially in scope — even if it never handles CUI itself. This is where scope creep happens. A corporate laptop connected to the same network as a CUI file server, even via a separate VLAN, may still be a Contractor Risk Managed Asset requiring documentation. Network segmentation is what turns these from "in scope" to "out of scope."
Not sure what's in scope for your environment?
Run a free CMMC gap assessment and get a readiness score with a prioritized action plan.
Enclave vs. organization-wide compliance
Every contractor pursuing CMMC faces a fundamental architectural decision: do you bring your entire organization into compliance, or do you isolate CUI into a defined enclave and comply only within that boundary?
| Factor | CUI Enclave Approach | Organization-Wide |
|---|---|---|
| Compliance cost | Lower — only enclave assets must meet all 110 controls | Higher — every system and employee in scope |
| Assessment scope | Smaller — fewer systems for C3PAO to evaluate | Larger — entire infrastructure under assessment |
| Timeline to certification | Faster — 60–120 days for a well-designed enclave | Slower — 12–24 months for most organizations |
| Operational disruption | Lower — most employees unaffected | Higher — org-wide policy and tooling changes |
| Management complexity | Higher — two operating environments to maintain | Lower — single set of policies and controls |
| Scalability | Harder — every new CUI user must be added to enclave | Easier — all employees already compliant |
| Licensing cost | May require duplicate licenses for enclave tools | Single set of licenses org-wide |
| Best for | Contractors where CUI is handled by a defined team | Contractors where CUI flows across the whole organization |
For most small and mid-sized defense contractors — especially those where only a project team, engineering department, or specific role handles CUI — the enclave approach is the right call. The cost and time savings are substantial, and the technical requirements are manageable.
Organization-wide compliance makes more sense when CUI is embedded in every business process, when you have a large IT team capable of managing broad compliance, or when you're pursuing growth that will expand your CUI footprint significantly and don't want to continuously expand an enclave boundary.
How to define your boundary: step by step
Scoping isn't a one-time exercise — but it has to start somewhere. Here's the process used by experienced CMMC Registered Practitioners to define a defensible assessment boundary.
Identify every CUI data type you receive
Start with your contracts. What type of CUI does each DoD contract require you to handle? Technical data, export-controlled specs, procurement-sensitive information, ITAR-controlled drawings? List the CUI category for each contract. This defines what you're protecting.
Map how CUI enters, moves through, and leaves your environment
Trace every CUI data flow: how does it arrive (email, USB, secure file transfer, government portal)? Where does it live (file server, cloud storage, workstation)? Who accesses it? How does it leave (email, physical delivery, upload to government system)? Document this as a data flow diagram. Hidden flows — CUI copied to personal email, synced to personal Dropbox — are the most common scoping failures.
Identify every asset that interacts with CUI data flows
Every system, device, and person in your CUI data flow is a candidate for scope. Include cloud services, managed service providers, external service providers, and subcontractors who touch CUI. An MSP with admin access to your file server is in scope. A cloud storage provider holding CUI is in scope.
Categorize every asset using the five asset categories
Apply the CUI Asset, Security Protection Asset, Contractor Risk Managed Asset, Specialized Asset, or Out-of-Scope classification to every asset you identified. Document the reasoning for each classification — especially exclusions. Auditors will ask why specific systems were excluded.
Minimize scope through network segmentation
Now that you know what's in scope, ask: what can you remove? Corporate systems connected to your CUI environment can be taken out of scope if you enforce network segmentation — logical separation via VLANs, firewalls, and access controls. This is the scope reduction step. Every system you successfully isolate from CUI is one fewer system to harden and document.
Define the formal boundary and draw your network diagram
Document the boundary as a formal scope statement and a network diagram showing the enclave, all connections into and out of it, and clearly marked in-scope vs. out-of-scope systems. This diagram must be readable without zooming and include a legend. Auditors will use it as their map during the assessment.
Validate the boundary with a second opinion
Before finalizing scope, have a CMMC Registered Practitioner (RP) or Registered Practitioner Organization (RPO) review your boundary definition. They've seen what assessors look for and can identify hidden connections and flow paths you may have missed. This is far cheaper than discovering scope issues during the actual C3PAO assessment.
How to build a CUI enclave
Once you've defined your scope, building the enclave is a matter of enforcing the boundary technically — so that CUI genuinely cannot escape into the wider corporate environment, and the wider corporate environment genuinely cannot reach CUI without going through controlled access points.
The two enclave models
Cloud-only enclave: All CUI work happens inside a FedRAMP-authorized cloud environment (Microsoft 365 GCC High, Azure Government, Google Workspace for Government). Users access it through a virtual desktop or secure browser session. No CUI ever touches local devices. This is the fastest and cleanest approach for organizations without significant legacy on-premises infrastructure.
Hybrid enclave: CUI systems live on-premises (a dedicated server, storage, or workstation cluster) with strict network segmentation from the corporate environment. Corporate systems connect through a controlled gateway with MFA and logging. More complex to build and maintain, but necessary if you have legacy systems or manufacturing OT that can't move to the cloud.
Technical requirements for a defensible enclave
An enclave isn't just a policy declaration — it has to be technically enforced. Assessors will verify these controls exist and operate effectively:
- Network segmentation: CUI systems must be on a separate VLAN or network segment, with firewall rules blocking unauthorized lateral movement from corporate networks. Administrative access requires going through a controlled access point, not a direct connection.
- Access control: Only authorized users with documented need-to-know can access the enclave. Access is provisioned through a formal process and de-provisioned within defined SLAs when employment ends. MFA is required on all access points.
- Logging and monitoring: All access to and within the enclave is logged. Logs are retained for the required period (typically 90 days minimum, 1 year preferred). Automated alerts fire for suspicious activity, privilege escalation, and failed authentication attempts.
- Endpoint controls: Devices inside the enclave are enrolled in MDM, have full-disk encryption enforced, run up-to-date EDR, and are patched within defined SLAs (critical patches within 14 days).
- Data controls: CUI cannot be emailed out of the enclave to personal accounts, uploaded to non-approved cloud storage, or printed on unsecured printers. DLP controls or clear user policies with monitoring enforce this.
Cloud enclave shortcut: Microsoft 365 GCC High and Azure Government are FedRAMP High authorized and designed specifically for CMMC compliance. Many of the 110 NIST 800-171 controls are inherited from the platform — Microsoft publishes a detailed shared responsibility matrix showing exactly which controls they cover. For most small contractors, a GCC High tenant is the fastest path to a defensible enclave.
External service providers in your enclave
Any external service provider (ESP) with access to your CUI environment is part of your scope. This includes your managed IT service provider, cloud hosting provider, SIEM vendor, and any contractor or subcontractor who touches CUI. For each ESP, you need to document: their role, their access level, what controls they implement, and how you verify their compliance posture. FedRAMP-authorized cloud services satisfy many of these requirements automatically — non-FedRAMP services require more documentation.
Documenting scope in your System Security Plan
The System Security Plan (SSP) is the central compliance document for CMMC — it's the first thing a C3PAO reads and the document auditors reference throughout the assessment. Your scope definition lives here, and it needs to be precise.
A well-structured SSP scope section contains:
- Scope statement: A concise written description of what is included and excluded from the assessment boundary, including the specific CUI types handled and the CMMC level pursued.
- Asset inventory: A complete list of every in-scope asset with its asset category, data classification, owner, and data flow context.
- Network diagrams: Current (not legacy) network diagrams showing the enclave boundary, all connections, and system relationships. Must be readable and include a legend.
- Boundary justification: For every exclusion, a documented reason why that system cannot store, process, or transmit CUI and what controls prevent it from doing so.
- Data flow descriptions: Written narratives describing how CUI enters, moves through, and exits the enclave, cross-referenced to the network diagrams.
Version control matters: Your SSP must reflect the current state of your environment at the time of assessment. Auditors will compare the SSP against what they observe during the assessment. An SSP describing a system architecture that no longer exists, or missing recently-added systems, creates immediate credibility problems. Keep it version-controlled and update it whenever the boundary changes.
Pre-assessment scope checklist — verify before your C3PAO arrives
Common scoping mistakes that fail assessments
These are the most frequent scoping errors that experienced C3PAOs encounter. Most are avoidable with upfront rigor.
1. Declaring scope without verifying CUI flows
The most common failure: a contractor declares a narrow enclave without actually tracing where CUI goes. CUI shared via personal email, synced to a personal laptop through a cloud drive, or accessed from home over an unmanaged personal computer expands scope immediately. The discovery happens during the assessment — not before — and the result is a major non-conformity.
2. Treating segmentation as an administrative declaration
"These systems are separated because we said so" doesn't pass an assessment. Segmentation must be technically enforced — firewall rules that block traffic, VLANs that prevent broadcast domain overlap, access controls that require authentication. Auditors will test the segmentation. If CUI can reach out-of-scope systems through any network path, that system is in scope.
3. Forgetting managed service providers
Your MSP has admin access to your servers. That makes them an External Service Provider with access to your CUI environment — which puts them in scope. If your MSP isn't FedRAMP authorized and doesn't have their own CMMC compliance documentation, this is a gap. Many contractors discover this issue during assessment prep, not upfront.
4. Not updating scope when the environment changes
CMMC scope isn't a one-time definition. Any significant change to your environment — a new system connected to the enclave, a new employee with CUI access, a new cloud service, a merger or acquisition — potentially changes your scope. The CMMC Final Rule requires a new assessment when there are "significant architectural or boundary changes" to the previous CMMC Assessment Scope. Track changes and reassess scope whenever they occur.
5. Underestimating subcontractor scope
If you share CUI with subcontractors, they need their own CMMC compliance. CMMC flows down through the entire supply chain under DFARS 252.204-7021. If your subcontractor handles CUI and isn't CMMC certified at the appropriate level, your contract is at risk. Map your subcontractor CUI flows as part of your scoping exercise.
Frequently asked questions
Is a CMMC enclave required?
No — an enclave is not required by CMMC. You can pursue organization-wide compliance instead, where all systems and employees meet CMMC requirements. The enclave approach is a strategic choice to reduce compliance scope, cost, and complexity. It makes most sense for organizations where CUI is handled by a specific team or department rather than across the whole business.
Can I use Microsoft 365 (standard) inside my enclave?
No. Standard Microsoft 365 (including E3 and E5) does not meet CMMC Level 2 requirements because it doesn't provide FedRAMP High authorization or the data residency and sovereignty guarantees required for CUI. You need Microsoft 365 GCC High or Microsoft 365 Government (GCC) at minimum. Microsoft GCC High is the most commonly used platform for CMMC Level 2 enclave deployments.
How many people does a typical CMMC enclave cover?
It varies significantly. The most efficiently scoped enclaves cover 5–30 people — the team that directly handles CUI on specific contracts. Organizations with broader CUI access may have enclaves covering 50–100 people. The goal is minimum viable scope: only the people who genuinely need to handle CUI should be inside the boundary.
What happens when I win a new DoD contract that expands my CUI footprint?
You need to reassess your scope. If the new contract introduces new CUI types, new data flows, or requires new people to access CUI, your boundary must be updated and your SSP revised. Significant boundary changes may require a new CMMC assessment. Factor this into your compliance strategy when bidding on contracts — budget for scope review and potential boundary expansion.
Does CMMC scope include our offices in other locations?
It depends on whether CUI is accessible from those locations. If remote offices or employees at different sites access CUI systems (even through VPN), those people and their access infrastructure are in scope. Physical location matters less than logical access — what matters is whether CUI can reach those systems and people, and whether those systems and people can reach CUI.
Know your CMMC readiness before you scope
A gap assessment shows you exactly which controls you're missing — before you commit to a boundary that includes systems you're not ready to certify.