There's a quiet assumption baked into most Microsoft 365 deployments: that because data exists in the cloud, and because some kind of retention policy is in place, it's protected.
It isn't. Not fully.
This isn't a criticism of Microsoft's platform — it's a genuinely powerful one. But retention tools are precision instruments designed for a specific job. When organizations treat them as a general safety net, gaps appear. And those gaps tend to surface at the worst possible times: during an audit, after a ransomware attack, or when a regulator asks for records that should exist but don't.
Let's walk through what's actually happening under the hood.
When a user deletes an email or removes a file in SharePoint, what happens next depends entirely on whether a retention policy applies to that content.
If one does, the file isn't gone. Microsoft quietly moves a copy to the Preservation Hold Library (for SharePoint and OneDrive) or the Recoverable Items folder (for Exchange). The user sees nothing. The data sits in a compliance hold until the retention period expires, at which point Microsoft can automatically dispose of it.
This is the core mechanic of Microsoft 365 data retention—and it works well, provided the policy was set up correctly in the first place.
The problem is: many weren't.
Microsoft gives you two ways to enforce retention, and the distinction matters more than most teams realize.
Retention policies work at scale. You apply them to entire services — all mailboxes, an entire SharePoint site, every Teams conversation — and they run silently in the background. They're the right tool for organization-wide baseline compliance.
Retention labels work at the item level. A specific contract, a particular project folder, a regulated document — anything that needs its own retention lifecycle regardless of where it lives or what happens to it. Labels follow the content, not the container.
The two can coexist on the same item. When they conflict — say a policy says retain for three years and a label says five — Microsoft applies a simple rule: the longer retention period wins, and retention always beats deletion. The system is designed to err on the side of keeping data, not losing it.
Understanding this priority order matters when you're auditing your own setup. A label applied years ago by someone who's since left the organization might be silently overriding your current policies.
Two failure modes dominate, and they pull in opposite directions.
Keeping too much. Without clear retention schedules tied to data type and legal requirement, organizations default to indefinite retention. It feels safe. It isn't. Every byte of data you hold unnecessarily is a byte that can be subpoenaed, a liability in a breach, and a cost on your storage bill. GDPR explicitly requires that personal data not be kept longer than necessary — indefinite retention isn't a compliant strategy under that framework.
Deleting too soon. On the other side, under-configured or missing policies can allow data to be permanently deleted before regulatory holding periods — under HIPAA, SEC rules, or industry-specific mandates — have elapsed. The consequences range from regulatory fines to an inability to respond to legal discovery.
The fix requires three things working together: clear retention schedules defined by data category, a compliance team involved in the design (not informed after the fact), and regular audits that verify policies still match current legal obligations.