The Scoping Decision You Never Finalized
You cannot finish implementing against a boundary that never stops moving. An assumption is not a decision, and an approved baseline is what lets you finish.
The SSP gets a little longer every few weeks. A new tool, a new file share, another kind of CUI someone turned up. Each addition feels like progress, and in a way it is. But the finish line keeps sliding, always a few months out, no matter how much work gets done.
If that sounds familiar, the problem probably isn’t your documentation or your pace. It’s that a decision you thought you made never actually closed.
The program that’s always almost done
Here’s the pattern I watch play out. A compliance lead scopes the environment, writes the SSP, and starts working through the gaps. Months pass. They’re almost ready, three months out, maybe less. Then a new contract lands with a kind of CUI they hadn’t accounted for, or an engineer mentions a system nobody had scoped, and the target moves. New assets join the SSP. New controls apply. The date that was three months away is three months away again. And again.
That’s the bind. You cannot finish implementing against a boundary that never stops moving. The work is real, the effort is real, but the finish line keeps walking away, because the thing everything else depends on, the scope, was never actually pinned down.
When I was the compliance lead, I remember the specific frustration of being perpetually almost done. It took me a while to see that the issue wasn’t how fast we were working. It was that we’d never truly closed the question of what we were working on.
An assumption is not a decision
Here’s the mistake, and it’s a quiet one. Most teams never actually make a scoping decision. They make a scoping assumption: we handle CUI, so everything is in scope until proven otherwise. It feels careful. What it really does is leave the boundary open, so every asset you discover and every new system you add just flows into the scope and onto the SSP. Nothing ever closes, so nothing ever finishes.
Finalize the input, and the output follows
Your boundary defines what you’re protecting. Your SSP documents how you’re protecting it.
Both have to reflect the environment as it actually operates, and that is where this breaks down. You’ve been trying to settle the documentation while the boundary underneath it keeps moving. A boundary you never approve is a program that never converges. Finalizing scope doesn’t mean freezing your environment forever. It means approving a documented baseline, declaring what’s in and what’s out, and then handling changes deliberately instead of letting them wander in on their own.
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.
Why open scope doesn’t converge
Two things happen when scope stays open. The SSP grows without end, because every asset that isn’t clearly categorized gets handled as though it carried the full weight of the controls, and the document just keeps absorbing your environment. And new CUI entering the environment can change the systems, people, and processes you need to protect. Sometimes your existing controls already cover it. Other times, a new contract or information flow exposes a gap you didn’t anticipate. The problem isn’t that the information is new. It’s discovering too late that your environment wasn’t prepared to handle it.
Here’s the part that matters, though: the damage comes from the surprise, not the change. New CUI showing up isn’t the disaster. New CUI showing up that nobody reviewed is. Approving a baseline, and putting a review in front of changes to it, turns a scope event from something that happens to you into a decision you make on purpose.
Approving the baseline is what lets you finish
This is the reassuring part, and it surprised me the first time I felt it. Approving a baseline isn’t restrictive. It’s liberating. It’s the move that finally lets the program converge, because now there’s a defined target to aim at instead of a horizon that keeps receding. You don’t need a perfect scope. You need an approved one you can support, and a simple way to govern what changes it. For many organizations, that decision can be made far sooner than they expect, often long before the implementation that follows is done.
What I would do if I were in your seat
Establish a documented scope baseline.
Identify the systems, assets, people, and processes that currently handle or protect CUI, and formally approve the boundary. From that point forward, manage changes through a defined review process. If you discover CUI outside the documented boundary, address it immediately and determine whether the boundary, controls, and documentation need to change.
Resolve every open “maybe.”
Review each asset against the CMMC scoping categories and document the rationale for its classification. If you cannot confidently determine where an asset belongs, keep it flagged for investigation and do not assume it is out of scope. Apply appropriate interim protections based on the potential CUI exposure until the classification is resolved.
Assign ownership of boundary changes.
Define who reviews new systems, contracts, CUI flows, and services before implementation. Document the decision, obtain the appropriate approval, and update the SSP, asset inventory, and data-flow documentation when the environment changes.
Look upstream, not just inward.
Check what CUI a new contract will bring during the proposal stage, and I would run a short CUI review each quarter. You want to meet scope changes early, on your terms.
Separate two ideas that get confused.
“Keep the SSP accurate” is a forever job. “Our documented scope is our approved baseline, and any changes are reviewed, evaluated, and recorded” is a governance practice you establish and then maintain. Both are true at the same time.
Scope is the one decision that gates every other decision, and it is an easy one to leave quietly open. Approve it, govern it, and the finish line finally stops moving.
So here’s the question worth sitting with: have we actually approved the boundary we’re working from, or are we still letting it change without a decision? If you can’t point to the decision, that’s the one to make this week, before you write another page.
A few sources
- CMMC Level 2 scoping guidance and 32 CFR Part 170: asset categorization, scope determination, and documentation of the CMMC environment
- NIST SP 800-171 Rev. 2: the security requirements and system security plan documentation applicable to the current CMMC Level 2 baseline
- 32 CFR Part 2002 and the CUI Registry: identifying and appropriately handling CUI
- NIST SP 800-128: security-focused configuration management, including managing and documenting system changes
