3 September 2026LANTEK Computers
This one comes up in nearly every conversation about backup, and it is a completely reasonable assumption to have made. The mail is in the cloud. Microsoft is one of the largest companies in the world. Surely that is the backup.
It is not, and the reason is worth understanding properly, because it is not a gap Microsoft is hiding. It is a division of responsibility they state openly, and once you see where the line falls the rest follows.
What Microsoft is actually promising
Microsoft’s commitment is about the service. They undertake to keep it running, to keep it available, and to make sure that a failure of their infrastructure does not lose your data. They replicate across data centres and they are extremely good at it.
What they do not undertake is to protect your content from you. If a member of your staff deletes a folder, or a departing employee empties their mailbox, or somebody with a compromised account deletes a year of correspondence, that is not a Microsoft failure. The service worked exactly as designed. It did what the signed-in user asked it to do.
This is usually described as shared responsibility, and the short version is: they are responsible for the platform being there, you are responsible for what is in it.
The four ways businesses actually lose data in Microsoft 365
Not one of these is an outage.
Somebody deletes something and nobody notices for months. By far the most common. A folder gets dragged somewhere, or a shared library gets tidied up by somebody who did not realise what they were tidying. There is a recycle bin, and it holds things for a while, and that while is finite. Notice inside the window and it is trivial. Notice afterwards and it is gone.
An account is closed and the mailbox goes with it. This one catches businesses regularly, and it is expensive. Somebody leaves, the licence is removed to stop paying for it, and the mailbox is deleted along with it. Months later there is a dispute, or an audit, or a client asking about an agreement, and the correspondence that would have settled it does not exist.
A compromised account deletes deliberately. An attacker who has been in a mailbox and wants the evidence gone. This is the case where the damage is intentional and targeted at exactly the thing you would use to investigate.
Ransomware reaches synced files. If a machine is encrypted and its files are synchronised to the cloud, the encrypted versions sync too. There is version history that helps here, and it does help, but restoring a large library version by version at speed under pressure is not the experience people imagine when they say it is in the cloud.
The retention question, and why we are not giving you a number
The obvious next question is how long the recycle bin holds things.
We are deliberately not putting a figure in this article, and it is worth explaining why rather than looking evasive. The windows differ between mail, files and sites, they differ by licence level, and Microsoft has changed them more than once. Any number written here would be wrong for some readers immediately and for everyone eventually.
What is durable is the shape of it. There is a period during which deleted items are recoverable, it is measured in weeks rather than years, and after it they are not. So the practical question for your business is not what is the number. It is: how long could something be deleted here before anybody would notice?
For a mailbox somebody uses daily, probably not long. For an archive folder or a shared library nobody opens between audits, easily longer than any retention window. That gap is the exposure, and it is specific to you rather than to Microsoft.
Ask your provider for the current windows on your specific licences, get the answer in writing, and diarise a check on it. That is more useful than any figure we could print.
Retention policies are not backup either
Worth separating these, because they are frequently conflated.
A retention policy stops things being deleted, or keeps a copy for compliance purposes. It is a legal and governance control and it is a good thing to have.
It is not a backup, for two reasons. It is not designed for recovery: getting content back out of a retention hold is a search and export exercise, not a restore, and it is slow and awkward at volume. And it lives inside the same tenant. If the problem is the tenant, whether that is an administrative account compromise or an account closure, the policy is inside the blast radius.
A backup lives somewhere else, under separate credentials, and restores in bulk. Those are the two properties that make it a backup.
What actually covers this
A third party backup of the tenant. It runs on its own schedule, holds data outside the tenant under separate credentials, keeps it for a period you choose rather than one Microsoft chooses, and restores at a useful granularity: a single message, one mailbox, one library, or everything.
Two properties matter more than the rest. The retention period should be long enough to cover the realistic gap between something being deleted and somebody noticing, which in most businesses means well beyond a few weeks. And it should cover a mailbox after the account has been closed, because that is the specific case that costs money.
A quick way to find out where you stand
Three questions, and you can put all three to whoever supports your systems today.
If somebody deleted a shared folder eight months ago and we noticed today, could we get it back? This is the whole article in one question.
When a member of staff leaves, what happens to their mailbox, and for how long? If the answer is that the licence is removed, ask what happens to the contents.
Has anyone restored anything from Microsoft 365 here, and what was it? Same test as any other backup. An untested restore is a plan.
The point underneath all of this
Cloud changed where data sits. It did not change who is responsible for it. The platform is more reliable than the server it replaced, by a wide margin, and that reliability addresses hardware failure, which was never the main way businesses lost data anyway. Deletion, departure and compromise all still work exactly as they did.
The same reasoning about what recovery actually requires is in backup is not the same as disaster recovery, and the test that turns a backup into a control is in how to test a backup.
What we cover is on Backup and Disaster Recovery and Cloud Computing. If you are not sure what your current position is, ask us and we will find out with you.