Introduction
Before a single control gets tested, CMMC assessors need to know one thing: what's actually in scope. Scoping determines which systems, users, facilities, services, and data flows must be protected and assessed before a DoD contractor can demonstrate compliance.
Get the boundary wrong in either direction and you pay for it. Too broad, and you're assessing servers and endpoints that never touch federal contract information or controlled unclassified information. Too narrow, and you've left out the one shared drive or backup path that actually carries CUI.
DoD Level 2 certification assessments cost an estimated $104,670 to $117,768 over three years, according to the 2024 final rule. Scope size drives most of that number.
This guide walks through a practical scoping workflow: what to gather, how to classify assets, where contractors usually go wrong, and how to keep the boundary defensible after the assessment ends.
Key Takeaways
- CMMC scope starts with contract obligations and information type, not a preferred tool
- Map where FCI and CUI enter, move, reside, and exit before classifying any system
- Assets that protect CUI count, even if they never store it directly
- A defensible boundary needs diagrams, inventories, documented assumptions, and stakeholder sign-off
How to Define Your CMMC Assessment Boundary
Scoping isn't a one-afternoon exercise. It's a sequence, and skipping steps is how contractors end up with boundaries that collapse under assessor scrutiny.
Step 1: Confirm the Contract, Information Type, and Required CMMC Level
Start with the paperwork, not the network diagram. Review the solicitation, contract, subcontract flow-downs, DFARS clauses, statement of work, and any data markings from the prime contractor. This tells you whether your environment handles FCI, CUI, or both.
Don't assume. A general defense-industry relationship doesn't automatically set the same level for every system in your environment.
| Level | Information | Requirements | Assessment |
|---|---|---|---|
| 1 | FCI | 15 FAR 52.204-21 practices | Annual self-assessment |
| 2 | CUI | 110 NIST SP 800-171 practices | Self-assessment or C3PAO certification, every 3 years |
| 3 | CUI (higher risk) | Level 2 plus 24 additional practices | DCMA DIBCAC certification, every 3 years |
If the contract language is ambiguous about which level applies, don't default to the lowest-burden interpretation. Document the open question and get clarification from the contracting officer or data owner before you build anything.
Step 2: Map CUI and FCI Data Flows
Once you know what type of information you're dealing with, trace where it actually goes. Build a data-flow map showing where information is received, created, accessed, modified, stored, transmitted, backed up, printed, archived, and destroyed.
Pay close attention to transfer points, including:
- Email and collaboration platforms
- File-transfer services and removable media
- Remote access sessions and supplier portals
- Manufacturing systems and managed service connections
For each flow, identify the people, applications, devices, and facilities involved. This is also where you separate systems that genuinely handle CUI from systems that just support general business activity.
Step 3: Inventory and Classify Assets
With data flows mapped, build the asset inventory: endpoints, servers, virtual machines, cloud resources, applications, network devices, mobile devices, identity systems, backup systems, and physical locations.
Official CMMC Level 2 scoping guidance defines five asset categories:
- CUI assets – process, store, or transmit CUI directly
- Security protection assets (SPAs) – provide security functions to the environment, such as a SIEM or identity provider
- Contractor risk managed assets (CRMAs) – could handle CUI but are managed by policy to avoid it
- Specialized assets – IoT, OT, test equipment, or GFE that can't be fully secured
- Out-of-scope assets – cannot handle CUI and don't protect CUI assets
Reduced assessment isn't exclusion. CUI assets, SPAs, CRMAs, and specialized assets all stay in Level 2 scope, just with different evidence requirements. Only true out-of-scope assets drop out entirely.
Step 4: Define the CUI Enclave or Security Domain
Now choose the boundary model: a segmented CUI enclave, a dedicated cloud environment, a tightly controlled security domain, or a broader enterprise scope when CUI can't realistically be isolated.
Segmentation has to be enforced, not just drawn. It runs through identity controls, network architecture, device management, access control, logging, and physical safeguards. A diagram with a dotted line around a subnet proves nothing on its own.
Test the boundary by asking: can administrators, shared services, remote connections, or backup paths cross it? If yes, that path has probably just expanded your practical scope.
Step 5: Document, Validate, and Approve the Boundary
Pull it all together into the core scoping package:
- System security plan and architecture diagrams
- Asset inventory and boundary narrative
- Control responsibility matrix
- External service providers list, with documented rationale for every excluded asset
Trace each in-scope asset and data flow to the relevant CMMC practices. Flag which controls are inherited from a cloud or managed service provider versus owned internally.
Finally, walk the boundary through IT, security, engineering, contracts, operations, and an executive stakeholder before calling it final.
QMS Learning's $395 CMMC & NIST 800-171 course builds these same outputs (a data inventory, enclave outline, draft SSP, sample SPRS score, and POA&M) as working deliverables rather than theoretical exercises.
When Scoping Approaches Make Sense—and What You Need First
A contained enclave can shrink the number of systems requiring direct assessment. But it only works if you can consistently prevent unapproved CUI storage, transmission, access, and administrative dependencies outside that enclave.
Enclaves tend to fit organizations with:
- A small number of CUI users
- Limited defense programs relative to total business
- Repeatable engineering workflows
- A clear split between commercial and DoD work
A narrow boundary gets risky fast when any of these are present:
- Shared identity services or enterprise-wide email
- Uncontrolled remote administration
- Broad backup access or mixed-use endpoints
- Unclear supplier data flows
In those cases, the enclave looks good on paper and leaks in practice.
Systems and Discovery Prerequisites
Scoping work depends on a reliable asset-discovery process already running, plus current records you can trust:
- Network and data-flow diagrams
- Identity and access records
- Endpoint and cloud inventories
- Configuration baselines
Documents and Records to Gather
Before you start, gather:
- Contract documents and CUI handling instructions
- Data inventories and system architecture records
- Provider agreements and incident-response procedures
- Records showing where data is created, retained, and destroyed
Cross-Functional Alignment
Contracts, engineering, IT, security, operations, and executive leadership all need to agree on where the boundary sits. A scoping decision made solely by IT, without contracts or engineering input, tends to miss edge cases like derivative CUI on an engineer's laptop.
QMS Learning's Defense Cybersecurity Readiness pathway, covering CMMC and NIST SP 800-171, opens as a Q3 2026 pilot cohort for teams building this cross-functional capability.
Key Scope Variables That Affect the Assessment Boundary
Scope is a function of data movement, trust relationships, administrative access, and control ownership. A department PC count alone does not define the boundary.
Data Type and Handling Activity
Whether you're handling FCI or CUI drives your required CMMC level, so verify current definitions against your contract clauses and current DoD guidance rather than relying on last year's assumption.
Scope also grows quietly. These everyday actions pull additional processes and assets into the boundary, even when nobody intended that outcome:
- Creating derivative CUI
- Combining data sets
- Downloading files locally
- Printing technical drawings
- Retaining old backups
Connectivity and Segmentation
Network routes, wireless access, VPNs, remote desktop sessions, APIs, removable media, and shared storage can all connect systems you thought were separate.
A separated subnet means nothing if the administrators, endpoints, identity systems, or backup infrastructure behind it are shared without effective controls. One engineer emailing a CAD file to a personal Gmail account, or saving a marked-up drawing to an unencrypted shared drive, can turn a "clean" subnet into a CUI incident.
Shared Security and Administrative Services
Identity providers, privileged access tools, endpoint management platforms, vulnerability scanners, SIEM tools, backup platforms, and managed service providers can all touch in-scope assets without storing CUI themselves.
These often qualify as security protection assets. A hosted SIEM collecting logs from your CUI environment stays in scope, including wherever those logs end up stored. Research the current scoping treatment for each service category. A blanket assumption rarely holds up under assessment.
External Service Providers and Inherited Controls
Cloud providers, managed security providers, software vendors, and subcontractors all affect the boundary, the evidence package, and the responsibility matrix.
Before treating any control as inherited, verify:
- Contractual responsibilities and service authorizations
- Tenant isolation and logging access
- Incident reporting obligations and data location
- Available evidence from the provider
Operational and Physical Dependencies
Engineering workstations, manufacturing or operational technology, laboratories, portable media, paper records, and physical access paths can all interact with CUI even when they're not conventional IT systems.
A CNC machine pulling a technical drawing from a networked file share is handling CUI, regardless of whether anyone thinks of it as an "IT system."
Common Scoping Mistakes, Troubleshooting, and Alternatives
Most scoping failures trace back to a handful of repeatable mistakes:
- Starting with a software purchase instead of a data-flow exercise. Tool-first decisions preserve unnecessary scope and create evidence gaps later.
- Excluding systems because they don't store CUI. Access, administration, monitoring, and backup functions can still pull an asset into scope.
- Treating a diagram as proof of segmentation. A boundary line on paper means nothing without checks on firewall rules, identity groups, endpoint policies, and backup access. Official DoD CIO guidance notes that VDI does not exclude an endpoint unless local CUI handling, copying, and screenshots are blocked with MFA enforced.
- Assuming encryption alone defines the boundary. Encryption protects data in transit; it doesn't prevent transfer or enforce a network boundary.
When you find an unexpected in-scope asset mid-project, work through it methodically:
- Confirm the data classification on the unexpected asset
- Identify the data flow path and its business owner
- Determine whether segmentation or process changes are realistic
- Update the asset inventory and network diagrams
- Reassess the affected CMMC controls and related evidence
Isolating CUI into a smaller enclave is often the right fix. Other times you redesign a workflow, move work to a properly controlled provider, or accept a wider enterprise scope. Document the cost and security trade-offs either way. The decision itself becomes part of your evidence package.
Conclusion
An effective CMMC boundary starts with contract and data analysis, then follows the real movement of FCI and CUI through people, processes, technology, facilities, and providers. It doesn't start with a product demo.
Scope reduction only has value when it's technically enforced, operationally workable, and contractually defensible. A pretty diagram that doesn't match reality will fall apart the moment an assessor starts asking follow-up questions.
Plan on reviewing the boundary again after any material change to your environment, including:
- Contract changes
- New CUI workflows
- System migrations
- Supplier changes
- Security incidents
As primes increasingly require suppliers to show a working CMMC pathway, generic templates won't hold up. Your SSP needs to reflect your actual environment, and your POA&M needs to show real gap closure, not copied language.
Frequently Asked Questions
How much does it cost to become CMMC compliant?
Cost depends on your CMMC level, CUI volume, existing controls, boundary size, remediation needs, and whether you use external providers. Scope your environment first, then research current market estimates rather than relying on a single universal figure.
What are the CMMC compliance requirements for 2026?
Requirements depend on your assessed CMMC level. They cover applicable practices, the correct assessment or self-assessment pathway, SPRS reporting or affirmation where required, and ongoing DFARS obligations. Verify current timing against active DoD sources before finalizing plans.
What does it mean to be CMMC compliant?
Compliance means implementing the requirements tied to your contract and assessed environment, maintaining supporting evidence, completing the required assessment pathway, and sustaining that posture over time. Completing training or buying a tool alone does not establish compliance.
What is CMMC for DoD?
CMMC is the Department of Defense's framework for verifying that contractors protect federal contract information and controlled unclassified information. The required level depends on the information you handle and your specific contract terms.
Is CMMC still required?
Requirements vary by implementation phase, and some phases have shifted timing. Review your active contract clauses, solicitations, and subcontract flow-downs, and check current DoD announcements before changing your compliance plans.