The email, files and chat for the whole company live in Microsoft 365, and the assumption in most offices is that a large cloud provider is looking after all of it. In one sense that is true: the platform is resilient, the data centres are duplicated and the service rarely goes down. But resilience of the service and recoverability of your data are two different promises, and only the first one is made on your behalf. The second is yours to arrange.
The shared responsibility split
Cloud platforms operate on a shared responsibility model. The provider is responsible for keeping the service running: the hardware, the network, the software, the availability of the platform itself. The customer is responsible for the data inside it: what is created, who can reach it, what gets deleted, and whether a copy exists that can be restored when something goes wrong. Retention features and recycle bins are tools the platform offers you to manage your own data; they are not a backup service operated for you.
That distinction matters because most of the ways businesses lose data have nothing to do with the platform failing. They come from inside the tenant.
What retention and recycle bins actually do
Deleted email and files pass through recycle bins and recoverable-item stages before they are gone for good, and those periods are measured in days or weeks rather than years. Retention policies and holds can keep content for longer, and they are genuinely useful for compliance and legal purposes: they stop content being purged and let an administrator search for it. What they do not do is give you a clean point-in-time copy of a mailbox, a document library or a user’s files that can be restored in bulk to how it looked last Tuesday.
Retained content also lives inside the same tenant, under the same administrative accounts, subject to the same policies. Anyone with the right permissions can change the policy, and any incident that reaches the tenant reaches the retained copies too.
Where the gaps show up
Accidental and malicious deletion
A user empties a folder they thought was old. A frustrated employee clears out a shared library on their last day. Recycle bins catch the first case if it is noticed in time; the second is often discovered weeks later, once the window has closed. Retention policies help only if they were configured to cover that content before it was deleted.
Ransomware and synchronized files
File synchronization is a convenience and a risk. When ransomware encrypts files on a laptop, the sync client faithfully uploads the encrypted versions, and version history becomes the only recovery path. Some platforms offer a limited rollback window for personal file storage, which is valuable, but it is not designed as a full recovery mechanism across a whole organization and it has to be used within a limited time.
Departed users
When a licence is removed from a leaver, their mailbox and files enter a deletion path unless someone deliberately preserves them, whether by placing a hold, converting the mailbox to a shared one or transferring ownership. In busy organizations that step gets missed, and the data goes with it.
Retention gaps and configuration drift
Retention is only as good as the policy that was applied, and policies drift: new sites are created outside the scope, licences change, an administrator adjusts a setting during a migration. Nobody notices until a restore is needed and the content is not there.
What a real third-party backup adds
An independent backup takes regular point-in-time copies of mailboxes, calendars, contacts, files, shared libraries and team data, and stores them outside the tenant under separate credentials. That gives you three things retention cannot: a copy that survives whatever happens inside the tenant, the ability to restore an item, a folder, a mailbox or a whole site to a specific date, and retention that you control for as long as your business or your regulator requires. It also lets you keep the data of departed users without keeping their licence, and search across it when a legal or HR question arises. Our managed backup service treats cloud data this way for exactly these reasons.
Restore testing is the actual product
A backup that has never been restored is a hope, not a control. The value of a managed service is that restores are tested on a schedule, that someone confirms the jobs actually ran, and that the recovery time for a mailbox or a library is known before it is needed. Ask whoever runs your backup when the last test restore happened, what it recovered, and how long it took. If the answer is vague, the backup is not finished.
Common questions
Does Microsoft 365 back up my data automatically?
The platform protects the service and offers recycle bins, version history and retention features that you configure. Those tools help with recent deletions and with legal holds, but they are not a point-in-time backup held outside your tenant. Recovering from ransomware, a malicious deletion discovered late, or a departed user’s data usually needs an independent backup you arrange yourself.
Is a retention policy enough for compliance?
Retention policies are a good compliance tool because they prevent content from being purged and make it searchable. They are not a substitute for backup, because they cannot restore a mailbox or library to a previous state, they can be changed by an administrator, and they live inside the same tenant as the data they protect. Most organizations need both.
What should a Microsoft 365 backup cover?
Mailboxes, calendars and contacts, personal file storage, shared document libraries and team or channel data at minimum, with the ability to restore a single item as well as a whole account. It should store copies outside the tenant with separate credentials, retain them for as long as your business requires, and be tested regularly so restore times are known rather than guessed.
How often should cloud data be backed up?
Most organizations run several backup passes a day for mailboxes and files, because the acceptable amount of lost work is usually measured in hours, not days. The right frequency depends on how quickly your data changes and how much rework you could tolerate after an incident. That decision should be made deliberately and written down, then reflected in the backup schedule.
If you are not certain what would happen to your cloud data after a bad deletion or a ransomware event, our managed backup and cloud services pages describe how we protect it, and you can contact us to have your current retention and backup setup reviewed.
