CMMC Level 2 Scope Creep Fix, how to shrink your CUI boundary without breaking work (simple scoping worksheet)

Scope creep in CMMC Level 2 scoping usually doesn’t happen because people are careless. It happens because CUI shows up in normal work, email threads, shared drives, Teams chats, ticketing systems, and on laptops that travel.

When I help small defense contractors get ready, I focus on one thing first: draw a boundary that matches how work really happens, then redesign the weak spots so CUI stays inside that boundary on purpose, not by luck.

This post is my practical approach to shrinking your CUI boundary safely, plus a copy/paste worksheet you can use today.

What “in scope” really means, and why assessors push back on your boundary

For CMMC Level 2, the fastest way to lose control of scope is to treat “CUI systems” like a short list of servers. Assessors usually look at data flow and reachability, not just where you intended CUI to live.

Current Level 2 scoping guidance centers on grouping assets by category (CUI assets, security protection assets, specialized assets, connected and routable assets, and out-of-scope assets). If you want the plain-English version with references, I keep Level 2 scoping guidance details bookmarked and align my worksheets to that structure.

Here’s what scope creep looks like in the real world:

• A PM downloads CUI to a laptop “just to review,” now that endpoint is a CUI asset.
• A file sync client copies CUI from a “secure” folder into a personal device cache.
• A general-use admin account can reach the enclave, so systems that “don’t touch CUI” still become connected and routable in practice.
• Your backup, EDR, SIEM, or identity provider protects the enclave, so it becomes a security protection asset and still lands in the assessment scope.

Assessors don’t accept “we don’t use that for CUI” by itself. They ask for proof: diagrams, access paths, logs, and configuration evidence that your boundary is real.

A repeatable 9-step process to shrink your CUI boundary (with tradeoffs)

I use this same sequence whether the environment is on-prem (classic Data Center Technology) or modern Cloud Infrastructure with SaaS and IaaS. It also works if you’re mid Office 365 Migration and worried that “everything will become in scope.”

1. Read contract language first: Confirm what counts as CUI, required retention, flow-downs, and reporting. If anything is unclear, I confirm with contracts and legal so scope reduction doesn’t break obligations, eDiscovery, or incident response.
2. List CUI entry and exit points: Email inboxes, portals, SFTP, customer systems, and deliverables.
3. Map the CUI “touch points”: Where CUI is created, edited, stored, or transmitted, including temp files and local caches.
4. Separate identity paths: Decide where you need identity segregation (dedicated accounts, role separation, admin boundaries). If one admin can manage both worlds, scope expands fast.
5. Pick a boundary pattern (enclave, VDI, separate tenant, secure portal): Choose the smallest design that still supports how teams work.
6. Move CUI to one or two approved locations: Centralize storage, block personal sync, reduce copies.
7. Harden what stays inside: Endpoint Security, Device Hardening, logging, and access control for the enclave users and systems.
8. Prove what stays outside: Remove routes, remove trust paths, restrict admin tools, and document interfaces.
9. Write the rationale while you build: If you wait until the SSP, you’ll forget why a system is out of scope.

If you want a good third-party breakdown of how assessors think about boundaries and asset types, this CMMC assessment scoping walkthrough matches what I see in the field.

Simple CUI Boundary Scoping Worksheet (copy/paste)

Copy/paste this into a doc and fill it out with your team. I keep answers short, then link to diagrams, screenshots, and tickets as evidence.

Worksheet Field	Prompt (fill in)
Contract drivers	Which contracts generate or require handling CUI? What retention, eDelivery, eDiscovery, and reporting terms apply?
CUI types	What kinds of CUI do we handle (engineering data, test results, ITAR-adjacent docs, etc.)? Who labels it?
CUI entry points	How does CUI arrive (customer portal, encrypted email, physical media)? Who receives it?
CUI creation points	Where is CUI created or modified (CAD station, proposal team, QA lab)?
Approved CUI storage	Exact systems and locations where CUI is allowed to live (repositories, project shares). Include naming standards.
CUI transmission paths	How does CUI move (VDI session, secure file portal, internal share, API)? List each interface.
In-scope systems (CUI assets)	Systems that store, process, or transmit CUI. Include endpoints used to access it.
Security protection assets	Identity, logging, vulnerability scanning, EDR, backup, or admin tools that protect in-scope assets.
Connected and routable	Anything network-connected that could impact the enclave. Note why it’s connected and how you limit routes.
External services	Cloud services and MSP tools involved (Cloud Management, ticketing, remote support). What data do they see?
People and roles	Who can access CUI, who admins the boundary, who approves access, who supports incidents?
Out-of-scope systems list	List systems you want out of scope (HR, accounting, marketing, general email, CRM).
Out-of-scope rationale (required)	For each out-of-scope system, state: (1) no CUI stored, (2) no CUI processed, (3) no CUI transmitted, (4) no admin path into enclave, (5) network segmentation and access controls that prevent routable impact, (6) evidence location (diagram, config, screenshot).
Assessor challenge notes	What would a skeptical assessor ask? Pre-answer it with evidence pointers.

How assessors typically challenge scope: they look for “shadow paths” (sync clients, shared admin creds, RDP from general desktops, VPN split tunneling, unmanaged mobile access). They also compare your SSP narrative against reality. A useful summary of scoping confusion points is in this DoD CMMC FAQ scoping discussion, which mirrors the kinds of questions I hear in assessments.

Scope-reduction patterns I rely on (and what they cost you)

I’m not talking about buying magic tools. I mean repeatable designs that shrink where CUI can exist.

CUI enclave: A small set of systems where CUI is allowed. Tradeoff: users need discipline and a clean intake process.

Secure file portal for CUI exchange: Keep partners and subs from emailing CUI into your general mailbox. Tradeoff: one more step for external sharing.

Dedicated project share: A single repository per contract with strict access, versioning, and logging. Tradeoff: you must stop “saving to Desktop.”

VDI or jump host: Users work on CUI through a controlled session, leaving endpoints mostly out of the CUI path. Tradeoff: performance and user experience tuning.

Separate tenant or subscription: Strong separation for identity, devices, and admin paths, helpful during Office 365 Migration or multi-division setups. Tradeoff: more admin overhead and governance.

Identity segregation: Dedicated privileged accounts and tighter admin boundaries reduce the “connected and routable” blast radius. Tradeoff: admins manage two identities.

Before and after: a scope-shrink diagram in words

Before: CUI arrives by email, gets downloaded to laptops, is edited in local apps, then copied into shared drives, and backed up with the rest of the company.

After: CUI enters through a controlled intake (portal or dedicated mailbox with rules), lands in one approved repository inside the enclave, users access it through a jump host or controlled device set, and sanitized outputs move back out through a defined “CUI Out” path.

This is where I connect compliance work to real operations. I still support Small Business IT needs like Restaurant POS Support and Kitchen Technology Solutions for mixed-use organizations, but those stay out of the CUI boundary through routing limits and role separation. That’s what “Tailored Technology Services” and “Innovative IT Solutions” should mean in compliance work: fewer surprises, not bigger scope.

Conclusion and next actions (this week)

If you remember one thing, make it this: shrinking scope is less about arguing and more about engineering a smaller CUI footprint, then documenting why everything else is truly out of scope. Done right, you get Infrastructure Optimization, clearer IT Strategy for SMBs, and stronger Business Continuity & Security at the same time.

Next actions:

• Write a one-page CUI data flow and mark entry, storage, exit.
• Choose one boundary pattern (enclave, portal, VDI, separate tenant).
• Freeze “approved CUI storage” to one or two locations.
• Remove admin paths from general IT into the enclave, document it.
• Update incident response steps for the enclave, confirm retention and eDiscovery with contracts and legal.
• Start the worksheet above, then attach evidence links as you implement.
• Assign an owner for Secure Cloud Architecture and boundary governance (your Business Technology Partner or Technology Consulting lead).