The thing nobody tells you about ransomware until you've sat through one is how many decisions arrive at once, and how bad the hour is when they do. It's rarely a civilised weekday afternoon. It's the small hours, or the start of a public holiday, and within the first twenty minutes a dozen consequential questions are all demanding an answer from people who are frightened, half-awake, and improvising.
We've been in that room. The organisations that come through it well are almost never the ones with the best luck or the biggest tools budget. They're the ones who made the hard decisions before the incident, calmly, with coffee, instead of during it, in a panic. Readiness is not a document. It's having already decided.
The decisions you don't want to make live
Picture the first hour. The questions that land, more or less simultaneously, include: what do we isolate, and who actually has the authority to pull production offline — because someone has to, and if that authority is ambiguous you lose an hour arguing while the encryption spreads. Which systems do we restore first, and are we certain the backups are clean and not themselves encrypted or tampered with? Who talks to staff, to customers, to the regulator, and when — because in the UAE, for a bank or a healthcare provider, the reporting clock is real and it's ticking? Do we involve law enforcement, legal counsel, the cyber insurer? And how do we preserve evidence while we're frantically trying to recover, so we can later understand what happened and prove we handled it properly?
Answering any one of these for the first time, live, costs time you don't have. Answering all of them at once, live, is how a bad night becomes a business-ending week. Every one of them can be decided in advance. That's the entire point of readiness.
Why the plan on the shelf doesn't count
Most organisations we assess have an incident-response plan. It's a document, it exists, it was written to satisfy a requirement, and it has never once been tested under anything resembling pressure. When the real thing hits, that plan does surprisingly little, because a plan nobody has rehearsed is just a theory about how people will behave in a crisis — and people in a crisis rarely behave according to theory.
The gap between having a plan and being ready to execute it is enormous, and it only closes one way: rehearsal. Not a read-through. An actual exercise where the people who'd be in the room are in a room, the scenario is realistic, and the facilitator keeps injecting the complications that always show up in the real thing — the backup that turns out to be incomplete, the key decision-maker who's unreachable, the journalist who's already called.
What readiness actually looks like
A programme that genuinely prepares an organisation, in our experience, works on three fronts at once.
There's the plan itself, but a usable one — not forty pages of prose, but a clear map of who decides what, at what thresholds, with which contacts, so that at 3am nobody is reading paragraphs. There's rehearsal, and it needs to happen at two levels: a technical tabletop for the people who'll do the containment and recovery, and a separate executive tabletop for the leadership who'll make the business, legal, and communication calls, because those are entirely different muscles and the executive one is almost always the weaker. And there's recovery capability — validated, isolated backups and a tested restoration path, because the grimmest moment in any ransomware incident is discovering that the backups you were counting on were online, reachable, and encrypted along with everything else.
Get those three working together and a ransomware event becomes a bad day with a known sequence of moves. Skip them and it becomes an improvisation with your business on the line.
Preserve while you recover
One hard-won lesson worth passing on: speed and evidence pull against each other, and you have to hold both. The instinct under pressure is to wipe and restore as fast as possible, get the business back, move on. Do that carelessly and you destroy the forensic trail — which means you can't establish how they got in, can't be sure you've evicted them, and can't produce the evidence a regulator or insurer will ask for.
We've seen organisations restore straight back into a reinfection because they rushed the recovery without understanding the root cause. Containment and recovery have to protect the evidence, not because forensics is a nice-to-have, but because without knowing the entry point you're just resetting the board for the same attacker to play again.
The uncomfortable question for your leadership
Here's the test we put to executive teams, and it's a useful one to sit with. If ransomware hit tonight, would your leadership know their first three moves? Not in general terms — specifically. Who declares the incident. Who authorises taking production down. Who picks up the phone to the regulator, and when the clock on that started.
If the honest answer is "we'd figure it out," that's the exercise to run this quarter, because "we'd figure it out" is exactly what everyone says right up until the night they're trying to figure it out with the business on fire. The cheapest ransomware incident by a wide margin is the one you were ready for.
If you only do one thing, start with the backups
Readiness has many moving parts, but if you're starting from nothing and can only fix one thing this quarter, make it the backups — because they are the single point on which most ransomware recoveries succeed or fail. And "we have backups" is not the same as being covered. The questions that matter are whether they're genuinely isolated from your production network, so the ransomware can't reach and encrypt them along with everything else; whether they're immutable, so an attacker who does reach them can't simply delete them; and whether you have actually tested a restore recently, end to end, rather than assuming the job that runs every night produces something usable. We've watched more than one organisation discover, at the worst possible moment, that their backups were online, reachable, and encrypted, or that they'd been failing silently for months, or that a full restore took days they didn't have. Fixing that one thing — isolated, immutable, tested backups — does more to guarantee you survive a ransomware event than almost anything else on the readiness list. Start there, then build the plan and the rehearsals around it.
If you'd like to pressure-test your readiness before an attacker does — a technical tabletop, an executive one, or an honest look at whether those backups would really save you — that's a conversation worth having now rather than later.