Ransomware recovery starts long before the attack

The question that matters

Ask most IT teams whether they are protected against ransomware and the answer is a list of tools: endpoint protection, email filtering, a firewall, a backup product. Ask how long it would take to have the business running again if every server were encrypted tonight, and the room goes quiet.

That second question is the one that decides how a ransomware incident ends. Prevention matters and should keep improving, but no control stops every attack. When one gets through, the organisations that recover quickly are the ones that planned the recovery as carefully as the defence.

No control stops every attack. The organisations that recover quickly planned the recovery as carefully as the defence.

Attackers read your backup strategy too

Modern ransomware operations rarely encrypt on day one. They gain access, escalate privileges and spend time learning the environment. Backup servers, snapshots and recovery consoles are high on their list, because deleting those removes the victim’s best alternative to paying.

This changes what a good backup looks like. A copy that an administrator account can delete is a copy an attacker with that account can delete. The design has to assume that production credentials are compromised.

Five foundations of a recoverable estate

1. Follow 3-2-1-1-0Three copies of important data, on two different media, one offsite, one immutable or offline, and zero errors on verified restores. It is a simple rule that closes most of the gaps attackers rely on.
2. Separate the backup identityBackup infrastructure should not trust your main directory. Use separate administrator accounts with phishing-resistant MFA, and require a second person to approve deleting backups or shortening retention.
3. Make one copy immutableObject lock, hardened repositories or offline media mean the copy cannot be changed or removed before its retention ends, whoever is logged in.
4. Protect SaaS data as wellEmail, files and chat in platforms such as Microsoft 365 are part of the business too. Native retention is not the same as an independent backup.
5. Watch the backupsAlerts for failed jobs, sudden changes in data volume and attempts to alter retention settings are early signs that something is wrong.

Decide the recovery order now

When everything is down, everything is urgent. Without an agreed order, recovery becomes a series of arguments at the worst possible time.

Group systems into tiers with the business, not just within IT. Identity and core infrastructure usually come first, because nothing else can be restored or signed into without them. Then the systems that take orders, pay people and serve customers. Then the rest. For each tier, agree how much data loss is acceptable and how long the business can run without it.

Rehearse, then rehearse again

Restore tests should be routine, not a once-a-year event. Start with single servers, then whole applications, then a tabletop exercise that walks leadership through the first 72 hours of an incident.

• Who declares an incident, and who can authorise taking systems offline?
• How will people communicate if email and chat are unavailable?
• Who talks to customers, regulators, insurers and law enforcement?
• Where are the recovery runbooks stored, and can they be reached if the network is down?

Frameworks such as NIST CSF 2.0 put Recover alongside Identify, Protect, Detect and Respond for a reason. The first four functions reduce the chance of a bad day. Recover decides how bad it gets.