Part 2 of “Just Because You Can Keep It Doesn’t Mean You Should”
Last week, Tiffany Carberry wrote about the digital equivalent of the junk drawer, all the information organizations collect for good reasons and then keep long after anyone has stopped asking whether it’s still needed. Her question was a simple one. Just because we can keep it, does that mean we should?
Later that day, my dad unintentionally handed me Part 2.
He’d watched a show about decluttering that suggested a pretty simple test. Look at something you’re keeping and ask yourself two questions. Have I used this in the past 90 days? Will I use it in the next 90 days? If the answer to both is no, maybe you don’t need it anymore.
There was an exception for seasonal things, which will become important in a minute.
Then he asked me whether data could work the same way and my first thought was yes. My second was that he’d just invented a much easier data-retention policy than most organizations have.
Of course, there’s a catch.
When it’s your stuff, deciding what stays and what goes is relatively easy. You own it. You know why you bought it. You know whether you’ve used it. And if you haven’t touched something in six months and can’t imagine needing it six months from now, you can make the decision to get rid of it.
Company data doesn’t usually belong to one person in quite the same way.
The same information might have value to the business unit that collected it, the application team that stores it, Legal, Finance, Operations, Security and several other people who have accumulated an interest in it over the years. Put five or ten of those people in a room and someone can almost always come up with a reason the organization might need that information someday and the frustrating part is that they may be right.
That’s where my dad’s seasonal exception becomes surprisingly useful. Nobody looks at Christmas decorations in July, realizes they haven’t been used in 90 days and throws them away. Their purpose explains why they’re still there.
Data has seasonal items too.
Regulatory requirements may require information to be retained for a defined period. Legal holds can change what an organization is allowed to delete. Financial, contractual or historical records may have legitimate value even when nobody has touched them recently. Some business-critical information simply has a longer useful life.
So I wouldn’t actually recommend that anyone start deleting corporate data because it failed Dad’s 90/90 test.
I would, however, start asking the question, if we haven’t used this information recently and don’t reasonably expect to use it soon, what specific reason do we have for continuing to keep it?
Sometimes there will be an excellent answer. If there is, keep the data, protect it appropriately and document why it’s being retained. The more interesting cases are the ones where nobody can really answer beyond some variation of “we might need it someday.”
That answer feels safe because deletion is permanent while keeping something feels passive. But from a Security perspective, keeping data isn’t passive at all. Every additional dataset, document, customer record, identity artifact or historical database the organization retains is something it continues accepting responsibility for protecting.
Getting rid of information that no longer serves a purpose reduces that responsibility. There’s less sensitive data available to expose in a breach, fewer places where access has to be managed and monitored, and less old information quietly following an organization through migrations, backups, cloud platforms and systems nobody remembers quite as well as they used to. It can simplify the environment operationally too. Teams spend less time protecting, classifying, searching and governing information that isn’t providing anything in return.
There’s also a benefit that’s easy to overlook. Data you no longer possess can’t be stolen from you.
That doesn’t make deletion a substitute for good Security, but it does make reducing unnecessary data one of the few Security decisions that can actually remove part of the problem instead of adding another control around it, and that matters when something goes wrong.
One of this week’s stories involves attackers claiming access to ASOS’s Snowflake environment. The details of that claimed compromise are still being investigated, but incidents involving large data platforms raise a useful question regardless of what ultimately happened in this particular case. If an attacker gets access to one of our data repositories tomorrow, how much of what they find is there because the business still needs it, and how much is there because nobody ever decided to remove it?
I think that’s the harder half of the conversation Tiffany started last week.
Organizations are usually pretty good at establishing ownership when something is created. Someone owns the application. Someone requested the project. Someone collects the information because the business needs it.
Years later, who owns the decision that its useful life has ended?
If that isn’t clear, retention can quietly become the default. Nobody specifically decides to keep something for ten years. Nobody periodically confirms that its value still outweighs the responsibility of protecting it. It just remains there because deleting it requires a decision and keeping it doesn’t appear to.
Except keeping it is a decision, even when nobody consciously makes it, so maybe the goal isn’t to make organizations better at deleting data. It’s to make them better at deciding why they’re keeping it.
And Dad, if you’re reading this, I’m pretty sure you just became a data governance consultant. 
Jon Rogers
Principal Consultant
Pinpoint Security
Principal Consultant
Pinpoint Security



