Building a retention schedule and a records governance framework

Most organisations do not have a retention problem. They have a classification problem that presents as a retention problem. Nobody can say how long a document should be kept because nobody has established what kind of record it is, which function it belongs to, or whether the copy in front of them is the record at all or one of eleven convenience copies of it.

The framework below is the standard structure of that work. It applies equally to paper and digital records, which is the point: a retention schedule that only governs the filing room while a shared drive grows unchecked is not a retention schedule.

Step one: inventory what exists

An inventory is not a list of documents. It is a list of record groupings, captured at whatever granularity the organisation actually manages them. For each grouping, record what it is, which business function creates it, where it lives, what format it is in, how much of it there is, who owns it and who can access it.

Do this by talking to the people who create and use the records, not by reading the org chart. The most common discovery in this phase is not a missing record type. It is that the same record exists in four places under four names, and that the version everyone treats as authoritative is not the one in the official repository.

Step two: classify into record series

A record series is a group of records that share a purpose, arise from the same activity, and can therefore be retained and disposed of as a unit. Classify by function and activity rather than by department, because departments reorganise and functions do not. A scheme built on the current org chart is obsolete after the next restructure, and every record in it becomes an orphan.

Two distinctions make classification tractable.

• The record versus the copy. One instance of a document is the official record, subject to the schedule. The rest are convenience copies with a short working life and no independent retention. Naming the official copy for each series removes most of the ambiguity people struggle with in practice.
• Transitory material versus records. Drafts, duplicates, routing notes and superseded working files are not records of the activity. They need a stated rule, because in the absence of one people keep everything, and keeping everything is itself a risk rather than a safe default.

Step three: find the retention driver for each series

Every retention period has a reason. Writing down the reason next to the period is what makes a schedule defensible, and it is what allows the schedule to be maintained when something changes, because you can see which entries are affected.

Where drivers conflict, the longest applicable period governs the series. Where a series contains records with genuinely different drivers, that is a signal the series is drawn too broadly and should be split.

Step four: define the trigger, not just the period

This is the step most often skipped, and skipping it makes a schedule unimplementable. A retention entry has two parts: a trigger event that starts the clock, and a period that runs from it. Without the trigger, nobody can calculate a disposal date and the schedule sits unused.

• Common triggers include end of the financial year in which the record was created, termination or expiry of a contract, completion of a project, end of an employment relationship, closure of a matter or case, and disposal of the asset the record relates to.
• The trigger must be a data point the system actually holds. A rule keyed on contract end date is only enforceable if contract end date is an index field. This is precisely why classification and retention belong in the indexing schema, agreed before digitization rather than bolted on afterwards.
• Some triggers are open-ended by nature. A personnel file whose clock starts at end of employment cannot be scheduled while the person is employed, so the system must hold the record in a pending state rather than assigning it a false date.
• Record the trigger, the period, the driver and the source in the schedule itself. An entry consisting only of a number is impossible to audit and impossible to maintain.

Legal hold overrides everything

When litigation, an investigation, an audit or a regulatory request is reasonably anticipated, relevant records must be preserved regardless of what the schedule says. A hold suspends disposition. It does not shorten or extend the underlying period, which resumes when the hold is lifted.

Mechanically, a working legal hold process needs five things: a defined trigger for when a hold is issued and by whom, a written notice to the custodians who control the relevant records, a technical block that prevents scheduled destruction from running on the held set, a record of what was held and when, and a formal release step. Holds that are issued and never released are a common and quiet failure. They accumulate until the organisation is effectively retaining everything, which recreates the original problem under a different name.

One practical point specific to digitization: if records are being scanned while a hold is live, the hold covers the physical originals as well as the images. Destruction of originals after scanning must be blocked for anything within a hold's scope, and the provider needs to be told which boxes those are.

Disposition is more than destruction

At the end of a retention period a record has one of three outcomes: secure destruction, transfer to permanent archive, or a documented review that extends retention for a stated reason. All three are disposition. Only one is deletion.

• Destruction should be authorised by the record owner, executed against a defined list, and evidenced by a certificate identifying what was destroyed, on what date, by what method and under whose authority. The certificate is retained after the records are gone, and is frequently the only proof that disposal was deliberate rather than accidental.
• Digital destruction needs the same rigour as paper, and is harder. Backups, replicas, cached copies, previous versions and copies held in personal drives all need to be in scope, or the record is not destroyed in any meaningful sense.
• Permanent records need active preservation: stable formats, integrity checks over time, and a migration plan when a format ages. Permanent retention with no preservation plan tends to mean permanent retention of files nobody can open.
• Apply disposition on a schedule and log every run. A retention schedule that is never executed provides no benefit and, having been written down, is arguably worse than none.

Where digitization fits

Scanning does not resolve a retention question. It changes the format of the record and, if planned well, makes the schedule enforceable for the first time by putting classification and trigger data into index fields that a system can act on.

The question that always arises is whether the paper can be destroyed once it has been scanned. That is not a scanning question. It depends on whether a record class must be retained in original form and on what evidential weight the image carries in your context, and both must be confirmed with your own legal advisers before any originals are destroyed. What a digitization programme can do is make the answer easy to act on: capture to a preservation-grade format, keep an auditable chain of custody from shelf to file, record classification and trigger fields at indexing, and hold originals pending an explicit written instruction rather than destroying them by default.

Review the schedule on a fixed cycle and after any material change to the business, its structure or its regulatory environment. A schedule reviewed once at creation describes an organisation that no longer exists.