[NEIL: opening sentence]
Monday's sort finds the data people touch every day. This one goes after the data nobody touches, since that's where the damage came from in the case below.
My background is eDiscovery, and most of that work comes down to finding data in places nobody expected it to be.
One case shows it better than any framework could. It started with restricted data that bled into a place it didn't belong. [NEIL: what kind of restricted data was it? A category is enough, no client name.]
It ended up in [NEIL: where it was parked, a share, a mailbox, a project folder] because the client and the user both failed to recognize it for what it was, so it sat there looking like every other file around it. Nobody stole it, and nobody moved it with bad intent. Someone parked it there and unknowingly left it.
It sat for [NEIL: roughly how long?]. The whole time, it passed every control the client had, because no control was looking at that location for that kind of data. The scheme had a label for it, and the access rules did their job on the place it was supposed to live, which was a different place entirely. Neither one did anything, since the data wasn't in its place and nobody had ever applied the label.
Then a discovery motion arrived.
Discovery doesn't care where you meant to keep things. It asks for everything responsive in the places you control, and the collection pulled that location in along with everything else around it.
The restricted data went out in the production to opposing counsel. [NEIL: what happened next? Caught before or after, a clawback, a very bad phone call?]
Every step in that story was ordinary. Nobody made a decision that looked wrong when they made it. A person saved a file somewhere convenient, the client never looked in that folder again because nothing gave them a reason to, and the policy and the scheme stayed correct on paper. The failure lived in one moment of non-recognition, and then it sat there quietly accruing risk the way an unpatched server does, until something outside the organization went looking.
It surfaced through litigation and not through security for a reason. A discovery collection is one of the few routine processes that reads everything in a location regardless of what anyone believes is in it. Security tooling mostly looks where the policy says sensitive data lives. Litigation looks everywhere it's allowed to look, and it has no interest in your matrix.
Put that next to Monday's story, the program that died in a knife fight over the matrix, and the two look like opposite failures. One scheme was too big to use. The other client had a usable scheme and it still didn't matter. I think they're the same failure.
Classification gets decided at one moment, when a person puts data somewhere, and the whole program depends on whether that person recognizes what they're holding.
Call it the recognition gap. It's the distance between the label your scheme defines and the label a person would actually think to apply in the second before they hit save. Every row added to a matrix widens it, and so does every exception somebody defended in an interview. The seven figure program widened it so far that nobody could have closed it, which is why it never shipped.
The gap also explains something about cold data. Cold storage collects past recognition failures, because a misplaced file that nobody opens never gets a second look from anyone who might notice it doesn't belong there.
Hot data gets corrected through use. Somebody opens the shared tracker, notices a column that shouldn't be there, and moves it. Parked data gets none of that, so it stays exactly as wrong as the day someone saved it, through every audit and every migration that never had a reason to open the folder.
So the access count sort and the parked data problem are two halves of one picture. The hot set shows you where recognition happens every day, which is where a small scheme does the most good. The cold set shows you where recognition already failed, sometimes years ago, with nobody coming back to fix it.
After a misplaced data incident, the instinct is to add precision. A new category goes in, a definition gets sharper, another exception gets written down, and a slide gets added to next year's training. It feels responsible. It's also the same move that built the unusable matrix one interview at a time.
The appeal is easy to see. A bigger matrix looks like diligence to an auditor and like rigor in a steering meeting, and a short list of labels looks naive, as if somebody skipped the hard part. And every person asking for an exception could make a real case for their own data, which is what turned the paring into a knife fight. Every exception had an owner who could defend it.
Teams that get this right accept a scheme that's a little wrong in exchange for one that people actually apply. They test it with one question instead of a coverage percentage. Could the person saving this file name the right label from memory? If not, the label doesn't exist in practice, whatever the policy says.
Start with Monday's ten. As you label them, notice which ones made you stop and think. Write those down. That hesitation marks where the recognition gap lives in your scheme, and if you, the person who owns classification, had to think, the person saving the file never stood a chance.
Then test the labels outside security. Hand one of the ten to someone who has never sat in a classification meeting and ask what they'd call it, and when their answer doesn't match yours, change the scheme before you try to change the person. Watch for the second order effect here, because a scheme people can recognize starts producing its own corrections when users notice something sitting in the wrong place and have words for why.
It gets hard where restriction depends on context and not content. A document can be ordinary on its own and restricted because of who sent it, which matter it belongs to, or what it sits beside. eDiscovery lives inside that problem, and no label applied at save time fully solves it.
When you hit one, resist the new category. Write down the context that makes it restricted and decide whether that context belongs in the location's access rules instead of in the label.
The parked data still needs its own pass, with a different method, and Friday takes that one.
The data you never open is still being read, just not by you.