The phrase tends to arrive uninvited. An owner reads up on data minimisation ahead of an AI rollout, follows a link into the ICO guidance, and keeps meeting the words storage limitation. Somewhere around the second page, a less comfortable thought lands. The firm has never deleted anything. The inbox goes back to the year the business moved to cloud email. The shared drive holds every CV ever received. The CRM still knows the mobile number of a lead who said no in 2016.
Storage limitation is the principle that turns that from a housekeeping quirk into a compliance question. Here is what it means, what the ICO expects, and where to realistically start.
What is storage limitation?
Storage limitation is the UK GDPR principle that personal data has a shelf life. Article 5(1)(e) says you may keep data in a form that identifies people for no longer than you need it for the purpose you collected it for. When that purpose ends, you delete the data or anonymise it, and you should be able to explain why anything older is still there.
The principle sits alongside the better-known data minimisation principle, and the two are easy to blur because ICO guidance mentions them in the same breath. Minimisation is about what you collect. Storage limitation is about how long you keep it once you have it. A firm can pass the first test comfortably and fail the second by simply never deleting anything.
Two things follow from the wording. Retention is tied to purpose, so if you cannot say why a record is there, you cannot say how long it should stay. And because the law talks about data in a form which permits identification, anonymisation counts. If you still need the numbers for reporting but no longer need the names, stripping the identifiers satisfies the principle without losing the insight.
Why does it matter for your business?
The ICO expects every organisation, whatever its size, to set retention periods or review criteria for the personal data it holds, to justify them per category of data, and to delete or anonymise records when the period ends. It also expects your privacy notice to state those periods or the criteria behind them. A firm with no retention decisions at all fails on each count.
The regulation deliberately sets no fixed periods. How long you keep data depends on how long you need it for your stated purpose, and the burden of working that out sits with you. That flexibility is also the trap, because without a deliberate decision the de facto retention period becomes however long the server lasts.
The ICO’s own retention and disposal policy shows what a considered approach looks like. Each record type gets a trigger, such as end of employment or end of financial year, a duration, and an end action of review or destroy. Where a review finds a record still needed, the extension runs two years at a time rather than indefinitely, and every destruction is logged. Scaled down, that model fits an owner-managed firm on a single page.
Getting it wrong compounds in three directions. A breach exposes everything you hold, so ten years of unweeded records multiplies the harm and the regulatory response. Subject access requests take longer and go wrong more often when the volume is uncurated. And old data drifts out of date, which puts you on the wrong side of the accuracy principle as well.
Where will you actually meet it?
For a firm of 5 to 50 people, storage limitation applies wherever personal data accumulates. The email system, the shared drive, the CRM, the HR folder and the accounting package usually hold the bulk of it between them. Each one needs a retention decision, and each is exactly the kind of store an AI assistant will happily search from end to end.
AI adoption is what moves this up the priority list. The ONS reported that 25% of UK businesses were using some form of AI by late December 2025, up 15 percentage points in just over two years. Assistants inside email, document and CRM systems derive their value from searching what you already hold. A ten-year-old disciplinary note or a complaint thread from 2015 used to be protected by the effort of finding it. A natural-language query removes that friction. Everything you should have deleted is now one prompt away from resurfacing.
The practical response does not require a records management programme. Pick the five stores that hold the bulk of your personal data. Set one retention rule per store, tied to a purpose. Client project files might be kept for six years after completion to cover claims. CRM contacts might be reviewed two years after the last meaningful interaction. Recruitment CVs might go six months after a process closes. The numbers are yours to choose and defend.
Then calendar the first review, and keep a one-line note of what was deleted and when. The ICO logs its own destruction events; a lighter version of the same habit demonstrates accountability if anyone ever asks. The first pass will be rough, and that is fine. Any considered rule beats a decade of default.
When can you keep data for longer?
Storage limitation bends to other legal duties. Accounting records must be preserved for at least three years in a private company under the Companies Act, and HMRC expects six years for records behind a tax return. Litigation triggers a legal hold on relevant records. Archiving in the public interest and genuine research carry their own exemption. Each justifies retention for a defined period, with a reason you can write down.
Statutory duties supply the easiest numbers in the whole schedule, and HMRC’s six years run from the end of the financial year the records relate to. Employment carries its own numbers. Right-to-work checks, for instance, should be kept for the duration of employment and two years afterwards. Where a law names a period, write it into the schedule and keep the records it covers for exactly that long.
Legal holds are the second case. When litigation is reasonably anticipated, you suspend deletion for the records relevant to the dispute. The hold should be targeted and documented, and it lifts when the matter is resolved, at which point normal retention rules resume. It covers the dispute’s records and nothing wider.
The archiving and research exemption in Article 89 gets more attention than it earns in an owner-managed context. Data processed solely for archiving in the public interest, scientific or historical research or statistical purposes can be kept longer, subject to safeguards such as pseudonymisation. Everyday business records do not qualify, and pseudonymised data still counts as personal data, so for a commercial firm this one can usually be noted and set aside.
The common thread is that every exemption is specific, purposeful and time-bounded. None of them stretches to cover an inbox kept since 2011 because nobody got round to a decision.
What else connects to storage limitation?
Storage limitation is one of six principles in Article 5, and it leans on its neighbours. Purpose limitation supplies the reason you hold data at all. Data minimisation limits what you collect in the first place. Accuracy suffers when records sit unreviewed for a decade. And accountability means writing your retention decisions down so you can show them to the ICO if asked.
If the boundary with minimisation still blurs, the two principles are compared directly in how data minimisation and storage limitation differ in practice. The short version is that one governs the front door and the other the back.
Retention is also becoming an AI governance control in its own right. If you are working out how to limit what your AI tools can see and keep, the cleanest answer is a data estate where the old and unnecessary records are already gone. And for firms with EU operations or clients, data retention under GDPR and the EU AI Act adds a further layer for higher-risk systems.
For a firm that has never deleted anything, the starting point is smaller than the guidance makes it feel. Five stores, one rule each, one date in the calendar. The compliance position improves, the breach exposure shrinks, and the AI tools you adopt next will be searching a data estate you can actually vouch for.
