What is data minimisation?
Data minimisation requires that only the personal data a specified purpose needs is processed. The principle is set out in Article 5(1)(c) of Regulation (EU) 2016/679 (GDPR), and the provision's own label in brackets is "data minimisation".
Under Article 5(2), the controller must be able to demonstrate compliance with the principle ("accountability"). How data minimisation fits with the GDPR's other obligations is set out in the GDPR guide.
The specified purpose is the yardstick
Data minimisation does not mean processing as little data as possible; it means processing no more than the specified purpose requires. Without a defined purpose, the principle cannot be applied. A vaguely described purpose justifies every additional data field and limits none.
A legal basis or consent does not change this: Article 5(1)(c) applies to every processing operation alongside Article 6.
Data minimisation therefore depends on purpose limitation under Article 5(1)(b): data is "collected for specified, explicit and legitimate purposes". Assess both principles together.
The four reference points of Article 25(2) GDPR
Article 25(2), second sentence, GDPR names four reference points to which data protection by default applies. They work as a checklist for every system and every form:
| Reference point under Article 25(2), second sentence | Test question | Example |
|---|---|---|
| Amount of personal data collected | Which fields, and what precision, does the purpose need? | year of birth instead of full date of birth, postcode instead of full address |
| Extent of their processing | Which processing steps does the purpose need? | analysis on totals instead of individual records |
| Period of their storage | How long does the purpose need the data? | retention period per data category in the erasure policy |
| Their accessibility | Who needs to see the data? | role and access concept, views instead of full access |
The third sentence sharpens the last point: by default, personal data must not be made accessible without the individual's intervention to an indefinite number of natural persons. The default value of a form field, a share setting or a retention setting is therefore the minimal option; anyone who wants more makes an active choice.
Article 25(1) expressly names pseudonymisation as a measure designed to implement principles such as data minimisation effectively. How the two duties connect is explained in the entry on privacy by design and by default.
How does data minimisation relate to storage limitation?
Data minimisation and storage limitation are two principles asking different questions. Data minimisation under point (c) asks whether a data item is needed at all. Storage limitation under Article 5(1)(e) asks how long the form of storage may still permit identification.
Processing that was minimal at collection breaches storage limitation once the purpose has lapsed and the data is still kept. A data retention and erasure policy with data categories, purposes and retention periods answers both questions.
Every copy falls under the source's retention period
Surplus copies of personal data build up outside the system of record, in places such as these:
- log and telemetry data
- test environments with copied production data
- spreadsheet exports on workstations
- mailboxes and ticketing systems
- analytics databases
- backups
Each of these copies belongs under the retention periods of the source data set. For backups, the erasure policy sets the period after which a backup set is overwritten.
What distinguishes pseudonymisation, anonymisation and aggregation?
Pseudonymisation, anonymisation and aggregation reduce the link to a person to different degrees:
| Tool | Effect on the link to a person | Does the GDPR apply? |
|---|---|---|
| Pseudonymisation (Article 4(5)) | attribution only possible with additional information kept separately | yes; pseudonymised data remains personal data (Recital 26) |
| Anonymisation | the person is not or no longer identifiable | no, not to anonymous information (Recital 26) |
| Aggregation | analysis on totals or groups instead of individual records | depends on whether individuals remain identifiable |
Under Recital 26, anonymity is judged against all the means reasonably likely to be used for identification. Removing a name is not enough while identification numbers or online identifiers remain.
How do you justify the necessity of a data field?
Justify the necessity of a data field where the decision is made: when a system is introduced, a form is designed or an interface is connected. Because Article 5(2) requires demonstrable compliance, the justification belongs in the system's documentation.
For high-risk processing, the assessment is a mandatory part of the data protection impact assessment. Article 35(7)(b) requires an assessment of the necessity and proportionality of the processing operations in relation to the purposes.
Five patterns undermine the principle, and each shows up during this justification:
- Fields are collected because the system in use offers them.
- The purpose is worded so broadly that it covers any collection.
- Analyses run on individual records although totals would do.
- Test systems work with unaltered production data.
- Retention periods are defined, but no process carries them out.
Copies as supporting assets
In Rizzqo, you link every copy of a data set as a supporting asset to the primary asset its data comes from. Examples are a test environment with production data or an analytics database. Each copy inherits that asset's personal data flag and confidentiality rating, including a file server whose technical role does not reveal it.
Put the Article 5(1)(c) question, whether the purpose needs this copy, to the process that justifies it.