Article 5(1)(e) of GDPR requires that personal data 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’ — the storage limitation principle. This principle is violated by organisations that retain personal data indefinitely ‘just in case’, that keep data beyond the period for which it was originally collected, or that accumulate data in backups, archives, and legacy systems without a plan to delete it.
Storage limitation enforcement is increasing in DPA activity. Regulators have found that many organisations have detailed collection processes and security measures but no systematic approach to deletion. The result is expanding data lakes of personal data that were relevant at collection, retained beyond their useful life, and eventually lost to a breach or found in a regulatory audit. Data you do not hold cannot be breached and cannot generate a retention violation.
The Retention Schedule: Core Documentation
A retention schedule is the foundational document for storage limitation compliance. It maps each data category to a defined retention period and the criteria or legal basis for that period. The retention schedule should be specific: ‘customer contact data: retained for the duration of the contract plus 2 years for legal claims’ is a compliant entry; ‘customer data retained as long as necessary’ is not, because it provides no defined endpoint.
RETENTION SCHEDULE — REQUIRED FIELDS PER DATA CATEGORY
| Field | Content | Example |
|---|---|---|
| Data category | The specific category of personal data covered by the entry | Customer transaction records |
| Business system(s) containing data | Which systems or databases hold this data | Salesforce CRM; order management database; email archive |
| Retention period | Defined period from a specific trigger point | 7 years from date of transaction |
| Trigger event | The event that starts the retention clock running | Date of last transaction; date of contract termination; date of employee leaving |
| Basis for retention period | The legal or regulatory obligation, business need, or limitation period that justifies the retention period | Tax law requires 7-year retention of financial records (HMRC guidance) |
| Deletion method | How the data is deleted at end of retention period | Automated deletion via system workflow; manual deletion by data steward; secure erasure for archives |
| Exceptions or holds | Any circumstances that extend retention (litigation hold; regulatory investigation; consent to extended retention) | Data subject consented to extended retention for future offers; regulatory investigation hold in place |
| Review date | When the retention period and basis should be reviewed | Annual review; or when relevant law changes; or when processing purpose changes |
Defining Retention Periods by Data Category
Retention periods are not arbitrary choices. They should be determined by the purpose for which the data was collected, the legal and regulatory retention obligations that apply to the data, and the limitation periods for claims the data may need to support. The principle is that data should be retained for as long as it is needed for the defined purpose, and no longer. Where legal obligations specify a minimum retention period, that minimum is the floor, not the ceiling.
RETENTION PERIODS BY COMMON DATA CATEGORY
| Data Category | Typical Retention Basis | Suggested Retention Period | Key Consideration |
|---|---|---|---|
| Financial and tax records | Legal obligation (tax law, accounting regulations) | 6–7 years from end of tax year in which transaction occurred | Specific period varies by jurisdiction; confirm local tax law requirement |
| Employment records (general HR) | Legal obligation; legal claims | During employment plus 6 years (UK limitation period for contract claims) | Longer retention may apply for pension, occupational health, or certain health and safety records |
| Recruitment records (unsuccessful candidates) | Legal claims (discrimination) | 6 months to 1 year after notification of decision (sufficient for claims); longer if consent obtained | Longer retention (2 years) permissible with specific consent for consideration for future roles |
| Customer contract records | Legal claims; contractual obligation | Duration of contract plus 6 years (limitation period for contract breach claims) | Limitation period varies by jurisdiction; confirm local law |
| Marketing consent records | Accountability; legal claims | Duration of consent plus 3 years (sufficient to defend claims that marketing was sent without consent) | Must retain evidence of the consent itself; not just the data subject’s details |
| Website analytics (user behaviour) | No legal obligation; business analytics | 13 months maximum (CNIL guidance); review annually | Many analytics tools default to longer retention; must be configured to comply |
| CCTV footage | Security; legal claims | 30 days standard; longer if incident-related footage retained pending investigation | Longer retention must be documented; CCTV policy should specify retention period |
| Access logs and audit trails | Security; legal claims; accountability | 1–2 years; longer if required for regulatory investigation | Minimum period to support security incident investigation; review against regulatory requirements |
| Health data (patient records) | Regulatory obligation (varies by healthcare regulation) | As required by applicable healthcare regulation; varies significantly by jurisdiction and record type | National healthcare law overrides GDPR minimum; DPA guidance and sector regulators should be consulted |
Implementing Deletion: Automated and Procedural
Defining retention periods is only half of storage limitation compliance. The other half — and the more operationally challenging half — is ensuring that personal data is actually deleted when the retention period expires. This requires either automated deletion workflows built into systems, or procedural deletion processes that are reliably followed. Most organisations need both: automated deletion for high-volume, routine data and procedural deletion for archive, backup, and legacy systems.
DELETION IMPLEMENTATION — APPROACHES BY SYSTEM TYPE
| System Type | Recommended Deletion Approach | Implementation Consideration |
|---|---|---|
| Primary operational systems (CRM, HR, e-commerce) | Automated deletion triggered by retention schedule; deletion review queue for records approaching retention end; automated deletion at defined trigger | Most modern SaaS platforms support retention rules and automated deletion; configure and test deletion workflows at implementation; validate deletion actually executes |
| Data warehouse / analytics platform | Scheduled deletion jobs; retention policies in data pipeline; ETL process filters out personal data beyond retention | Avoid persisting personal data in data warehouse longer than necessary; implement data lifecycle management in pipeline |
| Email archive | Automated deletion of emails beyond retention period; litigation hold mechanism to preserve specific emails when required | Email archives frequently contain large volumes of personal data beyond retention; configure archive retention limits; test deletion |
| Backup and disaster recovery systems | Flag records for deletion in live system; record in deletion log; confirm deletion at next backup rotation cycle; document approach | True deletion from backup is technically complex; acceptable approach is to flag deleted records so they are excluded from any restore; document the methodology |
| Legacy systems / data archives | Manual deletion with data steward sign-off; project approach to decommission legacy systems holding personal data beyond retention | Legacy systems often have no deletion capability; manual export and deletion; decommission planning should include data deletion as a requirement |
| Paper records | Secure disposal (cross-cut shredding or confidential waste service); disposal certificate for sensitive records | Paper records subject to same retention schedule as digital records; often overlooked; include in retention schedule and disposal procedure |
Data Minimisation at Collection
The storage limitation principle works upstream as well as downstream. Retaining data for shorter periods is easier if less data is collected in the first place. Data minimisation — collecting only the personal data that is necessary for the specific purpose — reduces the volume of data subject to retention management, reduces breach severity, and simplifies compliance.
DATA MINIMISATION — IMPLEMENTATION CHECKPOINTS
| Checkpoint | Question to Ask | Minimisation Action |
|---|---|---|
| Form and registration design | Is every field on this form collecting data that is actually needed for the stated purpose? Are any fields optional that could default to absent? | Remove or make optional any fields not strictly necessary; periodic form review against current processing purpose |
| Third-party data purchases | Is the full purchased dataset necessary? Can the data purchase be scoped to only the fields and segments actually used? | Scope data purchase narrowly; delete fields not used; do not retain purchased data beyond the campaign or purpose for which it was acquired |
| Analytics and tracking | Are we tracking more user behaviour than we actually analyse and use? Are we collecting identifiable data where aggregate data would serve the same purpose? | Configure analytics to collect only what is actually used; sample rather than full tracking where sufficient; anonymise where possible |
| Employee data collection | Are HR systems collecting data about employees that is not needed for employment management? Are monitoring systems collecting more data than the stated monitoring purpose requires? | Review HR data fields against employment contract and legal requirements; remove fields not required; configure monitoring proportionately |
| BITLION INSIGHT | The organisations with the strongest storage limitation compliance are those that have made retention and deletion a system requirement rather than an afterthought. When a new system is procured or built, the data retention requirements should be specified as part of the technical requirements — including automated deletion capability, configurable retention periods, and deletion audit logging. Retrofitting deletion capability into systems that were built without it is expensive and technically complex. Requiring it at procurement costs nothing and ensures that the tool serves the compliance programme rather than undermining it. |