Article 5(1)(e) of the GDPR establishes the storage limitation principle: personal data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the data is processed. This is one of the core data protection principles, and it applies to every category of personal data you hold.
The principle sounds simple. In practice, it is one of the most difficult GDPR obligations to implement. Unlike consent or data processing agreements — which can be addressed through specific documents — retention requires a comprehensive understanding of every data category your organisation holds, why you hold it, and the legal and business reasons that justify keeping it for a specific period.
Organisations that get retention wrong tend to fall into one of two traps: they keep everything indefinitely because deletion feels risky, or they adopt vague policies that say all the right things but are never enforced. Both approaches create liability. Keeping data too long exposes you to regulatory action and increases the impact of any data breach. Having a policy you do not follow is arguably worse than having no policy at all, because it demonstrates that you were aware of the obligation but failed to act on it.
A defensible data retention policy must identify every category of personal data your organisation processes, link each category to a specific retention period or clear criteria for determining one, explain the legal or business justification for each retention period, and set out the process for deleting or anonymising data once the retention period expires.
The GDPR does not prescribe specific retention periods. Instead, it requires you to determine the appropriate period based on the purposes of the processing. This means you must make — and document — a reasoned judgment for each data category. The supervisory authority does not want to see a blanket statement that all data is retained for seven years. It wants to see that you have thought about each processing activity individually and arrived at a justified period.
While the GDPR requires you not to keep data longer than necessary, other legislation may require you to keep certain data for a minimum period. These statutory retention obligations override the storage limitation principle for their specific scope — but only for that scope.
In Belgium, key statutory retention periods include accounting records, which must be retained for seven years under Article III.86 of the Belgian Code of Economic Law. Tax documentation, including VAT records and supporting documents, must similarly be retained for seven years under the Belgian Tax Code. Social security and employment records, including payroll records, must be retained for five years following the end of the employment relationship. Corporate documents such as board resolutions and shareholder registers must be retained for the duration of the company plus the applicable prescription period.
These statutory periods define the minimum. They do not authorise keeping data indefinitely. Once the statutory period expires, the GDPR storage limitation principle applies and the data should be deleted or anonymised unless another specific ground justifies continued retention.
The practical core of any retention policy is the retention schedule — a structured document that maps each data category to its retention period and justification. A well-built retention schedule is organised by business function or processing activity and includes the category of personal data, the data subjects concerned, the purpose of the processing, the legal basis for retention, the retention period, the action to be taken at expiry, and the department or person responsible for ensuring compliance.
Your Records of Processing Activities should be the starting point for building the schedule. If your RoPA accurately maps your processing activities, it provides the framework on which retention periods can be layered. Where the RoPA has gaps — and in our experience it usually does, particularly for website processing and legacy systems — the retention schedule project will surface them.
For some data categories, the retention period is straightforward because legislation prescribes it. For others, you must exercise judgment. Common approaches include aligning with the applicable prescription period for claims related to the processing. Under Belgian law, the general contractual prescription period is ten years, but shorter periods apply in specific contexts — five years for tort claims, one year for certain employment claims. If you retain customer data to defend against potential contractual claims, the ten-year prescription period provides a defensible justification.
Another approach is aligning with industry practice or regulatory guidance. Some sector regulators or data protection authorities have issued guidance on appropriate retention periods for specific data categories. The Belgian DPA has not published a comprehensive retention schedule, but it has addressed retention in specific decisions and guidance documents.
Where no external reference point exists, the test is proportionality. How long do you genuinely need the data for the purpose you collected it? If you collected email addresses for an event, retaining them for five years after the event is difficult to justify. If you hold medical records for an occupational health assessment, the retention may need to extend well beyond the employment relationship.
The GDPR does not prohibit archiving personal data, but it requires that archived data remains subject to the same principles — including storage limitation. Organisations sometimes interpret archiving as exemption from deletion. It is not.
If you move data from active systems to an archive, you must still delete it when the retention period expires. The archive is a storage mechanism, not a justification for indefinite retention. Where data is archived for research, statistical, or historical purposes, Article 89 of the GDPR provides a framework that allows longer retention, but it requires appropriate safeguards including technical and organisational measures to ensure the principle of data minimisation.
The GDPR applies only to personal data — data that relates to an identified or identifiable individual. If you genuinely anonymise data so that re-identification is not possible, the anonymised data falls outside the GDPR and can be retained indefinitely.
The key word is genuinely. Pseudonymisation — replacing identifiers with a key that can be reversed — is not anonymisation. Aggregation that still allows individual-level inference is not anonymisation. The Article 29 Working Party's opinion on anonymisation techniques remains the reference document for assessing whether data has been effectively anonymised. If there is any reasonable possibility of re-identification, the data remains personal data and subject to GDPR requirements including storage limitation.
For many organisations, anonymisation offers a practical middle ground: retain aggregated or anonymised data for analytics, reporting, and business intelligence, while deleting the underlying personal data when the retention period expires.
No retention periods at all. Many organisations have privacy policies that mention storage limitation but never specify actual periods. This fails the accountability requirement. You must be able to demonstrate the specific retention period for each data category and the reasoning behind it.
One retention period for everything. A policy that states all personal data is retained for seven years is unlikely to be defensible. There is no justification for retaining a job applicant's CV for seven years if the position was filled within months. Retention periods must be granular and purpose-specific.
Policy exists but is not enforced. A retention schedule that sits in a compliance folder but is never implemented is a liability, not an asset. If you cannot demonstrate that data is actually being deleted in accordance with your policy, the policy creates evidence against you rather than for you.
Backup systems ignored. Even if you delete data from production systems, it may persist in backups. Your retention policy must address backup retention and include a strategy for ensuring that backed-up data does not persist indefinitely beyond its retention period. This is technically challenging, and many organisations acknowledge backup retention as a residual risk rather than resolving it completely, but the risk must at least be documented and mitigated.
No legal holds process. When litigation or regulatory investigation is anticipated, you may have a legal obligation to preserve relevant data even if it would otherwise be due for deletion. Your retention policy must include a legal hold mechanism that can override scheduled deletion when necessary, and clear procedures for lifting the hold when it is no longer required.
A retention policy is only as good as the processes that enforce it. Effective implementation requires assigning ownership for each data category to a specific team or individual who is responsible for ensuring timely deletion, automating deletion where possible through system configurations that flag or remove data when the retention period expires, conducting periodic audits to verify that data is being deleted in accordance with the schedule, training staff who handle personal data to understand their responsibilities under the retention policy, and integrating retention into your data protection by design processes so that new systems and processing activities are designed with retention limits from the outset.
Manual deletion processes are inherently unreliable at scale. Where your systems support automated retention enforcement — and most modern CRM, HR, and document management platforms do — you should configure those capabilities. Where they do not, compensating controls such as quarterly deletion reviews become essential.
Data retention intersects with virtually every other GDPR obligation. When responding to a data subject erasure request, you need to know whether any retention obligation overrides the deletion right. When a data breach occurs, the volume of affected data is directly influenced by how much historical data you retain. During M&A due diligence, buyers will review your retention practices as part of data protection compliance. And when the supervisory authority asks to see your retention schedule, the absence of one is a finding in itself.
A well-implemented retention policy reduces your data footprint, simplifies compliance, and limits the blast radius of any incident. It is one of the most practically valuable elements of a mature data protection programme.
At Pitch, we help organisations build, review, and implement data retention policies as part of our broader data protection practice. Our approach starts with your processing activities — mapping what data you hold, why you hold it, and what legal and business grounds justify each retention period — and produces a structured retention schedule that your teams can actually follow.
Where your data landscape includes website processing, SaaS platforms, and digital marketing tools, our technology monitoring capabilities help identify data flows that may not be documented in your existing records — and that need retention periods assigned.
We also advise on the interplay between GDPR retention obligations and Belgian statutory retention requirements, helping you navigate the tension between keeping data long enough to satisfy legal obligations and deleting it promptly enough to satisfy the storage limitation principle.
Pitch is the law firm for innovators and creatives. If you need to build or review your data retention policy, get in touch or schedule a meeting with our team.
%402x.svg){kind=small}
%402x.svg){kind=icon}
%402x.svg){kind=icon}
