Writing a data retention schedule you can defend

The five columns

A schedule that can actually be executed has five columns, and the third is the one most drafts omit.

• Category — the class of data, not the table. "Employee records", not hr_dim_person_v2.
• Period — a number and a unit.
• Trigger — the event that starts the clock. End of employment, end of the contract, last transaction, end of the financial year. Retention measured from creation is almost always wrong.
• Basis — the statute, the limitation period, or the named business justification.
• Disposal — delete, anonymise, or archive to a stated place with stated access.

Without the trigger, nobody can build the query that finds what is due for deletion, and the schedule stays theoretical for ever.

Where the periods come from

Three legitimate sources, in order of how easily they survive challenge.

Statutory requirements

Some periods are set for you. UK examples a mid-market business will meet: company accounting records under the Companies Act (six years from the end of the financial year for a private company); payroll and PAYE records for HMRC (three years after the end of the tax year they relate to); working time records (two years); and the pension auto-enrolment records (six years, with opt-out records four). Check the current position rather than quoting this paragraph — these change, and sector rules layer on top.

Limitation periods

How long someone could bring a claim, plus a margin. In England and Wales the ordinary contract limitation period is six years, which is why so many commercial records land on six. Personal injury is three years from knowledge, which is why some employment records are held longer than the tax rules require.

Documented business need

Everything else. This is legitimate — a business genuinely needs three years of sales history to forecast — but it has to be written down with a reason and an owner. The test is whether you could say it out loud to the person the data is about.

What is not a basis: "storage is cheap", "the data science team might want it", and "we've always kept it". Under UK GDPR storage limitation is a principle, and the burden of explaining the period sits with you.

The backup problem

This is where most schedules fall apart. The production database honours a three-year rule and the backup regime keeps snapshots for seven, so the data is still there and the policy is now a document that describes something untrue.

The pragmatic position, and the one the ICO's guidance supports, is that data in backups may persist beyond the live deletion provided you can say so honestly and can commit to not restoring deleted records into production. That means three things:

• State the backup retention in the schedule, next to the live retention, rather than pretending they are the same number.
• Write down the rule that a restore is followed by re-applying deletions — and make it a step in the restore runbook, not an aspiration.
• Keep the backup window as short as your recovery obligations allow. Seven years of snapshots is rarely a recovery requirement; it is usually an unexamined default.

Do the same exercise for the places data goes that nobody lists: warehouse copies, BI extracts, the analytics tables built from production, email attachments, the spreadsheet on somebody's OneDrive. A retention schedule that covers only the source system covers the least likely place for data to leak from.

Deletion, anonymisation and archive are three different promises

Deletion means gone. Anonymisation means the data survives but nobody can be identified from it, directly or indirectly — a genuinely high bar, and a dataset with a pseudonymised key that still joins to a live customer table is not anonymised, it is pseudonymised, and it remains personal data. Archive means moved somewhere colder with restricted access, and it is not a retention outcome at all: an archive needs its own retention period or it is just an indefinite hold with extra steps.

Pick one per row and be precise, because the three carry different obligations and people use the words interchangeably.

Drafting the first schedule in a day

1. Group into categories, not tables. Most businesses land on 15 to 30 categories: employee records, payroll, customer contracts, customer transactions, marketing consents, supplier records, CCTV, website analytics, support tickets, and so on.
2. Take the statutory ones first. They are non-negotiable and they anchor the document.
3. Default the rest to six years from the trigger and then argue each one down. Starting from a defensible number and reducing is much faster than starting from nothing.
4. Mark the ones where deletion is currently impossible. Being honest about this is more useful than a schedule that describes a capability you do not have. It also produces the shortlist for what to fix.
5. Get one person to sign it and set a review date. An unsigned schedule is a draft, whatever the file name says.

Making it happen once a year

The schedule is the easy half. The half that decays is execution, and the fix is to make it an event with a name and a date rather than a background intention.

Run a disposal review annually: a query per category that lists what is past its trigger date plus its period, an owner's confirmation, the deletion, and a dated record that it happened. That record is the thing you produce when someone asks whether the policy is real, and it takes about half a day a year once the queries exist.