Home / Knowledge hub / Data minimisation
Knowledge hub
Data minimisation
Collecting and keeping only the personal data you actually need.
What it means
Data minimisation is the principle that personal data should be adequate, relevant and limited to what is necessary for the purpose you collected it for. The GDPR lists it among its core principles in Article 5, next to a related rule on not keeping data longer than needed.
It is a design rule, not a clean-up job. Before you add a field to a sign-up form, a column to a table or an attribute to an API response, you ask what the feature really needs. If the answer is nothing, the field does not exist.
Why it matters
Data you never collected cannot be stolen, subpoenaed or leaked. A data breach of a table with names and emails is bad. The same breach with dates of birth, ID numbers and home addresses is a very different letter to send to customers.
It also lowers audit effort. Fewer personal fields means a smaller scope for GDPR and India's DPDP Act, fewer deletion requests to honour, and fewer places where someone can ask why you hold something at all. Smaller data sets also move faster, back up faster and cost less to store.
How it shows up
You meet it in forms that ask for more than the product uses, in databases that keep every old record forever, in logs that capture full request bodies, and in API responses that return the whole user object when the screen shows a name. Test copies of production data are another quiet source.
Check three things. Does each personal field have a stated purpose? Is there a deletion or expiry rule that actually runs? Does the API return only what the caller needs? The last one is where excessive data exposure turns a privacy rule into a live vulnerability.
Questions people ask
Data minimisation, answered
Is data minimisation the same as encryption?
No. Encryption protects data you hold. Minimisation decides whether you hold it in the first place.
They work together. Encrypted data that you did not need still has to be managed, deleted on request and explained to an auditor.
Does the GDPR actually require data minimisation?
Yes. Article 5(1)(c) says personal data must be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed.
The same article also sets out storage limitation, which covers how long you keep it.
Is anonymised or masked data covered by the same rule?
Data that can no longer be tied to a person falls outside the personal data rules, but only if the link is truly gone. Masking that can be reversed, or a dataset that can be matched against another, may still count as personal data.
Treat masked copies with care until you have checked how reversible they are.
How do we test for data we should not be collecting?
Read your forms, database schema and API responses side by side and ask what each field is used for. Then look at what the API actually returns to a signed-in account, which is often more than the page shows.
Logs, analytics events and exports are the usual places where extra data hides.
Does keeping less data hurt analytics?
Sometimes a little. Often you can keep the useful part, such as a count, a region or a month, and drop the identifier.
Decide the question first, then keep the least data that answers it.
Sources
Where this comes from
Related
Terms that sit next to this one
GDPR
The EU law governing personal data, with strict duties and large fines.
Data masking
Hiding part of a value, such as card digits, so most people only see a safe version.
PII
Any data that points at a specific human being.
Data classification
Labelling data by how sensitive it is so each kind gets the right protection.
Excessive data exposure
An API sends whole records and trusts the page to show only the safe fields.
Does your API return too much?
Responses that carry more personal data than the screen needs are a common finding, and we check what each signed-in account can actually pull back. Each one arrives with the request and the response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.