Most retention schedules fail at the same point: they state a period but not what it counts from. "Seven years" is meaningless until someone says seven years from what - creation, last transaction, or end of the relationship. Without that, nobody can implement it and the schedule stays a document.
The columns that make it work
| Column | Why it matters |
|---|---|
| Data category | Group by category, not by system. Systems change; categories persist. |
| Retention period | The longest binding requirement, not the longest imaginable use. |
| Trigger event | What starts the clock. The column most often missing and the one that decides implementability. |
| Legal basis | Which statute, regulation or contract requires it - so the period can be defended and revisited. |
| Owner | A named role accountable for the category. |
| Systems | Where this category actually lives, including replicas and analytics stores. |
| Disposal method | Delete, secure erase, or anonymise - the last is often the better answer for analytics data. |
Setting periods defensibly
- Identify every binding obligation - tax, employment, sector regulation, contracts.
- Take the longest of those as the period.
- Stop there. "We might want it someday" is not a retention justification, and under privacy law it is an argument against you.
- Where obligations conflict - a tax rule requiring years against a privacy duty to minimise - retain only the narrow subset the law demands and delete the rest. Document that reasoning; a regulator will ask about exactly this.
Link retention decisions to the obligations behind them
GRC Copilot ties data categories to the regulations that govern them and the controls protecting them, so retention decisions are recorded and owned.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Where deletion does not reach
State the position explicitly rather than implying instant erasure everywhere:
- Backups - not routinely searched for deletion; they age out on a defined schedule and restores re-apply deletion. This is the accepted approach and regulators have broadly accepted it.
- Replicas, warehouses and analytics platforms, frequently forgotten.
- Exports and reports in shared drives and inboxes.
- Third parties who received the data - deletion must be contractual, with evidence requested at contract end.
- Logs, which often contain personal data nobody classified as such.
Legal hold
The schedule needs a documented mechanism to suspend automated deletion for identified data when litigation or investigation is reasonably anticipated, and to release it afterwards. Build this before automating deletion - its absence is why many organisations never automate at all, which is the worse outcome.
Evidencing disposal
Auditors ask for the schedule, evidence it is applied, and evidence of actual disposal. The third is where most organisations have nothing. Keep disposal records - category, period, date, method, authorised by - without retaining the data itself. Certificates of destruction for physical media belong in the same file.
Frequently asked questions
How granular should categories be?
Granular enough that one period genuinely fits the whole category. If you find yourself writing exceptions, split it.
Should deletion be automated?
Ideally, because manual deletion does not happen. Build legal hold first, then automate with confidence.
Is anonymisation an alternative?
Yes if genuine - truly anonymised data falls outside privacy law. Re-identifiable data is pseudonymised and remains in scope.
How long for security logs?
Commonly a year, with a shorter searchable window. Detecting a historical intrusion depends on having logs from when it happened.
Key takeaways
- The trigger column decides whether the schedule is implementable.
- Set the period to the longest binding obligation and stop.
- State the backup position explicitly rather than claiming instant erasure.
- Build legal hold before automating deletion.