Does Microsoft back up your Office 365 data? Most IT admins assume the answer is yes — Microsoft runs the infrastructure, so it must be looking after what's stored on it. It isn't, and Microsoft says so in its own contract. The Microsoft Services Agreement recommends that customers back up their own content, because what Microsoft 365 actually offers — recycle bins, retention holds, litigation hold — was built for short-term recovery, not for long-term backup. Understanding that distinction is the difference between a five-minute restore and a permanent, unrecoverable loss.
What Microsoft's services agreement actually says
Microsoft's position isn't buried in a footnote. The Microsoft Services Agreement, the contract every Microsoft 365 customer accepts, contains two clauses that say plainly whose job backup is.
Section 6.b states: "We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services." Section 4.a.iv.2 goes further, tying it directly to account termination: "You should have a regular backup plan as Microsoft won't be able to retrieve Your Content or Data once your account is closed."
Neither clause is ambiguous. Microsoft is telling customers, in the agreement they sign to use the service, that backup is not something Microsoft 365 does for them. It's a recommendation, not boilerplate, and it lines up with how the platform's built-in recovery tools actually behave once you look closely at the time limits attached to them.
Retention vs backup — the 30/93-day traps
The confusion usually comes from Microsoft 365's native recovery features looking enough like a backup to be mistaken for one. They're not, and the gap shows up as soon as something is deleted outside the recovery window.
In Exchange Online, a deleted email doesn't vanish immediately. It moves to the Recoverable Items > Deletions folder, where it sits for 14 days by default before Microsoft purges it permanently. Admins can extend that window, but only up to a hard ceiling of 30 days. Past that point, whether the deletion was accidental, malicious, or the result of a compromised account quietly covering its tracks, the email is gone. There's no support ticket that brings it back.
SharePoint and OneDrive work on a similar principle with a longer, still-finite window. Deleted files pass through a two-stage recycle bin, first-stage then second-stage, for a combined 93 days from the point of deletion, and that period isn't configurable by an admin. Once the 93 days elapse, the file is permanently deleted from both stages, no matter how important it turns out to be in hindsight.
Teams sits at the opposite extreme, and is arguably the riskier case: without an admin-configured retention policy, chat and channel messages simply persist indefinitely, with no built-in expiry and no built-in backup either. Nothing stops someone from manually deleting a channel's history, and nothing restores it once they have.
None of this is Microsoft cutting corners. Retention windows exist to bound storage and manage litigation holds, not to protect against data loss. The trap is assuming a time-bounded recycle bin is functionally the same thing as an independent backup, when the two solve different problems: one gives a short grace period to undo a mistake, the other gives a restorable copy that exists outside the system that could have caused the loss in the first place.
What this looks like when it goes wrong
None of this is theoretical. A departing employee with admin rights deletes a shared mailbox on the way out, and it's gone for good once the 30-day window passes unnoticed over a long weekend. A phishing-compromised account is used to quietly empty a SharePoint document library, and nobody spots it until well past the 93-day recycle bin. Ransomware encrypts a mapped OneDrive folder, and the encrypted version syncs to every device before anyone realises what happened, leaving no clean local copy to fall back on. In every one of these cases, Microsoft 365 did exactly what it was designed to do: it kept the platform running and enforced its own retention rules. None of that rule set was ever designed to catch these specific failures, because retention isn't a substitute for a restorable, independent copy of the data.
That's also why "we have a retention policy" and "we have a backup" aren't interchangeable answers, even though they're often used as if they were. A retention policy tells Microsoft 365 how long to keep something before deleting it. A backup exists specifically so that deletion, whether accidental, malicious, or the side effect of a bigger incident, isn't the end of the story.
For Australian businesses working toward frameworks like the Essential Eight or SMB1001, this distinction has practical weight beyond convenience. Those frameworks expect regular, tested backups as a baseline control, not native retention settings repurposed to look like one. An auditor asking for evidence of a working backup and restore process won't accept "Exchange keeps deleted items for 30 days" as the answer, and for good reason: it isn't one.
The Microsoft 365 shared responsibility model, in plain English
The gap between what Microsoft 365 quietly relies on and what it actually delivers has a name: the shared responsibility model. Microsoft 365 splits obligations the same way every major SaaS platform does. The provider secures the infrastructure, and the customer secures what they put on it.
Microsoft's side covers the physical data centres, the platform's uptime, patching the underlying services, and the security of the infrastructure layer itself. That's a genuinely large set of guarantees, backed by an SLA. What it doesn't cover is what happens to data once it's inside a tenant: who deleted what, whether a phishing-compromised account quietly wiped a mailbox, whether a departing employee took a folder on the way out, or whether ransomware encrypted files that then synced across every connected device.
That's the customer's half of the model. Access management, data governance, and, critically, recovery from data loss caused by user error, malicious insiders, compromised accounts, or ransomware all sit on the customer's side of the line, not Microsoft's. It isn't a gap in the platform. It's a deliberate, documented split, and Microsoft 365's marketing rarely mentions it, because "you're on your own for backup" doesn't sell subscriptions.
What a real backup actually adds
A genuine third-party backup solves the two problems retention windows can't touch: time and independence.
Time, because a real backup keeps point-in-time restore points going back well past 30 or 93 days, which matters because data loss isn't always discovered immediately. That's the normal case for ransomware, where dwell time before detection routinely runs into weeks, and for slow, deliberate insider deletion designed not to trigger attention. If the loss surfaces after the native recovery window has closed, native retention was never going to help regardless of how it was configured.
Independence, because a backup stored outside the production tenant can't be touched by whatever compromised the production tenant. An attacker with admin credentials inside Microsoft 365 can purge mailboxes, wipe SharePoint libraries, and disable retention policies on the way through, all inside the platform they've compromised. A backup copy held independently, on storage a compromised admin account can't reach or alter, survives that scenario by design. Keepit is built specifically around that principle for Microsoft 365, Google Workspace and a wide range of other SaaS platforms: independent copies with restore points that aren't bound by a platform's own retention clock.
What Australian businesses should do next
Start with what's actually in scope. Exchange, SharePoint, OneDrive and Teams are the obvious four, but Entra ID, Power Platform and any other Microsoft 365 workload holding business-critical data belong on the same list. Losing configuration or identity data is just as disruptive as losing a mailbox.
Then check what's genuinely covered today, not what's assumed to be covered. If the honest answer is "Exchange has a 30-day window and everything else has whatever the default is," that's the gap a proper SaaS backup strategy closes: independent of Microsoft's retention settings, with restore points that reach back further than 93 days and can't be touched by whatever caused the data loss in the first place.
Microsoft was clear about where its responsibility ends. The businesses that read that clause and act on it get a five-minute restore when something goes wrong. The ones that don't find out the hard way, on day 94.
Sources: Microsoft Services Agreement, OneDrive retention and deletion — Microsoft Learn, Recoverable Items folder in Exchange Online — Microsoft Learn, Learn about retention for Teams — Microsoft Learn