Retention is not backup, versioning is not recovery, and "it's in the cloud" is not an answer.
Retention is not backup, versioning is not recovery, and "it's in the cloud" is not an answer.
Ask a firm where their Microsoft 365 backups are and you will usually get one of three responses. The confident one is "it's in the cloud, Microsoft handles it." The cautious one is "we have retention policies." The honest one is a pause.
All three are the same answer, and it is the wrong one.
Read the shared responsibility model rather than assuming it. Microsoft commits to the availability and resilience of the service. Their infrastructure is replicated, their uptime is excellent, and a datacenter failure is genuinely not your problem.
Your data is a different matter. Microsoft's own documentation is direct about this: you are responsible for your data. Their obligation is to run the service, not to protect you from your own deletions, your own misconfigurations, a malicious insider with administrative rights, or ransomware that arrives through a synced folder.
That is not a gap in the product. It is the design, stated plainly, and most firms have simply never read it.
It is worth being precise, because the native protections are real. They are just not backup.
SharePoint and OneDrive recycle bins. Two stages, and a combined retention window measured in weeks, not years. Long enough to catch the deletion someone notices on Monday. Not long enough to catch the one nobody notices until the quarterly close.
Version history. Genuinely useful, and the single best defense against a small ransomware event. It is also finite, and it is per-file. Restoring one document from version history is trivial. Restoring forty thousand documents across nine sites, each to the correct pre-encryption version, is a project, not a procedure.
OneDrive Files Restore. Self-service, roughly a month of history, rolls a single user's OneDrive back to a point in time. Excellent for exactly the scenario it was built for. It does not cover SharePoint sites, Teams, or Exchange.
Retention policies and litigation hold. This is the one that causes the confusion, so it deserves a direct statement:
"Retention prevents deletion. It does not create restore points."
If a file is encrypted, corrupted, or overwritten with garbage, a retention policy dutifully retains the encrypted, corrupted, garbage version. It has done its job. It has not saved you.
Retention answers "can we still produce this document for regulators." Backup answers "can we get the firm working again by Tuesday." They are different questions, and firms conflate them constantly, usually because the person who configured retention was solving a compliance problem and never thought about recovery.
Ransomware through the sync client. An endpoint is compromised, files are encrypted locally, and the OneDrive sync client faithfully replicates the encryption to the cloud. Version history is your only defense, and at scale, restoring from it is measured in days of engineer time and partial success.
The departed employee's OneDrive. Account is deleted, the retention clock starts, and it is shorter than most people assume. Six months later someone needs the model they built. This is the most common data loss event we encounter, and it is entirely self-inflicted.
The compromised or malicious administrator. Global Administrator can disable retention policies, delete sites, and purge mailboxes. Every native protection listed above is administered from inside the tenant, by the same identity an attacker would target first. A backup that lives inside the thing you are protecting against is not a backup.
The quiet corruption. A misconfigured integration, a bad script, a sync tool that overwrote a folder. Nobody notices for two months. Every native window has closed.
First, define the numbers. Not the product. The numbers.
For a fund on a trading day, both of these are small, and saying them out loud usually ends the debate about whether backup is worth the line item.
Then decide where the copy lives. The core principle is that a backup must survive the compromise of the environment it protects. That means a copy under separate administrative control, with separate credentials, ideally immutable for a defined window. If your Global Administrator account can delete it, it is not doing the job you think it is.
Then pick a tool. Microsoft now offers a native backup product for the major workloads. The established third-party vendors have been solving this for a decade and generally offer longer retention, more granular restore, and, importantly, a copy that is not administered from inside your tenant. Both are defensible. Which is right depends on your RPO, your retention obligations, and how much you value administrative separation.
We have a view, but it is genuinely a per-firm decision and we would rather have the conversation than sell you a logo.
Then test the restore. This is the whole point.
Nobody has a backup problem. Everybody has a restore problem, and they find out on the worst day.
So when you are evaluating your own position, or reading a vendor's, or answering an allocator's diligence questionnaire, the useful question is not "do we have backups."
It is: "when did we last restore something, what did we restore, how long did it take, and who watched?"
If the answer is "we have never tested a restore," then you do not have a backup. You have a subscription and an assumption.
Unsure about your disaster recovery posture?
KYA Consulting designs and tests recovery for firms where an outage has a price. If nobody at your firm can answer the recovery questions, get in touch.
Get in Touch