En bref. « On est sur Microsoft 365, donc c'est sauvegardé » est faux, et c'est la croyance la plus coûteuse de la suite. Microsoft répond de l'infrastructure ; vos données sont votre responsabilité, c'est écrit dans leur modèle de responsabilité partagée. Dans Exchange Online, un élément purgé survit 14 jours par défaut, 30 au maximum. Une rétention n'est pas une sauvegarde et une réplication non plus. Cet article donne les fenêtres réelles par service et les trois questions à poser avant de découvrir le problème un mardi matin.
The sentence that costs the most
"We use Microsoft 365, so our data is backed up."
It is the most common and most expensive misconception in the suite, and it is not a misreading of anything Microsoft published. Microsoft is explicit: the service runs on a shared responsibility model where Microsoft is responsible for the cloud and the customer is responsible for the data within it.
That is standard across every major cloud provider. It is also the paragraph nobody reads until the week they need it.
What you actually have
Microsoft 365 ships several features that look like backup from a distance and behave nothing like it up close.
Recycle bins. SharePoint and OneDrive have a two-stage bin — a first-stage bin the user can restore from, and a second-stage bin for administrators. Items move through and out on a schedule. They are a safety net for the file you deleted this morning, not an archive.
Version history. Useful for a document someone overwrote. Useless for a document someone deleted, and useless if the corruption predates the versions you kept.
Retention policies. These are the most misunderstood, because they genuinely do keep data. But retention was designed for content lifecycle management and compliance — keeping records for a legal period, deleting them when the period lapses. It is not point-in-time recovery. You cannot use a retention policy to say "put the tenant back the way it was on the fourth of March."
Replication. Microsoft replicates your data across datacentres, which protects against a datacentre failure. It does not protect against you. Deleted and corrupted data replicates as deleted and corrupted, efficiently and everywhere.
The windows, specifically
The exact numbers are the part that changes people's minds, because they are shorter than almost everyone assumes.
In Exchange Online, an item a user deletes goes to Deleted Items. Emptied from there, it goes to the Recoverable Items folder, where it survives 14 days by default. An administrator can extend that to 30 days — and 30 is the maximum. Past that, it is gone.
Approximately 25% of organisations relying only on short retention settings permanently lose data older than three months.
That statistic describes the real failure mode, and it is not the dramatic one. Nobody loses a datacentre. Somebody deletes a SharePoint folder in February, nobody notices until the audit in June, and by then every window has closed.
The scenarios native features do not cover
Delayed discovery. The gap between a deletion and someone noticing is usually weeks. Every native window is measured in days.
A departed employee's data. When a licence is removed, the mailbox and OneDrive enter a deletion path. If nobody thought to preserve them first, the clock is already running.
Ransomware that encrypts before it announces itself. Encrypted files sync to SharePoint and OneDrive as legitimate changes and replicate cheerfully. Version history helps if the version count is high enough and the encryption was recent enough. Neither is reliable.
A misconfigured retention policy. A policy that deletes after a period does exactly that, on schedule, whether or not the period was set correctly.
Loi 25 obligations. Being able to produce a record, and being able to prove you deleted one when asked, are both data-handling obligations. Neither is satisfied by "it is in the cloud."
What a real backup looks like
Four properties. Anything missing one of them is not a backup.
It is outside the tenant. A copy that a tenant-level compromise can reach is not a copy. This is the property native features cannot have by definition.
It has a retention window that matches the discovery gap, not the deletion date. If deletions typically surface months later, a 30-day window is decorative.
It covers the services you actually use — Exchange, SharePoint, OneDrive, and Teams. Teams is the one most often missed, because its data lives across several underlying services.
It has been tested by restoring from it. This is the one that separates a backup from an intention, and it is the one that gets skipped. A backup nobody has restored is an unverified assumption with a monthly invoice.
Three questions to ask this week
1. What is our actual retention window, per service? Not the assumed one. Check the Exchange setting rather than trusting that someone extended it.
2. Is there a copy outside the tenant? If the answer is a Microsoft feature name, the answer is no.
3. When did we last test a restore? If the answer is "never," there is no backup — only an arrangement that has never been asked to work.
Microsoft's own guidance supports all three. This is not a gap they hide; it is a division of responsibility that most buyers have never been walked through.
In short
Microsoft keeps your data available. Availability means the service is up and the data is where you left it. It does not mean recoverable after somebody deletes it, encrypts it, or lets a retention policy run its course.
Fourteen days, extendable to thirty. That is the window. Everything past it is a decision you have either made or defaulted into.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.