Ask a room of business owners whether their Microsoft 365 data is backed up and most will say yes — it's in the cloud, Microsoft has data centers, surely that's the point. Then a departed employee's OneDrive turns out to have been purged on schedule, or a ransomware crew encrypts a SharePoint library through a compromised sync client, and the question gets asked again with real money on the table. The honest answer is uncomfortable: Microsoft 365 backup is not something Microsoft provides you. Microsoft keeps the service alive; keeping your data recoverable is, contractually and practically, your job. Here's where that line actually sits and what to do about it.

What "Shared Responsibility" Means in Plain Terms

Every major cloud platform operates on a shared-responsibility model. Microsoft's side of the deal: the infrastructure, the uptime, the platform security, redundant copies of data across data centers so a hardware failure never loses anything. Your side: the data itself, who can access it, and recovering it when something on your side goes wrong — a deletion, an overwrite, a malicious insider, a compromised account. Microsoft's own services agreement says it plainly: service interruptions happen, and you should regularly back up the content you store in the services.

The distinction that matters is replication is not backup. Microsoft replicates your data superbly — which means when ransomware encrypts your files or someone deletes a mailbox, the deletion and the encryption replicate superbly too. Redundancy protects against Microsoft's failures. It does nothing about yours.

"But There's a Recycle Bin" — The Retention Reality

Microsoft 365 does give you native safety nets, and for everyday oops-deletions they're genuinely good. It's worth knowing exactly where they end:

  • Deleted email sits in recoverable folders for a bounded window (measured in weeks by default), then it's gone.
  • SharePoint and OneDrive recycle bins hold items for up to 93 days, then purge them.
  • A departed user's OneDrive is retained for a set period after their license is removed (30 days by default, configurable), then deleted — the classic loss scenario, discovered months later when someone needs the former employee's files.
  • Retention policies and litigation hold can preserve content much longer — but they're compliance tools, not recovery tools. They keep a copy existing somewhere discoverable; they don't give you a point-in-time restore of a mangled site, a mass-deleted mailbox, or a Teams channel as it stood last Tuesday.

Every one of those windows is fine until the day you discover the loss on day 94, or the day you need last month's version of everything, not the encrypted current one.

The Scenarios That Actually Cause Loss

Cloud data loss almost never looks like a Microsoft outage. It looks like:

  • Ransomware through the sync client — files encrypted on a laptop sync their encrypted selves to OneDrive and SharePoint, version history gets churned or the attacker had time to age out the copies.
  • Account takeover — an attacker with a real user's credentials can delete, exfiltrate, and empty recycle bins as that user; a compromised admin can do it tenant-wide.
  • Malicious or careless insiders — the departing employee who empties their mailbox and OneDrive on the way out.
  • Well-intentioned automation — a retention policy configured wrong, a script with a bad filter, a migration that overwrote instead of merged.
  • The slow discovery — data lost quietly, needed loudly, months later: a contract dispute, an audit, a records request.

Notice that MFA and good security hygiene shrink several of these but eliminate none. Backup is the control for the failures that get through everything else.

What Real M365 Backup Looks Like

A proper third-party backup for Microsoft 365 is a separate copy of your tenant's data, on infrastructure and credentials independent of the tenant itself. Evaluate options against a short list:

  • Coverage: Exchange mailboxes, OneDrive, SharePoint, and Teams (including chat where the platform supports it) — not just mail.
  • Point-in-time restore: the ability to roll a mailbox, site, or folder back to how it stood at a chosen moment — the capability retention policies don't give you.
  • Granularity: restore one email, one file, one folder — not just "the whole site."
  • Independence: backups stored outside your tenant, with separate admin credentials, so the account takeover that hits your tenant can't reach the copies. Immutability here is the same principle as in our ransomware recovery guide.
  • Retention you choose: years if your industry needs years, independent of Microsoft's windows.

The cost runs a few dollars per user per month — one of the cheapest line items in the stack relative to the failure it covers.

Where This Fits in Continuity Planning

M365 backup is one leg of a continuity posture, not the whole of it. The same discipline that applies to servers applies here: know your recovery-time and recovery-point objectives, test restores on a schedule instead of assuming, and write the runbook before the incident. Our business continuity vs disaster recovery primer covers the framing, and good tenant administration shrinks the odds you'll need the backup at all. The businesses that get hurt are the ones who assumed the platform's job description included theirs.

The Bottom Line

Microsoft keeps Microsoft 365 running; nobody at Microsoft is responsible for getting your data back when it's deleted, encrypted, or sabotaged from your side of the line. Native retention buys you windows measured in days and compliance holds — not point-in-time recovery. Put an independent backup behind the tenant, choose retention deliberately, and test a restore before you need one. If you'd like that stood up and monitored as part of your stack, our managed IT team handles M365 protection end to end. Get in touch and we'll close the gap before it costs you.