An office manager at a twenty-person services firm has done the reading. They know what data minimisation means, they agree with every word of the storage limitation principle, and they have told the owner it will be handled. It is now Wednesday, the promise falls due on Friday, and none of the guidance says what to do first.
Here is the honest answer. The two principles turn into practice as a single loop. Decide what you genuinely need to collect, decide how long you need to keep it, and be able to prove that both decisions exist. A firm that can show the loop running beats a firm with a beautifully worded policy it never applies. Everything below is about getting the loop started this week.
What does applying these principles actually involve?
Applying data minimisation and storage limitation comes down to four artefacts the ICO’s guidance keeps pointing at. A data inventory showing what personal data you hold and where. A documented purpose for each category. A retention rule for each category or store. And evidence that deletion actually happens. If you can produce those four things, you are applying the principles.
The ICO’s accountability guidance is blunt on this point. Compliance has to be demonstrated rather than asserted, and for a firm of five to fifty people the documentation can be proportionate as long as it is, in the ICO’s words, granular and meaningful. The bar is a clear record of what data you process, why, where and for how long, plus proof that the rules get applied. Enterprise governance software does not come into it.
If the principles themselves are still fuzzy, start with the plain-English explainers on what data minimisation means and what storage limitation means, or the piece on how the two differ in practice. This post assumes the definitions and deals with the doing.
How do you build a data inventory in one afternoon?
Structure the afternoon around business functions rather than data types. Take staff management, customer delivery, marketing and finance in turn, and for each one record what personal data is used, why, where it lives, who it is shared with and how long it is kept. The ICO’s own documentation guidance recommends exactly this broad-to-narrow approach, and it fits a firm under fifty people comfortably.
Run it as a series of short conversations with whoever owns each function, and anchor every answer to a visible system. Payroll software, the CRM, shared drives, email, the ticketing tool, and any AI services staff have started using. For each system, work through the ICO’s own prompting questions. Why do you use personal data, who do you hold it about, what do you hold, who sees it, how long do you keep it, and how is it kept safe.
Capture the answers in a spreadsheet, one row per purpose, and aim for breadth over depth. A complete rough map of every system beats a perfect catalogue of one. Where nobody knows the answer, write down “unknown” and move on. The ICO treats this documentation as a living record, so gaps become follow-ups, and the unknowns tend to be where the real risk sits anyway.
Where does over-collection happen in practice?
Three places account for the bulk of over-collection in an owner-managed business. Forms that ask for more than the purpose needs, CRMs whose default fields invite hoarding, and AI tools that can reach everything a user can see. Each one is fixable in an hour or two once the inventory has told you what each collection point is supposed to be for.
Forms first. The ICO warns against collecting personal data on the off-chance it might be useful, so test every field against its purpose. A date of birth where an age bracket would do, a full postal address on an email-only newsletter, a mobile number on a form whose replies go out by email. Cut those fields or make them optional, and note the change in the inventory.
Then the CRM, whose default schema was designed for somebody else’s business. Compare what the system captures against the purposes you documented and switch off fields with no rational link. AI tools need the same check from a different angle. An assistant such as Copilot or Gemini can reach whatever the signed-in user can reach, so the fix is scoping, restricting which repositories the assistant sees and applying rights-management controls to sensitive files. Google’s own guidance confirms that IRM-protected files are excluded from what Gemini can retrieve.
How do you set retention rules without drowning in them?
Set retention rules per store, not per record. One rule for email, one for the CRM, one for HR files, one for shared project folders, each tied to the purposes that store serves. Then automate wherever the platform allows, so deletion happens on a schedule rather than depending on anyone remembering to tidy up. A handful of standard periods covers a firm of this size.
The platforms you already pay for do the heavy lifting. Microsoft 365 retention policies in Purview can retain and then delete content across Exchange, SharePoint and OneDrive, scoped per location, with the clock running from creation or last modification. Google Workspace does the same through Vault retention rules. Seven years for finance mailboxes, two years after last activity for project folders, and the deletion runs on schedule with a log to show for it.
Some systems have no retention engine at all. For a CRM or ticketing tool without one, the answer is a routine, a quarterly review that batch-deletes closed records past their period, with the date noted somewhere findable. Where a legacy system genuinely cannot delete, the ICO’s audit guidance accepts putting the data securely out of reach or anonymising it. The logs and notes from all of this become your fourth artefact, the evidence of deletion.
How does AI use change the calculus?
AI tools add three new places where data accumulates. Training data, the content an assistant can reach, and the prompts and outputs themselves. Each needs the same treatment as any other store, a documented purpose, a retention rule and a way to show deletion, and each is easy to miss because none of them looks like a filing system.
Training first. If a vendor offers to fine-tune or adapt a model on your content, decide what is excluded before anything is ingested. HR files, complaints and anything touching special category data stay out unless there is a documented reason to include them. Then retention inside the tools. Google Workspace administrators can set how long Gemini prompts and responses are kept and can audit which files the assistant touched, so treat prompts as a category in the inventory with a deliberately short retention period.
The harder risk to see is scope creep. A staff member pasting a grievance or a customer complaint into a chat tool has started a new processing activity nobody assessed. Set plain boundaries on what AI can be used for, and when a tool starts shaping decisions about individuals, you are into DPIA territory, which is a different exercise from this one. The wider picture across UK GDPR and the EU AI Act is covered in the data retention rules for AI piece.
So the Friday answer has three parts. Book the inventory afternoon and run it function by function. Fix the single worst over-collection point the inventory reveals, usually a form or a CRM field set. And turn on one store-level retention rule in email or file storage, keeping the log it produces. That is the loop running in miniature, and once it exists, everything else is refinement rather than a standing start. The beautiful policy can wait. The evidence cannot.
