When hackers stole approximately 250,000 UK legal aid records during a 2025 breach, some of that data dated back to 1978. The Legal Aid Agency discovered that decades-old benefit assessments and criminal case details were sitting in systems that predated modern security protocols. If you're a Data Protection Officer (DPO), this should feel uncomfortably familiar: your organization almost certainly holds sensitive data in systems you rarely audit, under retention schedules you inherited rather than designed.
Here's a policy template you can adapt immediately. It's built around a three-tier retention classification that forces your organization to justify why it's keeping old data, not just how long it's allowed to keep it.
Purpose of This Template
This retention policy template helps you document:
- What categories of personal data you hold
- Why you're holding each category (mapped to your Article 6 lawful basis and processing purpose)
- How long you'll keep it before secure deletion
- Who reviews these decisions and how often
You'll notice this isn't just a table of retention periods. It requires you to tie retention to your lawful basis and purpose limitation obligations under Articles 5(1)(b) and 5(1)(e). When a supervisory authority asks why you still hold data from 2003, "because the system allows it" won't satisfy them.
Prerequisites
Before you customize this template, gather:
- Your existing data inventory or Article 30 processing register
- Current retention schedules (if they exist)
- Legal hold requirements specific to your jurisdiction and sector
- Your organization's defined roles for data governance
You'll also need sign-off authority from whoever owns data governance decisions in your organization. This policy will trigger deletion workflows, so don't deploy it without executive backing.
The Template
LEGACY DATA RETENTION POLICY
Last reviewed: [DATE]
Next review: [DATE]
Owner: [ROLE]
1. SCOPE
This policy applies to all personal data processed by [ORGANIZATION] where:
- The data subject relationship ended more than [X] years ago, OR
- The original processing purpose has been fulfilled for more than [X] years
2. RETENTION TIERS
TIER 1: Active Retention (Keep)
Personal data required to fulfill an ongoing legal obligation, defend a legal claim in progress, or complete a purpose for which we have a valid lawful basis.
Retention period: As long as the legal obligation, claim, or purpose remains active
Review frequency: Annually
Deletion trigger: When obligation ends, claim concludes, or purpose is fulfilled
Examples:
- Employment records where statutory retention periods apply
- Contract data during contract term plus limitation period
- Data processed under consent where consent remains valid
TIER 2: Conditional Retention (Justify or Delete)
Personal data where the original purpose has ended but a secondary justification may exist.
Retention period: [6 months / 1 year] after purpose fulfillment
Review frequency: Quarterly
Deletion trigger: If no documented justification exists at review, schedule for deletion within 30 days
Examples:
- Customer records after account closure
- Applicant data after hiring decision
- Marketing data after consent withdrawal
Required justification must reference:
- Specific [Article 6](/glossary/article-6) lawful basis for continued processing
- Documented legitimate interests assessment if relying on Article 6(1)(f)
- [Compatibility assessment](/glossary/compatibility-assessment) if purpose has changed from original collection
TIER 3: Mandatory Deletion (Delete)
Personal data with no active legal obligation, no valid lawful basis, and no justified business need.
Retention period: 0 days after identification
Review frequency: Monthly
Deletion trigger: Immediate scheduling upon identification
Examples:
- Data from systems decommissioned without migration plan
- Records predating your oldest documented lawful basis
- Personal data collected for purposes you no longer perform
3. LEGACY SYSTEM CLASSIFICATION
All systems holding personal data must be classified:
ACTIVE: System receives regular updates and security patches
- Standard retention rules apply
- Quarterly access reviews required
MAINTAINED: System receives security patches but no functional updates
- Tier 2 review required for all data annually
- Document why data cannot be migrated to active system
LEGACY: System receives no updates
- Immediate Tier 3 classification for all data
- If data cannot be deleted due to legal hold, system must be isolated from network and monitored continuously
- DPO approval required to maintain legacy system beyond 90 days
4. REVIEW PROCESS
Data Stewards must:
- Review their assigned data categories according to tier frequency
- Document retention decisions in [SYSTEM/REGISTER]
- Escalate Tier 2 items that cannot be justified to DPO
DPO must:
- Approve all Tier 2 retention justifications
- Audit Tier 3 deletion completion monthly
- Report legacy system status to [GOVERNANCE BODY] quarterly
5. DELETION STANDARDS
Secure deletion must:
- Render data irrecoverable using appropriate [technical measures](/glossary/technical-measures)
- Include backups and archived copies
- Be logged with deletion date, data category, and approver
- Follow [REFERENCE YOUR DELETION PROCEDURE]
6. EXCEPTIONS
Legal holds override this policy. When litigation, investigation, or regulatory inquiry requires data preservation:
- Legal team must document the hold scope and affected data categories
- Data moves to Tier 1 with "Legal Hold" justification
- Review hold [necessity](/glossary/necessity) every 90 days
- Remove hold and resume standard retention when matter concludes
How to Customize It
Start with your Tier 3 category. Look for systems you know are outdated. The Legal Aid Agency breach included records from the 1990s and 2000s, with some predating 1990. If you have data that old, you need a documented reason it's still there or a deletion plan.
Replace the bracketed timeframes based on your sector. Financial services might need seven years for some records. Healthcare might need longer. But don't just copy statutory minimums into every category; Article 5(1)(e) requires you to keep data no longer than necessary for your specific purposes.
The "Conditional Retention" tier is your forcing function. It catches data that's drifting toward legacy status before it becomes a security liability. Set your review frequency based on your risk appetite and team capacity, but quarterly is reasonable for most organizations.
For the legacy system classification, be honest about what "maintained" means. If you're applying security patches but the system can't support multi-factor authentication or modern encryption, it's not really maintained; it's legacy with a slower countdown timer.
Validation Steps
After you've customized the template:
Map it to your Article 30 register. Every processing activity in your register should align with a retention tier. If you can't map an activity, either your register is incomplete or your retention policy has gaps.
Run a legacy system audit. Identify every system holding personal data that's more than five years old. Classify each one using your new definitions. If more than 20% fall into "Legacy," you have a remediation project, not just a policy problem.
Test your deletion process. Pick a small, low-risk data category and run it through Tier 3. Can your team actually delete it from all systems, including backups? How long does it take? The Legal Aid Agency breach exposed benefit assessments and criminal case details, some containing names and National Insurance numbers. If you can't delete a test dataset cleanly, you won't be able to delete sensitive data under pressure.
Schedule your first quarterly review. Don't wait. Put the first Tier 2 review on your calendar now with assigned owners. If nobody shows up or they show up without documented decisions, your policy is already failing.
Document your "why not" answers. For every Tier 2 item you decide to keep, write down why. If you're relying on legitimate interests, you need a legitimate interests assessment. If you're claiming legal obligation, cite the specific statute. Vague justifications like "might need it later" won't survive a supervisory authority inquiry.
This template won't prevent every breach. But it forces you to confront the question that the Legal Aid Agency apparently didn't ask often enough: why are we still holding this data? Answer that question with documented decisions, regular reviews, and actual deletion, and you'll shrink your attack surface considerably.
