Data Minimisation: GDPR Article 5(1)(c) in Practice

Most organisations hold far more personal data than any purpose requires, and every surplus field is extra breach impact, extra subject access work and extra regulatory exposure. Data minimisation is the GDPR principle, in Article 5(1)(c), that personal data must be adequate, relevant and limited to what is necessary for the purpose. This guide turns the principle into engineering and governance practice: field-level collection reviews, limits in forms, APIs and logs, aggregation and de-identification, analytics, AI training and inference, and how to audit the result. It is written for privacy engineers, data protection officers, data platform owners and security architects. The overall method for building privacy into systems sits in the Privacy by Design Guide for Engineering Teams; this page goes deeper on minimisation alone.

Key takeaways

Necessity is judged per field and per purpose. "Useful" or "might need it later" is not a justification; each data element needs a named purpose it is necessary for.
Minimisation has four dimensions. GDPR Article 25(2), as read by the EDPB, applies it by default to the amount collected, the extent of processing, the period of storage and accessibility.
The cheapest field to protect is the one you never collect. Data avoidance at the form, API and SDK level beats every downstream control.
Logs, analytics and AI pipelines are where surplus data hides. They copy production data silently and rarely get the same review as the primary system.
Pseudonymised data is still personal data. It reduces risk but does not take data out of scope; only effective anonymisation does.

What the principle requires

Article 5(1)(c) GDPR (and the identical UK GDPR text) requires personal data to be "adequate, relevant and limited to what is necessary" for the purposes of processing. The three tests work together:

Test	Question to ask	Failure looks like
Adequate	Is there enough data to achieve the purpose properly and fairly?	Decisions about a person made on incomplete data, for example a credit decision without income information
Relevant	Does each element have a rational link to the purpose?	Date of birth on a newsletter sign up; marital status on a support ticket form
Limited to what is necessary	Could the purpose be met with less data, less detail or for less time?	Full date of birth where an over 18 flag would do; exact location where a region would do

Minimisation is tightly linked to two neighbouring principles: purpose limitation (Article 5(1)(b)), because necessity can only be judged against a defined purpose, and storage limitation (Article 5(1)(e)), which requires data to be kept in identifiable form for no longer than necessary. Article 25(2) then makes minimisation the default. The EDPB's Guidelines 4/2019 on data protection by design and by default (final version, 20 October 2020) list the elements a controller should build in: data avoidance, limitation, access limitation, relevance, necessity, aggregation, pseudonymisation, anonymisation and deletion, data flow design that avoids unnecessary copies, and state of the art techniques.

Adequacy cuts the other way: minimisation does not mean collecting so little that processing becomes unfair or inaccurate. The aim is the smallest set that does the job properly.

Field-level collection reviews

The unit of review is the data element, not the system. A practical review works from the data inventory and record of processing (see the Data Mapping and ROPA Guide) down to each field.

List the fields. For each system or flow, export the schema: database columns, API request and response attributes, form fields, event properties in analytics and SDK payloads.
Bind each field to a purpose. Record the purpose from the ROPA that needs it and the lawful basis. A field with no purpose is a deletion candidate.
Challenge granularity. For each field ask whether a coarser form would work: age band instead of date of birth, postcode district instead of full address, month instead of timestamp, a boolean instead of a document copy.
Challenge mandatory status. Make optional anything not needed for the core service, and make sure optional really means optional (no blocking validation, no nagging).
Set retention per field. Some fields are needed only at onboarding (identity document images used for verification), others for the life of the account; give each its own period.
Record the decision. Keep the review outcome with the schema so the next change request is judged against it. This is the accountability evidence required by Article 5(2).

Common minimisation decisions

Data collected today	Minimised alternative	Typical purpose still met
Full date of birth	Age verification result or age band	Age restriction, segmentation
Copy of passport or driving licence kept indefinitely	Verification outcome, document type and reference; image deleted after check	Know your customer evidence
Precise GPS location	City or region; location computed on device	Local content, fraud signals
Full IP address in analytics	Truncated or hashed with rotating salt; country only	Geography reports, abuse rate limiting
Free-text notes fields	Structured picklists; prompts not to enter special category data	Case handling
Full card number in application tables	Payment token and last four digits	Refunds, customer recognition
Customer records copied to test environments	Synthetic or masked data	Testing and debugging

Collection limits in forms, APIs, SDKs and logs

Forms: remove fields the review could not justify; do not prefill optional fields from other sources; avoid free text where structured values suffice, because free text attracts health and other special category data.
APIs: define strict request schemas that reject unexpected attributes, and response schemas that return only the attributes the caller needs. Over-broad responses are both a minimisation failure and part of OWASP API3:2023 Broken Object Property Level Authorization, which merged the earlier Excessive Data Exposure risk. Give each client its own scope rather than one "full profile" endpoint.
Third-party SDKs and tags: configure them to the smallest data set, disable automatic capture of form fields and device identifiers you do not need, and review their default payloads after every upgrade. See the Cookie and Tracking Technology Compliance Guide.
Application logs: log events and identifiers, not payloads. Redact tokens, passwords, card data, national identifiers and request bodies at the logging library, not later in the pipeline. Set log retention to a defined security purpose (NIST SP 800-53 AU-11 Audit Record Retention) rather than storage capacity.
Machine identities and integrations: service accounts, API keys and OAuth grants should be scoped to the fields they need. An integration token with read access to every customer attribute defeats minimisation in the application behind it. See the Tokenisation and Data Masking Guide for field-level protection.

Aggregation, pseudonymisation and anonymisation

When a purpose needs patterns rather than individuals, reduce identifiability before data reaches the people and systems that use it.

Technique	Still personal data?	Good for	Watch out for
Aggregation (counts, averages, cohorts)	Usually not, if groups are large enough	Management reporting, dashboards	Small cells that single out individuals; set a minimum group size
Pseudonymisation (tokens, keyed hashes)	Yes	Linking records across systems without exposing direct identifiers	Keys stored with the data; unsalted hashes of emails or phone numbers that are easy to reverse
Generalisation and suppression	Depends on result	Research and analytics extracts	Combination of quasi-identifiers (postcode, birth date, gender) re-identifying people
Noise addition and differential privacy	Depends on parameters	Published statistics, telemetry	Privacy budget spent across many queries
Synthetic data	Depends on generation method	Testing, model development	Models that memorise and reproduce real records

The ICO is explicit that pseudonymisation is essentially a security and risk reduction technique and that pseudonymised data remains in scope of data protection law. Deeper treatment: Pseudonymisation Techniques Guide, Anonymisation and Re-identification Risk Guide, Differential Privacy Guide and Synthetic Data Risk Guide.

Storage limitation and deletion

Minimisation over time is storage limitation. The EDPB lists what a working retention design contains: internal procedures for deletion and anonymisation, verification that deleted data cannot be recovered, automation, documented storage criteria and justification for each period, enforcement and testing of retention policies, retention periods for backups and logs as well as live systems, and tracking of copies. In practice:

Retention in the schema: attach a retention class to each table or object store, and enforce it with time-to-live settings or scheduled deletion jobs, with alerts when a job fails.
Event-based triggers: account closure, end of contract and completed verification should start the clock automatically, not wait for a manual review.
Copies count: exports, data lake replicas, analytics warehouses, support tool attachments and email inboxes hold the same data under different owners. Each needs a retention rule.
Backups: define how long backups live and whether restored data is re-filtered against deletions made since the backup.

Detailed deletion engineering is in the Data Retention and Secure Deletion Guide and the Data Retention and Disposal Policy Template.

Analytics and product telemetry

Decide the questions first: instrument events to answer defined product questions rather than capturing everything "for later analysis". Each event property should map to a question.
Prefer identifiers you can rotate: session or install identifiers that reset, rather than account IDs or email addresses in event streams.
Strip at the edge: remove query strings, form values and URL parameters that carry email addresses or search terms before events leave the client or the collection endpoint.
Short raw retention, longer aggregates: keep raw event-level data briefly and retain aggregated tables for trend analysis.
Restrict access: event-level data with identifiers should be available to a small analytics group; most users need only aggregated views. Access limitation is one of the four Article 25(2) dimensions.

AI training and inference

AI projects pull towards maximising data: more examples and more features usually improve a model. The ICO's guidance on AI and data protection says organisations must assess which features, and therefore what data, are relevant for the purpose and process only that data. Techniques it describes:

Stage	Technique (ICO guidance)	Practical step
Training	Feature selection	Drop features that do not improve the model measurably; document the test
Training	Perturbation (adding noise)	Add noise to training data, accepting reduced accuracy for lower individual risk
Training	Synthetic data	Generate training data from real distributions; test for memorisation
Training	Federated learning	Train locally and share model updates; note that shared gradients can still leak information
Inference	Converting to less human-readable formats	Process feature vectors instead of raw inputs, remembering they can still be personal data
Inference	Local inference	Run the model on the user's device so the input never leaves it
Inference	Privacy-preserving query approaches	Obtain predictions without fully revealing the query

Training sets are copies: datasets extracted for model training need their own purpose, retention and deletion, and should be scrubbed of direct identifiers and free-text personal data before use (NIST SP 800-53 SI-12(2) Minimize Personally Identifiable Information in Testing, Training, and Research).
Prompts and outputs are data: generative AI applications and agents collect prompts, retrieved documents and tool outputs. Log only what is needed for security and quality, redact identifiers, and set short retention. See the AI Data Retention and Deletion guide.
Agents should fetch narrowly: an AI agent with a broad data connector retrieves whole records into context when it needs one field. Scope the agent's identity and tools to the minimum data set and use field-level filters in retrieval. See the AI and GDPR Guide.
Regulator attention: the EDPB adopted Opinion 28/2024 on data protection aspects of AI models on 18 December 2024; read it before relying on a model being anonymous.

Auditing data minimisation

A minimisation programme needs evidence that it works over time, because schemas and integrations grow every sprint.

Start with the highest-risk stores: customer master data, identity verification, HR, support tooling and the data warehouse.
Scan for unexpected data: use data discovery to find special category data, national identifiers and card numbers in places the inventory says they should not be, such as logs, tickets and file shares.
Gate new collection: add a minimisation question to design review and to the DPIA screening (see the DPIA Guide): every new field needs a purpose and a retention class before it ships.
Pilot deletion before enforcing it: run deletion jobs in report-only mode first, review what would be removed with data owners, then enforce, keeping a restore path for the first cycle.
Re-review annually: purposes change, features are retired and fields stop being used.

Metric	What good looks like
Fields with a documented purpose and retention class	Close to 100% for systems in scope
Fields removed or coarsened per review cycle	A steady number early on, levelling off as the backlog clears
Records past retention still held	Falling to near zero; a rising count signals failed deletion jobs
Discovery findings of sensitive data outside approved stores	Falling trend; each finding closed with a root cause
Non-production environments using real personal data	Zero, or each one with a documented exception

Framework mapping

Framework	Reference	Relevance
GDPR / UK GDPR	Articles 5(1)(b), 5(1)(c), 5(1)(e), 25(2)	Purpose limitation, minimisation, storage limitation, minimisation by default
NIST SP 800-53 Rev. 5	SA-8(33) Minimization; SI-12(1) Limit Personally Identifiable Information Elements; SI-12(2); SI-12(3) Information Disposal; PM-5(1) Inventory of Personally Identifiable Information; PT-3	Engineering principle, field limits, test and training data, disposal, inventory, purposes
NIST CSF 2.0	ID.AM-07 inventories of data and metadata; GV.OC-03 legal and privacy requirements	Knowing what data you hold and why
CIS Controls v8.1	Safeguard 3.1 data management process; Safeguard 3.4 enforce data retention	Retention and disposal in security operations
ISO/IEC 27001:2022 Annex A	5.34 Privacy and protection of PII; 8.10 Information deletion; 8.11 Data masking	Control set for certification programmes

Common failure patterns

Just in case collection: fields added because they might be useful for future marketing or analytics, with no purpose in the ROPA.
Minimising the form but not the pipeline: the sign up form is lean, but the analytics SDK captures every field typed and the logs record full request bodies.
Verification evidence kept forever: identity document images retained long after the check, turning a one-off verification into a permanent high-value store.
Production copies in test: full customer tables restored into development environments with weaker access control.
Sharing by default: features that expose a user's data to other users unless they opt out breach the accessibility dimension of Article 25(2).
Deletion that never runs: a retention policy on paper, with no job, no alert and no test, so data accumulates indefinitely.

Lessons from incidents

In the 23andMe breach, credential stuffing gave access to just over 18,000 accounts, but because each account could see profile information about its genetic matches, almost 7 million people were affected. The UK ICO fined the company £2.31 million in June 2025. The regulators' findings focused on authentication and monitoring, but the scale shows the accessibility dimension of minimisation in action: data visible to other users multiplies the impact of any single account compromise. Limit what one account, one integration or one agent can see, and the blast radius of a credential compromise shrinks with it.

Practitioner checklist

Bind every collected field to a purpose and lawful basis in the ROPA; delete or stop collecting fields without one.
Replace precise values with coarser ones wherever the purpose allows (age band, region, truncated IP).
Enforce strict API request and response schemas and per-client scopes.
Redact secrets and personal data at the logging library and set log retention by purpose.
Give every table, bucket and export a retention class enforced by automated deletion with failure alerts.
Ban real personal data in non-production environments; use masked or synthetic data.
Run feature selection and identifier scrubbing before any AI training extract, and set retention for prompts and outputs.
Scope service accounts, integration tokens and AI agents to the fields they need.
Add a minimisation gate to design review and DPIA screening.
Track the five audit metrics and re-review high-risk systems annually.

Data Minimisation: Collect, Use and Keep Only the Personal Data You Need