A Controlled Deletion: Proving Microsoft 365 Retention Works Before the Regulator Asks

UK GDPR does not merely ask whether a business has a retention policy. It asks whether personal data is kept no longer than necessary, and whether the business can show it. When a subject access request lands, the statutory clock gives you one month, and the requester is entitled to know what you hold — including material you believed had been deleted. The gap between what the policy says and what Microsoft 365 actually does is where most small firms come unstuck.

That gap is rarely a failure of intent. It is a failure of verification. A retention label configured in Purview and a retention outcome observed in a mailbox are two different things, and only one of them is evidence.

Four mechanisms that sound identical in a meeting

Ask a supplier or an IT manager how deletion works and you will usually hear one answer covering four distinct systems:

• Retention labels, which can retain and then delete content, or treat it as a record that users cannot remove.
• Retention policies, which apply at service level — all Exchange mailboxes, all SharePoint sites — without the user ever seeing a label.
• Holds, including eDiscovery preservation holds and the older litigation hold, which suspend deletion for named custodians.
• Native platform windows, such as the Exchange recoverable items folder and the SharePoint recycle bins, which keep deleted content for a fixed period regardless of any policy.

These interact, and the precedence rules matter. A hold beats a deletion instruction: if a mailbox is on hold, the retention label will preserve the item and the deletion will not occur, however confident the policy document is. A test that exercises only one mechanism will tell you only one thing.

Designing a test that costs an afternoon

You do not need a separate tenant. You do need to keep the exercise away from live records.

1. Create a test site and a test mailbox. A SharePoint site called something unglamorous — retention-test — and a licensed test account are enough. Do not use a departing employee's mailbox for this.
2. Create a test label with a short retain-then-delete period, and a second label that classifies content as a record. Publish them to the test location only.
3. Place sample content. Two documents and a handful of emails, none containing personal data. Give each a predictable name so the results are unambiguous.
4. Configure a hold on a second test mailbox, apply the same label, and delete the sample message. This is the test most firms skip, and it is the one that proves whether your legal hold actually overrides your retention settings.
5. Record the baseline before anything happens: an export of the label configuration, a screenshot of the published locations, and the date the clock started.

The configuration export is worth doing properly rather than by screenshot. From the Security and Compliance PowerShell module:

Get-RetentionCompliancePolicy -DistributionDetail | Export-Csv .\policies.csv -NoTypeInformation
Get-RetentionComplianceRule | Export-Csv .\rules.csv -NoTypeInformation

Those two files, dated and stored with the test report, do more for you than a paragraph of assurance in a policy document.

Reading the result without flattering yourself

Allow for processing time. Microsoft does not delete at the instant the retention period ends; deletion is processed in the background and can take several days. A label set to delete at 30 days should be read at day 40, not day 31, or you will draw the wrong conclusion and then argue with your own evidence later.

At the end of the window, check four things:

• Does the item still exist in the test library or mailbox? Search for it explicitly rather than trusting the recycle bin view.
• If it is gone from the user's view, is it still recoverable — and by whom? Search the recoverable items area and the site collection recycle bin.
• Where a hold was in place, is the item still present and retrievable through eDiscovery content search?
• Does the audit log corroborate the sequence of events with timestamps?

Then attempt a restore and record whether it succeeded. A restore attempt is the difference between a theory of recoverability and a demonstration of it.

Expect one of three outcomes. A clean pass is the least common on a first attempt. A partial pass — deletion works, holds do not, or the reverse — usually points to a label that was published but never applied, or a policy scoped to the wrong location group. A flat failure, where nothing happens at all, nearly always traces back to an auto-apply rule that never matched, a label that relies on users to apply it manually, or a licensing tier that does not include the feature the design assumed. Trainable classifiers and some auto-apply conditions sit above the entry-level plans; confirm entitlements before writing them into a policy.

The other direction: over-retention is also a finding

Retention reviews in small firms tend to concentrate on premature deletion. The more common problem is the opposite. Content accumulates because nobody applied the label, because the default was 'keep indefinitely', or because a hold was placed in 2021 and never lifted. That data remains disclosable, remains subject to access requests, and remains a liability in any dispute. A retention test that only checks deletion has examined half the question.

Writing it down so it survives scrutiny

Produce a one-page test report: scope, configuration evidence, dates, observations, outcome, and the name of the person who signed it off. Attach the PowerShell exports, the audit log extract and the screenshots. Store it with your data protection records rather than in a project folder that will be archived at the end of the financial year.

Three conditions should trigger a re-test: a change of licensing tier, a material change to the retention design, and any tenant-to-tenant migration. Add an annual review to the data protection calendar regardless.

Finally, make sure the privacy notice matches what you have proven. If deleted items persist in backups for a defined period, say so. If a hold means content will be kept beyond the stated period, say so. A short, accurate statement is defensible; an aspirational one is not.

A short checklist

• Test labels, policies and holds separately, then together.
• Use non-sensitive samples and a dedicated test location.
• Export configuration as evidence, not just screenshots.
• Read results after processing delay, not on the day the period ends.
• Attempt a restore and record the outcome.
• Check for over-retention as well as under-retention.
• Align the privacy notice with what the test proved.
• Date, sign and file the report; diarise the re-test.

The delete button is a promise. Until you have watched it happen to a file you control, in a location you scoped, against a hold you configured, it is only a promise — and a subject access request is an unkind moment to discover which kind.