Ransomware Readiness: Why Incident Plans Fail and How to Test Recovery Before Attack
Ransomware readiness often looks solid on paper until the first real incident exposes the gaps. The contact list is out of date. The backup cannot be restored quickly. No one knows who can approve shutting down a system. Legal, operations, and technology teams all make reasonable decisions, but not always the same decision.
That gap is expensive. The Sophos State of Ransomware 2024 report found that 59 % of organisations surveyed were hit by ransomware in the previous year. Sophos also reported that the average cost to recover, excluding any ransom payment, reached 2,73 million US dollars. For a mid-sized company, especially in a regulated sector, those numbers are not abstract. They point to lost operations, customer impact, reporting duties, and weeks of pressure.
Why incident plans fail when they are first used
Most incident plans fail for practical reasons, not because people ignored them.
A new incident response plan is often written as a document, not tested as a working process. It may describe what should happen, but not who will do it at 02:00 on a Sunday when core systems are locked.
Common weak points include:
Decision rights are unclear
The plan says “management will decide”, but does not name the person or backup person.
The plan assumes normal communication still works
Email, chat, shared drives, and phone directories may be unavailable or untrusted during an attack.
The recovery order is missing
Teams know systems are important, but not which ones must come back first to keep the organisation running.
Backups are trusted without proof
A backup only matters if it can be restored, within the time the business can tolerate.
Regulatory duties are treated as an afterthought
Regulated companies may need to assess notification duties quickly, with accurate facts and clean records.
Suppliers are not included
Managed service providers, payroll systems, cloud platforms, legal advisers, insurers, and forensic specialists may all be needed.
The first version of a plan should be treated like a draft. Its value comes from use, correction, and retesting.
Run a tabletop exercise before the real attack
A ransomware tabletop exercise is a structured practice session. It walks the response team through a realistic ransomware scenario without touching live systems. The aim is not to catch people out. The aim is to find weak points while there is still time to fix them.
1. Choose a realistic scenario
Use a scenario that fits the organisation. For example:
A finance file share is encrypted on a Monday morning.
The attacker claims to have copied customer data.
Backups appear available, but the last restore test was six months ago.
A regulator may need to be notified.
A critical supplier cannot be reached.
Keep it specific. A vague scenario produces vague answers.
2. Invite the right people
A good exercise includes more than the technology team. Bring in:
Operations leadership
Technology leadership
Legal or compliance
Finance
Communications
Customer service or service delivery
The backup or infrastructure owner
Key suppliers, where possible
If the company has no dedicated incident response team, name a temporary response group and test whether it works.
3. Assign clear roles at the start
Before the scenario begins, state who plays each role. At minimum, name:
The incident lead
The technical recovery lead
The business decision maker
The legal or compliance lead
The communications lead
The note taker
The note taker matters. Regulators, insurers, and executives may later ask what was known, when it was known, and why decisions were made.
4. Add pressure in stages
Do not reveal the whole scenario at once. Introduce updates every 10 to 15 minutes.
For example:
Staff report locked files.
A ransom note appears.
A backup server shows suspicious activity.
A journalist emails the company.
A regulator deadline may apply.
A senior customer asks if their data is safe.
This shows whether the team can work with incomplete information, which is exactly what happens during a real attack.
5. End with decisions, not discussion
The session must produce clear answers:
Who can order systems to be disconnected?
Who approves external help?
Who decides if customers are informed?
Who speaks to law enforcement?
Who can approve or reject ransom negotiation?
What systems come back first?
Document gaps as tasks with owners and dates. If no one owns the fix, the same gap will appear in the next exercise.
Backup restore testing is the proof point
Backups are often described as the safety net for ransomware recovery. That is only true if restore works.
Backup testing should answer practical questions:
Can the organisation restore from a clean copy?
How long does the restore take?
Are passwords, encryption keys, and administrator accounts available?
Can restored systems connect to each other safely?
Which data is missing between the last backup and the attack?
Can the business operate in a reduced mode while recovery continues?
Testing should include full restore drills, not just backup success reports. A dashboard that says “backup completed” does not prove an application can run after restoration.
For regulated sectors, backup testing also supports evidence. It shows that recovery arrangements are not just stated, but tested. Keep records of test dates, results, issues found, and fixes completed.
A sensible pattern is to test one critical service at a time, then run a wider recovery test at least annually. Include offline or protected backup copies where possible, because Sophos reported that attackers often try to compromise backups during ransomware attacks.
Decide before the crisis who has authority
During a ransomware attack, slow decisions cause damage. Conflicting decisions cause more.
Every plan should state who has authority for four decision types.
Decision area | Primary owner |
Contain the attack, including disconnecting systems | Technical recovery lead, approved by the incident lead when time allows |
Keep operations running or pause services | Business decision maker |
Meet legal, regulatory, and contractual duties | Legal or compliance lead |
Engage outside parties, such as forensic support, insurers, or law enforcement | Incident lead with executive approval |
The ransom decision needs special attention. It should not be left to the technology team alone. It involves legal risk, financial approval, operational impact, insurance conditions, and possible sanctions concerns. The plan should name the decision group before an attack happens.
Good incident response readiness means the company knows how decisions will be made, even when facts are incomplete.
Make the plan a cycle, not a file
Ransomware readiness improves through repetition. Write the plan, test it, fix it, and test it again. After each exercise, update:
Contact lists
Recovery priorities
Supplier details
Communication templates
Backup restore procedures
Decision authority
Evidence and record-keeping steps
The goal is simple: when ransomware hits, the organisation should not be inventing its response under pressure.
If your organisation needs help turning a written plan into tested readiness, or if your incident plan has never been tested, we can help you rehearse it and keep it current through Security Operations Oversight service. Build the plan, test the recovery, and clarify decisions before attackers force the issue.
