Microsoft makes sure Microsoft 365 keeps running. Making sure your data is still there when something goes wrong is your job. This division of labor has been in Microsoft's own documentation for years, and it still surprises people in conversations who work with M365 every day.
We understand why. The cloud feels like a place where nothing gets lost. Mails show up on three devices, files have version histories, deleted items sit in a recycle bin. That looks like safety. It is something else: it is a very well run service. The difference between the two only becomes visible on the day you need data back that the service no longer has.
Does Microsoft 365 need a backup?
Usually yes, but not for the reason backup vendors like to tell. The trigger is rarely a mistake on Microsoft's side. The realistic loss scenarios sit with you: accidental or deliberate deletion, a compromised account, ransomware in the tenant, an offboarding that went wrong. For these cases, the built-in tools offer time windows, not guarantees. Whether that is enough for you depends on your data, not on gut feeling.
That is the short answer. The longer one is worth it, because it explains why both camps get it wrong: those who say "it is in the cloud, so it is backed up", and those who want to sell you a product with disaster slides before you know your own situation.
What Microsoft takes care of and what stays with you
Microsoft documents the division of labor openly, in the so-called shared responsibility model (Microsoft Learn, as of August 2026). For SaaS services like Microsoft 365, this translates to: Microsoft is responsible for data centers, network, operating system and running the application. Your data, your accounts, your configuration and your access controls stay with you in every row of the table.
The split makes sense. Microsoft cannot know which of your data is business critical, how long you need it and who may still see it after which departure. So Microsoft builds a service that runs reliably and leaves the decisions about the contents to you.
For Swiss companies there is a second layer: Under the nDSG you remain responsible for personal data, even when it sits with a cloud provider. Responsibility does not travel with the data into the data center. It stays at your company's address.
In our experience, the blind spot is a decision that was never made. Most SMEs have never consciously answered the backup question for M365. They migrated, it worked, and the topic disappeared from the list.
The pattern we encounter most often looks like this: With the old server there was a backup, because it was self-evident. Tape, NAS, an external provider, something. With the move to the cloud, responsibility for the servers moved to Microsoft, and in people's heads the backup moved along with it. Except that is written in no contract. The old backup was switched off, a new one never set up, and nobody ever decided on this state. It came about on its own.
The moment this surfaces is rarely a major incident. The small variant is more typical: An employee has been gone for half a year, his account was cleanly deleted during offboarding, the license freed up, everything done correctly. Then a contract question comes up, and the only person who received the decisive commitment by mail was him. The mailbox is long gone, permanently. No attack, no defect, no culprit. Only a deadline nobody had on their radar.
Recycle bin, retention, backup: three different things
The confusion arises because Microsoft 365 does come with mechanisms that look like data protection. It helps to keep them apart.
The recycle bins and restore windows are built for everyday mistakes. A deleted file, a mailbox cleaned up too quickly, an account removed by accident: for these they work well. But they have expiry dates. According to Microsoft's documentation, you can restore a deleted user account including its mailbox for 30 days, after that it is gone. Permanently. If the mistake surfaces on day 31, because the successor is looking for an old customer commitment, no support ticket will help.
Retention policies can hold data much longer. But they are built for compliance, not for recovery. They answer the question "may we delete this?", not the question "how do we restore half a team's mailboxes to a usable state on Monday morning?". Anyone who has ever tried to reconstruct a running operation from retention archives knows the difference.
A backup, finally, is an independent copy outside the reach of the system it protects. This property is what the built-in tools lack: Whoever holds admin rights in your tenant, legitimately or not, can reach recycle bins and policies. An attacker with full access does not only delete data, he can also adjust the mechanisms that were supposed to protect it.
Three scenarios where the difference becomes concrete:
- The quiet departure. An employee leaves the company on bad terms and cleans up beforehand. What he deleted in his final weeks often only surfaces months later, long after all the windows have closed.
- The compromised account. We see taken-over M365 accounts at Swiss SMEs on a regular basis. An attacker with mailbox access can set rules, extract data and delete traces.
- Ransomware in the tenant. Encrypted files sync obediently via OneDrive and SharePoint. Version histories help partially, but with thousands of files, "partially" quickly turns into a week of work.
Honesty also requires the other direction: For everyday use, the built-in tools are good. Version histories rescue the overwritten quote, the recycle bin the folder deleted too quickly, and the 30 days are enough for any mistake that surfaces promptly. Microsoft has not built in too little. The built-in mechanisms are only built for a different purpose than what many quietly expect of them.
None of the three scenarios above is therefore a reason to panic. All three are a reason to decide the question consciously instead of inheriting it.
How you decide the question for your business
The reflex we do not recommend: buying a backup solution because the vendor happened to call. The other reflex we recommend just as little: postponing the topic because nothing has happened so far. Both leave the matter to chance.
The better sequence starts with the data, not with the product. Three questions carry the decision:
First: Which data in M365 would be a business problem after a loss? Not everything is equally critical. Project archives from 2019 survive a loss, the order and contract correspondence of the last two years probably does not.
Second: How long after an incident would the loss surface? Everything that surfaces within the built-in windows is covered by the standard. Everything that surfaces later is only covered by a backup. Deleted mailboxes of former employees are the classic in this category.
Third: Who restores, and how fast? A backup that nobody has ever tested for recovery is a hope with license costs. That applies to M365 just as it does to any other security tool that was bought and never operated.
From these answers, the sizing follows almost by itself. Some businesses need a full backup with data held in Switzerland or Europe, including contractually agreed retention. Others do well with a lean setup for mailboxes and the critical SharePoint areas. And for some, the most uncomfortable insight is: access rights and offboarding need cleaning up first, because the biggest loss risk sits there, not in the missing copy. Right-sizing security means the same thing here: The risk determines the tool, not the other way around.
The cost side belongs in the same calculation, in both directions. M365 backups are usually licensed per user per year. If you pay for the whole tenant although only part of the data justifies the effort, you are buying a good feeling instead of protection. If, conversely, you skip it entirely out of thrift although two or three data areas carry the business, you are saving in the wrong place. Both are sizing errors, not budget questions. A backup that fits your data is, by the way, often cheaper than the tool subscription that was bought out of a fear presentation and has been running along ever since.
If you want a sober outside view on this: Exactly these operational questions, from data protection to offboarding, are part of our Security Management. An initial conversation costs nothing, and often it is enough to get the backup question off the to-do list.
The question behind the backup question
"Does Microsoft 365 need a backup?" sounds like a product question. It is in truth a question of responsibility: whether someone in your business has decided which data must survive for how long, and whether that decision is written down anywhere.
If that person and that decision exist, the product choice afterwards is remarkably calm. If not, then your real risk is not the missing backup but the unanswered question. Microsoft has put its part of the division of labor in writing. Have you?
