Microsoft runs the platform. Your data recovery is still your responsibility.
Microsoft's own Service Agreement advises customers to regularly back up their content and data stored in Microsoft 365. Many organisations have not read that clause closely — and current Australian cyber insurance questionnaires increasingly ask about independent SaaS backup.
See where the shared-responsibility line sitsThe shared-responsibility model in plain terms; native retention windows per workload across Exchange, OneDrive, SharePoint and Teams; six scenarios where native retention does not bring the data back; how cyber attack reaches Microsoft 365 data; what the current insurance questionnaire actually asks for; and how Microsoft 365 backup posture is assessed inside broader recovery work. This page is for organisations that run mail, files and collaboration inside Microsoft 365 and need to understand what an independent backup is there to protect against.
What Microsoft provides, what native features do not cover, and what a defensible posture looks like.
Does Microsoft back up Microsoft 365?
No, not in the way most organisations assume. Microsoft operates the platform, keeps the service running, and replicates data across datacentres for resilience — it does not back up customer data with the intent of restoring it after deletion, cyber attack, admin error or malicious insider activity. Microsoft's own Service Agreement advises customers to back up their content.
What does Microsoft provide natively?
Short-term retention and recycle bins across Exchange, OneDrive, SharePoint and Teams. Version history for recent changes. Litigation holds through Purview for compliance. Geo-redundancy for platform resilience. Useful short-term recovery tools — not a backup in the sense insurers, auditors and recovery plans use the word.
What should a defensible posture look like?
Independent backup stored outside the tenant, under separate credentials with MFA, covering Exchange, OneDrive, SharePoint, Teams and Entra ID objects where supported. Immutable storage, retention well beyond native windows, granular restore, and dated restore-test evidence — mapped to the specific Microsoft 365 questions on current insurance questionnaires.
Microsoft keeps the cloud running. Your organisation keeps its data safe.
Microsoft 365 operates under the SaaS shared-responsibility model. The boundary between Microsoft's responsibility and the customer's is not ambiguous; it is explicitly documented by Microsoft and reinforced in the Service Agreement.
- Physical datacentre infrastructure and network
- Platform availability and service-level uptime
- Geo-redundancy across datacentres
- Hardware redundancy
- Disaster recovery of the underlying platform
- Customer data and content
- Identities and access management
- Endpoint configuration
- How long to retain content and how to protect it
- Backup, restore capability and recovery evidence
"We recommend that you regularly back up Your content and data that you store on the Services." — Microsoft Services Agreement
Short-term retention, recycle bins and version history. Useful, but not a backup.
Microsoft 365 includes several built-in protections against routine data loss. Each has a defined window, scope and limit. Understanding what each one covers is the first step in understanding what they do not. The distinction that matters: native retention is designed for routine user error; backup is designed for non-routine loss events. The two are not substitutes for each other.
Deleted mail moves to Deleted Items, then to the Recoverable Items dumpster. Default retention is 14 days, extendable to 30. A removed mailbox is retained around 30 days by default. After the window expires, native recovery is not available.
User-deleted files go to the Recycle Bin. If a user account is removed, OneDrive data is retained 30 days (admin-adjustable), then placed in the Site Collection Recycle Bin for an additional 93 days. Version history is retained per configured policy.
Site Collection Recycle Bin with similar two-stage retention. SharePoint-backed file recovery requires admin involvement once items leave the user recycle bin, and full-site restore is a more complex operation than per-item recovery.
Teams files sit in SharePoint and follow SharePoint retention. Channel messages and chat history live in Exchange under compliance storage. There is no user-facing Teams recycle bin, and team deletion recovery is time-limited.
Purview supports litigation holds and retention policies for compliance — useful to prevent deletion for legal discovery. They are not backups: the data sits inside the tenant, is accessible to administrators with the right privileges, and does not protect against the scenarios a backup is designed to address.
Six scenarios where native retention does not bring the data back.
Every scenario below is documented in Australian renewal reviews and post-incident investigations. These are not edge cases — each is a case where native retention expires, is bypassed, or was never designed to cover the outcome.
A file accidentally deleted 120 days ago in OneDrive or SharePoint is gone — the two-stage recycle bin tops out at 93 days, and an email purged more than 30 days ago cannot be retrieved through native tools. Discovery often lags deletion by months, especially for files rarely accessed until they are needed.
A cyber attack reaching Microsoft 365 through a compromised session encrypts files. Microsoft's replication copies the encrypted state across datacentres. Version history helps only where the attack is caught quickly and pre-encryption versions still exist; where the window has expired or the attacker has disabled versioning, recovery is not possible without an independent backup.
A global admin compromise allows mailbox deletion, site deletion, Teams destruction and retention-policy modification to accelerate permanent deletion. Microsoft does not provide a tenant-wide rollback. An independent backup stored outside the tenant under separate credentials is the control for this scenario.
A departing employee with legitimate access can delete mail, files and records; a dissatisfied admin can clear retention policies and trigger permanent deletion. Native retention assumes the actor is acting in error — deliberate destruction is outside the design intent of the feature.
A misconfigured policy, a bad migration script, a bulk operation that affected more than intended — these are replicated across Microsoft's redundant systems as normal state. There is no undo button at the tenant level; restoring requires granular work through the admin centre within retention windows, or an independent backup.
Restoring large volumes through the Microsoft Graph API hits throttling limits. A month of email across a hundred mailboxes recovered through eDiscovery can take substantially longer than an incident response timeline accepts. Backup products restoring through dedicated APIs and pre-indexed storage are not subject to the same throttling.
The assumption that SaaS is immune to cyber attacks has not aged well.
The early assumption was that cloud-hosted productivity data was outside the cyber attack threat model. The threat has adapted. Attacks that reach into Microsoft 365 data are now common enough that Australian insurance questionnaires increasingly ask about independent backup scope. The entry vector is usually an account compromise rather than a direct attack on Microsoft infrastructure: a stolen session token from an endpoint, a phished administrator credential without phishing-resistant MFA, or a malicious OAuth application granted broad tenant permissions. Each gives the attacker operational access to the same data the user would see, at the same permission level.
From there, the attacker can encrypt files through the authenticated session, modify retention policies, disable versioning, or simply delete content. Microsoft's platform-level defences do not prevent an authenticated user from performing actions the user is authorised to perform — that is not a Microsoft failure; it is the consequence of an authenticated compromise. Encrypted files inside Microsoft 365 are replicated by Microsoft's infrastructure as normal customer activity. In practice, discovery often happens days or weeks after the encryption run, by which time recoverable versions are gone or the attacker has disabled versioning as part of the attack chain.
A common pattern: the organisation discovers encrypted files across OneDrive and SharePoint. The IT team attempts recovery through recycle bins and version history. Partial recovery succeeds for recent or high-version files; significant quantities of older or single-version files cannot be recovered. When an underwriter asks whether the organisation has independent backup of Microsoft 365 data, the question is not hypothetical — it comes from claims history where the native retention did not hold up.
The question is now on the questionnaire. The answer needs to map to evidence.
Microsoft 365 backup is a recurring category on Australian cyber insurance renewal questionnaires. The specific questions vary by underwriter, but the pattern is consistent.
Do you have an independent backup of your Microsoft 365 data?
A "yes" requires a backup operated outside the tenant, under separate credentials. A "yes" that relies on native retention is typically scored as a gap, because the underwriter knows native retention is not what the question is asking about.
What is the scope, retention period and backup cadence?
Which workloads (Exchange, OneDrive, SharePoint, Teams, Entra ID), which retention (years rather than the 14-to-93-day native windows), and which cadence (typically multiple times daily). A vague scope answer signals the backup may not match the claim.
When was the last documented restore test?
A dated record of a real restore, with scope and outcome documented — the evidence that separates a backup that would work under pressure from one that has never been tested. Many organisations have the backup and have never performed the restore test.
Is the backup admin separate from the Microsoft 365 admin?
Backup admin accounts must be separate from Microsoft 365 global admin accounts, with independent MFA, not sharing credentials with the daily operational identity. Otherwise a Microsoft 365 admin compromise reaches the backup.
If your renewal answer on Microsoft 365 backup relies on native retention, it will likely be scored as a gap. A short review confirms independent coverage, credential separation and restore evidence before the questionnaire lands.
Review your M365 backupFour characteristics that turn an assertion into evidence.
Independent of the tenant, under separate credentials with independent MFA, so a tenant-wide compromise does not reach the backup. The primary control against the cyber-attack and compromised-admin scenarios.
Exchange, OneDrive, SharePoint, Teams and Entra ID objects where the product supports them — not partial coverage where one workload is backed up and another is assumed covered by native retention.
Measured in years rather than days, set against long-discovery deletion, cyber attack with a discovery lag, malicious insider activity uncovered months later, and regulatory or contractual evidence windows.
A dated restore-test report with scope, procedure, outcome and issues noted — produced often enough that the report on file is current when an insurer or auditor asks. This is what converts the backup from an assertion into evidence.
Part of the broader recovery position, not a standalone purchase.
Microsoft 365 backup is one category in a broader recovery architecture. It connects to backup architecture, identity recovery sequencing, dependency modelling, and the evidence layer that current insurance questionnaires increasingly require. Where the broader question is "could we recover from a destructive cyber event with evidence that holds up at renewal," Microsoft 365 backup posture is usually assessed inside a Recovery Readiness Assessment rather than as a standalone problem. Where Microsoft 365 backup is the specific area that needs attention and the rest of the recovery position is already understood, the work can be scoped directly within Backup and Disaster Recovery.
The Inlight IT view on Microsoft 365 backup.
Microsoft keeps the cloud running. Your organisation keeps its data safe. That sentence is closer to Microsoft's own Service Agreement than most buyers realise, and more directive than most buyers read it as. Where organisations usually have work to do is in three places: independent backup coverage that matches the actual workload scope rather than a partial implementation; backup administrator credentials separated from Microsoft 365 administrative credentials with independent MFA; and dated restore-test reports that turn the backup from an assertion into evidence.
None of these is exotic or expensive relative to the cost of a loss event, and all three are commonly absent until a structured review surfaces them. Independent recovery capability is the benefit; the cost of a dedicated third-party backup service, and the operational discipline to run it, is the trade-off.
A backup that exists is not the same as a recovery path that works. The difference matters most on the day it is tested by an attacker.
If Microsoft 365 holds your contracts, finance mail and client records, the shared-responsibility line is worth a one-hour check, not an assumption.
Check your side of the line →Microsoft 365 backup work in practice.
As an illustration rather than a headline: in one property-development environment, Microsoft 365 backup posture was reviewed as part of the broader recovery position rather than as an isolated product purchase — independent backup coverage across Exchange, OneDrive, SharePoint and Teams, credential separation from the Microsoft 365 administrative identity, retention aligned with insurance-questionnaire expectations, and restore-test evidence. The point of the example is the framing: Microsoft 365 backup treated as one part of a recovery whole, not a standalone tick-box.
Questions Australian organisations ask about Microsoft 365 backup.
Does Microsoft back up Microsoft 365?
How long does Microsoft retain deleted data?
What does the shared-responsibility model actually say?
What happens to Microsoft 365 data in a cyber attack?
What does an independent Microsoft 365 backup cover?
Do cyber insurance questionnaires ask about it specifically?
Is litigation hold in Purview the same as a backup?
What if an admin account is compromised and wipes our data?
What about Microsoft 365 Backup, the Microsoft service?
How do we assess our current backup posture?
Make Microsoft 365 backup posture defensible — for renewal, for audit, for recovery.
A short review maps native retention against the scenarios you carry, confirms independent backup coverage and credential separation, and turns the backup into dated evidence.
Review your Microsoft 365 backup posture