Immutability is the word every backup vendor puts on the box.
It means your backup can't be modified or deleted. It means ransomware can't reach it. It means you have a clean copy waiting when the worst happens.
What it doesn't mean is that you can actually use it.
I've spent 20 years at the C-level as a CISO, CIO, and CTO, and I've watched the difference between those two things turn into a crisis.
The CrowdStrike lesson nobody kept
In 2024, when the CrowdStrike sensor update caused one of the largest IT outages in history, most of the retrospectives focused on the same things: faulty code, rushed deployment, no staged rollout. All true. All relevant.
What got less attention was this: for many organizations, the backup servers were affected too.
Think about what that means. Your recovery target had the same problem as everything else. The thing you built to save you was underwater alongside everything it was supposed to save. Immutable backups don't help much if the infrastructure that reads them is offline.
Immutability is a property of the data. It says nothing about the availability of the system that holds it.
MGM figured this out the hard way in a different way. When ransomware hit their environment, the runbooks for recovery were encrypted along with everything else. The people who needed to execute the recovery plan couldn't access the recovery plan. It's a detail that sounds almost comically avoidable in retrospect. It cost them real money and real time during the outage.
Immutability is sold as a feature. It has to be an architecture.
The questions your vendor won't answer
Ask your backup vendor two questions and watch what happens.
First: what is the versioning depth before I run out of space?
Immutable backups work on the principle of versioning. Every version is retained for a defined period. You can't delete them. Which means they accumulate. Which means they consume storage. Eventually, you run out. The policy that governs when the oldest versions age out and free space is what actually defines your protection window.
Most vendors will show you retention policies. What they won't walk you through is what happens at the edges: what's the minimum clean copy you're guaranteed to have, and under what conditions does that guarantee break down?
Second: where do your runbooks live, and are they in scope of your own disaster?
This is the MGM question. Your recovery documentation, your escalation paths, your credentials and procedures, your vendor support contacts, the list of who has authority to declare a recovery complete. Are any of those things accessible from outside your primary environment? Or did they live on the same network that's now encrypted?
Most enterprises will pause on that question. They shouldn't have to.
What immutability actually requires
Immutability of the data is necessary but not sufficient.
You also need immutability of the recovery tooling. The backup system itself has to be outside the blast radius of whatever is taking down your primary environment. That means separate infrastructure, separate credentials, separate network paths. Not a different folder on the same server.
You need immutability of the process. Your runbooks have to be accessible when your environment isn't. That means offline documentation, printed procedures in a physical location, or a system that is definitionally not connected to the things that can be compromised.
And you need to understand the versioning economics of your specific environment. What's the cost of the storage depth that actually protects you? What's the retention window for the oldest clean copy you'd actually want to restore from? Are those two numbers aligned?
Vendors keep advancing their immutability stories with expanded platform coverage and stronger security controls. Those improvements are real. But no feature release resolves the architectural question: is your backup infrastructure outside the blast radius?
That's not a product answer. That's a design answer. And you have to make it.
The depth problem
Here's the number nobody publishes in the sales deck: at what storage consumption does your immutable backup policy start to break down?
If you're retaining ninety days of immutable backups for a large environment, what does that cost? What happens when storage costs force you to reduce retention? Are the policy decisions that govern that tradeoff made by IT, or by finance, or by procurement, or by nobody in particular until something goes wrong?
Immutability is not infinite. It ends where the budget ends or where the storage runs out. The question is whether you've explicitly designed for that boundary or whether you're going to discover it during an incident.
Design for it now.
What to do
Map your blast radius before something maps it for you. Identify every system that touches your backup infrastructure. If your primary environment goes down completely, what can still operate? What can still access your backups? What can still execute a recovery?
Audit where your runbooks live. Not where they're supposed to live. Where they actually are. Can your team execute a recovery without accessing your primary environment? If the answer is no, you have a runbook problem that no amount of backup technology solves.
Understand your versioning economics. Know your retention window, know the storage cost of that window, and make sure the people making budget decisions about storage know what they're trading away when they trim it.
A few specifics worth committing to:
- Enterprise IT leaders: Map your recovery blast radius. Know which systems would still be operational if your primary environment were completely unavailable. Design for that scenario, not just for partial outages.
- CISOs: The MGM problem is a process failure with a policy solution. Offline runbooks, out-of-band access, and recovery authority defined before an incident are controls you can implement today. Add them to your security program.
Immutability has an expiration date. Know when yours is.