Skip to content
AuditFront
Art.5.1e GDPR

GDPR Art.5.1e: Storage Limitation

What This Control Requires

Personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject ('storage limitation').

In Plain Language

Holding personal data indefinitely is one of the most common GDPR failures - and one of the easiest for regulators to spot. If you cannot point to a concrete reason why you still need to identify someone from a dataset, it is time to delete or anonymise that data. The central question is not "how long can we keep this?" but "for how long do we actually need to identify individuals?" If your original purpose can be served with anonymised or aggregated data, switch to that as soon as possible. Retention periods should be based on the processing purpose, any legal or regulatory obligations that mandate keeping records, and genuine business needs - not convenience or "we might need it later." There is an exception for data stored solely for public interest archiving, scientific or historical research, or statistical purposes, but only with proper Article 89(1) safeguards like pseudonymisation and access restrictions. This is not a loophole for keeping everything forever.

How to Implement

Write a concrete data retention policy with specific timeframes for each category of personal data and each processing purpose. "As long as necessary" is not a retention period - put actual numbers on it. Base those numbers on legal requirements (tax, employment, financial regulations), contractual obligations, and genuine business needs. Build a retention schedule that maps every dataset to its defined retention period, including the data type, processing purpose, legal basis, any statutory minimums, the concrete retention period, and what happens when it expires (deletion, anonymisation, or archiving). Get your DPO to review and approve it. Automate wherever you can. Configure your systems to flag or automatically process data that has hit its retention deadline. Set up clear workflows for reviewing flagged data and executing deletion or anonymisation promptly. Keep audit trails of what was deleted and when. Do not forget about backups and archives - they are where retention compliance usually falls apart. Develop a strategy for personal data in backup systems, whether through rotation cycles, selective deletion, or encryption with key destruction. Document any technical limitations honestly and describe what compensating controls you have. Run regular retention audits. Hunt for orphaned data in decommissioned systems, old databases, file shares, email archives, and paper records. When you find data kept past its expiry date, fix it and investigate why your process failed so it does not happen again.

Evidence Your Auditor Will Request

  • Documented data retention policy with specific retention periods per data category and purpose
  • Data retention schedule mapping all processing activities to defined retention periods
  • Evidence of automated deletion or anonymisation processes in operation
  • Audit logs of data deletion activities and retention reviews
  • Records of retention policy reviews and approvals

Common Mistakes

  • No defined retention periods, leading to indefinite storage of personal data
  • Retention policy exists on paper but is not implemented in systems or followed in practice
  • Data deleted from primary systems but retained indefinitely in backups, archives, or shadow databases
  • Retention periods based solely on storage costs rather than privacy considerations and necessity
  • No automated mechanisms for flagging or deleting data that has reached the end of its retention period

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.34 Related
ISO 27001 A.8.10 Related

Frequently Asked Questions

How do we determine the right retention period for personal data?
Start with the legal floor - are there regulations requiring you to keep certain records for a minimum period (tax records, employment files, financial transaction logs)? Then ask how long you genuinely need the data for its stated purpose. Factor in contractual obligations. The right retention period is the shortest one that satisfies all of these, not the longest one you can justify.
What about personal data in backups?
Regulators understand that surgically removing individual records from backup tapes is often impractical. What they want to see is a clear backup rotation schedule so old backups expire naturally, a commitment not to restore deleted records if you ever need to recover from a backup, and documentation of your approach. This is an area where honesty about technical limitations paired with sensible compensating controls goes a long way.
Can we anonymise data instead of deleting it?
Absolutely - truly anonymised data falls outside GDPR entirely. The catch is that the anonymisation must be irreversible. If there is any realistic way to re-identify individuals from the output, even by combining it with other available datasets, it is still personal data. Pseudonymisation (replacing identifiers with tokens) does not count - pseudonymised data is still personal data under the regulation.

Track GDPR compliance in one place

AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.

Start Free Assessment