Ransomware Recovery: A Business Continuity Plan That Works

The worst time to figure out your ransomware plan is the morning you need it. Screens are locked, a countdown timer is demanding payment in cryptocurrency, your phone is ringing, and someone is asking whether you can still process payroll. In that moment, the only thing that helps is a plan you wrote and tested while everything was calm. Most organizations have something they call a plan. Far fewer have one that survives contact with a real incident.

Assume You Will Be Hit

Prevention matters and you should invest in it. Patching, email filtering, endpoint protection, and staff training all lower your odds. None of them lower your odds to zero. The companies that recover well are the ones that stopped treating an incident as a remote possibility and started treating it as a scheduling problem. When you assume the breach will happen, your questions change. You stop asking how to keep them out and start asking how fast you can get back up.

Two numbers anchor the whole plan. Your recovery time objective is how long you can be down before the damage becomes serious. Your recovery point objective is how much data you can afford to lose, measured in time. If your backups run nightly, your recovery point is up to 24 hours, which means a Tuesday afternoon attack could cost you a full day of work. Decide what those numbers need to be for each critical system before anything goes wrong, because they drive every other choice.

Backups Are Only Real If You Have Tested A Restore

Everyone backs up. Plenty of those backups are useless when it counts. Modern ransomware hunts for connected backup drives and network shares and encrypts those too, so a backup sitting on the same network as your servers may be gone the moment your servers are. The practice that actually protects you follows a simple shape. Keep three copies of your data, on two different types of media, with at least one copy offsite and offline or otherwise immutable so attackers cannot reach it.

Immutable backups are the part worth pushing on. These are copies that cannot be altered or deleted for a set retention window, even by an administrator account, which is exactly what an attacker tries to steal first. And a backup you have never restored from is a hope, not a safeguard. Schedule a real restore test at least quarterly, time how long it takes, and write that number down. The first time you discover your full restore takes 30 hours should not be during the actual outage.

Every client who survived an attack well had two things in common. They had restored from backup as a drill at least once, and one specific person knew exactly who to call in the first ten minutes. The rest figured it out on the fly, and it showed.

— Incident Response Lead, IT services provider

Write The Runbook For A Bad Day

A runbook is the step by step document someone follows when the thinking part of their brain has checked out from stress. It names the first move, which is usually to isolate affected systems by pulling them off the network before the spread continues. It lists who declares an incident, who contacts your cyber insurance carrier, who calls outside counsel, and who talks to staff and customers. Print it. Store a copy offsite. If your runbook only exists on the file server that just got encrypted, you do not have a runbook.

Communication is the part people forget until it bites them. Decide in advance how you will reach your team if email and chat are down, which means having a phone tree or an out of band group that does not depend on your normal systems. Decide what you will tell customers and when, because silence during an outage erodes trust faster than the outage itself. If you carry cyber insurance, read the policy now, since many carriers require you to use their approved responders and to notify them within hours, not days, or the coverage shrinks.

Rehearse, Then Rehearse Again

A plan you have never practiced is a guess. Run a tabletop exercise once or twice a year where you gather the key people, present a realistic scenario, and walk through every decision out loud. You will find the gaps quickly. Someone owns a system but does not know the recovery steps. The insurance contact left the company. The offsite backup has been silently failing for two months. Better to find those in a conference room than at 2 a.m. during the real thing. The connectivity side matters too, because failover internet and a way to keep phones answering during recovery are part of continuity, not afterthoughts. Build the plan, test the plan, and keep it current as your systems and people change.