Glossary · Glossary · GDPR principles
Data minimisation: share only what is needed, documents included
Anonimatum Team
In short
Data minimisation is the principle in Article 5(1)(c) of the UK GDPR and EU GDPR that personal data must be adequate, relevant and limited to what is necessary for the purposes of processing.
Article 5(1)(c) of the UK GDPR, mirroring the EU GDPR, says personal data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”. That is the data minimisation principle: if a piece of data is not needed for the purpose, you should not collect it, keep it or send it on.
It is usually discussed in terms of forms and databases, but it bites hardest in everyday work: every time you forward a case file, attach a report or publish a decision, you are deciding which personal data travels with the document.
What the principle actually requires
- Adequate: sufficient to fulfil the purpose. Minimising does not mean holding so little that the processing fails or produces unfair decisions.
- Relevant: linked to that specific purpose, not to possible future uses.
- Limited to what is necessary: no more fields, no more people and no longer than needed. The time dimension ties in with storage limitation under Article 5(1)(e).
Under the accountability principle in Article 5(2) you must be able to demonstrate compliance. The ICO’s guidance suggests periodically reviewing what you hold and deleting anything you no longer need.
Link with data protection by design and by default
Article 25 turns minimisation into a design duty. Article 25(1) requires appropriate technical and organisational measures, such as pseudonymisation, designed to implement principles like data minimisation. Article 25(2) requires that, by default, only personal data necessary for each specific purpose is processed, covering the amount collected, the extent of processing, the storage period and accessibility.
The European Data Protection Board’s Guidelines 4/2019 and the ICO’s own guidance translate this into practice: default settings that do not expose more than necessary, restricted access, and workflows where surplus data is removed systematically rather than depending on each person remembering to do it.
Minimising when you share or publish documents
Before sending or publishing a document, ask three questions: what does the recipient actually need? Do they need to know who each person is, or only to tell people apart? What is hidden inside the file? The answers point to the measures:
- Cut: send only the relevant pages, annexes or columns, not the whole case file.
- Redact: irreversibly remove names, National Insurance numbers, home addresses or bank details that add nothing for the recipient.
- Replace: where people must remain distinguishable (Party A, Witness 1), use pseudonymisation instead of deletion.
- Generalise: give the year rather than the exact date, the county rather than the street address.
- Clean: remove PDF metadata, comments and tracked changes.
The same logic appears in freedom of information work on both sides of the Atlantic: releasing a redacted version, rather than refusing a request outright, is often what lets a public body disclose information while protecting third-party personal data.
Practical examples
| Situation | What the recipient needs | What is surplus |
|---|---|---|
| Sending payroll data to consultants for a gender pay gap analysis | Role, grade, gross pay, sex | Name, National Insurance number, bank details, home address |
| Sending a contract to an external translator | The clauses | Signatures, signatories’ ID details, bank details |
| Publishing a grant decision | Purpose, criteria, amount and recipient where the rules require it | Home address, phone number, family members |
| Passing an incident spreadsheet to the analytics team | Date, incident type, department | Columns with employee name and email |
In spreadsheets, minimisation is usually a matter of columns: you can anonymise an Excel file column by column and hand over the rest intact. If the dataset will be published, also check whether the remaining columns could single someone out; k-anonymity is a useful way to reason about that.
How Anonimatum helps
Anonimatum detects personal data in PDF, Word, Excel, PowerPoint, image and email files using AI and patterns, and lets you review every suggestion before applying it. You can redact irreversibly, replace consistently when the text must stay readable, strip metadata and extract or delete pages. Processing runs on its own AI on servers in the EU, without sending text to third-party language models, which is minimisation too: no extra recipients in the anonymisation process itself.
Frequently asked questions
Does data minimisation mean I must always anonymise?
No. It means not processing more than you need. Sometimes cutting or pseudonymising is enough; sometimes the purpose genuinely requires identifiable data, and then it is necessary.
Does it apply to internal documents?
Yes. The principle covers all processing, including transfers between departments. Being in the same organisation does not justify receiving data you do not need.
How do I show I have minimised?
Record the purpose, the data you consider necessary and the measures applied, for example redaction templates per document type and a log of who reviewed what.
How is it different from storage limitation?
Minimisation is about what and how much data you process; storage limitation is about how long you keep it in identifiable form. They are separate Article 5 principles that reinforce each other.
Sharing documents with more data than needed?
See the plans and start cutting, redacting or pseudonymising documents before you send or publish them, with a review step built in.