What is data minimization? Meaning, GDPR rules and examples

What is data minimization?

Data minimization is the principle that an organisation should collect, use and keep only the personal data it actually needs for a stated purpose, in the least identifying form, and for no longer than necessary. It is one of the core principles of the GDPR and appears, in similar words, in most modern privacy laws.

It is easy to agree with and hard to practise, because "we might need it later" is the default instinct in analytics. Data minimization asks you to name the purpose first and justify each field against it.

What the law says

Minimization also works alongside purpose limitation (do not reuse data for unrelated purposes) and storage limitation (delete it when the purpose is met).

Four questions for every field

1. Do we need it at all? What decision or feature depends on it?
2. Do we need it about a person, or would an aggregate do? Daily totals by country answer most traffic questions.
3. What is the least identifying form that still works? City instead of coordinates, age band instead of birth date.
4. How long do we need it? Raw rows for 90 days, aggregates for years is a common pattern.

Minimised forms of common analytics data

A worked example: reviewing a tracking plan

Sample data: a SaaS company reviews its tracking plan of 24 event and user properties against its stated purposes (product analytics and billing reports).

Before the review, three direct identifiers were stored in raw form (email, phone, street address). After it, none are. The product team lost nothing it actually used; billing reports join on account_id in the billing system, where the company name already lives. Nine of 24 properties changed (37.5%), which is typical for a first review.

Why it is worth doing

• Smaller breach impact. Data you never stored cannot leak.
• Simpler consent. Analytics that does not identify people may not need the same consent as identified tracking in some jurisdictions; check with counsel for yours.
• Fewer requests to handle. Data subject requests are easier when there is less personal data to search.
• Cleaner, cheaper data. Fewer high-cardinality fields mean smaller tables and faster queries.

Common myths

• "We might need it later." A possible future use is not a purpose. If it becomes one, start collecting then.
• "It's hashed, so it's fine." Hashing an email is pseudonymization; the result is still personal data. See PII.
• "Minimization means worse analytics." Behaviour does not need identity. Funnels, retention by cohort and channel performance all work on pseudonymous IDs.

Data minimization in TapCub

• Collect tiers. In Configuration › Privacy center, tier 1 is anonymous aggregates with a daily-rotating salt, tier 2 (the default) is a cookie-free pseudonym, and tier 3 allows a device ID and login only when the project is in identified mode. See collection tiers.
• IP addresses are not stored on events. The address is truncated, used for geography and the visitor hash, then discarded; geography can be city, country or none.
• Stripping on by default. Strings that look like emails or phone numbers are replaced with a placeholder, and autocapture does not record element text by default.
• Retention you choose. Project retention can be 30, 90, 365 or 730 days, set in Configuration › Settings › Privacy, and a scheduled job deletes expired rows. See data retention policy.
• Validation rules can drop a property at intake, so a field that should never arrive is removed before storage.

Sources

• GDPR Article 5: Principles relating to processing of personal data and Article 25: Data protection by design and by default.
• UK Information Commissioner's Office, Principle (c): Data minimisation.
• European Data Protection Board, Guidelines 4/2019 on Article 25.