Microsoft does not back up your Microsoft 365 data the way you think

An office manager deletes a former employee’s account 6 weeks after they leave. Nobody remembers that this person’s OneDrive held the only copy of 4 years of project files until a customer asks for one, 5 months later. The files are gone. Microsoft did nothing wrong. The tenant worked exactly as designed, and the design is not what most business owners think it is.

The belief runs something like this: “our files are in the cloud, Microsoft has data centers and engineers, therefore our data is backed up.” The first 2 clauses are true. The conclusion does not follow, and the gap between them has a name in Microsoft’s own documentation: shared responsibility. Microsoft is responsible for keeping the service running. You are responsible for your data in it.

What Microsoft actually provides

To be fair to the platform, the native protections are real. They are just recovery conveniences and compliance tools, not backup:

• Recycle bins. A deleted SharePoint or OneDrive file passes through 2 recycle bin stages totaling 93 days. Deleted Outlook items are typically recoverable for up to 30 days after leaving the Deleted Items folder
• Deleted user grace period. When you remove a user, their account and OneDrive are recoverable for 30 days. After that, the content is purged
• Version history. SharePoint and OneDrive keep prior versions of files, which helps with the “I overwrote the spreadsheet” problem and offers some ransomware rollback help
• Retention policies and litigation hold. With the right licensing, you can force content to be preserved for compliance purposes

Redundancy is also real: your mailbox lives in multiple data centers, so a hardware failure at Microsoft is not going to lose your data. Redundancy protects against Microsoft’s disasters. It does nothing about yours, because every mistake and every malicious act is replicated with the same efficiency as the legitimate data.

The gaps that actually catch businesses

Each of these is a pattern we see or a scenario the native tooling explicitly does not cover:

• The purged departed user. The opening story. License cleanup after offboarding is normal cost hygiene, and 30 days is a short memory for “did anything in that OneDrive matter?” This failure mode is silent and permanent.
• Deletion discovered late. The 93-day window feels long until you learn that a folder was emptied in March during a cleanup and someone needs it in September. Most data loss in small businesses is discovered months later, not days.
• Ransomware that syncs. The OneDrive client faithfully syncs encrypted files to the cloud, and version history helps only if the retained versions predate the infection and someone catches it within the version window. Attackers increasingly target cloud data directly too, deleting versions where they can.
• The malicious insider. An employee on the way out who empties folders and then the recycle bin, twice, has beaten the native protections on day 1.
• Admin-level mistakes and compromise. A bad retention policy change, a scripting error or a compromised global admin operates at tenant scale. The native protections all live inside the tenant, which means they share the tenant’s fate.

Notice the common thread: the native tools assume the deletion was innocent and recently discovered. Real incidents are often neither.

Retention policies are not backup either

A frequent objection from well-read owners: “we have retention policies, everything is preserved.” Retention is genuinely useful, and for some businesses contractually necessary. But it is a compliance instrument, not a recovery instrument:

• Restoring from retention holds means content searches and exports, a process measured in hours of admin work per request, not a restore button
• Retention lives inside the tenant, subject to admin error and admin compromise
• It preserves items, not structure. Getting a mangled SharePoint library back the way it was on Tuesday at 4 PM is not what eDiscovery tooling is for

The test for any backup story is the same one we apply in the 3-2-1-1-0 rule: is there a copy that is independent of the system being protected, and can you actually restore from it? A copy inside the tenant fails the independence test by definition.

What third-party M365 backup looks like

Purpose-built Microsoft 365 backup services solve exactly this. The product category is mature, the economics are small-business friendly (typically $3 to $6 per user per month) and a proper deployment gives you:

• Independent storage. Your data copied out of the tenant to the provider’s cloud, so a tenant-level disaster, mistake or compromise does not touch the backup
• Full workload coverage. Exchange mailboxes, OneDrive, SharePoint and Teams data, not just mail
• Point-in-time restore. Roll a mailbox, a library or a single file back to a chosen moment, with granular restore rather than an export dump
• Retention measured in years, immune to license cleanup, so the departed-user OneDrive stays restorable long after the account is gone
• Deletion that requires more than 1 angry admin click

For a 25-person company, that is roughly $75 to $150 per month to close every gap listed above. Compare that with the cost of recreating 4 years of project files, or explaining to a customer why their records no longer exist.

2 buying notes. First, insist on knowing where the backup data is stored and that access to it is protected with MFA, because a backup service is itself a high-value target. Second, a backup you have never restored from is a hope, not a plan. The discipline in our post on tested restores applies to cloud data with full force: schedule a quarterly test restore of a mailbox and a document library and treat failure as an incident.

Where this fits in priorities

If your business runs on Microsoft 365, which for most of our market means email, files and increasingly Teams as the operational record, then M365 backup is not an advanced measure. It sits in the same tier as MFA and endpoint protection: basic, cheap relative to the risk and conspicuous by its absence the day something goes wrong. Cyber insurers have noticed too, and questions about SaaS data backup are appearing on renewal questionnaires alongside the familiar MFA and EDR checkboxes.

The shared responsibility model is not fine print to argue with. It is the deal. Microsoft keeps the lights on. Whether your data survives your own worst day is up to you.

If you are not sure what your current M365 tenant would let you recover, we will map it with you: what is protected today, where the gaps are and what closing them costs. Talk to Atticus Rowan and we will make the shared responsibility line visible before it matters.