Data minimisation and storage limitation work together throughout the life of personal data. Article 5(1)© GDPR concerns whether the information is adequate, relevant and limited to what a purpose needs. Article 5(1)(e) concerns how long it remains identifiable. A short retention period does not cure unnecessary collection, and collecting only a few fields does not justify keeping them indefinitely.
The official GDPR on EUR-Lex supplies the rules. This guide turns their relationship into decisions for people designing a service, maintaining a database or reviewing an existing process. The practical aim is to control what enters the system, how it is used, who can access it, which copies exist and what happens when each purpose ends.
Treat minimisation as an ongoing decision
Minimisation is sometimes described as asking for fewer fields on a registration form. That is useful but incomplete. Processing also includes viewing, combining, disclosing and retaining information. Data that were necessary at collection may later be excessive for a narrower task, a different team or a changed service.
Article 25(2) makes the relationship especially clear: protection by default concerns the amount collected, the extent of processing, the storage period and accessibility. The EDPB’s final Guidelines 4/2019 discuss these dimensions and give practical examples. Those examples guide application; they are not an exhaustive set of mandatory product features.
Adequacy also matters. Removing information that is genuinely needed to distinguish two people or perform a service accurately may create another problem. The objective is an appropriate dataset for a specified purpose, not the smallest dataset imaginable. The data minimisation guide develops the necessity assessment at the level of particular categories and operations.
Start with a purpose that can be tested
Before debating a field, describe the result the organisation needs to achieve. “Improve the business” is too broad to explain whether a birth date or detailed location history is necessary. “Send the purchased item to the customer’s chosen address” makes the relationship between purpose and data easier to assess.
For each category, ask what would fail if it were absent, whether a less detailed value would suffice and whether identification is needed at all. The answer should reflect how the service operates, not a hypothetical future use. A request for a telephone number deserves a different explanation where it is used for a necessary delivery arrangement than where it is collected because the template includes it.
The legal basis remains a separate requirement. Minimising a dataset does not make an otherwise unlawful operation permissible. Equally, identifying a possible legitimate interest does not remove the need to establish necessity and balance individuals’ interests and rights. Other grounds have their own conditions.
A proposed new use should be assessed before it becomes part of the service. Purpose limitation and minimisation are connected: data collected for one task do not become available for every useful analysis. Compatibility, any applicable consent or legislative route, transparency and separate conditions for sensitive data must be considered where relevant.
A worked example: registration for an event
Imagine an organisation offering an online seminar and an in-person workshop. Its inherited registration form asks everyone for a home address, date of birth, job title, telephone number and dietary preferences. The team should not assume that one standard form makes all those fields necessary for both services.
For online attendance, an email address may be needed to provide access, while a postal address may serve no registration purpose. An invoicing requirement could justify some additional details for particular customers, but that requirement should be identified and scoped. It should not automatically make every optional field mandatory for every attendee.
The workshop may require information about an accommodation request. Ask for the practical adjustment needed where that is sufficient, rather than inviting an unrestricted medical history. If health data are processed, a condition under Article 9 must be established in addition to the ordinary legal basis. A shorter free-text field does not by itself resolve that legal question.
Separate operational purposes from optional publicity or future marketing. Attendance should not automatically populate a mailing list for unrelated events. A person can choose to receive updates without giving the organisation permission to publish a photograph or share contact details with sponsors. The form and subsequent data flows should reflect those distinctions.
Next define what happens after the event. Contact details used for immediate joining instructions, records needed for required accounting and information about adjustments may have different end points. Keeping them in a single row does not require a single retention period. The design should support the distinctions the legal and operational assessment has identified.
Reduce detail and exposure, not only the field count
Sometimes the purpose needs a category rather than an exact value. An aggregate count may be sufficient to plan capacity. A broad region may serve an analysis where a precise address would expose unnecessary information. Whether that reduction works depends on the actual question and how accurately it must be answered.
Free-text fields deserve attention because they can collect unexpected personal information about both the person completing the form and other people. Consider structured options, a clear instruction about what is needed and a process for handling unnecessary attachments. Removing an upload button may be more effective than asking staff never to use the documents it collects.
Default access should follow the task. An event facilitator may need a participant list while a finance team needs the appropriate billing information. Neither necessarily needs the other’s complete records. Limiting access does not excuse excessive storage, but it reduces unnecessary processing while justified retention continues.
Public availability also changes the scale of exposure. A system that publishes a participant profile by default needs a different assessment from a private attendance list. Article 25(2) includes protection against making personal data accessible to an indefinite number of people without the individual’s intervention. Existing publicity elsewhere does not supply every later organisation with a legal basis for reuse.
Design separate stages for separate purposes
A useful retention design identifies transitions, such as application, active service, closure, restricted preservation and deletion. These are practical organisational stages, not a statutory list. For each transition, determine which information remains necessary and which operations should stop.
Consider a recruitment process. Interview scheduling requires contact details; deciding an application may require relevant qualifications; a subsequent dispute may justify preserving particular evidence under the applicable rules. That does not mean every rejected application, private comment and duplicate attachment should remain available to all recruiters for the same duration.
Retention rules need starting events. “Delete after a set period” cannot be implemented reliably if the system does not record what starts that period. Closing a complaint, ending a contract and completing a financial year are different events. The legal source and the process determine which is relevant.
A data retention policy can record these decisions, including national or sector-specific requirements. There is no universal GDPR table prescribing a fixed number of years for every customer’s data. Avoid importing an example from one jurisdiction into another without checking its scope, trigger and exceptions.
Keep holds narrow and reassess them
A legal obligation or an actual need to establish, exercise or defend claims may justify retaining defined information after ordinary use ends. Preserve the records needed for that purpose and restrict incompatible use. A hold should not silently become a reason to keep every dataset connected to the person.
Assign responsibility for reviewing the hold and record the event that will end or change it. Where a dispute closes, the decision may require further consideration of an applicable retention obligation; it should not automatically restart every original clock. Conversely, routine expiry must not destroy records that still have a valid preservation requirement.
Staff need a way to distinguish an authorised exception from a failed deletion. Otherwise, technical teams may preserve too much because they fear deleting evidence, while process owners assume the policy is being followed. An exception record helps explain both the scope of continued storage and the safeguards against ordinary reuse.
Avoid unnecessary copies across systems
The same information may appear in a production database, a support tool, a reporting environment, an exported spreadsheet and a backup. A minimisation review should follow these flows. The number of fields in the main form says little about exposure if complete copies are distributed to many teams.
Before creating an export, ask whether a filtered view or aggregate report can answer the question. If an identifiable copy is necessary, define its recipient, use and deletion point. Temporary storage should have an actual ending mechanism; calling a folder temporary does not cause its contents to disappear.
Test and development environments require their own decisions. Real customer data should not be copied there solely because that is convenient. Synthetic or appropriately transformed information may meet the need. If identifiable data are necessary for a particular task, assess the basis, scope, security and retention rather than assuming the production justification automatically covers everything.
Analytics require the same discipline. An inferred score or profile does not escape the GDPR simply because the organisation generated it rather than asking the person to provide it. Check whether the inference is necessary, whether its use is compatible and how long both the inputs and resulting profile should remain available.
Anonymisation and research need real safeguards
Pseudonymisation can reduce risk, for example by separating identifiers from an analysis dataset. It does not automatically produce anonymous data. Under Recital 26, identifiability is assessed in context, including means reasonably likely to be used by the controller or another person and relevant objective factors.
An aggregate can still reveal someone where the group is small or the attributes unusual. Likewise, a sequence of activities can remain recognisable without a name. The assessment should cover the information left in the result, available linking information and the proposed recipients. Revisit it if the dataset or circumstances change.
Article 5(1)(e) permits longer storage insofar as data will be processed solely for public-interest archiving, scientific or historical research, or statistical purposes, in accordance with Article 89(1) and appropriate safeguards. These labels do not create a general exemption from lawful basis, minimisation or security requirements.
Article 89(1) requires measures supporting minimisation, potentially including pseudonymisation where the purpose can be achieved that way. Where the purpose can be fulfilled without identification, it must be pursued in that manner. An organisation should therefore decide whether it needs identifiable records for a particular research stage rather than treating the entire project as permanently exempt from ordinary controls.
Backups and suppliers must support the decisions
Backup design should identify the recovery purpose, necessary contents, access arrangements and justified replacement period. Neither Article 5 nor the EDPB guidance establishes a universal backup grace period. Retention must be assessed for that purpose, including how deleted records are treated during a restoration.
A practical restoration process should prevent ordinary operations from resuming with information that should already have been erased. The appropriate mechanism depends on the system. Documenting a technical constraint can help plan remediation, but the constraint does not create an unlimited legal entitlement to keep or reuse the data.
Where a supplier acts as processor, Article 28 requires the appropriate written arrangement, including electronic form, through a contract or another binding Union or Member State legal act. The supplier’s role should follow the actual processing. A vendor is not necessarily a processor for every service or every use it makes of information.
At the end of processing services, the controller chooses return or deletion of the personal data, and existing copies must be deleted in either case unless Union or Member State law requires storage. Agree how that obligation works in the service’s actual architecture. Simply returning a download does not resolve copies that remain with the provider.
Make the record, notice and system agree
A record of processing activities helps connect purposes, categories, recipients and safeguards. Article 30(1)(f) includes envisaged erasure time limits for different categories where possible. Additional fields such as system owner or deletion method can be useful without being separately mandatory fields under that provision.
The information supplied to individuals should also reflect the arrangement. Articles 13 and 14 require the retention period or, where that is not possible, the criteria used to determine it. Information notices should explain meaningful distinctions, rather than hiding every purpose behind an indefinite reference to business requirements.
A good review compares actual examples with both documents. Does the system collect a field the form description says is optional? Can a former team member still access a restricted archive? Does the export process copy more information than the recipient needs? These questions reveal whether design decisions survive ordinary operations.
Handle individual rights alongside routine expiry
People do not have to submit an erasure request before the organisation applies storage limitation. Conversely, a future expiry date does not settle a current right to erasure request. The controller must assess the Article 17 grounds and exceptions against the particular processing.
Requests should be addressed without undue delay and normally within one month. Article 12 permits a justified extension of up to two further months for complexity or number of requests, with information and reasons in the first month. If the controller will not act, reasons and information about complaint and judicial remedies must be provided without delay and at the latest within one month.
A refusal should identify the relevant basis and scope. Preserving one document under a legal obligation does not necessarily justify refusing deletion of an unrelated marketing profile. Equally, a request does not automatically require destruction of information whose continued retention meets a statutory exception.
Verify outcomes and assign ownership
Choose controls that fit the scale and risk of the processing. Automated expiry may be valuable where volumes make manual handling unreliable. Smaller workflows can use other effective procedures. The EDPB’s examples favour reliable implementation but do not turn one automation tool or a fixed quarterly review into a universal statutory requirement.
Assign someone to investigate failures and approve changes to the underlying rule. Keep proportionate evidence that checks occurred, what they found and how problems were resolved. Review both over-retention and premature deletion: information that remains necessary must also be protected against accidental loss.
When a new feature, supplier or purpose is introduced, revisit the linked decisions together. A new field can affect sensitivity and access; a new recipient can create additional copies; a new retention requirement may apply only to one category. Treating those changes as part of one review makes minimisation and storage limitation workable throughout the service.