The Boundary You Can Prove
A clean drawing feels like progress. But out of scope is not a decision you get to make by writing it down. It is a claim, and a claim has to be backed up.
There is a version of a boundary that looks finished. The VLANs are labeled, the out-of-scope list is filled in, the SSP says “no CUI” in all the right boxes. It’s a clean drawing, and it feels like progress.
Then someone asks your network engineer three quiet questions, and the whole thing comes apart. The line you drew was never the point. Whether the line is real is the point.
Where the clean drawing falls apart
Picture how that happens. Someone points at a printer in the room where CUI gets discussed, or an HR tool that quietly takes logins from the engineering network, or a monitoring box sitting one hop from everything. Someone on your team says, “we think that’s out of scope.” The answer comes back: show me. And there’s nothing to show. So the asset belongs in scope after all, and with it come more controls, more evidence, and work nobody budgeted for.
The frustrating part is that none of it was a surprise if you’d looked. The asset was always sitting there in the “maybe” pile. Somebody meant to sort it out and never did, and the question of whether it counted was still quietly unresolved when someone finally asked.
When I was the compliance lead, the scope calls that hurt us were never the obvious ones. They were the ones we argued about and never wrote down. An unresolved “maybe” doesn’t stay neutral. It waits, and it surfaces at the worst possible moment.
The mistake is declaring instead of proving
So here’s the mistake. We treat “out of scope” as a label we get to apply, a box we check because the SSP template has a field for it. But out of scope is not a decision you get to make by writing it down. It is a claim, and a claim has to be backed up. Separation that exists on paper but not in practice isn’t separation. It’s scope creep in a trench coat.
Out of scope is something you prove
Out of scope isn’t a line you draw. It’s a separation you can prove.
That’s the shift a System Owner has to make. What matters is not the boundary you drew. It is whether the boundary is real, and whether you can demonstrate it, live, when someone asks.
Underneath that is a bigger idea, and it runs through all of this work: documentation doesn’t create reality. It records it. Your SSP, your diagrams, your asset inventories don’t make something out of scope. They explain why it already is. That’s why evidence matters more than declarations. And it’s why my conservative rule for unresolved assets is simple: if you can’t support why an asset is out, don’t treat it as out until you’ve resolved the question.
A “maybe” is fine while you’re still doing the analysis. It just cannot stay one. An unresolved “maybe” doesn’t stay neutral. Eventually something settles it, and when the thing that settles it is an incident, you find out what was really in scope at the worst possible time.
A new stop every Tuesday and Thursday.
Our twice-weekly series breaking CMMC down one step at a time. Opt in and we’ll send each one to your inbox.
Where the boundary really gets decided
Every relevant asset needs a scope decision, and two categories are where boundaries break. The first is the out-of-scope pile. An asset belongs there only when it cannot process, store, or transmit CUI and does not provide security protection for CUI assets. Physical or logical separation can make that determination much easier to support, but the real question is what the asset can actually do in relation to CUI. The second is the contractor risk managed asset. These are already in scope, because they can process, store, or transmit CUI even though your policies, procedures, and practices are intended to prevent that. So when someone tells you, “sure, I’ve opened a drawing on that laptop,” that doesn’t pull the asset back into scope. It tells you the treatment you documented may not match how the asset is actually being used, and the category needs revisiting.
And if the honest count of in-scope assets feels overwhelming, the answer isn’t to reclassify things downward and hope. One legitimate option is to build an enclave: contain your CUI work within a defined, separated environment so systems outside it can legitimately remain outside the CUI environment. There are others, including redesigning a workflow, removing CUI from a system, or changing a service. Shrink the perimeter through architecture and workflow, not wishful labeling. Labeling something out of scope when it isn’t is just unprotected CUI with a delay on it.
You can make this defensible without shrinking the truth
Here’s the reassuring part. A defensible boundary is well within reach, and it doesn’t require pretending your environment is smaller than it is. It requires resolving every “maybe” and backing every “out” with evidence you actually have. An enclave is one honest lever when the number is too big. And every asset you sort out now is one you are not sorting out under pressure later, with less time and fewer options. Doing this yourself first is the whole advantage.
What I would do if I were in your seat
Kill every “maybe.”
Find every asset marked unclear, TBD, or discuss-later, assign it a category, and write the one-paragraph justification. If you can’t write that paragraph with confidence, I would treat the asset as in scope until you can.
Where separation is part of your rationale, build the evidence, not just the sentence.
The VLAN and the deny-all firewall rule, logs showing the boundary held, or floor plan and badge records supporting physical separation. “Show me” has to have an answer ready.
Watch the risk-managed assets closely.
For each one, document exactly what prevents it from touching CUI. If you can’t, reclassify it rather than hope.
If the in-scope list is overwhelming, consider an enclave.
Shrink the perimeter through architecture and workflow, not wishful labeling. A real, separated environment is one way systems outside it can legitimately stay outside.
Test the controls that establish the boundary, don’t just draw it.
Validate segmentation, access restrictions, firewall rules, and the other mechanisms you rely on, using your organization’s approved testing processes. Then make the diagram match what you verified, not what you intended.
None of that is glamorous work. It’s the unglamorous work that keeps your boundary from coming apart when it matters, and it’s entirely within your control right now, while the questions are still yours to answer.
So here’s the question worth sitting with: for every asset we call out of scope, if someone said “show me,” could we? Anywhere the honest answer is no is exactly where your boundary needs work, today, while it’s still yours to fix.
CMMC: Everything You Need to Know to Get Started (6th Edition)
Want the full compliance framework and the funding resources available to defense contractors? Our guide has it.
A few sources
- CMMC Level 2 scoping guidance and 32 CFR Part 170: the asset categories and what it takes to place, and support, each one
- NIST SP 800-171 Rev. 2: the security requirements underlying CMMC Level 2 and the protections the boundary exists to support
- DFARS 252.204-7012: the obligation to protect CUI, which is what the boundary exists to serve in the first place
