CUI Scoping: How to Define Your CMMC Level 2 Assessment Boundary in an Afternoon
Most small DoD subcontractors spend their first month of CMMC prep worrying about the wrong thing. They buy a tool, hire a consultant, or start filling out a System Security Plan before they answer the one question that controls everything else: exactly what systems are in scope?
Scoping is the highest-leverage decision in your entire CMMC Level 2 journey. Get it right and you're defending a tight, well-documented enclave. Get it wrong and you're defending your whole company, including the marketing laptop, the HR file share, and the break-room Wi-Fi.
Why Scope Is Everything
A Certified Third-Party Assessment Organization (C3PAO) assesses whatever you put inside your boundary. Every system inside the boundary gets evaluated against all 110 practices in NIST SP 800-171. Every gap inside the boundary is a finding. Every finding costs remediation time and potentially delays your contract award.
When a small subcontractor draws the boundary around their entire company network, the assessment scope can balloon 5 to 10 times compared to a tightly defined enclave. That translates directly into assessment hours, consultant fees, remediation surface area, and ongoing compliance maintenance costs. A well-scoped assessment for a 25-person firm might be manageable in weeks. A sprawling enterprise scope at the same firm can run for months and cost multiples of the initial budget.
The flip side is equally important: a smaller scope means a smaller attack surface. Fewer systems handling Controlled Unclassified Information (CUI) means fewer vectors for a breach. Scoping isn't just a compliance optimization. It's a security decision.
Step 1: Inventory Every System That Touches CUI
CUI flows through your environment in ways that aren't always obvious. The goal here is to trace CUI from the moment a contract award document or technical data package arrives until the deliverable leaves your facility.
Work through these categories systematically:
Ingestion points. How does CUI arrive? Common paths include:
- Email (Microsoft 365, Google Workspace, or on-premises Exchange)
- A DoD portal such as SAFE, piee.whs.mil, or a prime contractor's extranet
- Physical media or hard-copy documents that get scanned
Working storage. Where does CUI live while your engineers are using it?
- Workstations and laptops used by program personnel
- File shares (on-premises NAS, SharePoint, Teams channels, shared drives)
- Engineering tools: CAD software vaults, PDM/PLM systems, simulation environments
- Databases tied to program deliverables
Communication in transit. How do your people share CUI internally or with the prime?
- Email attachments
- Collaboration platforms (Teams, Slack, etc.)
- Video calls where CUI is shared on screen or in chat
Backup and recovery systems. This is where most small contractors miss something. If your file server backs up nightly to a cloud storage bucket or a tape drive in the server room, that backup contains CUI. The backup system is in scope.
Contractor-managed tools. Third-party software that processes or stores CUI, including cloud-hosted platforms, counts. If your subcontractor uploads drawings to a project management SaaS, that platform is in scope or needs a formal boundary decision.
Write every system down. At this stage, resist the urge to exclude anything. You'll make exclusion decisions in Step 2.
Step 2: Draw the Boundary as Tight as Possible
Once you know what touches CUI, the question becomes: can you isolate those systems from the rest of your environment?
The CMMC scoping guidance (documented in the DoD's CMMC Scoping Guide for Level 2) defines four asset categories:
CUI Assets
Systems that process, store, or transmit CUI directly. These are always in scope, full stop. Every NIST SP 800-171 practice applies to these assets.
Security Protection Assets
Systems that provide security functions protecting CUI Assets, even if they don't touch CUI themselves. Examples include your firewall, your identity provider (Active Directory, Azure AD/Entra ID), your endpoint detection platform, and your SIEM. These are in scope because a compromise here exposes your CUI Assets.
Contractor Risk Managed Assets
Systems that could interact with CUI but where you have implemented documented controls to ensure they don't. A common example: a general-purpose employee laptop that is network-adjacent to the CUI enclave but is technically and administratively restricted from accessing CUI systems. These assets go through a lighter-weight assessment treatment, but the risk management rationale must be documented.
Out-of-Scope Assets
Systems with no pathway to CUI and no security protection function for CUI Assets. The marketing team's laptops, the guest Wi-Fi, the POS system in the lobby. These genuinely have no CMMC obligations, provided the separation is real and documented.
The dedicated CUI enclave approach. For many small subcontractors, the cleanest solution is to carve out a dedicated enclave. This might be a small set of physically separate workstations on a VLAN with no route to the corporate network, or a cloud-hosted environment (a Microsoft GCC High tenant or an IaaS environment with appropriate configuration) used exclusively for program work. Everyone who touches CUI uses the enclave. Everyone else stays off it entirely.
This approach requires discipline. An engineer who opens a CUI email on their personal laptop or a corporate device outside the enclave just pulled that device into scope. Clear written policies and technical enforcement (block CUI email on non-enclave devices) are not optional.
Step 3: Document the Separation
Drawing the line is necessary. Proving the line exists is what the C3PAO actually evaluates.
For each boundary decision, you need documentation that covers:
- A network diagram showing in-scope and out-of-scope segments, firewall rules between them, and data flows for CUI.
- An asset inventory that maps every asset to its scope category (CUI Asset, Security Protection Asset, Contractor Risk Managed Asset, or Out-of-Scope).
- Technical controls enforcing the boundary. VLAN segmentation, firewall ACLs, conditional access policies that restrict CUI application access to compliant/managed devices, and Data Loss Prevention (DLP) rules blocking CUI from leaving the enclave via personal email.
- A written justification for each Contractor Risk Managed Asset, explaining why the asset is managed not to touch CUI and what controls enforce that decision. This maps directly to NIST SP 800-171 control 3.12.4 (system security plan) which requires you to describe the boundary.
- Policy documents referenced in your System Security Plan (SSP) that govern enclave access, acceptable use, and incident response for the in-scope environment.
This documentation package becomes the foundation of your SSP. If you start your SSP before this documentation exists, you're building on sand.
A Concrete Example: 25-Person Engineering Firm
Consider a mechanical engineering company with 25 employees. They have one DoD program, a prime contract for a defense system component. Eight engineers work that program. The other 17 employees are in business development, finance, and corporate engineering unrelated to DoD work.
Before scoping: The IT team manages one flat corporate network. All 25 laptops are on the same domain. SharePoint has one tenant with no segmentation. Everyone's email is in the same Microsoft 365 tenant with no sensitivity labels enforced.
After a one-afternoon scoping exercise:
- CUI Assets: 8 engineer workstations, one SharePoint site collection (program documents), one shared network drive (drawings and models), the email accounts of the 8 program engineers.
- Security Protection Assets: The M365 tenant's Azure AD/Entra ID instance (identity for CUI asset access), the endpoint management platform (Intune), the conditional access policies governing enclave access.
- Contractor Risk Managed Assets: The corporate file server (adjacent to the network but blocked from the CUI SharePoint via conditional access and DLP policies, with documented justification).
- Out-of-Scope: 17 non-program laptops, business development SharePoint sites, marketing email accounts, guest Wi-Fi.
The scope went from "entire company" to 8 workstations, one SharePoint site, one file share, and the identity infrastructure protecting them. The assessment surface shrank dramatically before a single control was implemented.
Common Scoping Mistakes to Avoid
- Treating the whole company as in-scope by default. This is the most expensive mistake. "We didn't know how to limit scope" is not a valid approach when the DoD scoping guide gives you explicit categories.
- Ignoring email. If program engineers receive technical data packages by email, that email account and the mail platform handling it are CUI Assets. They must be in scope.
- Forgetting SharePoint and Teams. Collaboration platforms that store or transmit CUI are in scope. A Teams channel where engineers share drawings is a CUI Asset.
- Leaving backup systems out. Backups inherit the classification of the data they contain. A backup job that sweeps your CUI file share into a cloud storage bucket puts that bucket in scope.
- Scope creep from convenience. Engineers who work CUI tasks on a personal device or a corporate device outside the enclave "because it's easier" destroy your boundary documentation overnight. Technical enforcement, not just policy, is required.
Still on the fence? See it on your data.
30 minutes, live screen-share against your real SSP or POA&M. No slides, no card on file.
Book a demo
Start with Scope, Then Build Everything Else
Every other CMMC activity, your SSP, your Plan of Action and Milestones (POA&M), your control implementation, your evidence collection, is scoped to the boundary you define here. A well-reasoned, documented, tightly drawn boundary is the single best investment of time before any assessment prep work begins.
Readyline GRC is built specifically for this workflow. The platform helps defense contractors map assets to CMMC scope categories, generate the network and asset documentation C3PAOs expect, and maintain the SSP that ties it all together. If you're doing this for a small subcontractor operation, take a look at what the platform covers for defense contractors before you start filling out spreadsheets manually.
Do the scoping work first. Everything else gets easier from there.
