Data minimisation

What is data minimisation?

Data minimisation means collecting and keeping only the personal data you actually need for a specific, stated purpose. Nothing extra, nothing kept just in case.

It is one of the core principles of the GDPR. Article 5(1)(c) says personal data must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." So the question to ask about any field is not "could this be useful one day," but "what does this stated purpose actually require?"

Necessity is measured against the purpose

You cannot judge whether a field is necessary without naming the purpose first. A delivery address is necessary to ship an order and pointless for a newsletter signup. The same piece of PII is fine in one context and excessive in another.

Because the test is tied to the purpose, it applies at two moments. First at collection: only ask for what the current purpose needs. Then again at every reuse, because the moment you use existing data for a new purpose, you run the same test against that new purpose. Data gathered for billing is not automatically fair game for training a model or building a lookalike audience. For higher-risk processing, writing down why each field is needed is exactly what a DPIA is meant to capture.

The pull to collect everything

Analytics and data teams lean the other way by habit. Storage is cheap, event tracking captures every click, and the reflex is to keep it all because someone might use it later. Model training sharpens the same reflex, since more data usually looks like a better model.

Minimisation is the deliberate counterweight. It does not say analytics is bad. It says name the purpose, collect for that, and treat "we might need it someday" as a red flag rather than a reason to keep everything. Fewer fields also tends to mean cleaner data, so it is a data quality win as much as a privacy one.

How you minimise in practice

A handful of concrete moves do most of the work:

• Collect fewer fields. If you only ever reply by email, the phone number on the contact form is probably dead weight.

• Aggregate at ingestion. A revenue-by-region dashboard needs regional totals, not a row per named customer, so store the summary and drop the identifiers.

• Pseudonymise early. Replace direct identifiers with keys close to the source. Anonymisation and pseudonymisation, and stronger methods like differential privacy, answer the same question with less exposure.

• Keep less over time. If you only need to know someone is over 18, store an age band, not a full date of birth, and delete records once the purpose is met.

Where these choices get recorded is part of data governance: the data catalogue, the retention schedule, and an owner who can say why each field exists.

Data minimisation versus data retention

The two are easy to confuse. Data minimisation is about what and how much you collect and use. Data retention is about how long you keep it. A recruitment form that asks intrusive personal questions breaks minimisation from the first keystroke, while a tidy, relevant record that sits in the system for years with no reason is a retention problem.