The CUI enclave is the boundary inside which all 110 NIST SP 800-171 controls apply — everything outside it is out of scope.
A well-defined enclave can reduce in-scope systems by 60–80%, proportionally cutting assessment cost and effort.
The SSP (System Security Plan) must fully document the enclave and every control within it — this is the primary artefact the C3PAO will examine.
Why scope is the most important decision
Every organization pursuing CMMC 2.0 Level 2 must implement all 110 NIST SP 800-171 controls — but "all 110 controls" applies only to the systems, people, and processes that handle Controlled Unclassified Information (CUI). Everything outside that boundary is out of scope for the C3PAO assessment. Defining that boundary — the CUI enclave — is therefore the single highest-leverage decision in your CMMC program. A poorly scoped enclave that includes your entire enterprise network means your entire enterprise network must meet all 110 controls. A well-defined enclave that contains only the systems that actually touch CUI can reduce the scope by 60–80%.
What a CUI enclave is
A CUI enclave is a defined, bounded environment that contains all the systems, components, and people that create, receive, process, store, or transmit CUI. The boundary is documented in your System Security Plan (SSP) and supported by network diagrams, data flow diagrams, and asset inventories. The enclave is separated from the rest of your environment by technical controls — network segmentation, access controls, and boundary protection mechanisms that prevent CUI from flowing outside the defined scope.
In practice, a CUI enclave might be a GovCloud tenant (e.g., Microsoft Azure Government or GCC High) where all DoD contract work lives, isolated from the commercial infrastructure used for other customers. It might be a separate network segment with dedicated endpoints, VPN-enforced access, and a separate identity provider. The architecture varies; what matters is that the boundary is documented, enforced, and auditable.
How to define your boundary
Start by tracing CUI flows: where does CUI enter your environment (contracts, drawings, specifications from the prime or the government), how does it move through your systems, who accesses it, where is it stored, and how does it leave (deliverables, reports, data returns). Every system that appears in that flow is in scope. Every person who has access to those systems is in scope. Every vendor with access to those systems is a subservice organization that must be assessed under CC9.2.
Once you have mapped the flow, design the architecture to minimize the enclave. Can the CUI-handling work be moved to a dedicated GCC High or GovCloud tenant? Can the team that touches CUI be limited to a defined group using dedicated endpoints? The goal is not to avoid controls — it is to apply them where they are needed and only where they are needed.
The SSP is the centrepiece
Everything about your CUI enclave — the boundary, the assets, the people, the connections to external systems, and the implementation status of all 110 practices — is documented in the System Security Plan. The SSP is the primary artefact a C3PAO examines during a Level 2 assessment. A complete, accurate, well-maintained SSP is not just a compliance requirement — it is the instrument that demonstrates you understand your environment. Any practice you cannot document in the SSP is a finding. Any control gap documented in the SSP but not tracked in a Plan of Action and Milestones (POA&M) with a remediation date is a deficiency. Build the SSP and POA&M first; everything else flows from them.