Where CUI Actually Lives
Your documentation describes the system you intended to build. CUI lives where your people put it, which means the first real job isn’t drawing the boundary. It’s going to look.
Picture an engineering firm whose asset inventory lists forty-seven things, while the environment where controlled information actually moves is several times that size. The gap does not surface in the documentation. It comes out in a forty-five-minute conversation with three department heads, while the team is working through its self-assessment.
Three people. Forty-five minutes.
That is all it takes to surface controlled information the documentation never mentioned. The scenario is illustrative rather than a specific company, but the shape of it is worth recognizing, because if you own the boundary, this is your problem before it is anyone else’s.
Your SSP maps the system you designed
Here’s the thing about an SSP. It describes the environment you built on purpose: the servers, the VPN, the cloud tenant, the network segments. It’s an honest picture of the system you designed. The trouble is that your people run a slightly different system, the one made of shortcuts and conveniences, and CUI follows them there.
It ends up in the places nobody documented because nobody designed them. An engineer emails a drawing to a personal account to finish it over the weekend. A spec gets discussed in a Teams thread instead of stored in the enclave. The proposal team keeps government performance data on a shared drive nobody scoped. A controlled drawing sits in the conference room printer tray. An old file server in a satellite office still holds a decade of exchanged drawings. None of it is on the network diagram, but every one of those locations may now matter to your CUI environment.
When I was the compliance lead running our program, the scoping surprises were never the servers. We knew the servers. It was the human paths, the emailed file, the personal laptop, the drive someone stood up to hit a deadline, that I had to go looking for, because the map I inherited described the design, not the reality.
The mistake is scoping from the diagram
So the mistake here isn’t sloppiness. It’s a natural one: we treat CUI as a marking problem, something you stamp on a document, and we draw the boundary from the network diagram. But scoping CUI is a data-flow problem. The data lands somewhere before anyone decides to mark it, and where it lands is often not where the diagram says it should be. Confirming that controlled information has entered the business is one question. Knowing where it went afterward is a different one, and the second question is the one scope depends on.
The designed system and the lived system
Your documentation describes the system you intended to build. Your job is to understand the system people actually use.
That’s the shift a System Owner has to make, and it’s bigger than CMMC. CUI lives where your people put it, not where your SSP says it should be. You cannot scope what you haven’t found, and you cannot find it by reading your own documentation, because the documentation describes the system you meant to build. The boundary has to account for where CUI is processed, stored, and transmitted, along with the assets that protect that environment. That means the first real job isn’t drawing the boundary. It’s going to look.
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 it hides, and where to look
CUI migrates toward convenience. It tends to land somewhere it shouldn’t when the approved path is slower than the workaround. That’s not a discipline failure so much as a workflow one, and it tells you where to look: wherever your people go when the approved way is inconvenient.
It also tells you where technology stops. Tools can help you find data: discovery scans, DLP, and endpoint solutions will surface plenty of unexpected locations. What they can’t do is explain why people put it there, and that is the part that actually matters. So discovery has to start with conversations as well as tools, and it has to cover four things, not one: the people who touch CUI, the technology they actually use, the locations it can land, and the processes that move it. Miss one of those four and you may be looking at only part of the environment while believing you’ve mapped all of it.
The good news: it’s cheaper to find than to be found
Here’s the encouraging part. You don’t need a tool to start finding where CUI actually moves. Remember the forty-five-minute conversation that found the gap. A handful of honest, no-blame conversations with the people doing the work can surface a great deal of it. The whole point is to find it yourself, on your timeline, rather than discovering it after the information has already been exposed, or putting your name to a self-assessment that assumes you already know where it all lives. Every location you catch now is a correction you control. Every one you miss is another place where CUI may be sitting without the protections you thought were there.
What I would do if I were in your seat
Interview the people, not just the systems.
Talk to everyone who might touch CUI, and go past the obvious. Sales engineers writing proposals, the contracts admin receiving prime exhibits, the PM coordinating drawing packages. Ask them plainly, with no blame: where do you actually put this when the approved path is slow?
Inventory the technology they truly use to process, store, transmit, or protect CUI.
That includes the personal laptop and the consumer file-sync nobody reported. What people use is rarely the same as what you issued.
Walk the locations.
Look where CUI is processed, stored, transmitted, or discussed, including the physical places people forget: printers, cabinets, conference rooms, and approved remote-work locations.
Map the processes.
How CUI enters, how it moves inside, how it leaves. Follow it hop by hop until the data-flow diagram matches reality, not aspiration.
Then decide what belongs in the environment.
Finding CUI somewhere unexpected does not automatically mean widening the boundary around it. Sometimes the right answer is to correct the path, stop the workflow, or move the work into a protected environment. Bring legitimate systems and processes into scope where they belong, then update the scope and the SSP so they reflect the environment you actually operate, not just the one you intended to build.
None of that requires new tools or a big budget. It requires the willingness to go look in the human places and write down what’s really there. That’s the difference between the system you documented and the system your people actually run, and understanding both is what system ownership really means.
So here’s the question worth sitting with: if we followed one drawing from the moment we received it to the moment we archived it, would every stop along the way appear in our SSP? If you’re not sure, that’s not a failure. It’s your cue to go trace it. Because you can’t protect CUI you don’t know you have.
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
- 32 CFR Part 2002 and the National Archives CUI Registry: the CUI categories, the authorities behind them, and who holds the designation
- NIST SP 800-171 Rev. 2, the revision DoW continues to enforce for CMMC, together with CMMC scoping guidance (People, Locations, Technology, Processes): why discovery has to cover more than the network
- DFARS 252.204-7012 and 32 CFR Part 170: the obligation to protect CUI and to understand the environment in which those protections apply
