Module 6: Scoping, Asset Classification, and Boundary Definition - CMMC 2.0 Expert Path: From Framework Basics to Contract-Ready Compliance

Step 1 – Why CMMC Scoping and Boundaries Matter

In CMMC, scoping is the process of deciding exactly which people, systems, and assets are subject to the assessment. Done correctly, scoping:

Reduces cost and complexity by avoiding unnecessary systems in scope
Prevents under-scoping, which leads to failed assessments and potential contract loss
Clarifies accountability: which networks, cloud tenants, and users must meet CMMC practices

As of late 2025, CMMC 2.0 scoping is still guided by the DoD CMMC Scoping Guides (v2.0 drafts released 2021–2022, still referenced by DoD and the CMMC-AB/CA ecosystem). These remain the de facto standard until DoD publishes updated final guides under the CMMC 2.0 rule.

Key points to keep in mind:

CMMC Level 1 (FCI only) uses a simpler scoping model: focus on assets that process, store, or transmit Federal Contract Information (FCI).
CMMC Level 2 (CUI) inherits scoping logic from NIST SP 800-171 and the DFARS 252.204-7012 clause: focus on systems that process, store, or transmit Controlled Unclassified Information (CUI).
Segmentation and enclaves are legitimate strategies to limit CUI to well-controlled islands and keep the rest of your environment out of scope.

Throughout this module, we assume a Level 2 (CUI) environment, because it is where scoping decisions are most complex and high‑impact.

> Mental model: Scope is not “everything your company owns” – it is the set of assets that can affect the confidentiality of CUI (or FCI), directly or indirectly.

Step 2 – CMMC Asset Types and Scoping Categories

The CMMC 2.0 scoping guides define asset types and classify them as in-scope or out-of-scope depending on their relationship to FCI/CUI.

Core Asset Types (CMMC Scoping Guide for Level 2)

CUI Assets

Systems that process, store, or transmit CUI.
Always in scope.
Examples: CUI file server, engineering workstations with CUI CAD files, secure SharePoint site containing CUI.

Security Protection Assets (SPAs)

Assets that provide security functions for CUI assets or the CUI environment.
Always in scope.
Examples: firewalls, IDS/IPS, SIEM, vulnerability scanners, identity providers (IdPs), centralized logging servers.

Contractor Risk Managed Assets (CRMAs)

Assets that can access the CUI environment but do not themselves store CUI and are managed by the contractor.
In-scope for risk-based treatment; you must justify controls or compensating measures.
Examples: admin jump boxes, IT support laptops with RDP access into the CUI enclave, management workstations with privileged access but no local CUI storage.

Specialized Assets

Operational Technology (OT), IoT, IIoT, test equipment, lab systems, etc. that may have limited or specialized interfaces with CUI.
Often need case-by-case analysis; may be in scope if they process CUI or provide security functions or could materially impact CUI confidentiality.
Examples: CNC machines receiving CUI design files, PLCs controlling processes that embed CUI tolerances, factory floor HMIs.

Out-of-Scope Assets

Assets that do not process, store, or transmit FCI/CUI, have no security function for in-scope assets, and cannot materially impact the confidentiality of CUI.
Examples (if properly segmented): a marketing website server, HR SaaS used only for internal HR data, a guest Wi‑Fi network separated from the CUI enclave.

> Advanced nuance: The hardest category is CRMAs and Specialized Assets. At Level 2, the assessor will expect a documented risk rationale explaining why some assets are treated with reduced controls or excluded, and how segmentation or technical safeguards prevent them from impacting CUI.

Step 3 – Classify Assets in a Hypothetical Environment

Consider this fictional small defense contractor, AeroFab LLC:

A. Engineering workstations running CAD with CUI drawings
B. A NAS file server storing CUI design packages
C. The corporate email system (Microsoft 365) where some CUI is exchanged
D. A firewall that segments the engineering VLAN from the rest of the corporate network
E. Accounting workstations (no CUI, only financial data)
F. A CNC machine that receives part programs containing CUI tolerances over the shop network
G. IT helpdesk laptops that can RDP into any workstation, including engineering
H. A public marketing website hosted by a third-party provider

Your task: For each asset, decide which category it belongs to:

CUI Asset
Security Protection Asset
Contractor Risk Managed Asset
Specialized Asset
Out-of-Scope Asset

Write down your classification and justify borderline cases (C, F, G, H). Then reveal the suggested mapping below.

<summary>Suggested classification (click to expand)</summary>

A. Engineering workstations → CUI Assets (process and store CUI)
B. NAS file server → CUI Asset (stores CUI)
C. Corporate email (M365) → CUI Asset if used to send/receive CUI; otherwise, if contract forbids CUI in email and controls enforce that, it may be out-of-scope or CRMAs. In most real environments, this is CUI.
D. Firewall → Security Protection Asset (provides security for CUI assets)
E. Accounting workstations → Likely Out-of-Scope, if strongly segmented and no CUI access; otherwise CRMAs.
F. CNC machine → Specialized Asset (OT system interacting with CUI content)
G. IT helpdesk laptops → Contractor Risk Managed Assets (can affect CUI via remote admin access)
H. Public marketing website (third‑party hosted) → Typically Out-of-Scope, if there is no CUI and no security dependency with the CUI environment.

</details>

Reflect: Which assets surprised you by being in scope? Most organizations underestimate how many assets become in-scope due to privileged access or security functions.

Step 4 – Defining the CUI System Boundary

To translate asset classification into a CMMC assessment boundary, you must define the system boundary for CUI processing, storage, and transmission.

A system boundary (in NIST and CMMC practice) is:

> The set of components (hardware, software, networks, people, processes) that collectively deliver a function and share a common security policy and management control.

For CMMC Level 2, the relevant boundary is the CUI system boundary.

Conceptual Components of a Boundary

Think of the boundary as a box around:

CUI data stores (databases, file shares, document libraries)
CUI processing endpoints (workstations, VMs, applications)
Network segments carrying CUI traffic
Security services that protect these components (firewalls, IdPs, logging)
Administrative interfaces that can materially affect these components

Everything inside the box must meet the CMMC practices (derived from NIST SP 800‑171). Some assets outside the box may still be in-scope if they:

Provide security functions (SPAs), or
Have privileged access or connectivity that can impact CUI confidentiality (CRMAs, some specialized assets).

Visual Description: CUI Enclave

Imagine a diagram with:

A central rectangle labeled `CUI Enclave` containing:
CUI file server
CUI application servers
CUI user workstations
A surrounding ring labeled `Security Services` containing:
Firewall, VPN, MFA/IdP, SIEM
Arrows from `Corporate Network` into the `CUI Enclave` through the firewall/VPN
A cloud tenant (e.g., GCC High, FedRAMP High SaaS) with a dotted line boundary connected to the enclave by an encrypted tunnel

The solid lines show the CUI boundary. The dotted lines show connected but separately managed systems (e.g., external cloud providers) that may be in scope via shared responsibility.

> Key idea: You are not defining an arbitrary boundary. You are discovering the natural security perimeter around all places where CUI lives or flows, and then tightening it with segmentation.

Step 5 – Using Enclaves and Segmentation to Control Scope

A common advanced strategy is to build a CUI enclave – a logically or physically segmented environment where all CUI is intentionally concentrated.

Example 1 – On-Prem CUI Enclave

Scenario: A mid-sized manufacturer with a flat network today.

Before:

All workstations on the same VLAN
CUI files scattered on desktops, email, and generic file shares
IT admin tools can reach everything from anywhere

After implementing a CUI enclave:

Create a dedicated CUI VLAN and CUI Active Directory OU for CUI users and systems
Move CUI file servers and CUI applications into that VLAN
Restrict CUI access to named CUI user accounts and CUI workstations only
Implement firewall rules so that:
Only CUI workstations can reach CUI servers
Only specific admin jump hosts can manage CUI systems
Implement data loss prevention (DLP) or other controls to prevent CUI from leaving the enclave via USB, email, or non‑CUI shares

Result:

In-scope: CUI VLAN, CUI workstations, CUI servers, jump hosts, firewalls, IdP, logging/monitoring infrastructure
Out-of-scope or CRMAs: Non‑CUI office workstations, marketing systems, guest Wi‑Fi, if they cannot access CUI

Example 2 – Cloud CUI Enclave (Microsoft 365 + Azure)

Scenario: A design firm uses Microsoft 365 Commercial for everything today and wants to handle CUI.

Options:

Move CUI to GCC High or FedRAMP High/Moderate environments (e.g., M365 GCC High) and treat that tenant as the CUI enclave.
Implement separate tenants: one for CUI, one for non‑CUI.
Use Conditional Access to restrict CUI access to hardened devices and locations.

Boundary implications:

The CUI tenant (GCC High) plus the devices that access it form the core of the CUI system boundary.
The commercial tenant can be mostly out of CUI scope if:
CUI is prohibited there by policy and technical controls
There are no syncs or cross‑tenant flows that move CUI

> Advanced challenge: Cloud providers operate under shared responsibility models. You must understand which controls are inherited (e.g., FedRAMP controls) and which are your responsibility (e.g., access control configuration, device compliance, key management).

Step 6 – Quick Check: Segmentation and Scope

Test your understanding of how segmentation affects scope.

A contractor creates a physically separate CUI enclave with dedicated switches, firewalls, and CUI-only workstations. The rest of the corporate network cannot route to the enclave, except for one hardened admin jump host. Which statement is MOST accurate for CMMC Level 2 scoping?

Only the CUI enclave assets are in scope; the admin jump host is out of scope because it does not store CUI.
The CUI enclave assets and the admin jump host are in scope; the rest of the corporate network can be out of scope if it truly cannot access the enclave.
All corporate assets remain in scope because they belong to the same legal entity.

Show Answer

Answer: B) The CUI enclave assets and the admin jump host are in scope; the rest of the corporate network can be out of scope if it truly cannot access the enclave.

CMMC scoping is based on **technical and logical relationships to CUI**, not just legal ownership. The CUI enclave is clearly in scope. The admin jump host is a **Contractor Risk Managed Asset** (or possibly a Security Protection Asset) because it has privileged access and can affect CUI confidentiality. The rest of the corporate network can be out of scope if segmentation is robust and properly documented.

Step 7 – Step-by-Step Scoping Method (Advanced)

Here is a rigorous, repeatable method you can apply to scope a CMMC Level 2 environment.

Step 1 – Identify CUI Sources and Obligations

Review contracts and flowdown clauses (e.g., DFARS 252.204‑7012, 252.204‑7021, 252.204‑7019/7020) to confirm:
Whether you will handle CUI or FCI only
Any system-specific requirements (e.g., use of US-only data centers)
Inventory all business processes that receive, create, or transmit CUI
Examples: engineering design, configuration management, quality control, program management

Step 2 – Map CUI Data Flows

For each process, trace:
Where CUI enters (email, portals, SFTP, DoD systems)
Where CUI is stored (file servers, PLM, ticketing, wikis)
How CUI moves (VPN, internal networks, removable media)
Where CUI exits (deliverables to primes/DoD, archives)
Use data flow diagrams (DFDs) or simple tables to document flows.

Step 3 – Identify CUI Assets and SPAs

Mark all systems that directly process, store, or transmit CUI → CUI Assets.
Identify systems that provide security functions for those assets → Security Protection Assets (firewalls, IdPs, SIEM, AV/EDR consoles, backup systems).

Step 4 – Identify CRMAs and Specialized Assets

List systems that:
Have admin or privileged access to CUI assets (IT laptops, jump hosts, management consoles), or
Are OT/IoT that receive or influence CUI content.
Classify them as Contractor Risk Managed or Specialized.

Step 5 – Analyze Connectivity and Segmentation

For each non‑CUI network or cloud environment, ask:
Can it reach the CUI assets (directly or via shared credentials)?
Does it host security services used by CUI assets (e.g., corporate IdP, DNS, NTP)?
Where possible, tighten segmentation so that only necessary systems remain connected.

Step 6 – Draw the System Boundary Diagram

On a single page, show:
CUI assets (highlighted)
SPAs around them
CRMAs and specialized assets with arrows showing access paths
External services (clouds, partners) with trust boundaries
Use different colors or shapes for each asset type.

Step 7 – Document Scoping Rationale

For every asset class (including those you exclude), record:
Why it is in or out of scope
The controls or architectural features that justify your decision (e.g., VLAN isolation, firewall rules, separate identity domains)
This document becomes a key artifact for assessors.

> Advanced expectation: In a real C3PAO assessment, expect detailed questioning about borderline assets, especially CRMAs, OT, and shared corporate services (e.g., enterprise IdP, backup systems, MDM). Your scoping rationale must be technically defensible.

Step 8 – Draft a High-Level Boundary for a Hypothetical Contractor

Apply the step-by-step method to this scenario and sketch a boundary mentally or on paper.

Scenario: SkyLine Avionics, Inc.

Receives CUI design packages via a secure DoD portal
Stores CUI on a dedicated on‑prem file server
Engineers access CUI from domain‑joined Windows 11 workstations
Uses Microsoft 365 Commercial for email and collaboration (policy: no CUI in M365)
Has a corporate AD domain that also serves non‑CUI users
Uses a single firewall to separate the corporate network from the Internet
Uses a cloud-based SIEM and EDR platform to monitor all endpoints
IT admins use laptops that can RDP into any workstation or server

Tasks:

List CUI Assets.
List Security Protection Assets.
List Contractor Risk Managed Assets.
Decide whether the M365 Commercial tenant is in scope.
Draw (mentally or on paper) a system boundary diagram showing:

CUI enclave
Corporate network
Cloud services

When you are done, compare with the suggested outline below.

<summary>One possible high-level boundary (click to expand)</summary>

CUI Assets

CUI on‑prem file server
Engineering workstations that access that server
DoD secure portal endpoint(s) where CUI is downloaded

Security Protection Assets

Firewall (if it enforces rules for CUI traffic)
Domain controllers (if they authenticate CUI users)
EDR agent and SIEM connectors on CUI systems

Contractor Risk Managed Assets

IT admin laptops with RDP access to CUI systems
Non‑CUI corporate servers that can still reach the CUI assets (if any)

M365 Commercial Tenant

If technical controls (DLP, transport rules, training, monitoring) effectively prevent CUI in M365, and CUI is never sent via email, you can argue M365 is out of CUI scope.
If in reality engineers occasionally email CUI, or there is no effective prevention, then M365 becomes a CUI Asset, greatly expanding scope.

Boundary sketch

Draw a `CUI VLAN` box containing: CUI file server, engineering workstations, DoD portal access point.
Surround it with: firewall, AD domain controllers, EDR/SIEM connectors.
Show admin laptops outside the CUI VLAN but with RDP arrows into it (CRMAs).
Show M365 cloud as a separate box; connect it with a dotted line to the corporate network.

</details>

Reflect: What architectural changes (e.g., separate AD domain for CUI, dedicated firewall, or a GCC High tenant) could further reduce or clarify SkyLine’s CUI scope?

Step 9 – Edge Case: Shared Services and Scope

Shared services often create subtle scoping questions. Consider this edge case.

A contractor uses a single corporate identity provider (IdP) and AD domain for all users, including those accessing the CUI enclave. The IdP also serves non‑CUI SaaS apps. Which statement best reflects the CMMC Level 2 scoping implication?

The IdP is out of scope because it does not store CUI content.
The IdP is a Security Protection Asset because it provides authentication and authorization for CUI systems, even if it also serves non‑CUI apps.
Only the CUI user accounts within the IdP are in scope; the IdP infrastructure is out of scope.

Show Answer

Answer: B) The IdP is a Security Protection Asset because it provides authentication and authorization for CUI systems, even if it also serves non‑CUI apps.

Because the IdP **controls access to CUI systems**, it is a **Security Protection Asset** and therefore in scope. It does not need to store CUI data to be in scope; its influence on CUI confidentiality via authentication and authorization is sufficient. You may scope controls to the portions of the IdP relevant to CUI, but the IdP infrastructure itself must be considered in the boundary.

Step 10 – Key Term Review

Use these flashcards to reinforce critical terminology before moving on.

CUI Asset: Any system, device, or application that directly processes, stores, or transmits Controlled Unclassified Information (CUI). Always in scope for CMMC Level 2.
Security Protection Asset (SPA): An asset that provides security functions or services (e.g., firewall, IdP, SIEM, EDR console) to CUI assets or the CUI environment. Always in scope.
Contractor Risk Managed Asset (CRMA): A contractor-managed asset that can access or affect the CUI environment but does not itself store CUI. In scope for risk-based treatment and justification.
Specialized Asset: OT, IoT, IIoT, lab, or test systems with specialized functions that may interact with CUI or influence its protection. Often require case-by-case scoping decisions.
System Boundary: The set of components (hardware, software, networks, people, processes) that collectively deliver a function and share a common security policy, defining what is inside vs. outside the assessed CUI environment.
CUI Enclave: A logically or physically segmented environment where all CUI processing, storage, and transmission is concentrated to simplify security controls and limit CMMC scope.
Segmentation: The use of technical controls (e.g., VLANs, firewalls, separate domains/tenants) to restrict connectivity and access paths, thereby limiting which assets fall into CMMC scope.

Key Terms

Scoping: The process of identifying which assets, users, networks, and services are included within the CMMC assessment boundary based on their relationship to FCI/CUI.
CMMC 2.0: The Cybersecurity Maturity Model Certification framework updated by the U.S. Department of Defense, aligning Level 2 primarily with NIST SP 800-171 requirements and using third-party assessments for certain contracts.
CUI Enclave: A bounded, segmented environment (on-prem or cloud) where CUI is intentionally isolated to simplify implementation and assessment of required security controls.
NIST SP 800-171: NIST Special Publication specifying security requirements for protecting CUI in nonfederal systems and organizations; forms the technical basis for most CMMC Level 2 practices.
System Boundary: The conceptual and often diagrammed perimeter within which all components share a common security policy and are subject to the same set of controls for assessment.
Specialized Asset: Non-traditional IT assets like OT, IoT, IIoT, lab equipment, or test rigs that may process or influence CUI and often require tailored scoping and control approaches.
Security Protection Asset: An asset that provides security-relevant services such as access control, monitoring, or network protection for in-scope systems; always included in CMMC scope.
Contractor Risk Managed Asset: An asset under the contractor’s control that can access or influence the CUI environment but is not itself a CUI data store; treated through documented risk-based decisions.
FCI (Federal Contract Information): Information provided by or generated for the U.S. Government under a contract to develop or deliver a product or service to the Government, not intended for public release.
CUI (Controlled Unclassified Information): Information that requires safeguarding or dissemination controls pursuant to and consistent with applicable law, regulations, and government-wide policies, as defined by the U.S. National Archives (NARA) CUI program.