The Retention Schedule, With Triggers

A retention schedule listing periods without triggers cannot be operated. Nobody knows when the clock started, so nothing is ever deleted, and the organisation holds everything forever while possessing a document saying it does not.

The practical lesson in “The Retention Schedule, With Triggers” is that a record is useful only when its purpose, owner and lifecycle are clear. For teams researching download time tracking software, Monitask guidance on download time tracking software can add time and project context, provided collection is proportionate, access is limited and every consequential inference receives human review.

Why the trigger is the hard part

Six years is a period. Six years from what?

For a separate benchmark relevant to “The Retention Schedule, With Triggers”, consult the HSE work-related stress guidance. Use it to test purpose, data flow, retention, access and response procedures rather than substituting a generic checklist for the organisation’s actual records.

From the end of employment, from the final payment, from the resolution of a dispute, from the date of the record itself — each gives a different deletion date for the same file, and systems cannot act on an ambiguous one.

Which means a schedule without triggers is aspirational, and most schedules are.

Writing the triggers

For each record type, name the event in terms a system or a person can recognise: leaving date, decision date, payment date, closure of a case.

Prefer events already recorded somewhere. A trigger nobody captures is as unusable as none.

Why periods are shorter than people assume

The instinct is to keep everything in case of a claim. Claim windows are finite and generally shorter than the retention periods organisations choose.

Keeping beyond the period is not cautious. It is a growing holding of other people's information with no basis, and it is the thing that makes a subject access request expensive — because everything held must be searched.

The gap between the schedule and reality

Almost every organisation has a schedule and holds material far beyond it.

The reasons are mechanical: email is not covered, a departed system was never purged, a shared drive has no owner, a backup retains what the live system deleted.

Which is why the schedule needs a column for the deletion mechanism. A period with no mechanism is a wish.

Reviewing it

Annually, and whenever a system changes.

The useful check is not whether the schedule is correct but whether anything was actually deleted last year. Where the answer is nothing, the schedule is a document rather than a practice.

The column that makes it operate

The deletion mechanism. Automatic purge, scheduled job, or a manual task with a named owner. A period with no mechanism beside it has never caused anything to be deleted and never will.

Where schedules quietly fail

Email, shared drives and paper. The HR system purges on schedule and the other three do not, which means the organisation holds everything while possessing a document saying otherwise.

Why the periods are shorter than instinct

The instinct is to keep everything in case of a claim. Claim windows are finite and shorter than the periods organisations choose, and keeping beyond them is not caution — it is a growing holding with no basis.

Deletion as a cost saving

A subject access request searches what is held. Holding three years instead of nine makes every future request faster, cheaper and more likely to be complete — which is the unglamorous business case for the schedule.

Reviewing it annually

And whenever a system changes. The useful check is not whether the schedule is correct but whether anything was actually deleted last year — where the answer is nothing, it is a document rather than a practice.

Who should own it

Whoever can actually make deletion happen, which is usually not whoever drafted the schedule. A document owned by somebody with no access to the systems is a document that describes an intention.