Proof of Absence: Testing Retention Where It Actually Lives

Most UK organisations can produce a retention schedule. Fewer can produce evidence that a record was actually deleted on the date the schedule promised. In 2026, that gap matters more than ever: records are spread across SaaS applications, integration layers, warehouses, BI extracts, shared mailboxes and backup platforms, each with its own idea of what deletion means.

The delete button is not necessarily a rumour. But it is often a rumour inside the organisation. The policy says the record goes; the system says the record is soft-deleted; the backup says nothing at all. A half-day rehearsal is enough to replace that uncertainty with a small, defensible body of evidence.

Why a policy is not a control

A retention schedule is a statement of intent. It records what the organisation has decided to keep, for how long, and on what trigger. It does not show whether the primary application enforces the rule, whether downstream copies inherit it, or whether an exception has quietly become permanent. Nor does it show whether anyone has tested the path from trigger to deletion.

This is not a counsel to distrust every schedule. It is a counsel to distinguish between governance artefacts and operating evidence. A board can approve a policy in ten minutes. It cannot know whether the policy works unless someone has observed a deletion in the live estate.

The rehearsal below is deliberately modest. It does not attempt a full records audit. It picks three record types, traces each to every plausible storage location, and tests whether the promised delete date survives contact with real systems. The output is a one-page evidence pack and a scorecard, not a transformation programme.

The half-day shape

Reserve four hours. The group should include a data governance lead, an IT operations or platform representative, and the business owner of each record type. A privacy or legal adviser should observe, but the purpose is operational evidence rather than a legal opinion. The session works best when the participants can log into the systems or call someone who can.

Use three record types with different characteristics. For example: a lapsed customer record in the CRM; a closed recruitment candidate record in the applicant tracking system; and a resolved support ticket containing free-text notes. These differ in sensitivity, system ownership and retention trigger, which is the point. A rehearsal that only tests the easiest record type produces a misleadingly clean result.

Step one: state the deletion claim in falsifiable terms

For each record type, write the retention claim as a sentence that a test could prove wrong. Not retention is managed in line with policy, but: when the trigger occurs, the record and its copies are deleted within the stated period, except where a documented legal hold applies, and backup copies expire on a defined cycle.

The wording matters. It forces the group to name the trigger, the period, the expected scope and the exception. It also exposes ambiguity before the test begins. If the business owner and the system owner disagree about when the clock starts, that disagreement is itself a finding.

Step two: draw the estate, not the architecture diagram

Trace each record type from its primary system to every place a copy could reasonably exist. The usual candidates are integration platforms, the data warehouse, BI extracts, spreadsheets exported for a one-off exercise, shared mailboxes, ticketing tools, vendor subprocessors and backup platforms. Include analytics copies even when the data has been pseudonymised; pseudonymised personal data is still personal data.

Do not rely solely on the enterprise architecture diagram. Diagrams show intended flows. The rehearsal should confirm actual flows with system owners, query logs, integration inventories and, where possible, a small sample record. The aim is a defensible map, not a perfect one. Unknown locations should be marked unknown, not assumed absent.

Step three: test the delete date

Select a small sample of records that are already past their promised deletion date. Three to five records per type is enough for a rehearsal. Submit a deletion request through the normal process, or run the native purge function if that is how deletion is meant to happen. Then observe what occurs.

Check for soft deletion, recycle bins, retention labels, legal holds and vendor-side retention. Confirm whether the deletion propagates to downstream systems automatically, manually or not at all. For backups, establish the expiry date and the restore process: a record that cannot be restored without reappearing is not fully deleted. Record the time taken for each step and the artefact that proves it, such as a screenshot, system log, ticket reference or signed confirmation from a vendor.

Step four: read the result against a simple scorecard

A board does not need a technical account of every integration. It needs a consistent view of whether the control operated. The following six dimensions are sufficient for a first rehearsal.

Dimension	Green	Amber	Red
Claim clarity	Trigger and period documented	Partial ambiguity	No testable claim
Estate coverage	All known locations traced	Some locations unknown	Primary system only
Deletion observed	Deleted within stated period	Deleted manually after chase	Not deleted or no evidence
Downstream propagation	Automatic and evidenced	Manual step evidenced	No propagation test
Backup position	Expiry date confirmed	Process described only	Unknown
Ownership	Named owner and next test date	Owner named only	No owner

Green means observed in this rehearsal, not asserted in a policy. Amber means the control depends on a manual step or an unverified process. Red means the organisation cannot yet demonstrate deletion for that record type. A mixture of colours is normal and more useful than an all-green scorecard produced without testing.

What the board should ask

The useful board question is not whether the organisation has a retention policy. It is when deletion was last proven for a specific record type, what the test found, and who is accountable for the exceptions. Directors should also ask which systems cannot delete records and why, what residual copies remain in backups and analytics environments, and what remediation date has been agreed.

These questions keep the conversation on evidence. They also avoid overclaiming. A successful rehearsal does not certify regulatory compliance; it demonstrates that a control has been tested in a defined scope. That is a more honest and more useful position than a policy attestation alone.

The output is a repeatable habit

Close the session with a one-page evidence pack: the claim tested, the estate map, the sample records, the observed result, the exceptions, the remediation owner and the next test date. Add it to the data governance forum's standing agenda and repeat the rehearsal quarterly with different record types. Over a year, the organisation builds a traceable record of operational testing rather than a library of policy statements.

The delete button may well exist. The rehearsal is how an organisation stops treating that as a rumour and starts treating it as a control.