Keep It or Kill It: The Framework

Five posts into this series and the argument so far has mostly been about what's wrong: data nobody trusts, AI trained on data that was never fit to train anything, definitions that contradict each other across departments, analysts drowning in more of all of it than anyone can reasonably process, and, sitting underneath the lot, an unbudgeted risk nobody has ever billed to anyone.

None of that is much use without an answer to the obvious next question. What do you actually do about it?

Not everything can be deleted, and not everything should be kept. Most organisations don't have a real answer for which is which, dataset by dataset, which is exactly how they end up hoarding by default instead of deciding on purpose. What follows is a simple way to make that decision, one dataset at a time, without needing a six-month governance programme to get started.

Four questions, asked honestly

Is it trusted?

Not "was it accurate once." Trusted now, by the people who'd actually use it. If an analyst would double-check a number before putting it in front of a decision-maker, or quietly avoid using a dataset because "it's a bit off," that's your answer. Untrusted data doesn't get more trustworthy by sitting in storage. It just gets older.

Is it defined consistently?

Does everyone who touches this data agree on what its fields actually mean, or is it one of the datasets where "active," "region" or "revenue" means something slightly different depending on who's asking? Data that can't be reconciled with the rest of the business isn't really an asset on its own. It's a liability waiting for someone to try to join it up with something else.

Is it tied to a decision anyone actually makes?

This is the one most datasets fail. Can you name the report it feeds, the meeting it informs, or the person who'd notice tomorrow if it vanished? If the honest answer is "not really, but it might be useful one day," that's not a yes. It's the absence of one.

Does keeping it create more exposure than value?

Every dataset still sitting on a server has to be secured, has to be accounted for under data protection regulation, and is a dataset a hacker or a regulator could eventually find. The previous post in this series made the full version of that argument. If a dataset has failed the first three questions, this one usually settles it: the risk of keeping it is no longer balanced by anything it's actually doing for the business.

Turning the answers into a decision

A dataset that passes all four questions gets kept, actively maintained, and treated like the asset it actually is. A dataset that's trusted and consistently defined but not currently tied to a live decision is a candidate for archiving rather than outright deletion, particularly where there's a genuine regulatory reason to retain it. Anything that fails two or more, especially the trust and decision questions, is very rarely worth the ongoing cost and risk of keeping around, whatever the instinct to hang onto it says.

The point of running data through this isn't to arrive at a smaller pile for its own sake. It's to make sure that what's left is something people can actually rely on, rather than a mix of the genuinely useful and the quietly ignored, indistinguishable from each other until someone goes looking.

This only works as a habit, not a one-off

Run this as a single audit and it'll do some good once. Run it as a standing part of how data gets reviewed, on a proper cadence rather than only when storage costs prompt someone to ask, and it stops the pile from reforming. New datasets get created constantly. Without a recurring version of these four questions, everything this series has described starts accumulating again almost immediately.

None of this requires new technology. It requires someone willing to own the answers, department by department, and a business prepared to accept that "we might need it one day" isn't a reason on its own. If it were, every organisation would already be data-driven, given how much data most of them are already sitting on.

This is the sixth in a short series on why more data isn't always better data, and the practical piece the earlier posts were building toward. There's one question left, and it sits upstream of everything covered so far: why does the mess keep forming in the first place? The final post looks at whether you're collecting the right data at all, and why the way your software gets sourced and built decides that before anyone's even thought about it.