Having Backups Isn’t the Same as Being Recoverable

“We have backups” is the most dangerous sentence in your disaster recovery plan. Not because it’s false. It’s usually true. There’s a job running somewhere, a green checkmark in a console, a vendor invoice that renews every year. The danger is in what the sentence quietly implies: that having backups and being recoverable are the same thing. They are not, and the gap between them is where companies discover, mid-incident, that the data they were paying to protect can’t be brought back fast enough, completely enough, or clean enough to matter. Any honest backup as a service evaluation has to start there — not with how much you can store, but with whether you can prove you’d get it back.

This is a backup as a service evaluation guide for the recoverability layer specifically. It assumes you already understand why you need backups. The harder, less-discussed question is whether the backups you have would survive a ransomware event, restore inside your actual time objectives, and cover the data you wrongly assume someone else is protecting. If you want the strategic layer above this one, start with where most business continuity plans quietly fall short — backup is one pillar of business continuity, and this article owns the technical pillar underneath it.

Backup vs. recoverability: the distinction vendors blur

A backup is a copy of data at a point in time. Recoverability is the proven ability to return that data to production, intact and usable, within a defined window, under the exact conditions you’ll face during a real incident. Vendors blur these two on purpose, because “backup” is easy to sell and easy to demonstrate, while recoverability is hard to guarantee and expensive to prove.

The blur shows up everywhere. A dashboard reports “100% of jobs succeeded” — but a successful write to a repository says nothing about whether that repository is reachable when your primary site is encrypted, or whether the restore would take 9 hours when your tolerance is 2. Marketing pages promise “instant recovery” while the fine print describes a single VM spinning up from a local cache, not your whole environment coming back after a coordinated attack. Retention is sold as protection, when retention without integrity verification is just a longer archive of potentially corrupt data.

Here’s the operating definition worth adopting: you do not have a backup until you have demonstrated a restore. Everything before a tested restore is a hopeful copy. The questions that follow — immutability, the Microsoft 365 gap, 3-2-1-1-0, RTO and RPO engineering, restore testing — are all different angles on the same demand: prove it, don’t assert it.

The Microsoft 365 / SaaS backup gap almost everyone assumes is covered

Ask ten IT leaders whether their Microsoft 365 data is backed up, and most will say yes without hesitation. Then ask who backs it up, and the room gets quiet. The assumption that Microsoft protects your data the way an on-prem backup protected your file server is the single most common and most dangerous gap we see in mid-market environments.

Microsoft operates a shared responsibility model. Microsoft is responsible for the availability and resilience of the platform — keeping the service running, replicating across their datacenters, surviving hardware failure. You are responsible for your data within that platform. Microsoft’s native features — recycle bins, retention policies, litigation hold — are not backups. They are short-window, configuration-dependent safety nets with hard limits. Deleted items age out. A retention policy is not a point-in-time restore. And none of it protects you from the threats that actually cause data loss in SaaS: a malicious or departing employee purging a mailbox, ransomware that syncs encrypted files up through OneDrive, an admin misconfiguration, or a third-party app with write access going rogue.

The Microsoft 365 backup gap is wide because the surface is wide. A real SaaS backup has to cover Exchange Online mailboxes, SharePoint sites, OneDrive for Business, Teams (which is deceptively spread across SharePoint, OneDrive, Exchange, and a chat back-end), and increasingly Entra ID configuration and conditional access policies. Most organizations that think they’re covered are covered for exactly one of these, by accident, through a retention setting. The same logic applies to every other SaaS platform holding business-critical data — if you can’t name the third party that takes independent, restorable copies of it, assume it isn’t protected.

The six capabilities that separate real data protection from storage

When you evaluate a backup-as-a-service provider, resist scoring them on storage capacity, price per terabyte, or how slick the console looks. Score them on the capabilities that determine whether you actually recover. These six separate genuine data protection from expensive storage.

Capability	What It Means	What “Proven” Looks Like	Red Flag
1. Immutability	Backups cannot be altered or deleted for a defined period, even by an admin or a compromised credential	Object-lock or WORM enforced at the storage layer; deletion requires a separate, time-locked process	“Immutable” that an administrator can toggle off on demand
2. Air-gap / isolation	At least one copy is logically or physically separated from production credentials and network	Separate authentication domain; backup repository not reachable from production with normal creds	Backup server joined to the same domain that gets encrypted
3. Integrity verification	Backups are automatically checked for corruption and restorability, not just job success	Scheduled, automated recovery verification with pass/fail reporting and alerting	“Job succeeded” is the only health signal
4. Granular + full restore	Recover a single item or an entire environment, from any retained point	Demonstrated single-file, single-mailbox, and full-system restores from multiple dates	Only full-image restore, or only “latest” available
5. Provable RTO/RPO	Recovery time and data-loss windows are measured under real conditions, not quoted from a spec sheet	Documented restore drills with actual elapsed times against your stated objectives	RTO/RPO described in marketing language with no test evidence
6. SaaS / M365 coverage	Independent, restorable copies of Microsoft 365 and other business-critical SaaS	Per-workload restore of Exchange, SharePoint, OneDrive, Teams, and Entra ID config	“Microsoft handles that” or partial coverage by retention policy

Use this as a scorecard, not a checklist. A provider can pass five and fail one — and the one they fail is often the one that decides the outcome of your next incident. Immutability without isolation still leaves you exposed if the attacker reaches the storage credentials. Granular restore without integrity verification means you can recover a file quickly and discover it’s corrupt. The capabilities reinforce each other; gaps compound.

Immutability, air-gap, and the modern 3-2-1-1-0 rule

The classic 3-2-1 backup rule — three copies of your data, on two different media types, with one copy off-site — was written for a world where the primary threat was hardware failure and natural disaster. It is still good advice and no longer sufficient. The threat model changed. Modern ransomware operators specifically hunt for and destroy backups before they trigger encryption, because they know an organization that can restore won’t pay. A 3-2-1 strategy where all copies are reachable with production credentials is a strategy an attacker can defeat in an afternoon.

The updated standard is 3-2-1-1-0:

• 3 — Keep at least three copies of your data (production plus two backups).
• 2 — Store them on two different media or storage types.
• 1 — Keep one copy off-site.
• 1 — Keep one copy offline, air-gapped, or immutable — unreachable and unchangeable by a compromised production environment.
• 0 — Maintain zero errors, verified through automated recovery testing and integrity checks.

The two new digits are where most environments fail. An immutable backup is one that cannot be modified or deleted for a fixed retention window, enforced at the storage layer — typically through object lock or write-once-read-many (WORM) policies. This is the single most important defense against ransomware destroying your recovery path, because immutability holds even if the attacker has stolen domain admin. The crucial test: can an administrator turn it off? If yes, it isn’t real immutability — it’s a setting an attacker who owns your credentials will simply disable. True immutability requires a separate, time-delayed process to override, by design.

The trailing 0 is the discipline most teams skip. Zero errors means restorability is continuously verified, not assumed. A backup that completes successfully but can’t be restored is worse than no backup, because it manufactures false confidence. Automated recovery verification — spinning up backups in an isolated sandbox and confirming they boot and pass integrity checks — is what turns the 0 from an aspiration into a fact.

Engineering RTO and RPO you can actually hit under ransomware conditions

Recovery Time Objective (RTO) is how long you can tolerate being down. Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time. Most organizations have numbers for these — usually pulled from a template or a compliance document — and almost none have validated those numbers against a real recovery, let alone a recovery during an active ransomware event.

The conditions matter enormously, because the RTO/RPO backup math that works on a calm Tuesday collapses under attack. Under ransomware conditions, your assumptions change in ways that destroy ordinary recovery estimates:

• You can’t trust production. You’re not restoring over a healthy environment — you may be rebuilding from bare metal onto clean infrastructure, which adds hours or days the spec sheet never mentioned.
• You restore everything at once. Recovery estimates based on restoring one server are meaningless when 200 servers and every endpoint need to come back simultaneously, competing for the same bandwidth and the same engineers.
• Forensics gates the restore. You can’t recover into a compromised network until you know how the attacker got in and confirm the backups themselves are clean. That investigation is part of your real RTO whether your plan accounts for it or not.
• Your most recent backups may be poisoned. If the intrusion predates detection, your latest restore points may contain the attacker’s foothold. Your true RPO becomes the last known-clean point, which can be days older than your stated objective.

Engineering recoverability means designing backward from these conditions. That includes tiered recovery (identifying which systems must come back first so your RTO reflects business priority, not alphabetical order), retention deep enough to reach a known-clean point well before a breach would plausibly be detected, and infrastructure ready to receive a full restore without waiting on hardware procurement. The cloud architecture decisions that make or break this — where recovery infrastructure lives and how fast it can scale — connect directly to the security decisions to lock down before you move workloads to the cloud. A provable RTO is one you’ve measured in a drill that simulates the real thing, not one you’ve asserted in a contract.

The backup as a service evaluation questions to ask before you sign

Sales demos are choreographed. The way to evaluate a backup-as-a-service provider is to ask questions that can only be answered with evidence, then watch how they respond when the answer requires specifics. Vague reassurance is itself a data point.

Bring these to the evaluation:

• “Walk me through your last full-environment restore for a client our size. How long did it take, end to end?” You want an actual elapsed time and a story, not a capability statement. Hesitation here tells you they sell backups, not recoveries.
• “Show me a recovery verification report.” If integrity testing is automated, they have artifacts. If they don’t, “successful job” is doing all the work.
• “Can one of your administrators — or one of mine with stolen credentials — delete the immutable copies before the retention window expires?” The only safe answer is a clear no, with an explanation of the separation that makes it impossible.
• “Exactly which Microsoft 365 workloads do you back up, and can you restore a single Teams channel, a SharePoint site, and Entra ID conditional access policies?” Specificity separates real M365 coverage from a checkbox.
• “What’s my realistic RPO if you discover the breach started two weeks ago?” This tests whether their retention and clean-point strategy survives a delayed-detection scenario.
• “If I leave, how do I get my data out, in what format, and how long does that take?” Portability answered uncomfortably is a sign of lock-in by design.

The same operating-model scrutiny you’d apply to any managed partner applies here — a backup provider is only as good as the team and process behind the console. The discipline of evaluating an MSP’s operating model and accountability is the right lens: who owns the restore when it’s 2 a.m. and the environment is encrypted, and what does their accountability actually look like in that hour?

Red flags that should stop a purchase

Some answers shouldn’t be negotiated around — they should end the conversation. If your evaluation surfaces any of these, treat it as a deal-stopper until it’s resolved in writing and demonstrated, not promised:

• “Immutable” backups that an administrator can disable or delete on demand — that’s a setting, not protection.
• No automated recovery verification — “the job succeeded” is the only proof of health they can offer.
• Backup infrastructure that shares credentials and network reachability with the production environment it’s meant to protect.
• RTO and RPO quoted from marketing material with zero restore-drill evidence to back the numbers.
• “Microsoft 365 is handled by Microsoft” — or M365 coverage that turns out to be a single retention policy.
• Recovery estimates based on restoring one server, presented as if they apply to a full-environment event.
• No documented strategy for reaching a known-clean restore point after delayed-detection ransomware.
• Retention windows too short to survive a breach that goes undetected for days or weeks.
• No clear, fast, well-documented path to extract your own data if you change providers.
• A provider who can’t or won’t describe a real, recent full restore in concrete terms.

Backups are easy to buy. Recoverability has to be engineered, tested, and proven — under the conditions you’ll actually face, not the conditions a demo is built to flatter. The organizations that come through a ransomware event intact are the ones that stopped trusting the green checkmark and started demanding the evidence.