The data was fine. For now. That was the problem. Sharing something from my own work that stuck with me. Hope it resonates. I was not looking for it. I was in the middle of a data programme. SQL scripts, Power BI dashboards, process maps, the usual. Head down in the analysis, trying to make sense of what the systems actually held versus what people thought they held. Those two things are often quite different and the gap between them is usually where the interesting work is. That is when I noticed the data aging. Not old enough to be a problem yet. But heading there. Records approaching six years. Personal data spread across systems that the organisation was querying, reporting on, building decisions around every day. Nobody had flagged it. Nothing had gone wrong. But I knew enough about UK GDPR storage limitation requirements to know that if nobody started thinking about this now, someone would be thinking about it in a panic later. I have seen what that looks like. It is not fun for anyone. So I raised it while there was still time to do it properly. The ICO guidance on storage limitation is honest about how complicated this is in practice. There is no single number the law gives you. What it says is that personal data should not be kept longer than necessary for the purpose it was originally collected for. Which sounds reasonable until you realise that necessary means something genuinely different depending on where you sit in an organisation. Finance are thinking about statutory obligations because VAT records and accounting data carry their own retention requirements that sit underneath personal data in ways that take time to untangle. Legal are thinking about lawful basis and what a defensible position looks like if anyone ever asks. IT are thinking about the fact that the data is not sitting in one tidy place waiting to be managed. It is in the warehouse. It is in reporting pipelines. It is referenced by jobs that other processes depend on. And governance are thinking about auditability because being able to show what was decided and why and by whom is itself a data management requirement. I sat with all of that for a while before I worked out how to make it useful. The SQL work had already given me the picture of what existed. But a database result set does not help a legal counsel understand retention risk and it does not help a finance manager see which records are approaching thresholds. So I built Power BI dashboards that translated the data into something every team could actually read in their own terms. Records mapped by age and by trajectory. Not just where things stood today but where they were heading and how quickly. Categories broken down by system, by record type, by the obligations that applied to each. Dependencies shown so that if someone wanted to act on one category they could see what else would be affected before they touched anything. It gave everyone the same starting point for the first time and once everyone could see the same thing, the conversation changed completely. Then I wrote it up. Properly. Not a summary email but a document that walked through the analysis, the reasoning behind each category, what I recommended for each one and why, and which ones needed more conversation before any decision could be made. I presented it to the stakeholder groups across legal, finance, IT and governance. It became the basis for a data retention framework the organisation could apply going forward, not just a one-off exercise. The thing I keep coming back to about that piece of work is not the SQL or the dashboards or even the framework. It is the timing. We had time. Because someone was paying attention to what the data was doing rather than just what it currently said. That time meant the organisation could make considered decisions rather than reactive ones. It meant legal had space to think. It meant IT could plan the architecture changes properly. It meant governance had a process rather than a problem. None of this happened because of me alone. It happened because the right people took it seriously when it was put in front of them Data governance done well is almost invisible. Nobody writes about the issue that never happened. But I know it happened. And I know why it did not become a crisis.

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

This story contains new, firsthand information uncovered by the writer.

LinkedIn

How Aging Data Becomes a Crisis

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

3-Tier Software Architecture Tutorial For Non-Developers

6 Ways Business Analysts Contribute in Software Development

A Brief Introduction Into A Typical Data Science Project Life Cycle

[A Response] to the Citron Research Report on Nanox

Are We Ever Going to Solve Cyber Security?

Everything your competitor knows about Risk Identification on Software projects

3-Tier Software Architecture Tutorial For Non-Developers

6 Ways Business Analysts Contribute in Software Development

A Brief Introduction Into A Typical Data Science Project Life Cycle

[A Response] to the Citron Research Report on Nanox

Are We Ever Going to Solve Cyber Security?

Everything your competitor knows about Risk Identification on Software projects

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps