Managed IT
Ask most businesses whether their Microsoft 365 data is backed up and the answer is yes, because it is in the cloud. Microsoft has never claimed that. Their shared responsibility model says so in writing, in public, and has for years. The gap is not that the terms are hidden. It is that almost nobody reads the part where the responsibility changes hands.
Shared responsibility is not a disclaimer buried in a contract. It is the design of the service. Microsoft runs the platform and guarantees it will be available; you own what you put into it. Both halves are reasonable, and the trouble starts because the first half is so visible and reliable that people assume it covers the second.
What the model actually says
The split is cleaner than most people expect once you see it laid out.
Genuinely covered
What Microsoft protects
Infrastructure · Service availability · Physical security · Hardware failure · Geo-redundancy
Microsoft protects the platform, and does it well. Their datacenters are replicated, their hardware failures are invisible to you, and their availability commitment is contractual. If a disk dies in one of their facilities, that is entirely their problem and you will never hear about it. The important thing to notice is what kind of protection that is: it defends against Microsoft's infrastructure failing, which is not the failure mode that actually costs businesses their data.
Yours to handle
What you protect
Your data · Access control · Retention beyond native limits · Recovery
Everything you put into the tenant remains your responsibility: the content itself, who can reach it, how long it is kept, and whether it can be brought back after something goes wrong. Microsoft's service level agreement covers uptime, not the recoverability of a mailbox somebody emptied. That distinction is the whole model in one sentence, and it is the part that tends to surprise people during an incident rather than before one.
The exposure
Where loss actually happens
Accidental deletion · Malicious deletion · Ransomware · Offboarding · Admin error
The gap sits between a platform that never fails and a set of native tools that were designed for short-term convenience rather than recovery. AIIM and Datto's State of the Backup research reports one in three organizations have experienced permanent data loss in Microsoft 365, and Datto puts 64% of SaaS data loss down to user error: accidental deletion, overwrites and admin mistakes. None of those are platform failures, which is exactly why the platform's protections do not address them.
Retention is not backup
Microsoft 365 includes features that feel like data protection. Deleted items go to a recycle bin, files keep versions, and retention policies control how long things are kept. All useful, and none of it is a backup, because all of it lives inside the same tenant under the same administrative control as the data it is protecting.
Per Microsoft's own documentation, the recycle bin retains deleted items for a maximum of 93 days. After that the item is gone, and no amount of escalation retrieves it. Retention policies can hold data longer, but they are configuration inside the environment rather than a copy outside it, which matters when the problem is the environment.
The four ways SaaS data actually gets lost
None of these involve Microsoft failing. All of them are common.
Deletion discovered late
Somebody empties a folder, clears a mailbox, or removes a SharePoint library, and nobody notices for four months. The recycle bin window has closed and the item is permanently gone. This is the most ordinary failure there is, and it is why the 93-day limit matters more than it sounds: the constraint is not how long deletion is survivable, it is how long it takes anyone to realize something is missing. Those two intervals are frequently very different.
Ransomware reaching synced files
An endpoint gets encrypted and the damage syncs upward into OneDrive and SharePoint. Versioning is meant to help here and often does not, because the encryption process writes enough successive versions to push clean copies out of the retained set. An independent backup is unaffected because it sits outside the environment the attack reached, which is the entire point of keeping it there.
Departing employees
Someone leaves, their license is reclaimed to stop paying for it, and their mailbox and OneDrive content goes with it. This is a genuinely awkward one, because reclaiming the license is correct financial practice and losing the data is a side effect nobody chose. Six months later somebody needs a contract from that mailbox and the answer is that it no longer exists.
Administrative error
A misapplied retention policy, a bulk operation that hit the wrong scope, a permissions change that cascaded. Administrative actions are powerful by design and native tooling offers limited ability to reverse them, since from the platform's perspective an authorized administrator did exactly what they instructed it to do.
What an independent backup changes
The word doing the work is independent. A second copy inside the same tenant inherits every problem the first copy has.
It sits outside Microsoft's control
Stored separately from the environment it protects, so a compromised administrator account, a ransomware event or a tenant-level mistake does not reach it. This is the structural difference between a backup and a retention setting, and it is the reason the storage location is worth asking about specifically.
Retention stops being a countdown
No 93-day window. Items remain recoverable at any point, including years after a deletion, which matters because the interval before somebody notices is the variable you cannot control.
Recovery is granular and point-in-time
Restore a single email, a folder, a full SharePoint site, or the state of things immediately before an administrative error. Point-in-time restore is what makes admin mistakes recoverable rather than permanent, since you can return to the moment before the change rather than reconstructing what was lost.
Departing employee data survives the license
Content is retained independently of whether the account still exists, so reclaiming a license stops the billing without destroying the contents of the mailbox.
It is not only Microsoft 365
The same exposure applies to Google Workspace and Salesforce, which operate on comparable shared responsibility terms. Aureon's SaaS Protect covers all three, which matters if your CRM is the system holding the data you would least like to lose.
Somebody has to actually run the restore
Worth asking who performs recovery when it is needed. A backup product with no one assigned to operate it becomes a project during an incident, at the moment when you have least capacity for one.
SaaS Data Readiness Checklist
The Checklist
Fifteen questions across retention, recovery and compliance. Tick the ones you can answer without going and asking someone, and the score updates as you go. Use it yourself or share it with your team.
Tick what you can answer without checking. The blanks are the gaps.
Retention Limits
Do you know how long deleted items stay recoverable?
Microsoft documents a 93-day maximum in the recycle bin. Most people assume it is indefinite.
How long would it typically take you to notice a deletion?
That interval is the one that matters, and it is usually longer than the window you have to act in.
Does any copy of your data live outside the tenant?
A second copy under the same administrative control inherits every problem the first copy has.
Do you know the difference between your retention policy and a backup?
Retention governs how long things are kept inside the environment. Backup is a copy outside it.
Is Google Workspace or Salesforce data covered too?
The same shared responsibility terms apply. Coverage often stops at email and forgets the CRM.
Recovery Scenarios
Could you restore a single email from eight months ago?
The most ordinary request there is, and the one native tooling most often cannot satisfy.
If ransomware reached synced files, would versioning save you?
Encryption can write enough successive versions to push the clean copies out of the retained set.
What happens to a mailbox when you reclaim the license?
Reclaiming is correct financial practice. Losing the contents is a side effect nobody chose.
Could you roll back a misapplied retention or permissions change?
From the platform's view an authorized admin did exactly what they instructed. Reversing it is another matter.
Who actually performs a restore, and have they ever done one?
A backup nobody has operated becomes a project during the incident, when you least have capacity for one.
Compliance Requirements
What retention period do your obligations actually require?
A specific figure from the framework that applies to you, not an assumption about what feels prudent.
Could you satisfy a legal hold on data deleted last year?
The request arrives after the fact. Whether you can answer it was decided before.
Do you know where your backup data is physically stored?
Data residency turns up in contracts and questionnaires more often than most teams expect.
Has a restore ever been tested, or only assumed?
An untested backup is a belief. The first test should not be a real recovery.
Could you evidence your SaaS data protection for an insurer?
Questionnaires increasingly ask about cloud data specifically rather than servers alone.
Frequently asked questions
The shared responsibility model defines which parts of a cloud service the provider secures and which parts remain the customer's. Microsoft protects the platform: infrastructure, service availability, physical security and their own hardware failures. The customer owns the data placed into that platform, who can access it, how long it is retained and whether it can be recovered. Both halves are reasonable. Confusion arises because the platform half is so reliable that people assume it covers the data half as well.
Not in the sense most people mean. Microsoft replicates infrastructure so their own hardware failures never affect you, and their service level agreement covers availability rather than the recoverability of data you deleted. Native features such as the recycle bin, file versioning and retention policies all live inside the same tenant under the same administrative control as the data they protect, which is why they are not equivalent to an independent backup held outside that environment.
Microsoft's documentation puts the maximum recycle bin retention for deleted items at 93 days, after which the item is permanently unrecoverable without an independent backup. Retention and litigation hold policies can preserve data for longer, but they are configuration inside the tenant rather than a copy outside it. The practical issue is less the length of the window than the fact that deletion is frequently not noticed until well after it has closed.
When the license is reclaimed, the associated mailbox and OneDrive content generally goes with it. This creates an awkward trade-off, because reclaiming the license is correct financial practice and losing the content is an unintended side effect. Businesses commonly discover the consequence months later when somebody needs a contract or a piece of correspondence from that account. An independent backup retains the content regardless of whether the account still exists.
Not reliably on its own. When an endpoint is encrypted, the damage syncs upward into OneDrive and SharePoint. File versioning is intended to help and frequently does not, because the encryption process writes enough successive versions to push clean copies out of the retained set. A backup stored independently of the tenant is unaffected, because the attack never reaches the environment it lives in, which is the reason storage location is worth asking about specifically.
User error, by a wide margin. Datto's State of the Backup research attributes 64 percent of SaaS data loss incidents to accidental deletion, overwrites and administrative mistakes, none of which are platform failures. AIIM and Datto also report that one in three organizations have experienced permanent data loss in Microsoft 365. The pattern in nearly every case is that the platform functioned exactly as designed, which is precisely why platform-level protection does not address it.
Yes. Google Workspace and Salesforce operate on comparable shared responsibility terms, where the provider secures the platform and the customer owns the data within it. Coverage gaps are common here because organizations that have thought about email backup often have not extended the same thinking to their CRM, which frequently holds the records they would least like to lose. Aureon's SaaS Protect covers Microsoft 365, Google Workspace and Salesforce.
No. Retention governs how long items are kept and when they are purged, and it operates inside the environment under the same administrative control as the data itself. A backup is a separate copy held outside that environment. The distinction matters when the problem is the environment: a compromised administrator account, a ransomware event or a misapplied tenant policy can affect retained data, while an independent copy remains untouched because the incident never reached it.
Could you restore an email from last year?
Get a free SaaS backup assessment. We'll walk the checklist with you and show you exactly where the 93-day window leaves you exposed.
