Most enterprise recovery strategies are built on a quietly reasonable assumption: if something goes wrong, you restore from backup and carry on. The backup is the safety net. The recovery plan is the thing you test once a year and hope you never need. It's a model that has served organisations well for decades.

It was also designed for a kind of failure that's no longer the one most likely to hurt you.

The classic recovery model assumes the bad event is sudden and obvious. Hardware fails, a data centre goes down, someone deletes the wrong thing. The damage happens at a known point in time, you have a clean backup from before it, and recovery is a matter of rolling back. The whole strategy depends on there being a clean "before" to roll back to.

Modern ransomware was built specifically to break that assumption.

The attack no longer happens when you notice it

A serious ransomware operation today doesn't announce itself on arrival, it gets in quietly and waits. It maps the environment over weeks - sometimes months - learning where the valuable data sits, how the backups work, and where the recovery points are kept. It moves carefully enough to avoid tripping the alarms that were designed for noisier, faster threats.

And critically, it targets the backups. The attackers understand your recovery strategy as well as you do, because it's the thing standing between them and a payout. So they corrupt, encrypt, or quietly poison the backups first - well before they detonate the visible attack - so that when you reach for the safety net, it isn't there.

By the time you know you've been hit, the "clean before" your entire recovery plan depends on may already be compromised. You go to restore, and discover the backups you'd have restored from were part of the attack.

Why the perimeter logic doesn't hold

The companion assumption is that defence happens at the edge - keep the attacker out, and the data inside stays safe. Backup and recovery is what you fall back on if the perimeter fails.

But once you accept that a capable attacker is already inside, patient, and specifically hunting your recovery capability, the perimeter-plus-backup model starts to look less like a strategy and more like a hope. The perimeter will eventually be crossed by someone determined enough. And the backup - the fallback for exactly that scenario - is now the primary target. The two halves of the strategy fail together, and they fail in the order most likely to leave you with nothing to recover to.

This isn't a reason to abandon backups. It's a reason to stop treating them as a sufficient answer to a threat that was designed to defeat them.

What the shift actually requires

If the attacker is already inside and the backups are the target, then the questions worth asking change. How quickly can you detect malicious behaviour while it's happening, rather than after the fact? Can you identify which recovery points are genuinely clean, rather than assuming the most recent one is safe? How fast can you get from "something is wrong" to "we are recovering from a known-good state" - minutes, or the days it takes to work out what was compromised and when?

Those questions point toward a different model of resilience - one where detection and recovery are continuous properties of the environment rather than a plan you execute after the damage is done. That's a meaningful shift, and it's the subject worth exploring next.

The immediate point is narrower. If your recovery strategy still assumes a sudden, obvious failure and a clean backup waiting behind the perimeter, it's answering a threat that has largely been replaced. The attackers updated their model years ago. The defence is still catching up.