How to Define Your Assessment Boundary to Minimize Scope and Cost
By Leonard Esere, Founder — AeoliTech
April 2026
Abstract
Defining the CMMC assessment boundary is the single most consequential decision a defense contractor makes before engaging a C3PAO. Get it wrong in either direction — too broad or too narrow — and the consequences are severe. Too broad, and you pay to assess and remediate systems that have no legitimate business reason to be in scope, inflating costs and extending timelines unnecessarily. Too narrow, and you exclude systems that actually process CUI, creating a materially false CMMC certification that exposes the affirming official to False Claims Act liability and the organization to contract termination.
This guide provides a systematic methodology for defining a defensible, auditor-tested CMMC assessment boundary. It covers the regulatory definition of CUI under 32 CFR Part 2002 and the NARA CUI Registry, the five asset categories defined in the CMMC Level 2 Scoping Guide, data flow mapping techniques, the enclave versus whole-organization scoping decision, network segmentation requirements, physical boundary considerations, subcontractor CUI flowdown obligations, and the most common scoping errors observed across real assessments. Where diagrams would aid understanding, this guide provides structured descriptions of boundary elements that organizations can adapt to their specific network architectures.
Engineers and compliance leads who understand how CUI flows through their organization will be equipped — after reading this guide — to make the scoping decision with confidence and document it in a form that withstands C3PAO scrutiny.
Table of Contents
1. Why Scoping Determines Everything
2. What Is CUI? The Regulatory Definition
3. Finding CUI: The Inventory Process
4. The Five CMMC Asset Categories
5. Enclave vs. Whole-Organization Scoping: The Core Decision
6. Data Flow Mapping: The Technical Foundation of Scoping
7. Network Segmentation: Making the Enclave Real
8. Physical Boundary Considerations
9. Subcontractor CUI Flowdown and Scoping Implications
10. Common Scoping Mistakes and How to Avoid Them
11. About the Author
12. References
1. Why Scoping Determines Everything
The CMMC assessment boundary defines the universe of assets — hardware, software, data repositories, personnel, and facilities — that must satisfy all 110 NIST SP 800-171 Rev 2 security requirements. Every asset inside the boundary must meet every applicable control. Every asset outside the boundary need not.
The financial consequence of poor scoping is direct: in a mid-size DIB company, the difference between a 20-system CUI enclave assessment and a 200-system whole-organization assessment can be $50K–$150K in additional remediation cost and $20K–$40K in additional C3PAO assessment fees. For large primes with complex network environments, the delta is larger still.
The regulatory consequence of under-scoping is equally direct. 32 CFR § 170.17(b) requires that the CMMC assessment cover all information systems that process, store, or transmit CUI within the scope of the applicable contract. The CMMC Level 2 Scoping Guide — published by DoD CIO — defines the asset categories and the rules for boundary determination. Excluding a system that legitimately processes CUI, and then attesting under penalty of law that the assessment covers all applicable systems, is the type of error that DoJ False Claims Act enforcement actions are built around.
2. What Is CUI? The Regulatory Definition
Before you can scope a boundary, you must understand what triggers the requirement. The authoritative definition of Controlled Unclassified Information comes from 32 CFR Part 2002, implementing Executive Order 13556. Under § 2002.4(h):
> "Controlled Unclassified Information (CUI) is information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls."
NARA serves as the CUI Executive Agent and maintains the authoritative CUI Registry, which catalogs every approved CUI category and subcategory, their governing authorities, and the applicable handling controls.
CUI comes in two forms:
- CUI Basic: The governing authority requires protection but does not specify particular controls. Handled per 32 CFR Part 2002 uniform controls. Most defense contract CUI is CUI Basic.
- CUI Specified: The governing authority specifies particular handling or dissemination controls (e.g., Naval Nuclear Propulsion Information, Privacy Act information). CUI Specified controls may be more or less restrictive than CUI Basic depending on the category.
CUI Categories Most Common in the DIB
| NARA CUI Category | Governing Authority | Common DIB Context |
|---|---|---|
| Controlled Technical Information (CTI) | DFARS 252.204-7012 | Technical drawings, specs, test data, software source code |
| Export Controlled | EAR, ITAR | Defense articles, dual-use technology, ITAR-controlled technical data |
| General Privacy | Privacy Act, HIPAA | Personnel records, health data for cleared employees |
| Procurement and Acquisition | FAR, DFARS | Bid data, source selection information, contractor cost data |
| Intelligence | ODNI policies | Threat intelligence shared under government agreements |
| General Financial Information | Various | Contract pricing not intended for public release |
For most engineering and manufacturing defense contractors, Controlled Technical Information is the dominant CUI category. The key question for every document, dataset, and system is: was this information provided by the government under a contract, or was it generated for the government under a contract, and is it marked or markable as CUI?
3. Finding CUI: The Inventory Process
CUI inventory is not a theoretical exercise. It requires structured discovery across all information repositories the organization uses in performance of DoD contracts.
Step 1 — Contract Review
Review every active DoD contract for DFARS 252.204-7012 ("Safeguarding Covered Defense Information") and 252.204-7021 (CMMC) clauses. These are the trigger clauses for CUI obligations. Document the applicable CUI categories referenced or implied by each contract's statement of work.
Step 2 — Information Repository Survey
Survey every repository where DoD contract data may reside:
- File servers and NAS devices
- Cloud storage (SharePoint, OneDrive, Google Drive, Box, AWS S3 buckets)
- Engineering platforms (PDM/PLM systems, CAD servers)
- Email systems (including archive and backup)
- Collaboration platforms (Teams, Slack, Zoom recordings)
- Removable media (USB drives, external hard drives, optical media)
- Physical documents (printed drawings, specifications, reports)
- Laptops, workstations, mobile devices
Step 3 — CUI Identification and Tagging
For each repository, determine whether DoD contract data resides there and whether it meets the CUI definition. Apply CUI markings per NARA and DoD requirements (CUI designation indicator, category marking, limited dissemination control marking if applicable).
Step 4 — Personnel Mapping
Identify every employee, contractor, and subcontractor with access to identified CUI systems. This becomes the personnel scope for assessment — these individuals may be subject to assessor interviews.
Output: A documented CUI inventory: what categories exist, where they live, who can access them, and how they flow through the organization. This inventory is the direct input to scoping and to the SSP's system description.
4. The Five CMMC Asset Categories
The CMMC Level 2 Scoping Guide establishes five categories into which every asset in a contractor's environment must be classified. The category determines whether an asset is in scope for assessment and what controls apply to it.
| Asset Category | Definition | Assessment Impact |
|---|---|---|
| CUI Assets | Assets that process, store, or transmit CUI | Fully in scope; all 110 requirements apply |
| Security Protection Assets | Assets that provide security functions for CUI (e.g., firewalls, SIEM, MFA solutions, patch management) | Fully in scope; all 110 requirements apply |
| Contractor Risk Managed Assets | Assets that can reach CUI Assets or Security Protection Assets but do not process CUI (e.g., a workstation on the same network segment that is managed by the contractor) | In scope but with reduced assessment burden; contractor manages risk |
| Specialized Assets | Assets with unique characteristics: OT/ICS/SCADA equipment, IoT devices, test equipment, government-furnished equipment (GFE) | Assessed per applicable requirements; some exclusions apply |
| Out-of-Scope Assets | Assets with no path to CUI or Security Protection Assets; must be provably isolated | Not assessed |
The categorization of an asset as "Out-of-Scope" requires demonstration, not assertion. An assessor will verify that out-of-scope assets have no logical or physical path to in-scope assets. If a workstation on a "separate" network has a VPN client that can connect to the CUI network, it is not out of scope regardless of how the SSP categorizes it.
5. Enclave vs. Whole-Organization Scoping: The Core Decision
This is the most consequential scoping decision, and it should be made deliberately and with full understanding of the technical requirements for each approach.
Whole-Organization Scoping
In this model, every asset in the organization's IT environment is considered in scope because CUI is dispersed throughout the enterprise with no meaningful technical boundaries preventing access. This approach is appropriate when:
- CUI flows to a wide population of employees without restriction
- The organization lacks technical capability to segment its network
- The nature of the work makes CUI isolation impractical (e.g., a small contractor where every employee works on the DoD contract)
The advantage: simpler documentation. The disadvantage: every asset — including HR systems, accounting systems, executive laptops, and reception area computers — must meet all applicable 800-171 controls.
CUI Enclave Scoping
In this model, CUI is restricted to a defined, technically isolated enclave: a set of systems with enforced access controls, network segmentation, and limited connection points to the broader enterprise or internet. This approach reduces the assessment scope to only the enclave and its security protection assets.
Requirements for a defensible enclave:
- Genuine network segmentation (VLANs with enforced firewall rules, or physical separation)
- Access control lists that permit only authorized users to access enclave resources
- No path from non-enclave systems to CUI assets (or documented, controlled, and assessed paths for any allowed connections)
- SSP accurately describes the enclave boundary and all connections
Scoping Decision Matrix
| Factor | Favors Whole-Org Scoping | Favors Enclave Scoping |
|---|---|---|
| CUI distribution | Dispersed across many users | Concentrated among a defined team |
| Network architecture | Flat network; segmentation not feasible | Segmentation capability exists or can be built |
| Workforce CUI access | Most employees handle CUI | CUI handled by a defined project team |
| Budget flexibility | More remediation budget available | Cost minimization is priority |
| Timeline | More preparation time available | Compressed timeline; reduce scope to reduce work |
| Future scalability | One-time CUI contract | Ongoing CUI work; enclave investment pays over multiple assessments |
Having supported ATO programs at LANL — where boundary definition between classified, CUI, and unclassified systems is a fundamental security engineering discipline — I can confirm that enclave scoping done correctly produces a smaller, more defensible assessment boundary. Done carelessly, it produces a false sense of security and a finding-rich assessment.
6. Data Flow Mapping: The Technical Foundation of Scoping
A data flow diagram (DFD) is not optional for CMMC Level 2. It is explicitly referenced in the CMMC Scoping Guide and is the primary artifact assessors use to evaluate whether the boundary accurately reflects CUI movement through the organization.
Elements of a CMMC-Compliant Data Flow Diagram
| Element | Description |
|---|---|
| CUI entry points | Where CUI enters the organization (email from DoD, GFE, contract deliverable receipt) |
| Processing systems | Systems where CUI is created, modified, analyzed, or compiled |
| Storage locations | Repositories where CUI persists (file servers, databases, cloud storage) |
| Transmission paths | All channels over which CUI moves (internal network, email, file transfer, VPN) |
| Exit points | Where CUI leaves the organization (deliverables to DoD, flowdown to subs) |
| External connections | VPN connections, internet access, third-party integrations |
| Trust boundaries | Network demarcation points (firewalls, DMZs, VPN concentrators) |
Data Flow Mapping Process
1. Start with the CUI inventory. For each CUI asset identified in Step 3 of the inventory process, map every system that touches that asset.
2. Trace upstream and downstream. For each CUI-touching system, identify what systems feed data into it and what systems receive data from it.
3. Identify all protocols and ports. Document whether connections are encrypted, authenticated, and authorized.
4. Mark trust boundaries. Each boundary crossing is a potential scope expansion point. Any system on the trusted side of a boundary that can reach CUI assets is in scope.
5. Validate against reality. Walk the network with the network engineer. Compare the diagram to firewall rules, Active Directory group memberships, and cloud access policies. Gaps between the documented diagram and the actual configuration are findings waiting to happen.
Cloud Services in the Data Flow
Cloud Service Providers (CSPs) that store or process CUI must appear in the data flow diagram. Per 32 CFR § 170.16(a)(2), CSPs must be FedRAMP Moderate authorized or equivalent. The CSP's FedRAMP authorization boundary and the contractor's use of the CSP must both be documented in the SSP and reflected in the data flow.
External Service Providers (ESPs) that are not CSPs (e.g., a managed detection and response provider with access to security logs containing CUI metadata) must also be assessed as part of the CMMC assessment scope or have their services separately assessed. The 32 CFR Part 170 final rule significantly clarified ESP treatment, removing the blanket FedRAMP requirement for non-CSP ESPs and instead requiring their services to be assessed within the OSA's scope.
7. Network Segmentation: Making the Enclave Real
Network segmentation is the technical control that makes enclave scoping defensible. Without genuine segmentation, an enclave exists only on paper — and assessors will test the paper.
Segmentation Implementation Options
| Approach | Implementation | Verification Method |
|---|---|---|
| Physical separation | Separate switches, cabling, and hardware; no shared network infrastructure | Physical inspection; cable tracing |
| VLAN segmentation | Layer 2 VLANs with enforced Layer 3 routing rules | Firewall rule review; traceroute testing |
| Firewall-enforced zones | Stateful firewall policies permitting only authorized traffic between zones | Firewall ACL review; penetration test |
| Zero trust micro-segmentation | Software-defined perimeter; identity-based access to individual resources | Policy audit; access attempt testing |
Minimum Segmentation Requirements for CMMC Enclave
Per NIST SP 800-171 Rev 2 requirement 3.13.1 (Monitor, control, and protect communications at external boundaries and key internal boundaries), the following must be enforced:
- CUI systems must not be accessible from non-CUI network segments without traversing a control point (firewall, proxy, or access gateway) with explicit allow rules
- Default deny posture at the boundary: only explicitly authorized traffic is permitted
- Ingress and egress filtering at the boundary
- All connections crossing the boundary must be logged
Common Segmentation Failures
- Flat Wi-Fi networks: A corporate wireless network that permits connections to the CUI LAN without a firewall between them effectively places every Wi-Fi device in scope.
- Shared domain controllers: If the CUI enclave's Active Directory domain controller is shared with non-CUI systems, the authentication infrastructure is shared, and all systems that authenticate against it are in scope.
- Shared printers and file servers: Any shared service that CUI assets and non-CUI assets both access becomes a Contractor Risk Managed Asset — in scope.
- VPN clients on non-CUI endpoints: If a non-CUI laptop has a VPN client configured to reach the CUI network, that laptop is no longer out of scope.
- Cloud storage synchronization: If CUI documents sync automatically to a cloud folder that is also accessible from personal or unmanaged devices, the boundary extends to those devices.
8. Physical Boundary Considerations
CMMC Level 2 includes physical protection requirements under NIST SP 800-171 Rev 2 control family PE (Physical Protection, 6 controls). Physical boundaries must be consistent with the logical boundary documented in the SSP.
Physical Protection Requirements Relevant to Scoping
| Control | Requirement | Scoping Implication |
|---|---|---|
| 3.10.1 | Limit physical access to organizational systems to authorized users | CUI systems must be in physically controlled areas |
| 3.10.2 | Protect and monitor the physical facility | Facilities containing CUI systems need access control and monitoring |
| 3.10.3 | Escort visitors and monitor visitor activity | Visitor access to areas with CUI systems must be controlled |
| 3.10.4 | Maintain audit logs of physical access | Access logs for CUI areas must be maintained |
| 3.10.5 | Control and manage physical access devices | Badge readers, key fobs, and physical keys must be managed |
| 3.10.6 | Enforce safeguarding measures for CUI at alternate work sites | Remote work locations where CUI is accessed are in scope |
Remote Work and Physical Scoping
The shift to hybrid and remote work creates physical scoping complexity. If employees access CUI systems from home, the home office environment becomes a physical access consideration. The SSP must address how CUI is protected in remote work contexts. Common approaches include:
- Prohibiting CUI download to unmanaged home devices; all CUI access through VDI/RDS sessions only
- Issuing government-managed laptops with full-disk encryption and enforced MDM policies for remote CUI access
- Implementing geofencing controls that limit CUI system access to approved locations
9. Subcontractor CUI Flowdown and Scoping Implications
Under 32 CFR § 170.23, prime contractors must flow CMMC requirements down to subcontractors that will process, store, or transmit CUI in performance of the subcontract. This is not optional, and it is not the prime's judgment call about whether the sub "really" handles CUI.
Flowdown Hierarchy
| Prime Contract Level | Subcontract CUI | Required CMMC Status |
|---|---|---|
| Level 2 C3PAO requirement | Sub processes CUI | Minimum Level 2 (Self or C3PAO per solicitation specification) |
| Level 2 requirement | Sub processes FCI only (no CUI) | Level 1 |
| Level 3 requirement | Sub processes CUI | Minimum Level 2 C3PAO |
Subcontractor Scoping Implications for Primes
A prime contractor's CMMC assessment does not cover subcontractors. Each subcontractor must separately achieve the required CMMC status and have a current SPRS score. The prime is responsible for verifying subcontractor CMMC status before award and for maintaining that verification throughout contract performance. DFARS 252.204-7020 places this supply chain responsibility directly on prime contractors.
Practical Guidance on Sub CUI Determination
Not every subcontract involves CUI flowdown. The test is whether the subcontractor will actually receive or generate CUI in performance of their work under the subcontract. A subcontractor providing commercial components with no access to technical specifications, project data, or government systems typically does not handle CUI. A subcontractor developing software under a funded R&D contract with access to classified-adjacent technical requirements typically does. The determination must be documented.
10. Common Scoping Mistakes and How to Avoid Them
Mistake 1: Defining scope by organizational chart rather than data flow
The business unit that holds the DoD contract is not necessarily the only unit that handles CUI. Finance, HR, and IT organizations often touch CUI-adjacent systems. Follow the data, not the org chart.
Mistake 2: Excluding cloud services from scope
"It's the cloud provider's responsibility" is not a valid CMMC position. If you store CUI in a cloud service, that cloud service is in scope — either because it's FedRAMP authorized (and its FedRAMP boundary covers the security controls), or because it must be assessed within your scope. Undocumented SaaS tools used by CUI-handling employees (shadow IT) are a frequent source of scope gaps.
Mistake 3: Treating network segmentation as a documentation exercise
VLANs configured in a switch but not enforced by firewall rules are not segmentation. Assessors will test whether a non-CUI system can reach CUI assets. A successful connection from an out-of-scope device to an in-scope resource during the assessment is a NOT MET finding for SC.3.177 and related controls.
Mistake 4: Forgetting that security protection assets are in scope
The firewall that enforces your CUI boundary, the SIEM that monitors it, the patch management platform that updates CUI servers — all of these are Security Protection Assets and are fully in scope for assessment. Organizations that secure their CUI servers but neglect the security infrastructure itself create the illusion of compliance.
Mistake 5: Not updating scope after significant changes
Per 32 CFR Part 170 and the CMMC Level 2 Scoping Guide, "significant changes" — including architectural or boundary changes — require a new assessment. Adding a new cloud service, migrating to a new network architecture, or acquiring a business that handles CUI triggers reassessment obligations.
Mistake 6: Assuming government-furnished equipment is automatically out of scope
GFE is classified as a Specialized Asset, but its presence in your network may expand scope depending on how it connects to other assets. Review each GFE item's connectivity and classification with your Contracting Officer Representative (COR).
About the Author
Leonard Esere is the Founder of AeoliTech, a cybersecurity and compliance advisory firm specializing in the Defense Industrial Base. His background spans DoD Secret and DoE Q clearances, CMMC framework development through MITRE, ATO program execution at Los Alamos National Laboratory, and PCI DSS compliance at Frontier Airlines. He has defined assessment boundaries across environments ranging from small engineering firms to large research laboratories — environments where the consequences of a poorly scoped boundary are measured not just in assessment cost, but in mission integrity and national security.
References
1. 32 CFR Part 2002 — Controlled Unclassified Information Program (eCFR)
2. NARA CUI Registry — Category and Subcategory List
3. 32 CFR Part 170 — CMMC Program Final Rule (eCFR)
4. CMMC Level 2 Scoping Guide — DoD CIO
5. NIST SP 800-171 Revision 2 — Protecting CUI in Nonfederal Systems
6. 32 CFR § 170.16 — Level 2 Self-Assessment Requirements (Cornell LII)
7. 32 CFR § 2002.4 — CUI Definitions (Cornell LII)
8. CMMC Assessment Guide Level 2, Version 2.13 — DoD CIO
9. FedRAMP Marketplace — Authorized Cloud Services
10. DFARS 252.204-7012 — Safeguarding Covered Defense Information and Cyber Incident Reporting
> Need help defining your CMMC assessment boundary?
>
> AeoliTech's CUI scoping engagements include data flow mapping, network architecture review, enclave design, and a boundary definition document ready for your C3PAO's pre-assessment review.
>
> - Schedule a CMMC Gap Assessment → /services/cmmc-gap-assessment