Shadow CUI: The Files Your Team Never Told You About
None of it was malicious. Shadow CUI hides from blame, not from tools, and how you run the hunt decides how much of it you’ll actually find.
If you run IT, you already know the shadow files are out there. A drawing that got emailed home on a Friday night. A spec that landed in someone’s personal Dropbox so they could open it on the road. A laptop that got swapped out and never wiped. None of it was malicious. It was just people solving problems at nine at night with whatever was fastest.
And you’re the one who has to go find it. Here’s the part most people miss: the tools matter far less than how you run the hunt.
The hunt tends to find more than the estimate
When a company sits down and honestly searches, the count often does not match the guess, and the gap tends to be wider than anyone expected. The estimate came from the systems everyone knows about. The reality includes the places people quietly went when those systems were slow or down.
None of that is sabotage. An engineer needed to review something from home. A contract attachment was too big for the portal. A vendor needed a drawing and email was right there. Nobody called any of it a security incident. Nobody called it anything. It just happened, over years, one reasonable shortcut at a time.
When I was the compliance lead running our hunt, the thing that changed everything was how safe people felt telling me the truth. The first time someone admits, out loud, that the specs have been going to their personal email, you learn more in one sentence than a month of scanning would have told you. But you only get that sentence if they’re sure it won’t be used against them.
The mistake is hunting for culprits
So the mistake isn’t failing to look. It’s looking in a way that makes people hide. Send around a stern questionnaire that asks “do you ever send CUI to personal email?” and you’ll get a page of noes, because that question answers itself. Treat the hunt like a search for who broke the rules, and the people who know exactly where the shadow files are will suddenly remember nothing. You didn’t find less shadow CUI. You just drove it deeper.
How you run the hunt is the whole thing
How you run the hunt decides how much of it you’ll actually find.
That’s the whole article in one sentence. Shadow CUI hides from blame, not from tools, so the deciding factor was never the scanner. It’s whether people trust you enough to tell you the truth. Don’t ask who broke the rules; ask how people actually work. Ask an engineer “when you need to review something at home, how do you get it there?” and the CUI surfaces as a byproduct, without anyone confessing to anything. You’re not fishing for wrongdoing. You’re mapping how work really happens.
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 the survey and the scanner both miss it
Two common approaches fall short on their own. The survey misses it because you asked the wrong people: department heads know the official systems, not the personal iCloud an engineer set up for backup. And the scanner misses it because the places shadow CUI hides, a personal Gmail, a home laptop, a consumer Dropbox, aren’t yours to scan. Technology will tell you where data exists. Conversations tell you why it got there.
That’s why a real hunt is both: honest conversations with the people doing the work, plus the technical evidence from the systems you do control. Neither half finds it alone. Together they find far more than either half does alone.
And there’s a bigger truth underneath this that every IT manager runs into eventually: technical controls alone don’t solve human workflows. If people don’t trust the process, they’ll work around it. People tell you the truth when they believe the goal is improvement, not punishment. So the point of this hunt isn’t to catch the workarounds. It’s to understand why they exist, so you can build a process people won’t need to route around.
You can start this hunt this week
The encouraging part is that this doesn’t take a big platform or a big budget to begin. A handful of fifteen-minute conversations and a few queries you can already run can surface a great deal of what is out there. The entire goal is to find it yourself, on your timeline, and fix it quietly, instead of learning about it after the information has been exposed, or discovering later that the picture you documented was never the whole picture. You’ll learn far more through trust than through interrogation, and it costs nothing but the promise to mean it.
What I would do if I were in your seat
Make it safe to tell the truth, and mean it.
Tell your team plainly that the goal is to find and fix problems, not to punish people for surfacing them. Be straight about the limit, too. If what turns up has to be escalated or reported, you will have to handle it that way. The promise is that honesty won’t be used against someone simply because they helped you find the problem, not that the organization can ignore what it discovers.
Interview the people doing the work, not their managers.
Ask process questions, not gotcha questions: where do you put files when the approved system is slow? What apps on your phone do you use for work? Let the CUI surface on its own.
Pull the evidence from systems you control.
Email sends to personal domains with attachments, OAuth apps connected to your tenant, cloud-upload logs if you have DLP, endpoint file searches, and the retired laptops sitting in the IT closet that nobody wiped.
Give every find a disposition.
Is it CUI? Was the transfer authorized? Is it still sitting in a personal account? And the question people forget: does what you found suggest a compromise, or an adverse effect on a system or the information in it? If it might, that is a cyber incident question, not an inventory question. If what you find indicates a cyber incident affecting covered defense information or the covered contractor information system where it resides, DFARS 252.204-7012 requires review for evidence of compromise and rapid reporting to DoD within 72 hours of discovery. Route that determination to whoever owns incident response before you close the item. Then remediate, and write down what you did. A log that shows you looked is worth far more than a blank page.
Update the data-flow picture to match reality.
Show the real paths and how you closed them. A diagram that shows the real paths, including the ones you closed, is a sign of a maturing program.
This isn’t a one-time project, either. Habits don’t change after a single conversation, so I would make a short re-check part of your quarterly routine, so the shadow doesn’t have time to grow back. But the first hunt is the one that turns the unknown into something you can actually manage.
So here’s the question worth sitting with before you start: when we go looking, are we set up to hear the truth, or just to catch people? Whichever one it is, that’s what will decide how much you actually find.
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
- NIST SP 800-171 Rev. 2 and CMMC scoping and data-flow guidance: discovery has to trace CUI from where it enters to where it is stored and disposed, across people, technology, locations, and processes
- 32 CFR Part 2002 and the National Archives CUI Registry: unmarked technical data and Distribution Statements can be CUI, and legacy FOUO is not automatically CUI (only the originating agency decides)
- DFARS 252.204-7012 and 32 CFR Part 170: the obligation to protect CUI and the environment your data-flow diagram has to describe accurately
