A CMMC enclave is a deliberately bounded environment — systems, identities, locations — where all of your CUI lives, so that the 110 requirements of NIST SP 800-171 apply to that boundary instead of your entire company. It is the single most consequential scoping decision in a Level 2 program: done well, it shrinks cost, timeline, and assessment surface simultaneously; done carelessly, it is a paper wall an assessor dismantles in an afternoon. We run our own CUI enclave — it is the environment our C3PAO assessed — so what follows is practice, not theory.
Enclave scope vs. whole-company scope
Nothing in 32 CFR Part 170 requires an enclave — the rule requires that wherever CUI is processed, stored, or transmitted, the controls apply. The choice is economic: a 15-person engineering team inside a 200-person company can carry the CUI mission in an enclave of a few dozen assets, or the whole company can live under 110 requirements. The first option means fewer systems to harden, fewer people to train and interview, and less evidence to maintain — the compounding savings we walk through in the cost breakdown.
The asset categories that define your scope
Level 2 scoping is a vocabulary, defined at 32 CFR § 170.19 and in the DoD’s Level 2 scoping guidance on the official CMMC documentation site. Your enclave design is literally the act of sorting everything you own into five bins:
- CUI Assets — process, store, or transmit CUI. Fully in scope, fully assessed.
- Security Protection Assets — provide security functions to the scope (your SIEM, your identity provider, your MSP’s tooling). Assessed for the functions they provide, wherever they sit.
- Contractor Risk Managed Assets — could touch CUI but are kept from doing so by policy and practice. Documented, lightly reviewed, and the first place weak enclaves fail.
- Specialized Assets — IoT, OT, government-furnished equipment, test gear. In scope but assessed against documented risk-based handling in the SSP.
- Out-of-Scope Assets — physically or logically separated from CUI, incapable of touching it. The whole point of the enclave is making this bin large and defensible.
GCC High enclave design
Most modern enclaves are cloud-first: a Microsoft 365 GCC High tenant for CUI collaboration, hardened endpoints enrolled to it, conditional access as the moat, and the rest of the company left outside. That architecture also keeps custody clean — your data in your tenant, including the CMMC Tracker, which deploys into your GCC High environment rather than ours. The pattern is not mandatory (some CUI profiles defensibly stay in commercial clouds with controls), but when ITAR or export-controlled data is in play, GCC High is usually where the analysis lands.
Pros, cons, and honest trade-offs
- For: smaller assessment surface; faster remediation; lower licensing and evidence burden; cleaner interviews (the people in scope actually do CUI work); easier maintenance between assessments.
- Against: migration effort up front; day-to-day friction when people must switch environments for CUI work; dual-environment IT overhead; and boundary discipline forever — one undisciplined file share un-draws the whole line.
When an enclave is the wrong choice
If CUI genuinely touches most of your staff and systems — a machine shop where drawings drive the floor, a small prime where every engineer sees deliverables — an enclave adds a boundary tax without shrinking anything. The honest answer is sometimes “your company is the enclave.” That is a scoping-judgment call, which is why it is step one of our CMMC compliance consulting and step two of the compliance checklist — and why we make it against your contracts, in writing, before anyone buys licenses.