Immutable backups and ransomware recovery: from plan to rehearsal

Everyone has backups. Almost nobody knows whether they can restore. And modern ransomware does not go for your data first: it goes for your backups, because an organisation that loses those stops having an alternative to paying.

Immutable backups are the technical answer to that problem: a copy that, once written, cannot be altered or deleted for a defined period, not even by an administrator holding valid credentials. It sounds simple. Rolling it out across a live platform is not, and testing it even less so.

Why traditional backup is no longer enough

For years, backup protected against failure: a disk that dies, an accidental deletion, a data centre that goes down. Against failure, a copy reachable over the network is fine.

Against an attacker it is not, because an attacker thinks. They get in weeks earlier, escalate privileges, find the backup console and attack it before encrypting anything. By the time the encryption starts there is nowhere to go back to. That is the standard script, and it explains how an organisation with perfectly good backups can still end up paying.

The difference between holding out and paying is almost never the backup technology. It is whether that copy is reachable with the credentials the attacker has obtained.

What makes a copy immutable

Immutable is not a marketing adjective: it is a property that either holds or does not. Three conditions, all three at once:

• It cannot be overwritten. The system rejects any write over an object already written, wherever it comes from.
• It cannot be deleted early. There is a retention period that not even the platform administrator can shorten. If somebody can shorten it, that is not immutability: it is a policy.
• It sits outside the trust domain. Different credentials, different authentication, ideally a different provider or network. An immutable copy reachable with the same account that administers the servers protects considerably less than it appears to.

Beyond that, the variants are implementation detail: object lock on compatible storage, appliances with enforced retention, offline tape, replicas in a separate tenant. All of them work if the three conditions hold. None of them work if one fails.

The rule that actually holds up

The old rule of three copies, two media and one offsite fell short. The version that survives today adds two numbers: one immutable or offline copy, and zero errors on verification.

The second is the one almost nobody meets. A copy that has never been restored is not a copy: it is an intention. Automated verification that the set is recoverable — not that the job finished without error, but that the data comes back up — is what turns an inventory of tapes into a recovery capability.

From the plan to a real rehearsal

This is where most continuity plans fall over. The document exists, the diagram exists, the responsibility matrix exists. What does not exist is the time it was actually done.

What a rehearsal has to measure

Not «whether we can restore». That much is known. A useful rehearsal measures three things: how long it really takes to have the service standing again, how much data is lost along the way, and how many decisions had to be improvised because the procedure did not cover them.

The first two numbers are the recovery time and recovery point objectives you already have written down. The third is written nowhere, and it is the one that predicts how the real day will go.

The scenario nobody rehearses

Almost every rehearsal restores a server. The scenario worth rehearsing is a different one: the corporate directory compromised, the backup console unreachable, the administrative credentials burned, and an instruction not to bring anything up until you know how they got in.

That is where the unasked questions appear. Which identity do you authenticate with if the domain cannot be trusted? Where is the procedure if the intranet is encrypted? Who authorises a restore over production, and through which channel, if corporate email is down? Those answers are prepared in advance or improvised badly.

What DORA, NIS2 and ISO 22301 require

All three push in the same direction, with different emphasis. DORA asks for backup policies and restoration procedures, and for operational resilience to be tested rather than declared. NIS2 places continuity and crisis management among the minimum measures, with accountability at board level. ISO 22301 supplies the method: impact analysis, recovery objectives and periodic exercises with evidence.

The common denominator is the word evidence. In front of a supervisor, a plan with no documented exercises weighs the same as having no plan. I cover this in the ISO 22301 and business continuity guide and in the regulatory overlap between DORA, NIS2, ENS and the AI Act.

What I have seen in regulated platforms

Three recurring patterns, and none of them is about product.

The immutable copy exists, but hangs off the same directory. The feature was bought and then integrated with corporate authentication because that was the convenient thing to do. The day the directory falls, the copy falls with it. Identity separation is not a deployment detail: it is half of the control.

The recovery objectives are on paper. They are written in the plan and nobody has ever measured them under real conditions. When they are measured, the first figure always disappoints; and that is exactly what an exercise is for, rather than an incident.

Nobody has rehearsed the order. Restoring is easy; restoring in the right order, with live dependencies and without reinfecting what is already clean, is not. That order comes out of a dependency inventory, the same discipline that underpins any serious migration. You can see how it is applied across the nine programmes I have run in banking.

How long should retention be

The question people get wrong most often. The retention period on an immutable copy is not chosen by available space or by whatever the console defaults to: it is chosen by how long an attacker can sit inside undetected.

If your detection capability takes weeks to surface an intrusion and your immutable window is seven days, the protected copy will already be contaminated by the time you need it. The practical rule is simple: immutable retention has to comfortably exceed your mean time to detect, not match your archiving policy.

Almost nobody has that number measured. If that is your case, start by assuming it is worse than you think and size accordingly. It is one of those decisions where erring on the generous side costs storage and erring the other way costs the company.

Retention is not archiving

It is worth separating two things that usually end up in the same policy. Archiving answers a legal or contractual obligation to keep information for years. Immutable retention answers an operational risk: being able to return to a clean point. Different periods, different media and often different owners.

When they are mixed, the same thing always happens: expensive storage is paid for over seven years to meet an obligation a far cheaper copy would satisfy, while the window that actually protects against encryption is two weeks.

How to defend the cost to the board

Immutability costs money: storage that cannot be released early, often with a second provider. And it arrives at the table competing with projects that do generate revenue.

The argument that works is not fear, which wears out in two committee meetings. It is the comparison between two figures a board understands without translation: what a day of downtime costs, and how many days recovery takes without a guaranteed clean copy. That product is the cost of the risk, and it almost always dwarfs the storage bill.

If you can also show the result of a real exercise — how long it took you last time — the conversation changes tone. You stop arguing about hypotheticals and start arguing about a number measured in your own house. It is the same mechanism that makes project indicators defensible: nothing persuades like your own measurement.

The mistakes that repeat most

• Protecting the data and forgetting the configuration. Databases come back and what makes the service work does not: firewall rules, certificates, job definitions, integrations. The copy has to cover the service, not the file.
• Storing the plan inside the system that is going to fall. If the recovery procedure lives on the intranet, the day the intranet is encrypted the procedure does not exist.
• Never testing a cross-environment restore. Restoring into the same environment proves little. The useful test is standing the service up on different infrastructure, because that is what you will have to do if the original is compromised.
• Leaving the copy unmonitored. An attempted deletion inside the retention window is one of the cleanest signals there is that somebody is inside. If that event raises no alert, you have thrown away the best warning available.

Where to start this week

• Check which credentials reach your backup repository. If they are the same ones that administer the servers, you already have your first finding.
• Ask somebody to try to delete a copy inside the retention window. If they succeed, the immutability is nominal.
• Pick a business service, not a server, and restore it end to end against the clock. Write down the real time and the decisions that had to be improvised.

Three tasks, an afternoon each. All three tell you more about your real recovery capability than any backup status report.

Conclusion: the copy that counts

The only copy that counts is the one that survives an attacker holding your credentials, and the one somebody has already restored, with a stopwatch running. Everything else is inventory.

Frequently asked questions about immutable backups