Retention & Legal Hold

Retention Schedules

A retention schedule says how long a kind of record is kept and from when. It is the difference between having a retention policy and operating one.

Where to find it

Architect Panel → Data:

• Retention & Disposal — the console — what is due, what is held, what has gone
• Retention Schedules — the schedules themselves
• Record Retention — the per-record retention state
• Destruction Certificates — the evidence that disposal happened

The trigger matters as much as the period

"Seven years" is meaningless without saying seven years from what. Case closure, last activity, a child reaching 25, the end of a contract, date of death — the trigger determines the date, and choosing the wrong one is how records are destroyed years early or kept for decades.

Write the trigger down in the schedule's description as well as configuring it. The person reviewing this in five years will not be you.

Implement the schedule you already have

Most organisations already have a retention schedule written by somebody who understood the legal obligations. Implement that rather than inventing one here. Where it is ambiguous, resolve the ambiguity with whoever owns it before encoding it — a configuration is a decision, and encoding an ambiguity just hides who made it.

Review before disposal

Configure a review step for anything consequential. Disposal is irreversible, and a schedule that runs straight from due to destroyed gives nobody the chance to notice that a case is still live, subject to a complaint, or about to be needed.

The review should be a genuine look. A queue of four hundred items with an "approve all" button is not a review, so size the batches to what a person can actually assess.

Destruction certificates

What is destroyed leaves a certificate: what, when, under which schedule, authorised by whom. That record is what demonstrates the policy operates, and it is what an information request or an audit will ask for.

This is not in tension with disposal. The certificate holds the fact of destruction and its authority — not the content that was destroyed.

Worked example — a council

Planning applications are kept permanently. Complaints are kept six years from closure. Safeguarding records are kept until the subject reaches 25, so the trigger is a date of birth on the record rather than closure. Each schedule has a review step, and the reviews are worked monthly by the information governance officer in batches of no more than fifty.

Test on something safe first

Run the schedule against a small, non-sensitive category and confirm what it proposes matches what you expect. A schedule with the wrong trigger looks entirely reasonable right up until it disposes of the wrong thing — and by then there is nothing to inspect.

Recommendations

• Start in preview. Read what it would do for a full cycle before arming anything.
• One schedule per genuinely different rule, not per datastore. Two datastores with the same rule share a schedule.
• Review the schedule annually against your published policy — they drift apart quietly.
• Never disable a review step to clear a backlog. The backlog is the review working.

Legal Hold and Disposal

Legal hold suspends the retention schedule for records that must not be destroyed, however overdue they are. Disposal is what happens to everything else — and it is the only part of the platform that permanently destroys customer data.

Where to find it

Architect Panel → Data:

• Legal Holds — what is held, why, and by whom
• Retention & Disposal — the console — due, held, disposed
• Destruction Certificates — the record of what was destroyed

Hold overrides the schedule, always

Destroying records relevant to litigation, an investigation or an information request is a serious matter regardless of the fact that a schedule said they were due. Hold takes precedence, and that ordering is not configurable — deliberately.

Applying a hold

Apply it as soon as you are on notice, not when proceedings begin. The obligation usually starts when litigation is reasonably anticipated, which is earlier than most people assume — often the letter before action, sometimes the complaint that precedes it.

Record why the hold exists and who applied it. A hold nobody can explain will eventually be lifted by somebody tidying up, and that is exactly the scenario the hold existed to prevent.

Lifting a hold

Lifting is a deliberate act, and once lifted the record returns to its schedule and may become immediately due. Confirm the matter is genuinely concluded — a hold lifted while an appeal window is still open is a hold lifted too early, and the records may be gone before anyone realises.

Disposal is a real delete

Marking a record deleted is not retention. It hides the personal data from one query builder while leaving it in every backup, every export and every database administrator's reach. If your retention policy is implemented as a flag, it has not been implemented.

So disposal genuinely removes the row.

Three independent switches

Because this is irreversible, disposal sits behind three switches, and every one must be turned on deliberately:

1. The schedule must be enabled. Schedules ship disabled.
2. The task must be enabled with preview mode off. The task ships disabled, and with preview mode on — so even when enabled, its first behaviour is to report what it would do rather than do it.
3. The installation must be armed in its configuration file. This ships off.

That is not belt-and-braces theatre. A retention job running one day early, or against the wrong criteria, destroys records nobody can recover — and the first two switches are database rows that a sync, a restore or a well-meaning administrator could flip. The third lives outside the database, so restoring a backup cannot arm disposal by accident.

Two things disposal refuses to do

Both are worth knowing before you plan a disposal programme.

• It declares a gap in the audit chain. Audit rows for a disposed record are deleted too, which would otherwise leave a hole indistinguishable from tampering. Disposal therefore records that it created the gap — so the chain remains verifiable and the absence is explained.
• It refuses to dispose from a datastore whose access model depends on the audit trail. Where row-level security resolves "rows you created" by looking at audit rows, deleting those rows would silently change who can see what. Rather than altering an access model as a side effect of a cleanup job, the engine declines and tells you. Migrating record ownership is the way forward.

Related records are also never cascaded — disposing of a closed case must not delete the open case that links to it.

Documents go with the record

Disposing of a record also disposes of its documents — their versions, their files and everything recorded about them — but only where the disposed record was the document’s last link. A document shared with two live cases keeps them; only the link to the disposed record goes.

Two exceptions are deliberate: a document adopted from a file store has its ledger removed and its file left where it is, because those bytes belong to a separate library with its own lifecycle. And the destruction certificate records a count of document rows rather than naming each one. See Document Management → Document Control → Documents and Disposal.

Worked example — a legal practice

Matter files are kept for the statutory period from closure. A matter subject to a negligence claim has a legal hold applied the day the letter before action arrives, recorded against the claim reference. The retention task runs nightly in preview for the first quarter while the schedules are validated; only then is the installation armed. Destruction certificates are retained permanently.

Recommendations

• Run in preview for at least one full cycle. Read every line of what it proposes.
• Arm last, and deliberately. Treat arming as a change with an approver, not a configuration tweak.
• Audit holds quarterly. Holds that should have been lifted are as much a compliance failure as records that should have been destroyed.
• Keep destruction certificates permanently. They are the proof the policy works.