Table of contents
- Microsoft 365 data retention vs backup: the difference in one page
- What Microsoft 365 data retention actually does
- The native windows people mistake for a backup
- Where Microsoft 365 data retention stops and backup starts
- Five failures that retention will not save you from
- What Microsoft 365 data retention is genuinely better at
- Licensing and cost: what each side really needs
- Configuring Microsoft 365 data retention without creating new risk
- Building the backup half properly
- A decision framework: which do you need, and when
- A 30-day plan to close the gap
- Final thoughts: two tools, two jobs
Microsoft 365 data retention vs backup: the difference in one page
Microsoft 365 data retention is not a backup, and the gap between those two ideas is where most avoidable data loss in UK businesses actually happens. Both features keep information alive beyond the moment somebody presses delete. Only one of them is designed to hand that information back to you quickly, in the shape you need, when something has gone badly wrong.
The confusion is understandable. Microsoft 365 data retention is built into the platform, it is visible in the admin centre, and it uses reassuring words like preserve, hold and immutable. A finance director who reads that sentence reasonably concludes the data is safe. The distinction only surfaces during an incident, which is the worst possible moment to discover it.
What Microsoft 365 data retention is designed to do
Microsoft 365 data retention exists to stop data disappearing before you are legally or contractually allowed to let it go, and to make sure it does disappear once that obligation ends. It is a compliance control. It answers the question “are we still holding this, and should we be?”
What a backup is designed to do
A backup exists to put working data back where it belongs after a loss event. It is an operational control. It answers a completely different question: “how fast can we return to the state we were in on Tuesday morning?”
The sentence that settles most arguments
Retention preserves; backup restores. Microsoft 365 data retention guarantees a copy continues to exist somewhere the compliance tooling can find it. It makes no promise at all about how quickly a service desk can put 4,000 files back into the right SharePoint library with permissions intact.
Why the confusion is so expensive
Because it is only ever tested under pressure. A business that has confused the two discovers the truth during a ransomware event or after a departing employee clears out a mailbox, when the honest answer to “can we get it back?” turns out to be “eventually, item by item, through a legal search tool.”
What Microsoft 365 data retention actually does
Understanding the mechanics matters, because the mechanics are what determine the limits. Microsoft 365 data retention is not one feature but a family of them, administered largely through Microsoft Purview, and each behaves slightly differently depending on the workload it is applied to.
Microsoft 365 data retention policies, labels and settings
A Microsoft 365 data retention policy is applied broadly to a location: all Exchange mailboxes, all SharePoint sites, all OneDrive accounts, Teams chats and channel messages. A retention label is applied to individual items or, through auto-labelling, to items matching a rule. Policies are the blunt instrument, labels the precise one, and most tenants need both.
The Preservation Hold Library and where copies really live
When a policy covers a SharePoint site and someone deletes a file, the file is copied into a hidden Preservation Hold Library inside that same site collection before the deletion completes. That copy is what Microsoft 365 data retention is actually protecting. It is invisible to ordinary users, it consumes tenant storage, and it lives inside the same tenant as the original.
Recoverable Items and the mailbox equivalent
Exchange Online does the same job with the Recoverable Items folder, which holds deleted messages and the versions of items edited while a hold is active. It has a storage quota. When a mailbox is under aggressive Microsoft 365 data retention and generating lots of edits, that quota is a real operational concern rather than a theoretical one.
Static and adaptive scopes
A static scope names the locations directly and needs maintenance every time the business changes shape. An adaptive scope queries directory attributes, so a policy can follow a department or a country automatically. Adaptive scopes are the right default for anything you expect to still be running in three years.
Retain, delete, or both
A policy can retain for a period, delete after a period, or retain and then delete. That third option is the one that does real compliance work, and it is also the one that quietly destroys data if the period was set by somebody who did not know what the business needed. Microsoft’s own documentation on retention policies and retention labels is worth reading before anybody touches a live tenant.
The native windows people mistake for a backup
Every one of the features below is genuinely useful, and none of them is a backup. These are also the controls most often confused with Microsoft 365 data retention itself, even though they operate on entirely separate timers. The reason none of them qualifies is always the same: each is a timer, and timers expire.
The two-stage recycle bin in SharePoint and OneDrive
A deleted file sits in the site recycle bin, then in the second-stage collection bin, for a combined window that ends at 93 days. That number is fixed and cannot be extended. Ninety-three days sounds generous until you consider how long a quietly corrupted folder can go unnoticed in a department that only touches it at year end.
Version history is not a point in time
Version history is per file. Restoring one document to last month’s version is trivial. Restoring 60,000 documents across four libraries to a consistent moment before an event is not something version history is built to do, and the effort scales linearly with the damage.
Deleted mailbox and deleted user timers
Delete a user in Microsoft 365 and the account is soft-deleted for 30 days, with the mailbox recoverable in that window. Miss it and the mailbox is gone unless a hold or an inactive-mailbox configuration was already in place beforehand. The word beforehand is doing an enormous amount of work in that sentence.
Teams data lives in three places at once
Teams is not a storage location in its own right. Channel messages sit in a group mailbox, chat messages in user mailboxes, files in SharePoint, and wikis somewhere else again. Applying Microsoft 365 data retention to Teams properly means covering several underlying services, and it is very easy to cover three of them and believe you have covered all four.
Every native window expires
That is the honest summary. Recycle bins, version limits, soft-delete timers and recoverable-items quotas are all bounded by the platform. Microsoft 365 data retention lets you extend preservation well past those defaults, which is exactly why it gets mistaken for a backup — but a backup’s retention is a commercial decision you make, and a native window is a default you simply live with.
Where Microsoft 365 data retention stops and backup starts
If you take one section from this guide, take this one. These are the five points at which Microsoft 365 data retention hands the problem over to something else entirely. They are consistent, they are structural, and no amount of configuration closes them.
Preservation is not restoration
Content held by a Microsoft 365 data retention policy is preserved and discoverable. Getting it back into production is a separate exercise, usually through eDiscovery: build a case, run a search, review, export to PST or a download package, then re-import. That is a legal workflow with a legal workflow’s timescales, not a recovery button.
Granularity: the item you need versus the search you run
Backup software restores a site, a library, a mailbox or a single item to a chosen point in time, with metadata and permissions preserved. Microsoft 365 data retention gives you a search result. Those are very different products, and the difference is felt most acutely when the person asking is a director who wants everything back by lunchtime.
Independence and blast radius
The copy that Microsoft 365 data retention creates lives in the same tenant, under the same identity system, reachable by the same global administrator accounts. If the threat is a compromised admin, a rogue insider, or a tenant-wide error, that preservation copy shares the blast radius. A backup in a separate storage account with separate credentials does not. Our note on Microsoft 365 security audits covers the identity side of this in more depth.
Speed: eDiscovery time versus recovery time
Nobody sets a recovery time objective in eDiscovery. Search, review and export are measured in hours to days depending on volume, and the process typically needs a compliance-licensed administrator rather than a first-line engineer. A backup restore is measured against an objective you agreed in advance and can rehearse.
Portability and exit
Microsoft 365 data retention keeps your data safe inside Microsoft’s platform. It does not give you an independent, readable copy you could hand to a new provider or use if the tenant itself became unavailable. That matters more than people expect during a provider change — a point we cover in leaving an IT provider.
Five failures that retention will not save you from
The five scenarios below are the ones that turn an abstract policy discussion into an emergency. In each case Microsoft 365 data retention behaves exactly as designed, and the business still loses working data.
Ransomware and mass encryption in the tenant
Encrypted files sync as new versions of legitimate files. Microsoft 365 data retention preserves them faithfully, because from the platform’s point of view nothing was deleted. Recovery means rolling thousands of items back through version history or restoring from an independent copy taken before the encryption began.
Microsoft 365 data retention misconfigured or switched off
A retention policy is configuration, and configuration can be wrong. A retain-then-delete rule with the wrong period will destroy data exactly as instructed, on schedule, with a full audit trail proving it was authorised. The platform has no concept of “that was probably a mistake.”
The admin mistake that removes the container
Deleting a Microsoft 365 group removes the connected site, mailbox and Teams presence together. Recovery windows exist, they are short, and they depend on nobody having recreated an object with the same name in the meantime.
A third-party app with write access
An application granted delegated permissions can bulk-modify or bulk-delete content at machine speed. Microsoft 365 data retention will preserve what it is scoped to preserve, but reversing the change across a tenant is a restore job, not a search job.
Tenant lockout and account compromise
If administrative access itself is the thing that has been lost, every in-tenant control is temporarily out of reach. This is the scenario that most clearly separates a compliance control from a disaster recovery control, and it is the one a managed IT services provider should already have an answer for.
What Microsoft 365 data retention is genuinely better at
This guide is not an argument against retention. Microsoft 365 data retention does several jobs that no backup product does well, and a business that buys backup and ignores retention has simply swapped one gap for another.
Legal hold and litigation readiness
When litigation is reasonably anticipated, you must preserve relevant content in a defensible, auditable way. Microsoft 365 data retention and eDiscovery hold do this properly, inside the platform, with the audit trail a court expects. A backup copy is not a defensible legal hold.
Records management and immutability in place
Records declaration, disposition review and immutable labelling let you prove a document could not be altered during its retention period. That is a compliance capability, and it sits entirely on the Microsoft 365 data retention side of the line.
Storage limitation under UK GDPR
Personal data must not be kept longer than necessary. Deletion policies are how you demonstrate that, and the ICO’s guidance on storage limitation is the reference point. Our UK GDPR checklist for small businesses translates that into practical steps.
Deleting on purpose, not by accident
Most organisations are better at keeping things than disposing of them. Microsoft 365 data retention is the only mechanism in the stack that deletes deliberately, on a schedule, with evidence. Backups, by design, work against that instinct.
Keeping data discoverable where it lives
Held content stays searchable in place through the compliance portal. For a subject access request or a regulatory enquiry, that is far more useful than a backup archive nobody can index without restoring it first.
Licensing and cost: what each side really needs
Budget conversations stall because the two controls are priced on completely different models. Microsoft 365 data retention is bundled into licence tiers, while backup is bought per user or per unit of storage, so a like-for-like comparison is not available.
What Microsoft 365 data retention needs in licence terms
Basic policies are available broadly, but the capabilities most businesses actually want — auto-labelling, adaptive scopes, records management, advanced eDiscovery — sit in the higher tiers or in a Purview add-on. If a licence review is on your list anyway, our guide to Microsoft 365 licensing sets out where those features fall.
What Microsoft’s first-party backup covers and charges
Microsoft now sells its own backup service for Exchange, OneDrive and SharePoint, priced on consumption. It restores fast because the data never leaves Microsoft’s estate, which is also precisely why it does not give you independence from the tenant.
Typical third-party backup pricing
Third-party Microsoft 365 backup generally lands in a low single-digit pounds-per-user-per-month range, varying with retention length, storage location and whether Teams and Entra ID are included. Ask what happens to the data if you cancel, and get the answer in writing.
The cost that never appears on a quote
The real number is the cost of the outage. Staff time lost, deadlines missed, customer confidence damaged and the professional fees involved in reconstructing records almost always exceed several years of subscription for either product.
Configuring Microsoft 365 data retention without creating new risk
Badly planned Microsoft 365 data retention introduces risks of its own: data destroyed on schedule, storage consumed invisibly, and policies nobody can explain to an auditor. These five habits prevent most of that.
Start from a retention schedule, not from the console
Write down what categories of information the business holds, how long each must be kept, and why. Configure to that document. Building policies directly in the admin centre without a schedule behind them is how tenants end up with overlapping rules nobody can explain.
Choose scopes deliberately
Prefer adaptive scopes tied to directory attributes so policies survive reorganisation. Where a static scope is unavoidable, put a calendar reminder against it, because the risk is not that it breaks loudly but that it silently stops covering new locations.
Understand what happens on conflict
Retention wins over deletion, the longest period wins, and an explicit label beats an inherited policy. Knowing these principles prevents the common surprise of data persisting long after somebody believed a policy had removed it.
Watch the interaction with deletion requests
An erasure request under UK GDPR can collide with an active Microsoft 365 data retention obligation. Decide in advance how you reconcile the two and record the reasoning, because you will be asked to justify it. This belongs in your IT governance documentation rather than in an engineer’s head.
Document who can change a policy
Changing Microsoft 365 data retention should require the same approval as changing a firewall rule. Restrict the role, log the changes, and review them periodically.
Building the backup half properly
Once Microsoft 365 data retention is doing its compliance job, the backup half needs the same deliberate treatment rather than whatever the first quote in the inbox happens to include.
The workloads to insist on
Exchange Online, OneDrive, SharePoint Online and Teams are the minimum. Entra ID objects, Planner and Power Platform data are the commonly forgotten extras. Map coverage against that list before comparing prices, because a cheap product with three workloads is not cheaper than a complete one.
Recovery point and recovery time objectives
Decide how much data you can afford to lose and how long you can afford to be without it, per workload. These two numbers drive backup frequency and restore design more than any feature comparison will. Our companion guide on Microsoft 365 backup works through the workload-by-workload detail.
Immutability and separate credentials
Backup storage should be immutable for its retention period and reachable only with credentials that are not tenant administrator accounts. If a compromised global admin can delete the backup, the backup is part of the same failure domain as the thing it protects.
Data residency for UK businesses
Confirm where the backup copy physically sits and name that location in the contract. For regulated sectors and public-sector tenders this will be asked about directly, alongside your wider security position.
Testing a restore is the only proof
An untested backup is a hypothesis. Restore something real every quarter, time it, and write the time down. The number you record is your actual recovery time objective, whatever the contract claims.
A decision framework: which do you need, and when
Very few businesses need to choose, but the balance of investment between Microsoft 365 data retention and backup does legitimately vary. Use the tests below rather than a vendor’s risk score.
When Microsoft 365 data retention alone is defensible
A very small organisation, with low data volumes, no regulatory exposure and a genuine tolerance for losing recent work, can run on native controls. That position should be a documented decision signed off by somebody senior, not an assumption nobody has examined.
When backup becomes non-negotiable
Regulated data, contractual recovery commitments, cyber insurance requirements, meaningful headcount turnover, or a board that would find a week-long outage unacceptable. Any one of those makes independent backup the correct answer.
How the two should be documented together
One page, two columns: what Microsoft 365 data retention covers and for how long, and what backup covers and for how long. Gaps become obvious immediately, and the page doubles as evidence for insurers and auditors.
Questions to put to your IT provider
Ask which policies exist today and who approved the periods. Ask where backups are stored and under which credentials. Ask for the date and duration of the last successful test restore. Vague answers to that third question are the most informative result you can get.
A 30-day plan to close the gap
Closing the gap is a documentation exercise far more than a purchasing one, and a month of deliberate effort is enough to know exactly where Microsoft 365 data retention ends and your real recovery capability begins.
Week one: find out what is actually configured
Export the current policies and labels, note every period and scope, and confirm whether any backup product exists at all. Most businesses find at least one surprise in this step.
Week two: write the retention schedule down
Agree categories and periods with the people who own the data rather than the people who administer it. Reconcile the schedule against what Microsoft 365 data retention is currently configured to do and list the differences.
Week three: prove a restore
Pick a real library and a real mailbox and recover them. Record how long it took and who was needed. If the only available route was eDiscovery, you have just measured your gap precisely.
Week four: document and hand over
Produce the two-column page, assign an owner, set a review date, and put the test restore into a recurring calendar. Documentation that nobody owns decays within a year.
Final thoughts: two tools, two jobs
Microsoft 365 data retention and backup are not competing products, and choosing between them is the wrong exercise. Retention answers to your lawyers and regulators; backup answers to your operations team on the worst day of the year. A business that funds one and neglects the other has covered half of a problem while believing it has covered all of it.
The practical move is unglamorous. Write down what you keep and why, configure Microsoft 365 data retention to match that document, add an independent backup for the workloads you could not run without, and prove once a quarter that a restore works. That is a small amount of ongoing effort set against the single largest avoidable risk in the platform most UK businesses now run their entire working day inside.
