BuzbyTimeRead the requirements guide

The law, named by jurisdiction · 3.5

How long to keep any of it

How long to keep any of it. What decides it, what it costs, and what usually goes wrong. For a practical comparison point, see Monitask's Jira time tracking integration.

Two obligations pulling opposite waysThe tension

Payroll, tax and employment records generally have to be kept for a period measured in years, and the period differs by jurisdiction and by record type.

Data protection law says the opposite: keep personal data no longer than the purpose requires, and delete it afterwards. For another perspective on the surrounding workflow, see American Psychological Association.

Both apply at once. The resolution is not a single period but a schedule: each kind of record, the obligation that governs it, the period, and what happens at the end.

Different data, different periods

  • Time entries supporting payroll: the statutory payroll period.
  • Entries supporting an invoice: long enough to answer a dispute, which is usually shorter.
  • Call recordings: frequently much shorter, because the purpose is quality rather than record-keeping.
  • Quality scores: as long as they are used for coaching, and no longer.
  • Location events from a clock: the shortest of any of these, because the purpose is satisfied once the shift is verified.

Treating all of it as one category and keeping everything for the longest applicable period is the common arrangement and it is the wrong answer to both obligations at once.

Deletion is a feature

A system that cannot delete on a schedule leaves you unable to comply with the second obligation, and every year of accumulated recordings is a year more that has to be secured, disclosed on request, and produced if litigation arrives.

Ask any supplier how deletion works, whether it is automatic, and whether it covers backups. The last part is where most arrangements are incomplete.

Litigation holds

Where a dispute is anticipated, an obligation to preserve relevant records generally overrides the schedule, and continuing an automatic deletion through it can be a serious problem in itself.

Which means the system needs a way to suspend deletion for a defined set of records, and somebody needs to know it exists before the day it is needed.

Documenting the reasoning

For each period, why. Two sentences per record type, in a schedule somebody maintains.

A regulator asking why recordings are kept for a year wants the reasoning rather than the number, and an organisation that has never written it down produces a rationalisation at the worst moment.

What the person sees

The retention period applying to each kind of record is stated in the notice everybody receives.

Where a period changes, the notice is reissued rather than amended quietly.

Anonymising instead of deleting

Aggregate history is frequently the part worth keeping, and it does not require identifying anybody. Stripping the identifiers from old records preserves the trend analysis and removes the obligation.

Done properly this is a good answer. Done carelessly it is not anonymisation, because a small team's records frequently identify people by inference regardless of the name field.

Not advice

Retention periods are set by statute and differ by jurisdiction and record type. This entry describes how to think about the conflict and states no period. Take advice, and write the schedule down.

Backups

Deletion from a live system is not deletion if a backup holds it for another year. Most regulators accept that backups cannot be surgically edited, and expect a documented cycle after which the data is genuinely gone.

Ask your supplier what that cycle is. It is a specific number and it is rarely on a feature list.

The default that is wrong

Most systems ship with retention set to forever, because that is the setting that never generates a support call. Changing it is a deliberate act somebody has to perform, and in most deployments nobody does.

Reviewing the schedule

Annually, and whenever a new kind of data is collected. A schedule written at deployment and never revisited describes a system that no longer exists.

Where to write it

One table: data type, purpose, period, basis for the period, who owns it. Kept with the notice rather than in a legal folder, because the people who need to consult it are operational.

The cost of keeping everything

Storage is cheap and the other costs are not: more to secure, more to disclose on request, more to produce in litigation, and a larger loss if anything goes wrong.

Retention is a risk decision rather than a storage decision, and framing it that way usually shortens the periods considerably.

A short summary

One schedule, per data type, with the reason for each period. Automatic deletion including backups. A hold mechanism for disputes. Annual review. And a preference for anonymising history over keeping it identifiable.

What to do this week

Find out what your current retention setting is. In most organisations nobody knows, and the answer is the default.

A test of whether the schedule is real

Ask what was deleted last month. An organisation with a working retention schedule can answer, and one whose schedule exists only as a document cannot.

Deleting on request

Separately from the schedule, individuals can in some places ask for data about them to be erased, and the answer is frequently that a legal retention obligation prevents it.

That is a legitimate answer and it has to be given with the reason and the date the obligation expires, rather than as a refusal.

The simplest version that works

Three periods rather than ten: a long one for anything supporting payroll or tax, a medium one for anything supporting an invoice, and a short one for everything else.

Most organisations can map every record type onto those three in half an hour, and three enforced periods are worth considerably more than ten documented ones.

Also in the law, named by jurisdiction