CUI Boundary Scoping for CMMC

Your CUI boundary is the set of systems, networks, and data flows that store, process, or transmit Controlled Unclassified Information. The boundary defines what gets assessed and what does not. Get it right and assessment is straightforward. Get it wrong and you either spend twice what you needed to (over-scoping) or fail assessment because in-scope assets were treated as out-of-scope.

The CMMC Scoping Guide is the authoritative document. It defines five asset categories with different control expectations. Read it before you draw a single network diagram.

Cross-reference your scoping against the CMMC framework reference and any flow-down requirements from your prime contractor.

The CMMC Scoping Guide defines five categories. Every asset in your environment falls into one:

1. CUI Assets: Process, store, or transmit CUI. Full 110 practices apply.
2. Security Protection Assets: Provide security functions for CUI assets (SIEM, IdP, MFA tokens, EDR consoles). Practices that are relevant to their security function apply.
3. Contractor Risk Managed Assets: Capable of processing CUI but where you have implemented controls that prevent it. Documented and managed.
4. Specialized Assets: IoT, OT, government property, restricted information systems. Limited control set applies.
5. Out-of-Scope Assets: No connection to CUI environment. Not assessed.

Each asset must end up in exactly one category. Document the categorization in an asset inventory.

Strong segmentation lets you reduce scope dramatically. If your CUI environment is in a dedicated VLAN, VPC, or AWS GovCloud account with controlled boundaries, then everything outside that segment can be out-of-scope, as long as the segmentation is enforced.

Segmentation that holds up:

• Separate identity tenant: A separate Okta or Entra ID tenant for CUI users, not just a group within the corporate tenant
• Separate cloud account or subscription: AWS GovCloud account or Azure Government tenant
• Network isolation: VLANs, security groups, or firewall rules with deny-by-default
• Data flow controls: DLP rules that prevent CUI from leaving the boundary
• Documented data flows: A diagram showing every path CUI travels

Weak segmentation drags everything into scope. If the same Active Directory authenticates both CUI and non-CUI systems, both are in scope.

Five mistakes show up in failed scoping decisions over and over:

• Email in-scope by accident: If users email CUI internally, the email system processes CUI. Either implement CUI handling controls in email or formally prohibit email for CUI with technical enforcement (DLP).
• Backup systems out-of-scope: If backups contain CUI, they are CUI assets. Encrypt them with FIPS modules and treat them like primary storage.
• Developer environments ignored: If devs ever pull production data containing CUI into staging, staging is in scope. Sanitize or block the flow.
• Personal devices not addressed: BYOD that touches CUI is in scope. Either prohibit it (technically enforce) or apply mobile device management with the full control stack.
• SaaS providers not categorized: Vendors handling CUI on your behalf must be FedRAMP Moderate Authorized or DoD impact level matched. Verify before you treat them as out-of-scope.

The C3PAO will ask for the scoping artifacts on day one. Have these ready:

1. Network diagram: Shows the CUI boundary in red or another distinct color. All network paths labeled. Trust zones marked.
2. Asset inventory: Every asset with its category (CUI, SPA, CRMA, Specialized, Out-of-Scope). Owner. Location.
3. Data flow diagram: How CUI enters, moves through, and leaves the boundary. Includes external interfaces.
4. System Security Plan (SSP): Describes the boundary in narrative form. Each practice in the SSP references the systems it applies to.
5. SaaS inventory: Every cloud service, with its FedRAMP status and what data it processes.

Update these artifacts as the environment changes. A network diagram from 18 months ago that does not show the new VPN concentrator looks careless to assessors.