Resource Guide · Updated August 2026
Most ransomware advice is about prevention. This is about the other half — what has to already exist when prevention fails, what the first day actually looks like, and why the decisions that determine your outcome are made months before the attack.
The Short Version
Every business should try to stop ransomware reaching it. Not every business has thought about what happens on the day something gets through — and that second question is the one that determines whether an incident is a difficult week or the end of the company.
The outcome of a ransomware attack is largely decided before it happens. Whether your backups are reachable by the attacker, whether anyone has decided what order systems come back in, whether you know who to call in the first hour — those are all settled in advance or not at all. There is no version of this where you work it out calmly on the day.
This guide covers what to put in place beforehand, what the first 24 hours look like, how long recovery genuinely takes, and what your insurer will expect to see. It pairs with our backup, disaster recovery and business continuity service, and with the security layers intended to stop the attack landing at all.
Before an Attack
These are the things that cannot be arranged once an incident is underway. If you do nothing else with this page, work through this list.
This is the single item that most determines the outcome. Modern ransomware groups look for backups first and destroy them before triggering encryption, precisely because a business that can restore has no reason to negotiate. A backup sitting on a network share, or in a cloud console reachable with the same admin credentials the attacker just stole, is not out of reach.
What actually holds up is immutable storage — copies that cannot be altered or deleted for a fixed retention period, even by someone holding valid credentials — and offline copies, which are unreachable by definition. Having one of the two is the minimum. Having neither means your backup strategy has not been tested against the threat it exists for.
A backup that has never been restored from is an assumption. Test restores on a schedule, and record the result. The failure we see most often is not a missing backup; it is a backup job that has been quietly failing for months, or one that runs perfectly while capturing the wrong data.
When everything is down, the sequence matters enormously. Restoring a file server before authentication is working means nobody can log in to reach it. Bringing back the application before the database it depends on just moves the queue along. Decide the order while nobody is under pressure, and write it somewhere that does not itself depend on the systems being restored.
Your incident contact list — IT provider, insurer, legal counsel, senior leadership, key clients — needs to exist outside the environment. If the list is in the email system that is encrypted, or the file share that is locked, you do not have a list. A printed copy in a drawer is unglamorous and works.
Reality Check
In our experience the technical recovery is rarely what delays a business. It is discovering the backup excluded a critical server, or that the only person who knew the recovery order left last year, or that nobody can find the insurer's out-of-hours number. None of those are hard problems — they are just problems nobody had a reason to solve until the worst possible moment.
See how we plan and test recoveryAfter an Attack
The instinct in the first hour is to start fixing things. That instinct destroys evidence, tips off the attacker, and occasionally makes the situation materially worse. A better sequence:
| Roughly when | What matters |
|---|---|
| First minutes | Isolate rather than power off. Disconnect affected machines from the network so encryption cannot spread, but leave them running — shutting down can destroy evidence held in memory and occasionally makes decryption harder. |
| First hour | Call your IT provider and your insurer, in that order. Many policies require notification before you engage a recovery vendor, and ignoring that clause can affect the claim. |
| First few hours | Protect the backups. Verify they are intact and, if they are not already immutable or offline, get them out of reach immediately. Establish how the attacker got in, because restoring into an environment they still control simply repeats the incident. |
| First day | Decide what to tell staff and clients, and check your notification obligations. Silence is usually worse than an honest holding statement, and some reporting deadlines are measured in hours. |
| Before restoring | Close the entry point and revoke access before anything comes back online. Restoring first and securing afterwards is how businesses get encrypted twice in a fortnight. |
The recurring theme is that speed helps in the first ten minutes and hurts thereafter. Isolating quickly limits the damage. Restoring quickly, before you understand how they got in, invites a repeat.
The Question Everyone Asks
This is a decision for your leadership, your insurer, and your legal counsel — not your IT provider, and not something to work out under pressure. What is worth knowing in advance:
The businesses that are never really forced to confront this question are the ones whose backups survived. That is the practical argument for immutability, made better than any prevention statistic.
Expectations
Longer than people expect, and the reason is that recovery is not one restore. It is rebuilding or cleaning affected machines, restoring in dependency order, verifying data integrity, and confirming the attacker is genuinely out before anything reconnects.
With tested backups, a documented recovery order, and immutable copies, a small business is realistically looking at several days to be substantially operational. Without those, weeks is common — and a meaningful proportion of that time is not technical work at all, but people trying to establish what they had, where it was, and what order it went in.
Partial operation usually arrives well before full recovery. Getting email and phones back early buys enormous breathing room even while file systems are still being restored, which is another reason the recovery order deserves thought in advance.
Cyber Insurance
Cyber insurance has shifted from a product you could simply buy to one you have to qualify for. Carriers have concluded that certain controls separate manageable claims from catastrophic ones, and they now ask about them at application and again at renewal.
Tested backups covering cloud data as well as servers, multi-factor authentication, endpoint detection, and a documented incident response plan are all commonly required rather than encouraged. Answering optimistically on a questionnaire is a genuinely bad idea — a claim can be disputed if the controls you attested to were not actually in place.
We covered the current requirements and what changed in why cyber insurance is getting harder. The overlap with this page is not a coincidence: insurers are asking for the same things that determine whether you recover.
Keeping It Real
A recovery plan written eighteen months ago for infrastructure you no longer run is not a plan. Two kinds of testing keep it honest, and they are different exercises.
Restore testing is technical and should be routine: pull data back from backup on a schedule and confirm it is complete and usable. This catches silently failing jobs, which is the most common backup failure by a wide margin.
Tabletop exercises are the conversation, not the technology. Walk your leadership through the scenario — who calls the insurer, who talks to clients, who decides whether to send staff home, what happens if the person who normally handles this is on holiday. These reliably surface gaps that no technical test will, and they take an hour.
Revisit both after any significant change: a server replacement, a move to new premises, a migration, or a change in who runs your IT.
Common Questions
Related Resources
We review what you would actually be able to restore, how long it would take, and where the plan breaks — then tell you plainly. You keep the findings whether or not you work with us.
