Ransomware Resilience Banking: Immutable Backup Architecture
Designing a Bank That Can Recover Without Paying
Every bank has backups, and most ransomware victims had backups too. The difference between an institution that restores in days and one that spends a fortnight negotiating is almost never the presence of backups. It is whether the copies were reachable by the same credentials that encrypted production, whether the retention window was longer than the attacker's dwell time, and whether anyone had ever restored an entire service rather than a test file.
Ransomware resilience banking work is therefore less about detection technology and more about a small set of architectural properties that hold up when your identity plane is compromised and your operations team is working from personal phones. The uncomfortable part is that most of those properties can only be proven by testing in a way that makes people nervous.
What does ransomware resilience actually mean?
Restoring critical services from data the attacker could not reach or alter, within survivable time, without their cooperation.
Note what that definition excludes. It says nothing about preventing intrusion, because prevention will eventually fail, and nothing about paying, because payment is not a recovery strategy and often does not restore service anyway. The NIST Cybersecurity Framework, now at version 2.0 released in February 2024, frames cyber risk management as a set of functions spanning governance through recovery rather than as a perimeter exercise, which is the right mental model: recovery is a designed capability, not the absence of a disaster.
Why is prevention the wrong primary objective?
Because the failure mode you are planning for is the one where prevention already failed.
Prevention investment reduces frequency and does nothing for severity. Resilience investment reduces severity regardless of how the intrusion happened, which makes it the more defensible allocation once basic hygiene is in place. That framing also changes who owns the programme: recovery capability is an engineering and operations deliverable with a board-level service commitment attached, not a security tooling purchase. The dependency mapping that makes it possible is the discipline described in this guide to moving from critical-process maps to live dependencies.
What does the business actually need to survive?
A defined set of critical services with recovery times the business has agreed and the technology can demonstrate.
Most institutions have recovery objectives per system and no agreed position on which business services must come back first, which is a different question and the one that matters at 3 a.m. Payments, customer access, and the ability to accept deposits usually outrank internal reporting by a wide margin. Get that ordering agreed before an incident, because deciding it live is how recovery efforts fragment across competing demands.
Could you name, in order, the first six services your bank would restore?
What makes a backup genuinely immutable?
Data that cannot be altered or deleted for a defined window, behind a separate control plane and separate credentials.
Immutability is a property of the whole arrangement rather than of the storage technology, and most failures happen in the parts people do not think of as backup.
| Approach | Protects against | Fails when |
|---|---|---|
| Production snapshots | Accidental deletion, single-system failure | Same account and identity plane as production |
| Object storage with retention lock | Alteration and deletion within the lock period | Lock period shorter than dwell time, or admin can shorten it |
| Separate account or tenancy with isolated credentials | Compromised production identity | Federated to the same directory being attacked |
| Logically air-gapped vault | Network-reachable attack paths | Restore path never tested, credentials stale |
| Offline media | Almost everything technical | Recovery time measured in days, handling process untested |
| Third-party managed vault | Internal compromise | Provider is itself a concentration risk |
Which properties actually matter?
Separate credentials, a separate control plane, a retention window longer than dwell time, and an immutable catalogue.
Separate credentials means the identity that can delete backups is not derivable from anything in production, including through domain trust or federated single sign-on. A separate control plane means the console, API, and policy that govern retention cannot be reached from a compromised production environment. Retention must exceed realistic attacker dwell time, since encryption frequently occurs weeks after initial access and your most recent copies may already contain the attacker's tooling. And the backup catalogue itself must be protected, because a vault full of data you cannot index is close to useless under time pressure.
Why do backups fail during real incidents?
Shared identity, encrypted catalogues, insufficient retention, and restores nobody has ever performed at scale.
Those four causes account for the majority of documented failures. The first is architectural, the second is a tooling configuration, the third is a policy decision usually made on cost grounds, and the fourth is a testing failure. All four are visible in advance to anyone who looks, which is why an honest review of these specific properties is the highest-value exercise available before an incident. The cost consequences of getting it wrong compound quickly, as set out in this analysis of what inflates ransomware recovery costs.
What has to be recovered before anything else?
Identity, key management, and the recovery infrastructure itself.
This is the sequencing error that costs the most time. Teams plan to restore applications and discover they cannot authenticate to the restored infrastructure, cannot decrypt the restored data, or cannot rebuild without a configuration repository that was itself encrypted. Plan and rehearse recovery of the directory and identity provider into clean infrastructure, of key material and secrets, and of the build pipeline and configuration needed to stand systems up. Key recovery in particular needs its own rehearsed ceremony, which is part of why key custody and recovery belong inside the design described in HSM and key management architecture.
How should recovery be tiered and sequenced?
By dependency order first, then business priority, with the sequence written down and rehearsed.
| Tier | Contents | Target |
|---|---|---|
| Tier 0 | Identity, key management, DNS, recovery tooling, clean build capability | Hours, before anything else can proceed |
| Tier 1 | Payment processing, customer authentication, core ledger read path | Same day |
| Tier 2 | Full core ledger write path, card authorisation, channels | One to two days |
| Tier 3 | Corporate channels, reporting to regulators, treasury tooling | Days |
| Tier 4 | Internal analytics, non-critical reporting, development environments | Weeks |
Dependency order beats business priority when the two conflict, because restoring a Tier 1 service without Tier 0 simply produces a broken service twice. Write the sequence down, keep it current as architecture changes, and store it somewhere retrievable when your intranet is down.
How do you test resilience honestly?
By restoring whole services into clean infrastructure using only the runbook and the isolated copies.
| Exercise type | What it proves | Frequency |
|---|---|---|
| File-level restore | The backup tooling works | Continuous, automated |
| Single service restore | One service can be rebuilt from isolated copy | Monthly, rotating |
| Tier 0 recovery rehearsal | Identity and keys can be restored independently | Quarterly |
| Full service-chain recovery | A business service works end to end after restore | Twice yearly |
| Unannounced scenario exercise | Runbooks and people work under pressure | Annually |
| Threat-led testing | Whether an attacker could reach the recovery estate | Per programme cycle |
The last row matters more than it appears. If your red team can reach the backup control plane, your immutability is theoretical, and that is exactly the kind of finding a structured threat-led programme surfaces, as covered in threat-led penetration testing. Testing recovery in production-like conditions is also the point of the broader discipline in this guide to disaster recovery for mission-critical platforms.
When did your bank last restore an entire business service from an isolated copy?
How do third parties change the picture?
They can take out your service and your recovery path simultaneously, so critical dependencies need alternatives.
The FSB's toolkit on third-party risk management and oversight, published in December 2023, provides tools for identifying critical third-party services, managing risk across the lifecycle of those relationships, and identifying and monitoring systemic third-party dependencies and concentration risk. Applied to ransomware, the questions are specific: if your recovery depends on a provider, what happens when that provider is the one compromised, what is the alternative, and has anyone tested it. The same applies to software supply chain: a compromised deployment pipeline can reinfect restored systems, which is why clean rebuild capability matters more than restoring the previous state.
What about the decision to pay?
Decide the position in advance, with legal and executive input, and remove the technical dependence that forces the question.
Whether to pay is a governance decision with legal and sanctions implications that must be settled before an incident rather than during one, and your role as a technology leader is mostly to make the question moot. If recovery is demonstrable, payment becomes a commercial choice rather than a necessity. Also plan for the second demand, which is the threat to publish stolen data, because that pressure survives a perfect restore and needs a communications and legal response rather than a technical one. Recovery capability does not remove extortion leverage entirely, and pretending otherwise leads to unpleasant surprises in the crisis room.
Which metrics prove resilience rather than activity?
Tested recovery time per tier, immutable coverage, isolation verification, retention against dwell time, and rehearsal currency.
Report tested recovery time rather than target recovery time, because the gap between them is your actual exposure and it is usually large. Track the share of critical services with genuinely isolated immutable copies, verified by attempting deletion with production credentials in a controlled test. Report retention windows against your assumed dwell time. Record when each tier was last rehearsed and treat anything stale as a finding rather than an accepted risk. And measure clean rebuild capability, meaning how long it takes to stand up a service from source in fresh infrastructure, since that is the only path that reliably removes an attacker.
How should delivery be phased?
Sequence and dependencies first, then isolation, then Tier 0 recovery, then service testing.
Start by agreeing the critical service list and the dependency-ordered recovery sequence, because everything else is scoped by it. Then fix isolation: separate credentials, separate control plane, retention longer than dwell time, protected catalogue. Then build and rehearse Tier 0 recovery, since identity and keys gate everything. Then work through service-level recovery testing tier by tier, fixing what each test reveals. Then add unannounced exercises and threat-led validation of the recovery estate itself. Where recovery depends on cloud infrastructure, the regulatory expectations around it are covered in cloud migration approval in banking, and the broader core-system recovery patterns are in this guide to disaster recovery for core systems.
Ransomware resilience is one of the few areas where the honest answer to a board question is verifiable. Either you have restored a full business service from an isolated copy recently, or you have not, and every bank that has been through an incident says the same thing afterwards: the test they wished they had run was the one they thought was too disruptive to schedule.
Frequently Asked Questions
What does ransomware resilience actually mean?
The ability to restore critical services from data an attacker could not reach or alter, within a time the business can survive, without depending on the attacker's cooperation.
What makes a backup genuinely immutable?
Data that cannot be altered or deleted for a defined retention window, protected by a separate control plane and separate credentials from the systems it protects.
Why do backups fail during ransomware incidents?
Because they share credentials or a domain with production, the backup catalogue itself gets encrypted, retention is shorter than the attacker's dwell time, or nobody ever tested a full restore.
What must be recovered first?
Identity and the recovery infrastructure itself. If your directory, credential store, and key management cannot be restored independently, nothing else can be brought back in a controlled way.
How long should immutable retention be?
Longer than realistic attacker dwell time, which usually means weeks rather than days, because encryption often happens well after initial compromise and recent backups may already be tainted.
Is a cloud snapshot an air gap?
No. A snapshot in the same account under the same identity plane is reachable by the same compromised credentials. Isolation is about control planes, not storage location.
What does a real recovery test include?
Restoring a full service, not a file, into clean infrastructure, using only the runbook and the isolated copies, with the people who would actually be on call doing it.
How does third-party concentration affect recovery?
A shared provider outage or compromise can take out your service and your recovery route at once, so critical third-party services need identified alternatives and tested exit paths.
