GDPR Art.5.1c: Data Minimisation
What This Control Requires
Personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed ('data minimisation').
In Plain Language
If you cannot explain why you need a specific piece of personal data, you probably should not be collecting it. That is the core of data minimisation, and it is one of the principles DPAs check most often during investigations.
The principle has three dimensions: adequacy (you have enough data to actually do the job), relevance (the data has a real connection to your stated purpose), and necessity (you are not hoarding extra fields "just in case"). If you can achieve the same outcome with less data, fewer data categories, or anonymised data instead of personal data, the GDPR expects you to take that route.
This goes beyond collection forms. It covers who can access data internally (apply least-privilege), what you send to third parties (only the fields they actually need), and how long you keep it. Every stage of the data lifecycle is in scope.
How to Implement
Go through every data collection form, app screen, and API endpoint field by field. For each field, ask: what specific purpose does this serve? If the answer is vague or amounts to "we might need it later," remove it. Registration forms and onboarding flows are usually the worst offenders.
Require a privacy impact check before anyone adds new data collection. Give product and engineering teams a short checklist: what data, why, can the purpose be achieved with less? Make this part of your definition of done for new features.
Enforce minimisation technically. Use pseudonymisation where you do not need full identification. Mask data in development and testing environments - there is no reason your staging database should contain real customer details. Default your systems to collect the minimum and require explicit justification to expand.
Review third-party data sharing. Before sending data to a partner or processor, strip out every field they do not strictly need. Document why each remaining field is necessary. If your vendor integration sends the full customer record when only an email address is required, fix the integration.
Run regular minimisation audits. Look for datasets that have grown beyond their original scope, particularly after system updates or new feature launches. Set up automated aggregation or deletion for detailed records that are past their useful life. Watch for scope creep in analytics pipelines - they tend to accumulate data quietly.
Evidence Your Auditor Will Request
- Data mapping records showing justification for each data field collected
- Privacy by design assessment forms showing data minimisation consideration in new projects
- Evidence of data field reviews and removal of unnecessary data collection
- Access control matrices demonstrating least-privilege access to personal data
- Data sharing agreements with third parties specifying minimum necessary data
Common Mistakes
- Collecting excessive personal data 'just in case' it might be useful in the future
- Using full production datasets containing personal data in development and testing environments
- Copying entire databases for analytics when only aggregated or anonymised data is needed
- Mandatory form fields for data that is not actually required for the service or purpose
- Sharing complete customer records with third parties when only a subset of data is necessary
Related Controls Across Frameworks
Frequently Asked Questions
Does data minimisation mean we should collect as little data as possible?
How does data minimisation apply to employee data?
Can we keep data for potential future purposes?
Track GDPR compliance in one place
AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.
Start Free Assessment