Every CMMC Level 2 engagement I have been part of started the same way: someone opened the 800-171 practice list and began assigning owners. It feels productive. It is almost always premature.
The practices tell you what to implement. They do not tell you where to implement it, and in most organizations that second question is genuinely unanswered.
Scope is derived, not chosen
A CMMC assessment scope is a consequence of where Controlled Unclassified Information lives, moves, and is processed. You do not get to draw the boundary and then check whether CUI respects it. You trace CUI first, and the boundary falls out of what you find.
This sounds obvious written down. In practice, organizations consistently discover CUI in places nobody put on the diagram:
- Attached to email threads that got forwarded to a shared inbox
- Pasted into a ticketing system by a support engineer trying to reproduce an issue
- Sitting in a sales team's file share because a contract deliverable was staged there
- Inside a backup of a system that was decommissioned two years ago
- In a log aggregation platform that ingests more than anyone realized
Each of those pulls a whole environment into scope, or forces a conversation about why it should not be.
Three environment classes, three different problems
When the same organization runs corporate IT, a multi-tenant cloud product, and customer-facing environments, CUI behaves differently in each — and needs a different tracing approach.
Corporate
This is where CUI sprawls. Email, collaboration tools, endpoints, file shares, ticketing. The hard part is not technical; it is that humans move data for legitimate business reasons and the paths are informal. Tracing here means interviews as much as tooling.
Cloud product
Usually the best-understood environment, because it was architected deliberately. The question is narrower: does customer data processed by the platform actually constitute CUI, and if so, which tenants, which regions, which services in the data path?
Customer environments
The messiest, because you control the least. Support access, professional services engagements, and diagnostic data extraction all create pathways where CUI can flow toward you from a customer environment, often without a formal agreement anticipating it.
Support tooling is the most commonly missed CUI pathway. It is designed to reach into customer systems and pull data out — which is exactly the behavior you need to scope.
A practical sequence
- Start from contracts, not systems. Which agreements actually carry a CUI obligation? The set is usually smaller than people assume, and it bounds everything downstream.
- Trace forward from each contract. How does the data arrive? Who touches it first? Where does it land? Follow it through every hop until it reaches rest or leaves your control.
- Trace backward from your data stores. Independently, look at your major repositories and ask what could plausibly contain CUI. This catches paths that forward-tracing misses.
- Reconcile the two maps. The gaps between them are where your real risk sits — those are pathways nobody had modeled.
- Only then, classify assets. CUI assets, security protection assets, contractor risk managed assets, specialized assets, out-of-scope. Now the classification is defensible because it rests on evidence.
What good output looks like
The deliverable is not a document that says "we are in scope for CMMC." It is a data-flow map where every arrow can be defended in an assessment, and every asset classification traces back to a specific observed pathway.
When an assessor asks why a given system is out of scope, "we determined it does not process CUI" is a much weaker answer than "here is the flow analysis, here are the controls that prevent CUI from reaching it, and here is how we monitor that."
The part people resist
Mapping CUI properly takes longer than anyone budgets, and it produces findings that are politically inconvenient. You will discover that a team has been handling CUI in a tool nobody approved. You will find that narrowing scope requires changing a workflow someone has used for years.
Doing that work early is uncomfortable. Doing it after you have already committed to a boundary — and built controls around it — is considerably worse.