Ransomware is not really a technology problem once it has happened. It is a series of decisions taken under pressure, by people who did not expect to be taking them, usually before eight in the morning.
The businesses that come through it well are rarely the ones with the most security software. They are the ones who had already decided who does what.
Hour zero: how it usually starts
Someone cannot open a file. Then someone else cannot. A file name looks wrong — an extension nobody recognises. Within a few minutes it becomes clear this is not a glitch.
By the time it is visible, the attacker has typically been inside the network for days or weeks. The encryption is the last act, not the first. That matters, because it means the question is not only “how do we decrypt this?” but “what did they do while they were here, and what did they take?”
The first hour: contain
The single most valuable action is disconnecting affected systems from the network — pulling the network cable or disabling Wi-Fi, rather than shutting machines down, because a running machine preserves evidence in memory that a powered-off one loses.
This is where prepared businesses separate from unprepared ones. Taking systems offline stops the business trading. If nobody is empowered to make that call alone, it gets escalated, discussed, and delayed — and the encryption keeps spreading through the conversation.
Decide in advance who can pull the plug without asking permission. It is the cheapest piece of incident preparation available.
Hours one to four: work out the size of it
What is encrypted, what is not, and what was accessed. Which backups exist, when they last ran, and crucially whether they are reachable from the compromised network — because if they are, they may be encrypted too. This is precisely why modern ransomware hunts for backup systems before it deploys.
Two calls should happen in this window. Your cyber insurer, because most policies require their appointed incident responder to be engaged before recovery starts and calling them afterwards can affect the claim. And, if personal data may be involved, the clock on your ICO notification obligation has already started.
Could you answer these at 7am on a Monday?
Not whether you could find out. Whether you could answer now.
The 72-hour clock
Under UK GDPR, a personal data breach likely to result in a risk to individuals must be reported to the ICO within 72 hours of becoming aware of it. Ransomware almost always qualifies, because unavailability of personal data is itself a breach — even when nothing was exfiltrated.
Seventy-two hours sounds generous until you are in it. You will be simultaneously trying to restore systems, work out what was accessed, and answer questions from customers. Knowing in advance who writes that notification, and what evidence they will need, removes one problem from a day that has plenty.
Days one to five: recovery, and the decision nobody wants
Restoring from clean backups is the goal. It takes longer than anyone expects — not because copying data is slow, but because systems must be rebuilt in the right order, verified as clean, and checked before anyone is let back on.
Paying is a decision for the board with legal advice, not an IT decision. What can be said flatly is that paying does not reliably work: decryption tools supplied by attackers are often slow and incomplete, and payment does not prevent the stolen data being published. It also does nothing about how they got in.
What actually reduces the damage
Four things, in rough order of value.
Offline or immutable backups. A backup the attacker can reach is a backup the attacker encrypts. At least one copy needs to be genuinely out of reach — and it needs restore-testing, because an untested backup is a belief.
Multi-factor authentication everywhere. The most common entry route remains a stolen or reused credential.
Fast patching. The second most common route is a known vulnerability in something internet-facing.
Monitoring that someone reads. The gap between compromise and encryption is the window in which this is stoppable. Unmonitored alerts do not close it.
The thing worth doing this month
Write one page. Who decides to disconnect. Who calls the insurer. Who talks to staff and to customers. Where the phone numbers live if email is down. Then print it, because a plan stored only on the network is a plan you will not have.
If you would like help building that page, or you would rather find out now whether your backups would survive this, both are short pieces of work and a considerably better use of a morning than the alternative.
