Scoping is the decision that determines the cost and complexity of your entire CMMC compliance program. Get it right and you assess only what needs to be assessed. Get it wrong and you either pay to secure systems that don’t need it, or you discover CUI in systems the assessor finds outside your boundary, which is one of the most damaging findings possible.
More CMMC assessment problems trace back to scoping than to any individual control failure. A missing control can be remediated and placed on a POA&M. A scoping error calls the integrity of the entire assessment into question.
What Scoping Means in CMMC
Scoping defines which assets, systems, people, and processes fall within your CMMC assessment boundary. Everything inside the boundary gets assessed against the applicable security requirements. Everything outside the boundary is excluded.
The assessment boundary is determined by where CUI lives, where it moves, and what protects it. If CUI touches a system, that system is in scope. If a system protects a system that touches CUI, it may also be in scope. The CMMC Scoping Guide defines five asset categories that determine what’s assessed and how.
The Five Asset Categories
CUI Assets
Systems that directly store, process, or transmit CUI. These are the core of your assessment scope.
Examples: workstations where engineers review technical drawings, file servers storing CUI documents, email systems where CUI is transmitted, ERP systems that process contract data containing CUI, collaboration platforms where CUI is shared with team members.
CUI Assets are assessed against all applicable NIST 800-171 security requirements for your CMMC level.
Security Protection Assets
A compromise of these tools directly threatens the CUI they protect — which is why they’re assessed even though they don’t hold CUI themselves. Security Protection Assets are the systems and tools that provide security functions for CUI Assets.
Examples: firewalls at the CUI boundary, SIEM platforms that collect logs from CUI systems, endpoint protection tools deployed on CUI workstations, identity and access management platforms that control access to CUI systems, vulnerability scanners that assess CUI infrastructure.
The security requirements applicable to these assets focus on their protective function.
Contractor Risk Managed Assets
Assets that aren’t intended to, but are capable of, processing, storing, or transmitting CUI because of the security policy, procedures, and practices in place.
This is the category that creates the most confusion. These are systems that could reach CUI if a control failed, but are prevented from doing so by your security architecture and policies.
Examples: a corporate laptop on the same network segment as CUI systems, but prevented from accessing them by access controls. A business application that has network connectivity to CUI systems but isn’t authorized to process CUI.
CRMAs are in scope, but the assessment approach is different. The contractor documents these assets and the security measures that prevent them from accessing CUI. The assessor verifies that those measures are in place and effective.
Specialized Assets
Assets that may interact with CUI but have limited or no ability to enforce standard security controls.
Examples: IoT devices, operational technology (OT) systems, government-furnished equipment (GFE), restricted information systems, and test equipment. These assets often can’t support MFA, encryption, or audit logging in the way a standard workstation or server can.
Specialized Assets are part of the Level 2 assessment scope. They must be documented in the asset inventory, addressed in the SSP, and shown as managed using the contractor’s risk-based security policies, procedures, and practices. The assessor reviews the SSP for these assets but doesn’t assess them against other Level 2 requirements.
Out-of-Scope Assets
Assets that can’t process, store, or transmit CUI, don’t provide security protections for CUI Assets, and are physically or logically separated from CUI Assets. Assets that fall into an in-scope category cannot be treated as out of scope.
Examples: systems on a completely separate network with no interconnection to the CUI environment, personal devices used exclusively for non-contract work, guest WiFi that has no path to CUI systems.
Out-of-scope assets are not assessed, and the Level 2 scoping guide doesn’t impose formal documentation requirements for them. However, maintaining internal evidence of separation is a smart practice. If an assessor discovers connectivity between an asset treated as out of scope and the CUI environment, that asset may be reclassified as in-scope during the assessment.
How to Define Your CUI Boundary
Step 1: Identify Your CUI
Start with your contracts. Look for DFARS 252.204-7012 clauses. Review the contract’s CUI marking guide if one exists. Identify the CUI categories present in your work using the CUI Registry maintained by the National Archives.
Common CUI categories in defense contracts:
- Controlled Technical Information (CTI)
- Export-controlled information (ITAR, EAR)
- Critical infrastructure information
- Procurement and acquisition data
- Personnel records associated with contract performance
- Financial information related to contract pricing
Don’t assume CUI is only the “technical stuff.” Program schedules, cost data, personnel assignments, and test results can all qualify depending on the contract.
Step 2: Map CUI Data Flows
Trace how CUI moves through your environment from entry to exit.
Entry points: How does CUI arrive? Email from the prime? Portal download? Physical media? File transfer? Direct system access to a shared environment?
Internal movement: Where does CUI go after it enters? Is it saved to a file share? Opened on a workstation? Processed in an application? Copied to a collaboration tool? Attached to an internal email? Backed up?
Storage locations: Where does CUI reside at rest? File servers, workstations, cloud storage, email archives, backup systems, removable media?
Exit points: How does CUI leave? Email to the prime? Upload to a portal? Deliverable submission? Printed documents? Does it leave through your MSP’s systems?
Map every path. Every system a CUI data flow touches becomes a candidate for the assessment boundary.
Step 3: Categorize Your Assets
With CUI flows mapped, assign every asset to one of the five categories. For each asset, document:
- Asset name and type
- Asset category (CUI, SPA, CRMA, Specialized, Out-of-Scope)
- Justification for the category assignment
- For CRMAs: the specific controls preventing CUI access
- For Specialized Assets: documentation showing they are managed using the contractor’s risk-based security policies, procedures, and practices
- For Out-of-Scope: as a best practice, maintain internal evidence of separation and rationale, even though formal Level 2 scoping guidance does not impose documentation requirements for out-of-scope assets
Step 4: Draw the Boundary
Your assessment boundary encompasses all CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, and Specialized Assets. Out-of-Scope assets are excluded.
Document the boundary clearly. Include network diagrams that show the demarcation between in-scope and out-of-scope systems. Show the security controls at boundary points (firewalls, access controls, network segmentation).
This documentation becomes part of your SSP and is one of the first things a C3PAO reviews during the pre-assessment scoping process.
Need help mapping your CUI flows and defining your boundary? Start with a free readiness check to identify what’s in scope and where segmentation can reduce it.
Scope Reduction Strategies
Every system you keep out of scope is a system you don’t need to secure to NIST 800-171 standards, document in your SSP, collect evidence for, or pay to have assessed. Scope reduction is the highest-ROI investment in your compliance program.
Network Segmentation
Isolate CUI processing into a defined network segment or enclave. Systems that don’t need CUI access stay on the general corporate network outside the boundary. Only the enclave is assessed.
Implementation options range from simple VLAN segmentation with firewall rules to dedicated physical networks with separate infrastructure. The right approach depends on your environment and budget.
Among contractors on our platform, those who implemented network segmentation before beginning remediation reduced their in-scope asset count by an average of 40%. The investment typically pays for itself within the first assessment cycle through reduced documentation effort, lower tool licensing costs, and shorter C3PAO on-site time.
Dedicated CUI Workstations
Instead of allowing CUI on every employee laptop, designate specific workstations for CUI work. These machines get hardened and documented. Personal or general-purpose devices stay out of scope.
This works well for organizations where only a subset of employees handles CUI. The engineer reviewing technical drawings uses the CUI workstation. The HR administrator processing payroll uses a general workstation that stays out of scope.
Cloud Enclave
Move CUI processing into a compliant cloud environment (such as a FedRAMP Moderate authorized service) and access it through a controlled path. The cloud enclave and the access mechanism are in scope. The rest of your corporate environment may stay out.
Several vendors offer pre-configured CUI enclaves designed specifically for defense contractors. These reduce the scoping burden by providing a contained environment where CUI lives, with the contractor’s general infrastructure separated.
Minimize CUI Retention
Not all CUI needs to stay in your environment forever. If you can return or destroy CUI after the work is complete, you reduce the amount of CUI at rest and potentially reduce the systems that need to remain in scope.
Establish CUI retention and disposal policies that align with your contractual obligations. Some contracts specify retention periods. Others allow return or destruction after performance is complete. Check your contract terms before disposing of any CUI.
Common Scoping Mistakes
Under-scoping: missing systems that touch CUI. The most damaging scoping error. When the assessor discovers CUI on a system you excluded from scope, the assessment can’t proceed normally for that area. You may need to expand the boundary mid-assessment, scrambling to produce controls and evidence for systems you didn’t prepare.
Email is the scoping blind spot we encounter most frequently. In a significant share of the readiness reviews we’ve conducted, the contractor’s email system was excluded from initial scope — only to discover that CUI had been shared via email attachment at some point during contract performance. One missed attachment brings the entire email infrastructure into scope.
Over-scoping: putting everything in scope unnecessarily. The opposite problem. The contractor puts their entire network in scope because they didn’t invest in segmentation or because they weren’t sure which systems touch CUI. The result: more controls to implement, more documentation to maintain, more evidence to collect, more systems to assess, and higher assessment fees.
Over-scoping is expensive but survivable. Under-scoping is assessment-threatening.
Overlooking data paths outside the “work environment.” MSPs and backup systems are the two most common blind spots after email. If your MSP processes CUI or Security Protection Data, their tools and environment are in your scope — RMM tools, ticketing systems, backup infrastructure, and any cloud platform they manage on your behalf. The same logic applies to backup and archive systems: if CUI is backed up, the backup system stores CUI; if email containing CUI is archived, the archive stores CUI. These systems are frequently excluded from scope because they’re “infrastructure” rather than “where the work happens.” But CUI at rest is CUI at rest, regardless of the system function. Failing to trace CUI through these paths creates gaps the assessor will find.
What happens when your environment changes after scoping? Your environment isn’t static. New systems are deployed. Employees start using new tools. CUI data flows evolve as contract work progresses. Scope needs to be reviewed whenever the environment changes materially. A scope decision made during initial compliance preparation may not reflect the environment at assessment time.
Scoping and Your SSP
Your System Security Plan must accurately describe the assessment boundary. This includes:
- A clear statement of what’s in scope and what’s out
- Network diagrams showing the boundary demarcation and security controls at boundary points
- Asset inventory organized by the five CMMC asset categories
- CUI data flow diagrams showing entry, movement, storage, and exit
- For each external service provider in scope, documentation of the services provided and how control responsibilities are divided
The scoping documentation we see fail most often during readiness reviews is the asset inventory. Contractors list their CUI Assets thoroughly but undercount Security Protection Assets and miss Contractor Risk Managed Assets entirely. If your firewall, SIEM, and identity provider aren’t in your asset inventory, your assessor will put them there for you — along with a finding.
The assessor uses your SSP scoping documentation as the basis for the pre-assessment scoping process. Inconsistencies between what the SSP describes and what the assessor observes generate findings before control evaluation even begins.
Getting Started
If you haven’t scoped your CUI boundary yet, start with data flow mapping. Follow the CUI from entry to exit. Document every system it touches. Then categorize your assets, evaluate segmentation opportunities, and draw the boundary.
If you’ve already scoped but haven’t reviewed it recently, now is the time. Check whether new systems, tools, or processes have been introduced that affect CUI flows. Verify that the boundary in your SSP matches reality.
Deep Fathom helps contractors define and maintain their CUI boundary as a living part of their compliance program. The platform maps CUI flows, categorizes assets, tracks boundary changes, and keeps scoping documentation synchronized with your SSP so the boundary you describe is always the boundary that exists.
Check your readiness or talk to our team.
Related reading: