Data minimization is easy to agree with and hard to practice. Nobody argues for collecting data they do not need. Then a signup form ships with a date-of-birth field because the old form had one. An analytics event captures the full request body. A debug log keeps email addresses for as long as the log bucket exists.
The principle sits in GDPR Article 5(1)(c): personal data must be adequate, relevant and limited to what is necessary for the purposes of processing. Article 25 then requires you to build that into design and defaults. The broader Article 25 obligation is covered in privacy by design under GDPR Article 25. This article is narrower. It covers the specific decisions, made by product and engineering teams, where minimization is won or lost, and the record that shows you made them.
What "necessary" means when you are designing a feature
Necessity is always measured against a purpose. You cannot decide whether a field is necessary until someone has written down what it is for. That is purpose limitation, Article 5(1)(b), and it comes first in practice even though it comes second in the text.
Necessary is also narrower than useful. A phone number is useful for account recovery, for sales follow-up and for fraud scoring. Each of those is a separate purpose, and each needs its own justification and its own lawful basis. If you have not yet picked one, the guide to the six GDPR lawful bases is the place to start.
Article 25(2) names four dimensions of minimization by default:
Amount collected. Fewer fields, and less precise fields.
Extent of processing. What you do with the data once you have it.
Period of storage. How long it lives, in every copy.
Accessibility. Who can see it. By default, it must not be made accessible to an indefinite number of people without the individual's intervention.
Most teams think about the first and forget the other three. A feature that collects one field but copies it into five systems with no expiry has not minimized anything.
US law points the same way. The CCPA, as amended by the CPRA, requires that collection, use, retention and sharing be reasonably necessary and proportionate to the purposes for which the data was collected. Several other state laws carry similar language, so a minimization habit built for GDPR travels well.
A field-level review at design time
The cheapest place to minimize is the design document, before a column exists. A short, repeatable review works better than a long one nobody completes:
List every personal data element. Include what the feature collects directly, what it derives, and what it receives as metadata: IP addresses, device identifiers, user agent strings, location.
Write one purpose per element. One sentence each. If the honest answer is "we might need it later", that is not a purpose.
Ask for a less identifying form. An age band or an "over 16" flag instead of a date of birth. Country instead of street address. A truncated IP address instead of the full one.
Decide required or optional. Optional fields should default to empty, and optional processing should default to off.
Set retention now. Decide the time-to-live while the schema is being written, not in a cleanup project two years later.
Decide who can read it. Which roles, which internal tools, which support views. Masking in admin consoles is cheap at design time and expensive later.
Record the outcome. Keep the completed review with the design document or ticket, so the decision is evidence rather than memory.
Seven questions is enough to catch most problems. A team that runs this on every feature touching personal data will find the same few issues recurring, and can then fix them in shared libraries rather than feature by feature.
Where data accumulates without anyone deciding
The form fields are the visible part. Most excess personal data arrives through paths nobody designed on purpose.
Logs
Application logs routinely capture email addresses in URLs, tokens in query strings and full request or response bodies. Structured logging with an allowlist of fields is more reliable than trying to scrub after the fact. Set a retention period on the log store that matches its purpose: debugging rarely needs months of history.
Analytics and product telemetry
Event schemas grow. A property added for one experiment becomes permanent. Review the event catalog the same way you review a form, and prefer internal pseudonymous identifiers over email addresses in event payloads.
Free-text fields and attachments
Support tickets, notes fields and file uploads collect whatever people type or attach, including data you would never ask for: health details, identity documents, screenshots of other systems. You cannot fully prevent this. You can set shorter retention, restrict access, and warn users in the interface not to include sensitive details.
Non-production environments
A copy of production in staging is a second production system with weaker controls. Synthetic or masked data for development and testing is the minimization measure that most often gets deferred, and it is the one auditors notice.
Third-party scripts and SDKs
An embedded SDK can collect device and behavioral data you never see in your own database. Each one should go through the same purpose question, and through vendor review before it ships.
Derived data
Scores, segments and inferences are personal data too. A churn-risk score attached to a named user is a new data element with its own purpose, retention and access question.
Techniques that reduce identifiability
Not every technique takes data outside the scope of GDPR. Teams often overstate what a technique achieves, so be precise about it in design documents.
| Technique | What it does | Still personal data under GDPR? |
|---|---|---|
| Generalization | Replaces a precise value with a broader one, such as age band or region | Often yes, depending on what else is held |
| Truncation | Drops part of a value, such as the last octet of an IP address | Often yes, especially when combined with other fields |
| Pseudonymization | Replaces identifiers with tokens, with the key held separately | Yes. Recital 26 says pseudonymized data remains personal data |
| Hashing | Applies a one-way function to an identifier | Usually yes. A hash of a known email address can be matched |
| Aggregation | Reports counts or totals instead of rows | Can fall outside scope if no individual can be singled out |
| Anonymization | Removes the possibility of identification by any means reasonably likely to be used | No, but the bar is high and it must hold over time |
Pseudonymization is still worth doing. Article 25 names it as an example of an appropriate measure, and it reduces the damage of a breach. It does not remove the obligations, so do not label pseudonymized datasets as "anonymous".
What people get wrong
Collecting for an unspecified future. "We might train a model on this" is a plan to define a purpose later. Define it now, or do not collect.
Minimizing once. A feature that passed review at launch drifts. New events, new integrations and new exports appear. Rerun the review when a feature changes materially, not only when it is new.
Treating encryption as minimization. Encryption protects data you hold. It does not reduce what you hold. Both matter, and an auditor will ask about each separately.
Assuming B2B means no personal data. Business contact details, user account records and activity logs about named employees of your customers are all personal data under GDPR.
Leaving it to the privacy team. Privacy reviewers see a fraction of design decisions. The questions belong in the engineering design template, where every feature passes through them.
Where a necessity judgment is close, for example whether a field is required to perform a contract or merely convenient, confirm the call with counsel.
Evidence that minimization is happening
If an auditor or a customer asks how you minimize, a policy statement is the weakest answer you can give. Stronger evidence looks like this:
- Not done:
A design review template with privacy questions, and completed examples
- Not done:
A data inventory whose fields match what the product collects
- Not done:
Retention settings on log stores, analytics tools and databases
- Not done:
Masking or synthetic data in non-production environments
- Not done:
Records of fields or events removed after review
For ISO 27701, these map naturally to its privacy controls on collection and processing; see ISO 27701. For GDPR more broadly, the GDPR framework page lists the related obligations, and your Article 30 record of processing should agree with what the review decided.
How TrustLynce helps
TrustLynce keeps your record of processing and DPIA workflows in one place, so minimization decisions sit next to the processing they govern; see data privacy. Policies covering collection and retention are versioned, with acceptance tracked per person, through policy management.