Last updated: 14 November 2026
Quick answer: Data minimisation is the GDPR and UK GDPR principle that personal data must be adequate, relevant and limited to what is necessary for the purposes you process it for. In practice it means collecting only the fields you need, restricting who can see them, keeping them no longer than required and reviewing holdings regularly.
Data minimisation sounds simple, yet it is one of the principles organisations most often struggle to evidence. Forms ask for “nice to have” details, analytics tools capture everything by default and old exports sit on shared drives for years.
For DPOs, the challenge is turning a one-line legal principle into decisions that product, HR, marketing and IT teams can apply. This guide explains what the principle requires under EU and UK law, how regulators interpret it, and gives a practical necessity test, a worked example and a review checklist.
What is the data minimisation principle?
It is the requirement that personal data be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”. The wording comes from Article 5(1)(c) of the General Data Protection Regulation (EU) 2016/679, and the UK GDPR uses the same text.
The ICO’s data minimisation guidance breaks the principle into three tests:
- Adequate: sufficient to properly fulfil your stated purpose.
- Relevant: having a rational link to that purpose.
- Limited: you do not hold more than you need for that purpose.
The first test is often forgotten. Minimisation does not mean collecting as little as possible at any cost. If holding too little data leads to wrong decisions about people, for example an incomplete record used to refuse a service, that is also a failure.
How does data minimisation relate to other principles?
Minimisation depends on purpose limitation, because you cannot judge what is necessary until the purpose is defined. It also works hand in hand with storage limitation in Article 5(1)(e), which requires that data be kept in identifiable form no longer than necessary. Under the accountability principle in Article 5(2), you must be able to demonstrate compliance, so undocumented minimisation decisions carry little weight with a regulator.
What does GDPR require in practice for data minimisation?
Beyond Article 5, the GDPR makes minimisation an engineering requirement. Article 25(2) requires controllers to implement measures ensuring that “by default, only personal data which are necessary for each specific purpose of the processing are processed”.
That default obligation applies to four dimensions:
- Amount of personal data collected.
- Extent of the processing.
- Period of storage.
- Accessibility, so data is not made available to an indefinite number of people without the individual’s intervention.
The EDPB’s Guidelines 4/2019 on data protection by design and by default, adopted in final form on 20 October 2020, list practical elements for minimisation, including data avoidance, relevance, necessity, aggregation, pseudonymisation, anonymisation, limitation and destruction.
In practice: most minimisation failures happen at design time. A new CRM field, a default “collect all” setting in a tracking tool or an HR form copied from another country creates excess data long before anyone asks whether it is needed. Building a minimisation question into your DPIA process and change reviews catches most of it.
How do you decide what data is necessary?
Start from a specific, documented purpose and test every data element against it. The ICO stresses that you must “first be clear about why you need it”, and you cannot collect information on the off-chance that it might be useful in future.
A five-question necessity test
- Purpose: which specific, documented purpose does this data element serve?
- Need: could the purpose be achieved without it, or with a less identifying version (age band instead of date of birth, city instead of full address)?
- Timing: is it needed now, or only later in the process for some people? If later, collect it later.
- Access: who genuinely needs to see it, and can others work with a masked or aggregated view?
- Retention: when does the need end, and what triggers deletion or anonymisation?
If you cannot answer the first two questions convincingly, the element should not be collected. Record the answers in your record of processing activities so the rationale survives staff changes.
Worked example: a job application form
| Field | Purpose | Decision |
|---|---|---|
| Name, email, phone | Contacting the candidate | Keep |
| CV and work history | Assessing suitability | Keep |
| Date of birth | None at application stage | Remove; confirm eligibility checks later only where legally required |
| Home address | Not needed to assess the application | Remove at application stage; collect on offer for payroll |
| Health information | Not relevant for an office role | Remove; ask only about reasonable adjustments for interview |
| Right-to-work documents | Legal check before employment | Collect at offer stage, not from every applicant |
| Unsuccessful candidate data | Handling disputes | Keep for a defined, documented period, then delete |
The ICO’s own examples follow the same logic, noting for instance that recruiters should not request health data from applicants for office jobs. The guidance also says it is “particularly important” to keep special category and criminal offence data to the minimum.
What are common data minimisation mistakes?
The most common mistakes are “just in case” collection, unrestricted internal access and indefinite retention. Each is easy to spot once you look for it.
- Optional fields that become mandatory by habit. Staff start treating optional form fields as required, so the data is collected anyway.
- Analytics and logging by default. Tools that record full IP addresses, user identifiers or free-text inputs without review.
- Copies of production data in testing. Using real customer records where synthetic or pseudonymised data would do.
- Free-text fields. Comment boxes that attract health details, opinions or third-party information nobody asked for.
- Retention schedules that exist only on paper. Policies that state periods but have no deletion jobs or owners behind them.
- Over-disclosure in access requests. Responding to a data subject request by sending unrelated records, or collecting excessive identity documents to verify a requester.
Common mistake: assuming that encryption or strong security solves minimisation. Security protects the data you hold. Minimisation questions whether you should hold it at all, and a breach of unnecessary data is harder to defend.
Our article on common mistakes in GDPR compliance covers related pitfalls in more detail.
If your minimisation decisions live in scattered spreadsheets, you can start your 14-day free trial of Enactia’s AI-powered GRC platform and keep ROPA entries, DPIAs and retention decisions linked in one place.
How do EU and UK rules on data minimisation compare?
The principle is worded identically in the EU GDPR and the UK GDPR. The main differences are the regulators, guidance and maximum fines.
| Aspect | EU GDPR | UK GDPR |
|---|---|---|
| Legal basis of the principle | Article 5(1)(c) | Article 5(1)(c), same wording |
| By default requirement | Article 25(2) | Article 25(2) |
| Key guidance | EDPB Guidelines 4/2019 and national authority guidance | ICO guide to the data protection principles |
| Maximum fine for breaching principles | EUR 20 million or 4% of worldwide annual turnover, whichever is higher | GBP 17.5 million or 4% of worldwide annual turnover, whichever is higher |
| Regulator | National supervisory authorities, coordinated through the EDPB | Information Commissioner’s Office |
Under Article 83(5)(a) GDPR, infringements of the basic principles in Article 5 fall into the highest fine tier. The ICO confirms that the same applies in the UK, with a maximum of GBP 17.5 million or 4% of turnover. For the latest UK reforms, see our UK Data Use and Access Act 2025 guide.
How can DPOs run a data minimisation review?
Run a periodic review that follows your data inventory, starting with the highest-risk processing. The ICO expects organisations to review holdings regularly and delete anything no longer needed.
Data minimisation review checklist
- Every processing activity in the ROPA has a specific purpose and a listed set of data categories.
- Each data category is justified against that purpose, with the reasoning recorded.
- Collection points (web forms, apps, call scripts, HR templates) match the approved data list.
- Optional fields are clearly optional and not required by staff practice.
- Access is role-based, and broad access is reviewed at least annually.
- Pseudonymisation or aggregation is used for analytics, reporting and testing where possible.
- Retention periods are defined per category, with an owner and an automated or scheduled deletion process.
- New projects and system changes go through a privacy review that includes minimisation questions.
- Processors and vendors are contractually limited to the data they need.
Keeping these steps connected is the hard part. Enactia’s GDPR compliance module links ROPA records, DPIAs and tasks so review findings become tracked actions rather than notes.
Key takeaways
- Data minimisation requires personal data to be adequate, relevant and limited to what is necessary for a specific purpose.
- Article 25(2) makes minimisation a default design requirement covering amount, extent, storage period and accessibility.
- Test every data element against a documented purpose and record the reasoning in your ROPA.
- The EU and UK principle is identical; breaches can attract top-tier fines of EUR 20 million or GBP 17.5 million or 4% of turnover.
- Regular reviews of collection points, access and retention turn the principle into evidence.
Frequently asked questions
What is an example of data minimisation?
A retailer that needs only an email address to send order confirmations asks for just that, instead of date of birth, phone number and full address. Another example is replacing exact dates of birth with age bands for analytics. In each case, the organisation collects the least identifying data that still achieves the purpose properly.
Does data minimisation mean collecting as little data as possible?
Not exactly. Data must also be adequate, meaning sufficient for the purpose. Holding too little can be a failure if it leads to inaccurate records or wrong decisions about people. The goal is the right amount for a specific purpose, justified and documented, rather than the smallest possible amount in every case.
Can we keep data in case it becomes useful later?
No. The ICO states that you cannot collect personal data on the off-chance that it might be useful in future. You can keep data for a foreseeable event that may never happen if you can justify it, but you need a clear, documented reason and a defined retention period rather than an open-ended possibility.
How does data minimisation apply to AI and analytics?
The same principle applies. Use only the data needed for the model or analysis, prefer aggregated, pseudonymised or anonymised datasets, and avoid feeding free-text or special category data unless it is necessary and lawful. A DPIA is often required for large-scale or innovative processing and is the natural place to document minimisation choices.
Is pseudonymised data still subject to data minimisation?
Yes. Pseudonymised data remains personal data under the GDPR and UK GDPR because it can be linked back to individuals with additional information. Pseudonymisation is a useful minimisation and security measure, but you still need to justify the data you hold, limit access and apply retention periods to it.
Conclusion: make minimisation a habit, not a clean-up project
Data minimisation works best when it is built into forms, systems and approval processes from the start, and checked through regular reviews. Clear purposes, documented necessity decisions and enforced retention periods give you both lower risk and a stronger accountability record. For documentation foundations, see our GDPR ROPA guide.
To manage ROPA, DPIAs, retention and review tasks in one connected privacy programme, contact us or book a demo or start your 14-day free trial.
This article is for general information and is not legal advice.
