Silence Is Not Compliance: Field-Testing Retention Automation Before the Regulator Does

Retention automation is often managed as a configuration exercise. A label is created, a policy is published, a disposition review is enabled, and the organisation records that deletion is under control. Yet a rule that never fires produces no error ticket and no user complaint. It simply leaves records in place. For UK data governance teams, the assurance question in 2026 is not whether retention rules exist, but whether they execute, across every workload in scope, with evidence that can be shown to a regulator.

The assurance gap between configuration and execution

Most retention programmes can demonstrate intent. They can show a policy document, a label taxonomy and a screenshot of an administrative centre. Far fewer can show that a record past its retention date was actually disposed of, that the disposition was authorised, and that the remaining copy was removed from secondary locations. This gap matters because the Information Commissioner's Office expects accountability to be demonstrated, not asserted. Under the UK GDPR and the Data Protection Act 2018, personal data must not be kept longer than necessary. A retention rule that is configured but dormant is not a control; it is a statement of hope.

Silent failures are particularly dangerous because they are invisible in ordinary reporting. The retention dashboard may show a policy as active while its scope excludes the very sites that hold the oldest records. A disposition review queue may be empty because no items have reached the review stage, not because disposal is timely. A shared drive may sit outside the retention estate entirely. The audit should therefore begin with a simple premise: absence of evidence of execution is a finding, not a clean result.

A sample-based evidence method

A defensible audit tests three proofs: configuration, operation and outcome. Configuration confirms that the rule exists and is correctly scoped. Operation confirms that the relevant jobs, labels and review workflows are functioning. Outcome confirms that a record past its retention period has been disposed of, or that a lawful reason for retention has been recorded.

The first step is to build a population inventory. For Microsoft 365, this means Exchange mailboxes, SharePoint sites, OneDrive accounts, Teams channels and any records-management workloads in use. For shared drives, it means file servers, network attached storage and departmental repositories, including legacy areas that may have been omitted from the original programme. The inventory should record owner, location, estimated volume, retention rule and whether the location is in scope.

The second step is to define a sampling frame. A purely random sample may miss high-risk pockets, so a stratified approach is preferable. Strata might include workload type, business unit, record category and known legal-hold status. Within each stratum, select a judgmental sample of records known or suspected to be past retention, supplemented by a random sample to test the general population. Document the rationale for the sample size and selection method. The aim is not statistical perfection but a repeatable, proportionate and explainable test.

The third step is to gather item-level evidence. For each sampled record, record the retention rule that should apply, the expected disposal date, the actual location, the label or policy applied, the relevant audit log entry, and the disposition outcome. Where a record remains, establish why: is it under a legal hold, subject to a disposition review, awaiting an event trigger, or simply missed? Non-destructive verification is essential. Test records can be used in controlled areas, but live records should be inspected read-only. The audit should also test secondary locations, including recycle bins, version history, backups and user downloads, because disposal is not complete if copies remain elsewhere.

Common failure modes in Microsoft 365 and shared drives

In Microsoft 365, silent failures often arise from scope and labelling. A retention policy may cover Exchange but exclude inactive mailboxes belonging to former employees. An adaptive scope may be stale, so new departments are not included. A default label may be absent, leaving users to classify records manually. A retention label may be overridden by a preservation hold, or a disposition review may stall because the named reviewer has left the organisation. Event-based retention can fail quietly if the triggering event is never recorded. Licensing changes can also remove the functionality that the policy depends on, while the policy continues to appear active.

Shared drives present a different profile. Retention is often implemented through scripts that rely on last-modified dates, but access or modification by an administrator can reset the clock. File server areas may never have been included in the retention estate. Duplicate copies, offline media and user-controlled archives can retain personal data long after the primary record has been deleted. Permission changes can also obscure ownership, making it difficult to confirm whether a record should be retained or disposed of. These are not hypothetical edge cases; they are routine findings in inherited estates.

The remediation log that can withstand scrutiny

A remediation log should be more than a list of defects. It should provide a defensible narrative of what failed, why it matters, what was done and how closure was verified. Each entry should record a unique identifier, the rule or control affected, the scope and population affected, the failure mode, the evidence gathered, the estimated number of records involved, the risk rating, the accountable owner, the interim control, the remediation action, the target date, the retest date and the closure evidence.

Risk rating should reflect the sensitivity of the data and the likelihood of regulatory or operational harm. Records containing special category data, records subject to a legal hold, and records relevant to a subject access request should be prioritised. Interim controls might include manual deletion, restricted access or a documented hold pending remediation. Closure should not be declared until a retest confirms that the rule now executes and that secondary copies have been addressed. The log should be reviewed at governance forums and retained as evidence of accountability.

From audit to operating rhythm

The field audit should not be a one-off exercise. Retention automation requires a routine of job-health checks, quarterly sample testing and an annual independent review. Material changes to systems, licences, organisational structure or retention rules should trigger a targeted retest. A dashboard of silent failures, open remediation items and overdue disposition reviews gives senior management a more honest picture than a list of active policies.

The ICO does not expect perfection. It expects organisations to know their estate, to test their controls, to record failures and to remediate them proportionately. A retention rule that never fired is not a technical curiosity. It is a governance finding waiting to be discovered. The organisation that discovers it first, and can evidence the response, is in a stronger position than one that relies on the quiet of an unexamined system.