Once a business learns that Microsoft 365 doesn’t back itself up, a reasonable-sounding rebuttal appears: “But Microsoft has retention policies — we can make it keep everything for seven years. Isn’t that backup?” It’s a genuinely good question, because retention policies are a genuinely powerful feature — and the answer is no, for reasons worth understanding precisely, because the two tools solve different problems and a well-run business usually needs both. Here’s the clean division.

What retention policies actually are

Retention is Microsoft 365’s compliance machinery: rules that say “content of this type must be kept for N years” (and, just as importantly, “…and then deleted”). Under a retention policy, even items a user deletes are preserved invisibly in the tenant, discoverable through compliance tools, for the policy’s duration. Litigation holds are the pointed version: freeze everything for this person or matter, indefinitely, the mechanism legal obligations run on. This is real, load-bearing capability — it’s how regulated firms satisfy books-and-records rules and how record-keeping obligations get enforced in the platform rather than by memo. If your industry has retention rules, these policies are the right tool and you should be using them deliberately.

The question each tool answers

Here’s the crisp distinction. Retention answers: “can we produce this item if asked?” — an email from 2023, a document under hold, discoverable one item at a time through compliance search, in whatever state it existed. Backup answers: “can we put everything back the way it was?” — this mailbox, this site, this whole tenant, restored to Thursday, working. Those are different capabilities with different machinery, and the gap between them is exactly where “retention as backup” fails:

  • Restoration at scale. Retention preserves items; it doesn’t reassemble them. Recovering a ransomware-scrambled OneDrive or a gutted SharePoint site from retention means compliance-searching and exporting item by item into a structure someone rebuilds by hand — technically possible the way hand-copying a library is possible. Backup restores the site, hierarchy and permissions and all, inside an RTO you’ve tested.
  • Shared fate. Retention lives inside the tenant it protects, governed by the same admin roles. The compromised or malicious admin who can damage your data can, with sufficient rights and patience, alter the policies guarding it — and a tenant-wide catastrophe (account lockout, licensing dispute, the vendor relationship itself failing) takes the retention layer down with everything else. Backup’s whole identity is independence: separate system, separate credentials, immutable copies.
  • Point-in-time. Retention keeps final and deleted states for compliance; it isn’t designed to answer “give me this site as it stood on March 4th” — which is the question corruption, bad syncs, and attack recovery actually ask.
  • Cost and license shape. Long retention everywhere inflates mailbox and storage footprints and leans on higher license tiers — it’s priced as compliance machinery, because that’s what it is. Backup storage is priced and tiered for keeping lots of history cheaply.

The right division of labor

Use each for its question. Retention policies for the obligations: regulatory record-keeping with defined periods, litigation holds, defensible deletion (the underrated half — data you’re required to dispose of shouldn’t outlive its welcome in either system), all configured deliberately rather than left at defaults, with counsel supplying the numbers where law is involved. Third-party backup for the recovery: the whole M365 estate — Exchange, OneDrive, SharePoint, Teams — captured frequently, stored independently, restorable at any scale, tested on the rotation. The overlap is smaller than it looks: retention can occasionally rescue a deleted item and backup can occasionally satisfy a discovery request, but each is clumsy at the other’s job, and the failure mode is trusting one to do both — usually discovered during whichever crisis it wasn’t built for.

The bottom line

Retention policies are Microsoft 365’s answer to “prove it and produce it”; backup is the answer to “put it back.” One is compliance, one is recovery, and they fail differently precisely because they were built for different bad days. Configure retention for the rules you’re under, run independent backup for the disasters you might meet, and never let the presence of one talk you out of the other.