Ransomware recovery plan: how to build one with ISO 22301

What should a ransomware recovery plan do?

A ransomware recovery plan answers one question: when systems are encrypted and the attackers may still be inside, how does the organisation keep delivering its most important services and recover without reinfecting itself? Many plans called "ransomware recovery" are really IT restore runbooks: useful, but silent on which service comes back first, how much lost data the business accepts and what people do by hand meanwhile.

ISO 22301 supplies the missing part. Its clause 8 chain (business impact analysis and risk assessment, strategies and solutions, plans and procedures, exercise programme, evaluation) turns a technical restore into a business recovery. A ransomware plan written this way is not a separate document competing with the continuity plan; it is the continuity plan applied to one of the most likely scenarios an organisation now faces.

Why ransomware breaks ordinary recovery assumptions

Most continuity plans assume loss of a site, a supplier or a utility, with the systems intact. Ransomware reverses that: the building and the people are fine, and the systems are the problem.

• The backups may be affected. A backup reachable with the same administrator credentials as production cannot be assumed to survive.
• The last good copy is not the latest copy. If intruders were present for weeks, recent backups may contain their tools.
• Identity services go down with everything else. When the directory service is encrypted, nobody can sign in to the systems needed for the restore.
• Investigation and recovery compete. Investigators want affected systems preserved; the business wants them rebuilt.
• Disruption lasts longer. Rebuilding from clean sources is slower than failing over to a standby site.
• Data may have left the building. Where information was copied out, the incident also carries data protection notification duties.

Each belongs in the risk assessment under clause 8.2.3 and should lead to a decision under clause 8.3.

Building the plan on the ISO 22301 chain

The clause titles below are those of ISO 22301:2019; the ransomware questions are Sterling's recommended way of applying them.

Where the organisation also runs ISO/IEC 27001, the technical controls for backup, incident management and ICT readiness sit in that system, and the two share one BIA. The guide on ISO 22301 and ISO/IEC 27001 as one system explains how.

Setting the recovery order: time frames, data loss and the clean restore

The guide on running a business impact analysis covers the method; for ransomware, three outputs matter most. The recovery time objective tells IT what to rebuild first. The recovery point objective tells IT how far back it may reach for a clean copy, and therefore how often backups must be taken and how long they must be kept. The dependency list shows the hidden systems, such as directory services and name resolution, that must return first.

A worked example

Consider a BPO in the Philippines running payroll and customer-service work for three overseas clients. Its BIA finds that client voice services can stop for only a few hours before contractual penalties begin, payroll for two days if no pay run is due, and internal reporting for a week. All three rely on the directory service, so the recovery order starts with the foundations.

Every tier passes a validation step before users reconnect: the restored system is scanned, access is checked and the data is compared against the last known good state. Manual workarounds for Tier 1, such as paper call sheets and client escalation numbers held off the network, keep the service alive while Tier 0 is rebuilt.

Decisions to settle before the attack

In a ransomware incident, undecided questions cause more delay than technology. The response structure required by clause 8.4.2 should settle them in advance:

• Authority to isolate. Who can disconnect a site, a network segment or a cloud tenancy without waiting for a meeting, and on what evidence.
• Investigation versus rebuild. Which systems are preserved for investigation, which are rebuilt immediately, and who breaks a tie.
• The ransom demand. Who decides, who is consulted (legal counsel, the insurer, law enforcement where appropriate) and what the organisation's position is before any demand arrives.
• Notifications. Which regulators, clients and data subjects must be told, within what period, and who owns each notification. The register of obligations under clause 4.2 is the source.
• External support. The incident response provider, forensic support and insurer contact points, with how to reach them when corporate e-mail is down.

Under clause 8.4.3, contact lists, message templates and a meeting bridge must not depend on the corporate network.

Exercising the ransomware scenario

Clause 8.5 requires exercises on appropriate scenarios with defined aims. The guide on business continuity exercises sets out the formats; for ransomware, two exercises give the most evidence. A tabletop with management tests decisions: the moment of declaration, isolation, the ransom question, the first client message and the regulator clock. A restore test tests the technology: rebuilding a directory service and one Tier 1 application from protected backups, in isolation, timed against the recovery time objective.

Useful injects include encrypted backups, a client asking whether its data was taken, and intruders found to have been present for a month. The post-exercise report should record what took longer than planned, and clause 8.6 then requires the BIA, solutions and plans to be revised where the exercise exposed a weakness.

Where ransomware recovery plans fail

• Backups tested for existence, not restorability. A green backup console does not show that an application can be rebuilt in time.
• No foundation tier. Plans list business applications but forget the directory service and privileged access that every restore depends on.
• A plan stored on the network it protects. If the only copy of the plan and the contact list is on the encrypted file share, the plan does not exist on the day.
• No manual workaround. The business assumes IT will restore quickly and has never agreed how to operate for several days without systems.
• Suppliers left out. Managed service and cloud providers' recovery commitments were never compared with the BIA's time frames.

Ransomware recovery planning with ISO 22301: questions buyers ask