Ask three IT managers whether their business has a Microsoft 365 backup and you will get three different answers, all of them delivered with confidence. One will say Microsoft handles it. One will say the retention policy covers it. The third will say the managed IT services provider takes care of it. Only one of those answers can be verified, and in most businesses nobody has checked which.

That gap matters because the thing people are picturing when they say backup — a separate copy of a mailbox, a site or a Teams channel, held outside the live system, restorable to a chosen point in time — is not what Microsoft provides as standard. Microsoft keeps the service running and keeps your data available. It does not keep an independent copy for you to roll back to after somebody deletes the wrong SharePoint library in March and nobody notices until June.

This guide sets out exactly where the line sits: what Microsoft genuinely protects, what the native retention features do and do not do, and what your business must back up itself. It covers every workload, the evaluation criteria for a Microsoft 365 backup solution, the recovery objectives to set, and the mistakes that turn a recoverable incident into a permanent loss.

Table of contents

What Microsoft Actually Protects in Microsoft 365

microsoft 365 backup what your business must back up b split platform with shield on one half and vault on the other

Microsoft protects the platform. That is a real and substantial commitment, and it is not the same commitment as protecting your content. Understanding the split is the whole foundation of a sensible Microsoft 365 backup decision.

The shared responsibility model in plain terms

Microsoft is responsible for the physical infrastructure, the datacentres, the network, the hypervisors, the application code and the availability of the service. You are responsible for your data, your identities, your access controls and your device configuration. Microsoft documents this split openly; it is not hidden in small print. The practical translation is simple: Microsoft guarantees you can reach your data, not that your data is still what you expect it to be.

Availability is not the same as recoverability

The financially backed service level agreement covers uptime. It says nothing about the contents of a mailbox after a user empties it, or about a SharePoint document library after an automation script overwrites four thousand files. Those events are not service failures. The platform did exactly what it was asked to do, by an authenticated account, and the platform has no way of knowing the request was a mistake.

Geo-redundancy is not a Microsoft 365 backup

Microsoft replicates your data across multiple datacentres so that a hardware failure or a site outage does not lose it. Replication is a resilience feature, and it works in both directions: a deletion replicates just as faithfully as a creation. A copy that mirrors every change instantly is not a Microsoft 365 backup, because there is no earlier state to return to.

What Microsoft itself recommends

Microsoft’s own guidance for customers points at the same conclusion this article does. The shared responsibility material advises organisations to protect their own content, and the platform’s third-party marketplace is full of Microsoft-certified backup vendors for exactly that reason. If a Microsoft 365 backup were unnecessary, that market would not exist and Microsoft would not have built a first-party product to compete in it.

The Native Features People Mistake for a Microsoft 365 Backup

microsoft 365 backup what your business must back up c hourglass beside a row of fading data cubes

Microsoft 365 has a genuinely useful set of retention and recovery tools. They rescue a great many everyday mistakes. The problem is not that they are weak — it is that they are frequently mistaken for a complete Microsoft 365 backup when they are something narrower.

Deleted items and the Recoverable Items folder

When a user deletes a message it goes to Deleted Items. When they empty that folder, the item moves to Recoverable Items, where by default it is retained for fourteen days. An administrator can extend that window to thirty days. Beyond that, the item is purged. Fourteen days is shorter than most people assume and much shorter than the time it typically takes to notice a quiet deletion.

The SharePoint and OneDrive recycle bins

Deleted files go to a first-stage recycle bin, and from there to a second-stage bin that a site administrator can reach. The total window across both stages is ninety-three days. A deleted site is also retained for ninety-three days before it is removed permanently. Ninety-three days is generous compared with Exchange Online, but it is still a fixed clock that starts without anyone being told.

Version history in document libraries

Document libraries keep previous versions of files — five hundred major versions by default in SharePoint and OneDrive — which makes overwrites and unwanted edits easy to undo. Version history is excellent for content that still exists. It is no help at all once the file, the library or the whole site has gone, because the versions live inside the item they belong to.

Retention policies and litigation hold

Purview retention policies and litigation hold preserve content so that it cannot be permanently removed, even by the user who owns it. This is a compliance control, and it works. What it does not give you is a restore. Preserved content sits in a hidden location and is retrieved through eDiscovery search and export, item by item, by someone who knows how to run it — not by clicking restore on a mailbox as it looked last Tuesday.

Microsoft 365 Backup, the first-party service

Microsoft now sells its own service under the name Microsoft 365 Backup. It is a pay-as-you-go product billed through an Azure subscription, it covers Exchange Online, OneDrive and SharePoint, and it restores those workloads to a point in time within the previous year at high speed because the data never leaves Microsoft’s platform. It is a real Microsoft 365 backup product and worth evaluating. It is also, by design, entirely inside the tenant it protects — which is the single most important thing to weigh when you compare it with third-party options.

Where Native Retention Runs Out

microsoft 365 backup what your business must back up d cracked data cube wrapped in glowing chains

Every native feature above is bounded in one of four ways. Those four boundaries are the reason an independent Microsoft 365 backup exists as a product category at all.

Time: every native window expires

Fourteen days, thirty days, ninety-three days. Each of those clocks is fine for the deletion somebody notices immediately, and useless for the one discovered at year-end, during an audit, or when a departed employee’s project is picked up six months later. A Microsoft 365 backup with a retention term you choose removes the guesswork about how quickly a loss must be spotted.

Granularity: preservation is not point-in-time restore

Retention preserves items. A backup restores a state. Those are different operations with different outcomes. If a folder structure is reorganised badly, if permissions are rewritten, or if a bulk edit corrupts thousands of documents, what you need is the shape of the site as it was on a particular morning — not a search result containing the individual files.

Independence: the same tenant is the same blast radius

Native retention lives inside the tenant. If an administrator account is compromised, the attacker inherits the ability to change retention settings, disable holds and delete content, and the same identity boundary that protects the data protects the controls over it. An external Microsoft 365 backup held under a separate identity and separate credentials survives events that take the tenant itself down.

Portability: getting your data out

Tenant lock-in becomes real during a migration, a divestment, a dispute or an insolvency. Native retention gives you no clean way to leave with a complete, structured copy of your organisation’s content. A Microsoft 365 backup that stores data in a format you can export is the difference between a portable business record and a hostage.

The Data Loss Scenarios a Microsoft 365 Backup Covers

microsoft 365 backup what your business must back up e four connected pillars of different geometric shapes

Everything above is theory until it is attached to the specific events that empty mailboxes and sites in real businesses. These are the ones that recur.

Accidental deletion, at scale and by hand

The most common cause of Microsoft 365 data loss is a person deleting something they should not have. Sometimes it is one message. Sometimes it is a shared library that looked like duplicated clutter. Individually these are small, and native retention catches most of them; collectively, the ones discovered late are why a Microsoft 365 backup earns its cost in a single incident.

Malicious insiders and departing employees

A leaver with notice served has access, motive and a fortnight of opportunity. Deleted mail, wiped OneDrive folders and emptied recycle bins are a recognised pattern in disputes, and the timing is rarely convenient: the discovery usually comes weeks later when someone needs the file. A Microsoft 365 backup taken before the account was disabled preserves the record regardless of what the account holder did with it.

Ransomware and account compromise

Modern ransomware follows the identity rather than the endpoint. A compromised account can sync encrypted files into OneDrive and SharePoint, and the platform will faithfully replicate them. This is where cybersecurity controls and a Microsoft 365 backup meet: prevention reduces the chance of compromise, and an immutable external copy is what turns a successful attack into a bad afternoon rather than a business-ending event.

Administrator error and policy changes

A misconfigured retention policy, a wrongly scoped script, an over-enthusiastic tidy-up of unused sites, a migration tool run against the wrong target — these delete far more data per incident than users do, and they run with privileges that bypass the ordinary safety nets. Any serious Microsoft 365 backup plan assumes the administrator is fallible, because the incident data says they are.

Third-party applications with write access

Every app you consent to in the tenant can create, modify and delete content with the permissions it was granted. A faulty sync connector or an integration failing halfway through a job can damage thousands of items quickly and quietly. When it happens, the fastest route back is a Microsoft 365 backup restore, not a support ticket with the vendor.

What Your Business Must Back Up, Workload by Workload

microsoft 365 backup what your business must back up f circular restore arrow lifting cubes back onto a platform

This is the checklist to hold your provider or your own team to. A Microsoft 365 backup that covers only mailboxes leaves most of the modern estate exposed.

Exchange Online mailboxes

Back up user mailboxes, shared mailboxes, in-place archives, calendars, contacts and public folders if you still use them. Shared mailboxes are the ones most often missed, because they are frequently unlicensed and fall outside per-user counts — and they are exactly where invoices, orders and support threads live.

OneDrive for Business

Every user’s OneDrive holds working documents that never make it to a shared site. When an account is deleted, the associated OneDrive is retained for a default period — commonly thirty days unless an administrator has changed it — and then removed. A leaver’s OneDrive is one of the highest-value and shortest-lived items in the whole tenant.

SharePoint Online sites

Back up document libraries, lists, metadata, permissions and the site structure itself. Metadata and permissions matter more than people expect: restoring ten thousand documents without their columns, versions and access model produces a folder of files, not a working site. Check that your Microsoft 365 backup restores structure, not just content.

Microsoft Teams

Teams is not a separate data store; it is a presentation layer over other services. Channel files live in SharePoint, chat files in OneDrive, chat and channel messages in hidden folders of user and group mailboxes, and the team’s configuration in Entra ID. A Microsoft 365 backup that claims Teams coverage should say explicitly which of those parts it captures and how a team is reconstructed.

Entra ID and directory objects

Users, groups, roles, conditional access policies and application registrations define who can do what. Recreating that configuration by hand after a bad change or a compromise is slow, error-prone and always happens at the worst possible moment. Directory protection is the least glamorous part of a Microsoft 365 backup and one of the most valuable during an incident.

The long tail: Planner, Power Platform, Bookings and Viva

Task boards, Power Apps, Power Automate flows, Dataverse tables and booking calendars accumulate business logic that nobody documented. Coverage here varies enormously between vendors. Decide deliberately what is in scope rather than discovering the answer after a loss, and record the decision alongside your other data protection commitments.

How to Choose a Microsoft 365 Backup Solution

Once the scope is agreed, the selection criteria are straightforward. Ignore feature lists that do not map to a restore you would actually perform.

Match coverage against the workload list

Take the list above into every vendor conversation and ask for a yes or no against each line, including Teams internals, Entra ID and the long-tail services. Vague answers about “full Microsoft 365 backup coverage” resolve into gaps once you ask which specific object types are captured and which are not.

Storage location, immutability and encryption

Ask where the data physically sits, whether the storage is immutable, who holds the encryption keys and whether the copy is reachable using tenant credentials. Immutability is what defeats an attacker who reaches your backup console; separate credentials are what stop a single compromised identity from deleting both the data and its copy.

Restore granularity and speed

You should be able to restore a single message, a single file version, a whole mailbox, an entire site and a full tenant view. Ask how long each of those takes at your data volume, and ask for evidence rather than an estimate. Restore speed is the number that matters on the day; backup speed never is.

Retention terms and what happens at the end

Confirm how long copies are kept, whether retention can be set per workload, and — critically — what happens to your data when the contract ends. A Microsoft 365 backup that cannot be exported in a usable format at the end of a term reproduces the lock-in you were trying to avoid.

Administrative controls and least privilege

Backup consoles are high-value targets: they hold a copy of everything. Require multi-factor authentication, role separation between operator and administrator, alerting on failed jobs, and an audit trail of every restore. Then confirm nobody is using a personal account for any of it.

Turning a Microsoft 365 Backup Into a Recovery Plan

Buying a product is not the same as being able to recover. The plan is what converts a licence into an outcome, and it takes an afternoon to write.

Set recovery point and recovery time objectives per workload

Decide how much data you can afford to lose, expressed in hours, and how quickly each workload must be back. Finance mailboxes and the contract library will justify tighter numbers than a dormant project site. These objectives belong in the same document as your managed IT SLA targets so the whole recovery picture reads consistently.

Name who runs the restore

Write down who is authorised to restore, who approves it, and how they are contacted out of hours. In a real incident this is the question that wastes the first two hours. If the answer is your provider, confirm it in the contract rather than assuming it is included in the monthly fee.

Document the runbook

A one-page runbook per scenario — deleted mailbox, encrypted OneDrive, deleted site, compromised tenant — beats a hundred-page policy nobody opens. Each should list the trigger, the decision-maker, the console to use, the expected duration and the verification step that says the restore worked.

Test restores on a schedule, not on faith

An untested Microsoft 365 backup is a hypothesis. Restore something real every quarter: a mailbox to a recovery location, a site to a temporary URL, a file from twelve months ago. Log the result with the date and the time taken, because that log is what an auditor, an insurer and your board will actually ask to see.

Rehearse the worst case at least annually

Once a year, walk through the scenario where the tenant itself is unavailable or untrusted. Who has the backup console credentials? Are they stored somewhere that does not depend on Microsoft 365 to reach? A recovery plan that requires a working tenant to log in has a circular dependency at its centre.

The compliance angle is where a Microsoft 365 backup earns approval from people who do not care about IT architecture, so it is worth getting the language right.

Backup and archiving solve different problems

A backup exists to restore a state after a loss. An archive exists to retain records for a defined period so they can be found on demand. Using one for the other produces either enormous storage bills or unretrievable evidence. Most regulated businesses need both, and should budget for them separately.

UK GDPR, residency and processor obligations

Under UK GDPR your organisation is the controller and both Microsoft and your backup vendor are processors. That means you owe the accountability: knowing where copies live, how long they are kept, who can access them and how they are deleted. Ask every Microsoft 365 backup vendor for a data processing agreement and the storage region before signing, not after.

Legal hold and eDiscovery still belong in the tenant

A backup is not a substitute for litigation hold. Holds are applied inside Microsoft 365 and operate on live content, and eDiscovery searches the tenant, not your backup vendor. Keep both, and make sure the legal team knows which system answers which question.

The right to erasure versus your backup copies

When someone exercises a deletion right, the copies held in a Microsoft 365 backup are part of the picture. The workable and widely accepted approach is documented: deletion is applied to live systems immediately, backup copies age out under a stated retention schedule, and those copies are not used to reinstate the data in the meantime. Write that position down before you are asked for it.

What a Microsoft 365 Backup Should Cost

Pricing is simple enough to model in a spreadsheet, provided you ask about the parts that are not on the pricing page.

The common commercial models

Most third-party vendors charge per user per month, typically with unlimited or generously capped storage. Microsoft’s first-party service charges on consumption, so cost scales with the volume you protect rather than the headcount. For a business with a small number of very large SharePoint sites, those two models produce very different bills — model both against your actual data.

The costs that are not on the price list

Ask about restore charges, egress fees, per-workload add-ons, minimum commitments and the price of extending retention beyond the standard term. Ask what happens to the bill when headcount rises mid-term. A Microsoft 365 backup quote without those answers is an estimate, not a price.

Comparing against the cost of the incident

The honest comparison is not backup cost against zero. It is backup cost against the working days lost rebuilding a mailbox from other people’s copies, the lost documents nobody can reconstruct, and the professional fees. Set against that, Microsoft 365 backup pricing sits in the same bracket as the coffee budget — which is why it survives the finance conversation once it is framed properly.

Where it belongs in your contract

If a provider manages your tenant, the backup obligation should be written into the agreement with the workloads, the retention term and the restore responsibility named explicitly. Our guide to what should be included in a managed IT services contract covers how to word that clause so it survives a change of account manager.

Mistakes Businesses Make With Microsoft 365 Backup

These are the recurring ones, and every one of them is cheap to fix before an incident and expensive afterwards.

Assuming the provider already does it

The most common and most costly assumption. Support contracts frequently include tenant administration without including a Microsoft 365 backup, and the distinction is invisible until a restore is requested. Ask for it in writing this week, and accept only a specific answer naming the tool and the retention term.

Backing up mailboxes and stopping there

Mail-only protection made sense when mail was the estate. Today the documents, the project history and most day-to-day collaboration live in SharePoint, OneDrive and Teams. A Microsoft 365 backup that covers a third of the tenant will be discovered to cover a third of the tenant on the day it is needed.

Never testing a restore

Backups fail quietly. Jobs that have been reporting green for months can be scoped to a group that no longer contains the mailboxes you assume. Only a completed test restore proves the chain works end to end, and it is the single highest-value hour in this entire article.

Leaving Teams and Entra ID out of scope

Both are routinely excluded because they are awkward, and both are painful to rebuild. Confirm explicitly what your Microsoft 365 backup captures for Teams internals and directory objects rather than assuming they are bundled with SharePoint coverage.

Keeping the backup inside the same identity boundary

If the same compromised administrator account can delete both the live data and the copies, you have redundancy rather than a Microsoft 365 backup. Separate credentials, separate multi-factor authentication and immutable storage are what make the copy independent — the same resilience thinking set out in our cyber resilience pledge FAQ guide.

Confusing a retention policy with a backup

Retention preserves; backup restores. A tenant with excellent retention configuration and no Microsoft 365 backup will pass a compliance review and still lose a week to a deleted site. Both belong in the estate, and they answer different questions.

A 30-Day Plan to Get Microsoft 365 Backup in Place

If this article has identified a gap, the fix is a month of small tasks rather than a project.

Week one: establish the facts

Confirm in writing whether a Microsoft 365 backup exists today, what it covers, how long it retains and who can restore from it. If the answer comes back vague, treat that as a no. Then list the workloads in use, including the Teams, Planner and Power Platform content that has grown without anyone deciding it should.

Week two: agree scope and choose the model

Decide which workloads are in scope and what retention each needs, then price the first-party service and two third-party vendors against that scope. Involve whoever owns compliance early, because their retention requirement usually sets the term.

Week three: pilot and prove a restore

Protect a representative subset — one department, a busy SharePoint site, a shared mailbox — then delete something deliberately in a test area and restore it. Time the restore. That number is your real recovery time, and it is the most useful figure the whole exercise produces.

Week four: document, monitor and hand over

Write the one-page runbooks, set alerting for failed jobs, record who holds the console credentials, and put a quarterly restore test in the calendar with a named owner. A Microsoft 365 backup that nobody monitors reverts to a hypothesis within two quarters.

Final Thoughts: Own the Data You Are Responsible For

Microsoft protects the platform extremely well. It keeps the service running, replicates your content across datacentres, and gives you a genuinely useful set of retention tools that recover the majority of everyday mistakes inside a fixed window. None of that is a substitute for a Microsoft 365 backup, and Microsoft has never claimed it is.

The businesses that come through a deletion, a departure or a ransomware incident without lasting damage are not the ones with the largest budgets. They are the ones that read the shared responsibility model literally, wrote down which workloads they were protecting, chose a Microsoft 365 backup that sits outside their tenant’s identity boundary, and tested a restore recently enough to trust it.

Do those four things and the question stops being frightening. Your data becomes something you can put back the way it was — on the ordinary Tuesday when someone empties the wrong folder, and on the far worse day when something deliberate happens. That is what a Microsoft 365 backup is for, and it is a decision worth making before the incident rather than during it.