What is Data Minimisation?

Storage became cheap long before restraint did. Forms grow an extra field because someone might want it, integrations sync whole objects because mapping individual fields takes effort, and every system quietly accumulates data nobody remembers deciding to collect. Data minimisation is the GDPR principle that pushes the other way: collect what the purpose needs, and nothing else.

What the principle actually asks

GDPR requires personal data to be adequate, relevant and limited to what is necessary for the purpose it is processed for. Read practically, that is three tests applied to every field. Adequate: is there enough data to do the job properly? Relevant: does this particular field bear on the purpose at all? Limited: is it necessary, or merely convenient? The principle is anchored to purpose, not volume. A payroll system legitimately holds bank details; a newsletter signup does not. The same field can be essential in one context and indefensible in the next, which is why minimisation cannot be settled with a policy statement. It has to be settled field by field, against a purpose someone can name. (This entry is a practical explainer, not legal advice.)

The “might be useful later” trap

The most common argument against minimisation is rarely spoken aloud, because it sounds so reasonable in the moment: the data might be useful later. It fails on both legal and practical grounds. Legally, later is not a purpose. GDPR expects purposes to be specified and explicit at the point of collection, and data gathered on speculation has nothing to attach a lawful basis to. Practically, speculative data is not free to hold. Every field you collect must be secured, backed up, retained on a schedule, produced when someone exercises their right of access, erased when someone validly asks, and counted when a breach is assessed. Those obligations apply to the data you hoarded just in case exactly as they apply to the data you use every day. Data you never collect is a risk you never carry, a breach you never have to notify, and a request you never have to answer.

There is a quieter cost too. Data collected without a purpose tends to get used without a decision. A field gathered for one reason drifts into another use, and the organisation discovers it has been doing something with personal data that nobody ever actually chose to do. Minimisation closes that door before it opens.

Minimisation is a design decision, made early

What matters most about minimisation is when it happens. Once a record exists it propagates: into backups, exports, spreadsheets, reports and downstream systems. Removing a field after the fact is a project; not adding it is a moment of restraint. That makes minimisation a design decision, taken by the people who draft the form, write the intake script, map the integration and set the retention default, most of whom do not think of themselves as making data protection decisions at all. The fix is to make the decision explicit: for every field, name the purpose it serves. If nobody can, the field goes. And where the honest answer is a different purpose arriving at a different time, collect it then. Right-to-work evidence belongs at offer stage, not on the application form.

One concrete example

Clearly illustrative, with no customer implied. A recruitment firm redesigns its candidate application form. The draft asks for date of birth, full home address, a photograph and current salary, because the old form did. Held against the purpose, assessing suitability for this role, each field falls. Date of birth does not bear on suitability, and right-to-work checks happen at offer stage, a different purpose at a different time. City is enough to judge location fit; the full address is only needed if a contract is signed. The photograph serves no purpose the firm can name. Current salary is convenient in a negotiation but not necessary to assess anyone. The shorter form is easier for candidates to complete, and every removed field is a liability the firm no longer holds: nothing to secure, nothing to disclose, nothing to erase, nothing to explain if a supplier is breached. For the wider set of obligations these choices sit inside, see GDPR for people businesses.

Data minimisation and decision intelligence

The same discipline that protects data improves decisions. More data does not make a decision better; relevant evidence of known quality does. Decision intelligence treats every fact behind a decision as something that must earn its place, carried with a state on the evidence hierarchy: measured, modelled, inferred, stated or unmeasured. A recommendation resting on a handful of relevant, measured facts is worth more than one buried under an export nobody has qualified. Minimisation asks the same question of collection that decision intelligence asks of reasoning: what does this purpose actually need? And because minimisation is a choice made early and unmade expensively, it deserves what any consequential choice deserves: a record of who decided what to collect, and why, so the next person inherits the reasoning instead of the guesswork.