A Records Retention Schedule Template You Can Adapt
A retention schedule is a table, not an essay. Here are the columns it needs, a worked example you can copy, and the habits that stop it going stale.
A records retention schedule answers one question for every kind of record you hold: how long do we keep this, counted from what, and what happens at the end? That is all it is. Most organisations that do not have one think it needs to be a long policy document. It does not. It needs to be a table that someone actually consults.
The columns that matter
A usable schedule has six columns. Anything more tends to go unmaintained.
- Record class — a type of record, described so a new starter could recognise it ("signed client engagement letters", not "legal").
- Owner — the role responsible for the class, not a named person.
- Trigger — the event the clock starts from: matter closed, contract ended, employee left, record created.
- Period — how long after the trigger.
- Action at end — destroy, review, anonymise, or transfer to a permanent archive.
- Reason — the legal requirement, contract term or business need behind the period. This is the column auditors read.
A worked example
The periods below are placeholders to show the shape. Minimum periods vary by country and sector, so check your jurisdiction before you fill yours in.
| Record class | Trigger | Period | Action at end |
|---|---|---|---|
| Client matter files | Matter closed | 6 years | Review, then destroy |
| Invoices and payment records | End of financial year | Per tax rules | Destroy |
| Unsuccessful job applications | Decision sent | 6 months | Destroy |
| Signed contracts | Contract ends | Claim window | Review |
| Board and committee minutes | Created | Permanent | Transfer to archive |
Classes, not folders
The most common mistake is writing the schedule around your folder structure. Folders mix record types: a client folder holds contracts, correspondence, invoices and identity copies, each with a different clock. Write the schedule around what the records are, then make sure each item can be identified as belonging to a class. That is the practical difference described in records management vs document management.
Triggers need dates on the record
A schedule that says "six years after the matter closes" only works if the closing date is written down somewhere reliable. Before you finalise the schedule, check that every trigger corresponds to a date you actually record. If you do not record when tenancies end or when employees leave, fix that first, or the schedule is decoration.
"Review" is not a period
Use "review" as an action only where a human decision is genuinely needed, and name who makes it. A schedule full of "review periodically" entries means nothing is ever disposed of. For personal data in particular, keeping records past their purpose is itself a risk; see tenant screening records for an example of how short some periods should be.
Keep it alive
- Put a version number and a review date on the schedule itself, and review it yearly.
- When someone creates a new kind of record, add a row before the records accumulate.
- Log every disposal: which class, which records, when, by whom, under which row. The log survives; the content does not.
A schedule you can read in two minutes and apply on a Friday afternoon beats a thirty-page policy nobody opens.
