If you're implementing CMMC and choosing an enclave strategy, your first job is to define what's in and what's out. This decision affects every dollar you spend on licensing, training, assessments, and infrastructure. Get the boundary wrong, and you'll either pay for security you don't need or fail your C3PAO assessment because you missed something.
This template guides you through scoping an enclave that protects Controlled Unclassified Information (CUI) without dragging your entire organization into CMMC Level 2's 110 security controls.
Purpose of the Template
Use this template to document your CMMC enclave boundary. You'll define which systems, staff, data flows, and vendors fall within scope, and which stay outside. The output becomes your scoping document for assessors, your training roster, your licensing budget, and your ongoing boundary monitoring plan.
This isn't a one-time exercise. Your enclave boundary will drift as contracts change, employees move, and systems evolve. Treat this as a living document you review quarterly.
Prerequisites
Before you start filling out this template, you need:
- A clear inventory of where CUI lives. If you don't know which systems touch CUI, Federal Contract Information, or Covered Defense Information, conduct a data flow mapping exercise first.
- Leadership buy-in on the enclave strategy. This approach creates operational friction. Your executive team needs to understand that the enclave will limit collaboration, require dual policies, and potentially exclude you from some contracts.
- Technical capability to enforce network segmentation. You can't define an enclave on paper and hope it holds. You need firewall rules, access controls, and monitoring to maintain the boundary.
The Enclave Scoping Template
Copy this structure into your documentation system. Fill in each section with specifics from your environment.
CMMC Enclave Scope Definition
Document Owner: [Name, Title]
Last Review Date: [Date]
Next Review Date: [Date + 90 days]
1. In-Scope Systems
List every system that processes, stores, or transmits CUI. Be exhaustive.
- System Name: [e.g., Contract Management Database]
- System Owner: [Name]
- CUI Data Types Handled: [e.g., technical specifications, pricing data]
- Hosting Location: [on-premises / cloud provider / hybrid]
- User Count: [number of accounts with access]
Repeat for each system. Include file shares, collaboration tools, email systems, and any application that touches CUI even briefly.
2. In-Scope Personnel
List roles that require access to CUI systems, not individual names. You'll map names to roles separately for training and access management.
- Role Title: [e.g., Program Manager - DoD Contracts]
- CUI Access Justification: [why this role needs access]
- Current Headcount: [number]
- Training Requirements: [CMMC awareness, role-specific security training]
3. Boundary Control Points
Document every place where data or access crosses the enclave boundary.
- Control Point: [e.g., VPN gateway for remote access]
- Control Type: [technical / procedural / both]
- Enforcement Mechanism: [firewall rule / access control list / manual review]
- Monitoring Method: [how you detect unauthorized boundary crossings]
Common control points: email gateways, file transfer systems, API connections, physical access to server rooms, remote access portals.
4. Out-of-Scope Systems (Explicit Exclusions)
List systems that do NOT handle CUI and explain why they're excluded. This prevents scope creep during assessments.
- System Name: [e.g., Marketing CRM]
- Exclusion Rationale: [no CUI processed, stored, or transmitted]
- Boundary Control: [how you prevent CUI from entering this system]
5. Vendor and Supplier Dependencies
Any third party that touches your enclave must meet CMMC requirements or you inherit their risk.
- Vendor Name: [company]
- Service Provided: [specific function]
- CUI Exposure: [yes / no]
- Vendor CMMC Status: [certified Level X / assessment in progress / not certified]
- Contractual Flow-Down: [yes / no - do your contracts require their compliance?]
If a vendor isn't CMMC-certified and handles CUI on your behalf, you have a compliance gap.
6. Data Flows Crossing the Boundary
Map legitimate business processes that move data in or out of the enclave.
- Flow Description: [e.g., monthly financial reports sent to corporate accounting]
- Data Classification: [CUI / non-CUI]
- Transfer Method: [encrypted email / SFTP / manual export]
- Approval Process: [who authorizes the transfer]
Every planned data flow needs a control. Unplanned flows are incidents.
Customizing the Template
For small enclaves (under 20 staff): Collapse the personnel section into a simple list of names and roles. You don't need elaborate role definitions when you can name everyone who has access.
For multi-site operations: Add a location field to every section. Your boundary might be physical (Building A, not Building B) or logical (AWS VPC X, not VPC Y), and assessors will want to see both.
For organizations with multiple DoD contracts: Create a separate scope document for each contract if CUI types differ significantly. A contract involving technical drawings has different system requirements than one involving pricing data. Don't lump them together if you can keep them separate.
For high-collaboration environments: Pay extra attention to Section 6 (data flows). If your staff routinely share files with non-enclave colleagues, you need procedural controls and monitoring, not just technical barriers. Document your approval workflow and make it enforceable.
Validation Steps
Your scope document isn't complete until you've tested it against these scenarios:
Walkthrough with a non-technical stakeholder. Can your CFO or a program manager understand what's in scope and why? If the boundary is too complex to explain, it's too complex to maintain.
Technical validation of controls. Have your IT team attempt to move a test file from an in-scope system to an out-of-scope system without following your documented procedures. If they succeed, your boundary isn't enforced.
Cross-reference with your licensing costs. Count the user seats you're paying for in every in-scope system. Multiply by the per-seat cost. If that number makes you wince, revisit whether those users actually need access or if you're paying for convenience instead of necessity.
Review with your C3PAO (if engaged). Before your formal assessment, have your assessor review this scope document. They'll identify gaps or ambiguities that would surface during the audit anyway. Better to fix them now than during a billable assessment.
Quarterly boundary drift check. Set a recurring calendar reminder. Every 90 days, review Sections 1, 2, and 5. Did you add a new system? Hire someone into a CUI-handling role? Start working with a new vendor? Update the document and re-validate your controls.
The difference between a 10-seat enclave and a 200-seat enterprise implementation can be hundreds of thousands of dollars in licensing, training, and assessment costs. This template ensures you're only paying for the scope you actually need.
