Ransomware has changed: So should recovery

Ransomware used to be treated like a break in problem. Harden the perimeter, block the intrusion, and you’re safe.

This framing doesn’t hold in a world where cybercriminals are increasingly resourceful, patient, and prepared. Today’s ransomware lives quietly in your environment long enough to map your identity model, locate your backups, and study the exact tools you’ll reach for under pressure. 

The objective has changed: rather than simply encrypting production, attackers are engineering your restoration to fail or become so uncertain you can’t trust what you bring back.

Strong controls help, but they aren’t enough. What really counts is the ability to recover on demand when everything else is failing, backed by evidence your recovery is clean and reliable. In other words, can you return to a trusted state, and  show it to the board and regulators without hesitation?

Prevention is essential. Recovery is the differentiator.

Cyberattacks are one of the biggest threats to UK financial stability, and geopolitical tensions are raising the stakes. Regulators, auditors, and boards all want evidence that’s practical and defensible. A disaster recovery plan isn’t enough if you can’t prove the environment you restore is clean, trusted, and accessible.

At a recent CRO Roundtable hosted by Shard Financial Media and sponsored by C&R Software, one principle stood out because it reflects how modern attacks behave: assume production will be fully compromised, then engineer a last line of defence with a completely different trust model.

Segregate. Transfer one way. Re-encrypt.

The recommended approach is deliberately simple and designed to keep working when everything else is in doubt.

First, create two genuinely separate cloud accounts or environments. This means no shared Identity and Access Management (IAM), no shared networking, and no shared administrative access to production. Access has to be limited to a minimal, audited break-glass process that’s hard to invoke and easy to evidence.

Second, use a secure, one-way replication mechanism that’s scheduled and time limited. Data should flow into a sterile recovery environment, with no inbound access back into production. If an attacker can traverse trust boundaries in both directions, it isn’t a boundary.

Third, re-encrypt data on arrival using an independent key hierarchy, paired with immutability controls and defined retention windows. Compromise of production keys or production recovery tooling shouldn’t give an attacker the ability to corrupt, delete, or lock your last good copy.

Finally, prove recoverability. Monitor replication integrity, retain audit logs, and run recovery simulations that restore into a clean environment. Then document results in a format that stands up to routine and board scrutiny.

This is when resilience becomes measurable. You’re no longer relying on optimism or assuming yesterday’s backup will be usable tomorrow. Instead, you’re setting a clear maximum data loss tolerance, then aligning replication cadence and recovery procedures to this outcome. In the roundtable discussion, 24 hours emerged as a meaningful benchmark because it forces real trade offs and clear accountability.

The “it’ll cost double” myth is usually a design myth

Some lenders assume this means duplicating everything and paying twice. In practice, the harder work is architecture and operating model discipline: deciding which services are truly critical, designing a clean trust boundary, and enforcing the controls keeping it intact.

Here’s another tip that came out of the CRO dinner. Don’t ask whether backups exist. Ask for proof that recovery is segregated from production, encryption keys are independent, and you can restore into a clean environment via a documented break glass process. Then set the tolerance that matters and make it real. That’s how you build operational resilience for the new age.

Find out here about the CRO’s Leaders’ Network.