Online Tool Store
· 4 min read
How to Write a Data Retention Schedule
Manesh Jayawardhana
CIO & Co-founder
Writing the policy is the easy part. Listing what data you actually hold is where most organisations discover they don’t know, and describing how deletion works is where most policies quietly become fiction.
Why every period needs a reason
Data protection regimes built on the storage limitation principle — GDPR among them — require personal data to be kept no longer than necessary for the purpose it was collected for.
“Necessary for what” is the operative question, and it’s why a retention period without a stated reason is difficult to defend and impossible to review. Three years because the finance regulations require it is a defensible period. Three years because that’s what someone typed in 2019 is not.
Writing the reason also makes the policy reviewable. In two years someone can check whether the reason still applies, which they can’t do with a bare number.
Common categories of reason:
- Statutory — a law requires retention for a set period, typically financial and employment records.
- Contractual — you need it for the duration of the relationship plus a limitation period.
- Operational — you genuinely use it, such as logs for debugging.
- Consent-based — you keep it until consent is withdrawn.
If a category doesn’t fit any of those, the honest answer is usually that you don’t need it.
Backups are where policies break
Delete a record from the production database and it’s gone from production. It remains in every backup taken before the deletion, and it stays there until those backups rotate out.
That’s not a failure — restoring a backup to recover from an incident is a legitimate purpose, and selectively deleting records from backup archives is often technically impractical.
What matters is that the policy states the backup retention window and treats it as part of the total. If backups are kept for 35 days, then a record deleted today persists for up to 35 more days, and the policy should say so rather than implying immediate erasure.
The corresponding operational commitment: if a backup is restored, the deletions that happened after it was taken must be re-applied. That’s a runbook item, and it’s the part that gets forgotten.
| Data category | Typical basis | Note |
|---|---|---|
| Financial records | Statutory | Period set by local law |
| Employment records | Statutory | Often longest retention |
| Customer account data | Contractual | Relationship plus limitation period |
| Marketing contacts | Consent | Until withdrawn |
| Server logs | Operational | Usually short — 30-90 days |
| Backups | Operational | Own window, part of the total |
The exercise of listing
Most of the value in writing a retention policy comes before the policy exists: enumerating what you actually hold, where, and why.
Almost every organisation doing this for the first time finds data nobody knew about — an old export on a shared drive, a third-party tool holding customer records, a database column populated years ago and never used. Those discoveries are worth more than the document.
Common mistakes to avoid
- Setting periods with no stated reason, which makes them unreviewable.
- Ignoring backups, which quietly makes the policy inaccurate.
- Writing periods you can’t technically enforce, which is worse than a longer honest one.
- Forgetting third-party processors who hold data on your behalf under their own retention rules.
- Treating the generated document as complete without legal review for your jurisdiction and sector.
How to do it with Data Retention Policy Generator
The Data Retention Policy Generator structures the schedule with reasons and backup handling.
- List the categories of data you actually hold — this step is the valuable one.
- Set a period per category with a stated reason.
- Record the backup window and treat it as part of the total.
- Have it reviewed by someone who knows your jurisdiction and sector.
Your national data protection authority — the ICO in the UK, or the equivalent where you are — publishes guidance on storage limitation. Other privacy tools are in the tools directory.
Frequently asked questions
Why does every period need a reason?
Because storage limitation principles require data to be kept no longer than necessary for a stated purpose. A period with no justification is hard to defend and impossible to review.
What about backups?
This is where most policies break. Deleting from the live database leaves the record in backups until they rotate. State the backup window and treat it as part of the total.
Is a generated policy enough?
No. It’s a structure and a prompt to make the decisions. Retention periods are legal and sector-specific and need review by someone who knows your jurisdiction.
Final thought
The list of what you hold is worth more than the document. Most organisations writing their first retention policy find data they’d forgotten existed — and that’s the finding, not the policy.