Enclaves & Use Cases

The Enclave Model

Most DIB contractors don’t — and shouldn’t — apply CMMC controls to their entire enterprise. Instead, they create an enclave: a defined security zone within the larger enterprise that contains CUI and is assessed against CMMC requirements. The rest of the enterprise stays outside the scope.

Within this model, you can meet CMMC requirements through a combination of enterprise-wide and enclave-specific controls:

Enterprise-wide controls — things your centralized IT already does that also protect the enclave. Your Entra ID provides identity services company-wide. Your Defender for Endpoint runs on every machine. Your HR department screens all employees. These controls are “inherited” by the enclave — they don’t need to be reimplemented inside it.

Enclave-specific controls — things that only apply within the CUI environment. CUI file share permissions. CUI-specific Conditional Access policies. The firewall between the CUI VLAN and the corporate VLAN. These controls are implemented and assessed within the enclave.

The inheritance rule: A requirement can be inherited from the enterprise only if the enterprise control actually satisfies the requirement for the enclave. If something inside the enclave contradicts or undermines the enterprise control, that requirement can’t be inherited — you must implement it another way. All 110 requirements must be MET, whether through inheritance or direct implementation.

What’s in scope: The enclave itself plus any enterprise assets that provide inherited controls. The Entra ID tenant, the Defender management server, the HR department’s screening process — these are Security Protection Assets because they contribute to the enclave’s security. The rest of enterprise IT is not automatically in scope.

---

FCI and CUI in the Same Scope

If your Federal Contract Information (FCI) and CUI live in the same environment, a Level 2 assessment covers both. You don’t need a separate Level 1 assessment — Level 2 automatically satisfies Level 1.

FCI and CUI in Different Scopes

If FCI and CUI are in completely separate environments with separate boundaries, you need separate assessments. Controls implemented in one scope don’t count toward the other — the assessments are independent.

---

Security Protection Data (SPD)

SPD is data created by or consumed by your security tools — SIEM logs, vulnerability scan results, firewall configurations, IDS signatures, admin passwords. The systems that create or store SPD are Security Protection Assets. The SPD itself needs protection because an attacker could use it to compromise your CUI environment.

Why this matters for scoping:

• If a SIEM is hosted by an ESP, the portion of the ESP providing the SIEM service is in your scope
• Both hot storage (active SIEM logs) and cold storage (archived logs in blob storage) are in scope
• Vulnerability scan results showing which CUI systems have which weaknesses are SPD — store and protect them accordingly
• Admin credentials that grant access to CUI systems are SPD — they need the same protection as the systems they unlock

To a CEO or Board

We use an enclave model — a defined security zone for CUI work that inherits enterprise controls where they apply and implements additional controls where they don’t. This gives us the tightest possible scope without duplicating infrastructure. Our SIEM logs, admin credentials, and vulnerability data are treated as sensitive security data and protected within the scope.