Ransomware was involved in 48% of breaches analyzed in the 2026 Verizon DBIR, and 96% of ransomware victims were SMBs. Every backup vendor selling into that market now describes their product as immutable, air-gapped, or ransomware-resistant. The terms have been used loosely enough in recent storage marketing that they no longer reliably distinguish between architectural protection and a configuration setting an attacker with domain admin can switch off.
That gap is where recovery failures live. The organizations that pay a ransom despite having backups usually had backups that were, in the vendor's defensible sense of the word, immutable — just not in the sense that mattered when someone with stolen credentials went looking for them.
The Two Words That Need Interrogating
"Immutable"
The claim to test is where immutability is enforced. Real immutability lives at the storage layer: object-lock in S3-compatible storage, WORM on-premises, a hardened repository the backup software cannot rewrite. Marketing immutability is a policy setting in the backup application's own console — which means anyone who compromises that console, or the credentials that administer it, can turn it off.
The diagnostic question: "Which specific credential or role can shorten or remove the retention lock, and what happens if that account is compromised?" If any answer traces back to a single administrative account in the backup product, the immutability protects you against accidental deletion and mostly not against a targeted attacker. Modern ransomware operators specifically hunt backup consoles before encrypting anything, precisely because that is the cheapest way to remove your alternative to paying.
A second dimension is immutability depth — whether the retention lock satisfies a regulatory standard like SEC Rule 17a-4 or FINRA Rule 4511, or only the vendor's own definition. If you have a records-retention obligation, that distinction has consequences beyond ransomware.
"Air-gapped"
This term has degraded further. To be credible, an air gap should mean physical or logical isolation from the production network — not a separate VLAN, and not a separate VPN. Both of those are reachable from a sufficiently privileged position on your production network, which is exactly the position an attacker occupies by the time they are looking for your backups.
The diagnostic question: "Is the isolation architectural or configurational — and can it be defeated by privileged credentials on our production domain?" An honest vendor will tell you which of the two they provide. Some vendors explicitly disclaim strict technical WORM immutability and instead offer protection through genuine physical isolation with disconnected media, which is a legitimate architecture — arguably a stronger one — but a different claim that should be evaluated on its own terms rather than conflated with storage-layer immutability.
The Questions Vendors Don't Volunteer
1. "Does your backup infrastructure authenticate against our production identity provider?"
This is the most consequential question on the list and it is rarely asked. If your backup platform authenticates via the same Active Directory or identity provider as production, then compromising domain admin compromises your backups in the same motion. Separate authentication for backup infrastructure — a distinct identity source, or at minimum separately credentialed break-glass access stored offline — is what makes the isolation claim mean anything operationally.
2. "What is the minimum retention we cannot shorten mid-contract?"
Attackers who cannot delete backups sometimes settle for shortening retention and waiting. A retention floor that cannot be reduced without a multi-party or out-of-band process is meaningfully different from one an administrator can adjust in a console.
3. "How is a restore authenticated, and how fast is it in practice?"
Two failure modes hide here. Restores that require a credential nobody can produce during an incident — because the person holding it is unreachable, or the credential lives in a password manager on an encrypted system. And restore throughput that makes the backup technically valid but operationally useless: a full environment restore constrained by network bandwidth from cloud storage can take substantially longer than the business assumed. Ask for measured throughput against a comparable data volume, not a theoretical maximum.
4. "Do your backups include the systems we'd actually need first?"
Backup scope drifts. Domain controllers, identity infrastructure, certificate authorities, network device configurations, and the backup server's own configuration are all commonly outside the protected set — and all are things you need early in a recovery. So are SaaS platforms: Microsoft 365 and Google Workspace data, and increasingly the SaaS applications running your business, are frequently assumed to be covered by the vendor's own resilience and are not covered by your backup at all.
5. "What does a real restore test look like, and when did we last pass one?"
Backup job success is not restore validation. A meaningful test restores a real business system to a usable state and confirms application-level integrity — that the database comes up consistent, that the application starts, that data written shortly before the snapshot is present. Automated recovery verification that boots a restored image and runs a health check is a genuinely valuable feature; ask whether the vendor provides it and whether it is actually enabled in your configuration.
6. "If we're compromised, is your platform in scope?"
Backup vendors and the MSPs who resell them have themselves been targeted, because compromising one reaches many downstream environments. Ask what would happen to your data if the vendor's own management plane were compromised, whether your encryption keys are held by you or by them, and what their incident notification commitment to you is. Customer-held keys change the answer materially.
Reading the 3-2-1 Rule Correctly in 2026
Three copies, two media types, one offsite remains sound — but ransomware exposed a gap the original formulation did not address, which is why the extended versions add an immutability requirement and a verification requirement. The useful mental model: 3 copies, 2 media, 1 offsite, 1 immutable or genuinely offline, and 0 unverified restores.
The common SMB failure against that standard is having three copies that are all reachable from the production network with the same credentials. Copy count without isolation is redundancy against hardware failure, not against an adversary — and hardware failure is not what is generating the 2026 incident numbers.
How This Fits Provider Selection
If an MSP manages your backups, they are the party whose answers matter, and the questions above translate directly into contract terms.
Get RPO and RTO commitments in writing with a remedy attached — a provider unwilling to attach consequences to a recovery-time commitment has not sized the recovery. Get a documented restore test cadence with results delivered to you, not performed and filed internally. Get clarity on who is authorized to shorten retention or disable immutability, and require that changes to those settings generate an alert to someone outside the provider's operations team. And confirm the incident notification interval in hours, not "promptly" — which matters more than usual now that statutory reporting clocks are involved, as covered in our piece on CIRCIA's 72-hour reporting requirement.
For the underlying vocabulary and the RTO/RPO framing, our backup and disaster recovery buyer's guide is the companion to this piece, and what ransomware recovery actually costs covers the economics that make a validated restore path worth paying for.
The practical takeaway: ask two questions of any backup arrangement you already have. Which single credential could shorten our retention or disable immutability? And when did we last restore a real system and confirm the application came up clean? If the first answer is a domain admin account in the backup console and the second is that you have never done it, the ransomware resistance you are paying for is a marketing claim rather than an architecture — and that is fixable well before you need it.
Frequently Asked Questions
What does "immutable backup" actually mean?
It should mean retention enforced at the storage layer — object lock, on-premises WORM, or a hardened repository the backup software cannot rewrite — so that no credential in the backup application can shorten or remove it. It is frequently used to describe a policy setting in the backup console instead, which an attacker who compromises that console can disable.
Is a separate VLAN an air gap?
No. A credible air gap means physical or logical isolation from the production network. A separate VLAN or a separate VPN is reachable from a sufficiently privileged position on production, which is the position a ransomware operator occupies before they start looking for backups.
What's the most commonly missed backup scope item?
Identity and infrastructure — domain controllers, certificate authorities, network device configurations, and the backup server's own configuration — followed closely by SaaS data in Microsoft 365, Google Workspace, and business applications, which is often assumed to be covered by the platform vendor's resilience rather than by any backup you control.
How often should we test restores?
Frequently enough that the test is routine rather than an event, and with results documented and delivered to whoever owns the risk. What matters more than cadence is what the test proves: a real business system restored to a usable state with application-level integrity confirmed, not a successful backup job report.
← Backup and Disaster Recovery Buyer's Guide | Evaluating an "AI-Powered MSP" Claim →