Data minimisation is the principle most often assumed to have been satisfied by something else. There is a legal basis, the data are encrypted, access is restricted, the vendor is certified. None of that answers the question the principle actually asks, which is whether the data needed to be collected in the first place. Minimisation applies in full to processing that is lawful, well secured and popular with the business.
The yardstick is the purpose, not a feeling
The principle does not mean processing as little data as possible. It means processing no more than the specified purpose requires. That distinction matters, because the principle cannot be applied at all without a properly determined purpose. Describe the purpose vaguely, as "improving the customer relationship", and you can justify any additional field and limit none. Minimisation hangs directly on purpose limitation and is assessed together with it.
Four dimensions
| Dimension | Test question | Typical lever |
|---|---|---|
| Volume | Which fields are genuinely needed? | Fewer mandatory fields, constrained free-text fields, a look at pre-filled values |
| Granularity | How precise does the entry have to be? | Year of birth instead of full date, postcode area instead of street address, age band instead of age |
| Reach of access | Who has to see the data? | Role and authorisation model, tenant separation, filtered views instead of full access |
| Duration | How long are they needed? | Erasure periods per data category, automated erasure runs, a separated archive |
The fourth dimension is the one most often overlooked, and it is the one that turns a compliant system into a non-compliant one without anybody doing anything. Processing that was minimal at the point of collection breaches the principle the moment the purpose falls away and the data stay put anyway.
Where the volume actually grows
Rarely in the primary system, almost always beside it: in log and telemetry data, in test environments running on copied production data, in spreadsheet exports on laptops, in mailboxes and ticketing systems, in reporting databases, in analytics warehouses and in backups. Copies multiply faster than the primary system grows, and erasure runs forget them with great consistency.
Backups deserve their own answer rather than an awkward silence. The conflict between minimisation and recoverability is real, it has a workable resolution, and that resolution belongs in the data retention and erasure policy where an auditor can find it.
Design and defaults do the work
Regulation (EU) 2016/679 requires data protection by design and by default as a duty in its own right. For minimisation that means something concrete and testable: the default value of a form field, a sharing setting, a visibility or a retention period is the data-sparing option, and anyone who wants more has to choose it actively.
This is worth more than any amount of training, because it changes what happens when nobody is thinking about data protection, which is most of the time.
Pseudonymisation, anonymisation, aggregation
Three tools, three different effects, routinely treated as one. Pseudonymisation lowers the risk but does not remove the link to a person; the data remain personal data and the Regulation still applies in full. Anonymised data fall outside its scope altogether, but the standard for that is high and is not met by stripping out the name. Aggregation is often the most pragmatic route of the three: for most reporting a total will serve, where record-level data are being crunched today out of habit.
Being able to demonstrate it
The necessity of every data field has to be justifiable, and the justification should be produced where the decision is taken: when a system is selected, when a form is designed, when an interface is connected. One standing question in requirements gathering costs minutes. Removing fields from a live system costs a project, and usually gets deferred until it costs a bigger one. For high-risk processing, minimisation forms part of the data protection impact assessment in any case.
Where it goes wrong
- Fields are collected because the system that was bought offers them.
- The purpose is drafted so broadly that it covers everything and constrains nothing.
- Reporting runs on individual records where totals would answer the question.
- Test systems run on production data with nothing obscured.
- There are erasure periods on paper, and no process that executes them.