A retention schedule lists each type of data you hold, why you hold it, how long, and how it is deleted. GDPR Article 5(1)(e) requires that personal data be kept in identifiable form for no longer than necessary for the purposes of processing. The schedule is how you show you thought about it.
What the law says
Article 5(1)(e) says 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 it is processed. There are exceptions for archiving, research or statistics where safeguards apply. Article 5(1)(f) separately requires appropriate security, including protection against unauthorised processing and accidental loss, destruction or damage.
The law does not give you fixed periods for most data. You set them, and you must be able to justify them. Specific retention minimums may come from tax, employment or sector rules, so ask your advisor for those that apply.
Step by step
- Inventory data types. Customer accounts, support tickets, logs, analytics, HR files, backups, marketing lists.
- Record the purpose for each. If you cannot name one, question why you hold it.
- Set a period and the trigger that starts the clock, for example account closure, end of contract or ticket resolution.
- Note any legal minimum from other rules, with the source.
- Choose the end action: delete, anonymise or archive with safeguards.
- Assign an owner per data type.
- Implement. Use lifecycle rules, scheduled jobs and database purge routines, then log what ran.
- Cover copies. Backups, exports, search indexes and analytics copies all count.
- Review yearly and when a purpose changes.
Example rows
- Support tickets. Purpose: Resolve and track issues. Trigger: Ticket closed. Period: Your decision, justified. End action: Delete.
- Application logs with user IDs. Purpose: Debugging and security. Trigger: Log written. Period: Short, documented. End action: Delete.
- Marketing opt-in. Purpose: Send updates. Trigger: Consent withdrawn. Period: Until withdrawal. End action: Delete.
Periods in your table are for you to decide. The values above are placeholders.
The hard part: backups
Deleting from production while old backups keep the data is common. Options include short backup retention, and crypto-shredding where per-subject keys are destroyed. See crypto-shredding explained. Document what you do, and tell people honestly about backup timing.
Pair it with encryption
Retention reduces how much is exposed. Encryption limits the damage of what remains. See GDPR Article 32 on encryption.
Quick check
Is there a standard retention period under GDPR?
No general one. You justify your own periods per purpose, subject to any sector or legal minimums.
Is anonymised data covered by the schedule?
Truly anonymised data is not personal data, but be careful: weak anonymisation may still count as identifiable.
Safeguard's compliance and evidence automation can help keep policies and supporting evidence organised once your schedule is written. This post is not legal advice.
Sources
Last reviewed: 19 October 2026.
