You’re setting up a new AI-enabled CRM, or configuring a helpdesk tool that logs every client conversation, and someone asks: “What are our GDPR obligations here?” You know UK GDPR has something to say about what you collect and how long you keep it. The two principles that cover this, data minimisation and storage limitation, are easy to conflate. They sound like variations on the same rule. They apply at different stages of the data lifecycle and govern completely different decisions.
What choice are you actually facing?
Data minimisation and storage limitation are distinct UK GDPR duties triggered at different moments. Minimisation, under Article 5(1)(c), governs what you collect: data must be adequate, relevant and limited to the stated purpose. Storage limitation, under Article 5(1)(e), governs how long you keep what you have collected: no identifiable data retained beyond the period it is genuinely needed. One is a design question; the other is an ongoing governance question.
The ICO frames both in similar language, which is part of why they get conflated: you must not collect or retain personal data “on the off-chance that it might be useful in the future.” That caution applies twice over, but at different decision points. When you’re deciding what fields to include on a client intake form or what an AI tool is allowed to ingest, you’re testing minimisation. When you’re deciding whether to keep a contact list from a previous campaign for a future one, or how long helpdesk logs stay live, you’re testing storage limitation.
Getting them confused means you might design a lean form (good minimisation) while never defining a deletion schedule (storage limitation failure), or set firm deletion rules while still collecting fields you have no real use for. Both gaps carry regulatory exposure.
When does data minimisation apply?
Data minimisation applies at design stage, before personal data enters your systems. Every field on a form or setting in a SaaS tool is data you will eventually have to protect, justify, and potentially delete on request. The ICO’s position is clear: if you can meet your stated purpose with less, collecting more is a breach of principle. The only test is whether each item is genuinely necessary for the documented purpose.
In practice, minimisation decisions arise when you’re building forms, configuring integrations, or specifying what an AI tool is permitted to ingest. The ICO gives concrete examples: if age verification is the goal, asking for a date of birth when an age band would suffice collects more than you need. If a postal address adds nothing to the purpose, a postcode is better. When AI tools with “log everything” defaults are switched on, you often inherit data you have no specific use for.
The principle also covers special-category data: health information, ethnicity, financial vulnerability indicators. If these appear in your intake flow or AI chatbot transcripts without a specific and documented reason, you are likely in breach of minimisation from day one.
A practical check before any form or integration goes live: go through each field and ask whether you could explain to the person it relates to why you need it. If the honest answer is “it might come in useful”, remove the field.
When does storage limitation apply?
Storage limitation applies once personal data is already in your systems, and it requires a deliberate decision about when that data should be deleted or anonymised. The ICO advises setting time limits for erasure or periodic review. The most common failure is a “set and forget” problem: no retention schedule, backups kept years beyond any recovery window, and old exports sitting outside the deletion routine entirely.
The ICO illustrates the principle with a political campaigning example: a spreadsheet built for one campaign must be deleted after that campaign, not kept in case there is a future referendum. The principle applies equally to a client CRM: once a contract ends and any applicable complaint or warranty window closes, the default is deletion or anonymisation, not indefinite storage because the system still has space.
Storage limitation also covers backup archives, which many small firms overlook. If you have years of CRM exports on a shared drive, or rolling email backups that contain identifiable personal data, those records are subject to the same obligations as the live system.
The principle does not require immediate deletion of everything that arrives. Legal retention obligations, such as HMRC’s requirements on financial records, FCA rules on certain client records, or employment law on contracts and payroll, create floors below which you cannot go. Storage limitation works within those floors. If a law says keep it for six years, keep it for six years, then delete.
What does it cost to get this wrong?
Getting either principle wrong makes any breach you suffer more serious, more expensive and harder to defend. UK GDPR fines for breaches of the basic principles go up to £17.5 million or 4% of annual worldwide turnover, whichever is higher. For a 20-person firm the more realistic immediate cost is the legal and forensic work triggered by an incident or ICO investigation, which can reach six figures before any fine is issued.
The ICO’s enforcement record makes the stakes concrete. In 2020 it fined British Airways £20 million and Marriott International £18.4 million following data breaches. In both cases, weaknesses in data handling, including what was held and how it was managed, contributed to the scale of the incident and the size of the sanction. After each breach, thousands of customers brought group litigation claims. The size of those claims was shaped partly by how much data was in scope and how long it had been retained.
For a smaller business the direct fine risk may feel abstract. The less abstract risk is that over-collecting and over-retaining enlarges the number of individuals affected by any incident, the types of data in scope, and the legal costs of investigating and reporting it. The Electronic Privacy Information Center puts it directly: minimising what you hold shrinks your attack surface.
What should you ask before you commit?
Before any system, integration, or AI tool goes live with personal data in scope, four questions will tell you whether you have addressed both principles. They take less than an hour for a straightforward implementation, and they produce the documentation you would need to show the ICO, a client, or an insurer if your approach was ever called into question. Work through them before you configure, not afterwards.
First, purpose and necessity. What specific business purpose are you meeting with this data, and is it documented? For each data field or data type, could you explain to the person it relates to why you need it? If the justification depends on possible future uses rather than current need, that is a minimisation problem.
Second, data flows. Which systems will receive this data, and do all of them need all of it? When an AI tool ingests client records, does it genuinely need identifiable data or would pseudonymised records meet the same objective? Does the integration between your CRM and email platform pass across full contact records when only an email address and consent flag are required?
Third, retention and deletion. What specific period will you set for this data type, and on what basis? What legal or regulatory floor applies? How will deletion actually happen, and does the plan cover backups and exports as well as the live system?
Fourth, risk and accountability. If this dataset were compromised tomorrow, what would the impact be for the individuals involved? Does that change what you collect or how long you keep it? Could you show a written justification and retention policy if asked?
These questions will not close every gap, but they will identify the decisions you have not yet made. Working through them at the outset is considerably cheaper than explaining the gaps after an incident. If you want to run through them for a specific system or rollout, Book a conversation.
