Cyber Resilience & Recovery Pack — Guide

Cyber Resilience & Recovery

Most recovery plans were written for a fire or a failed server: switch to the second site, restore last night’s backup, carry on. Ransomware breaks every part of that. Replication copies the damage to the second site. The attacker may have been inside for weeks, so last night’s backup may hold the attacker too. The sign-in directory and the administrator accounts you would recover with may now be the attacker’s. This pack plans recovery for that case as well as the ordinary one. You agree with the business how long each service can be down, check that what it depends on can come back in time, rebuild the foundations first from sources you trust, and let each system back only when it is shown to be clean.

Is this for you?

This pack is for you if:

• your recovery times were set by IT and nobody in the business has agreed them;
• you have never worked out how long recovery would take if the sign-in directory itself had to be rebuilt;
• a supplier runs a system you depend on, and you do not know how fast its contract says it will recover;
• NIS2 or DORA applies to you, and you cannot show a tested continuity and recovery plan for each critical service.

How it works

Start with the business, not the systems. For each critical service, its business owner rates how the harm grows over time, at 4, 8, 24 and 48 hours and on to a week, on the same impact scale as your risk register. The first point at which the harm becomes Severe is the maximum tolerable downtime. The recovery time objective must be shorter than that, and the recovery point objective says how much data the service can lose.

Then check the objectives against reality. Every system, supplier and data set the service depends on must recover inside its recovery time. Every backup must run at least as often as its recovery point. Every supplier that runs a system you need must have a recovery time in its contract. And the service’s cyber recovery time must fit too: the time to rebuild the foundations, then its own systems, from clean sources. A service that can be back within its objective after a server failure may take twice as long after an attack. Each check that fails is a gap with an owner and a date.

Recovery runs in seven stages, starting where incident response ends: assess, isolate and prepare a clean recovery environment, rebuild clean, restore data from a copy taken before the attacker arrived, validate, return to service in stages, and stand down. Twenty-two gates stand between a rebuilt system and production. The incident response plan keeps every decision it already makes: who isolates, who stops a service, and that only the board or its equivalent decides on a ransom.

Each critical service’s recovery is tested at least once a year, against its objectives, with the time achieved recorded. A tabletop exercise is useful, but it is not a recovery test.

How it runs in practice

Take a distributor with 900 staff, three warehouses and an online ordering service, an important entity under NIS2. After ransomware hit 14 office PCs at one warehouse in August 2026, its Head of Risk coordinated a review of the continuity plans. In two weeks of workshops the business owners re-agreed the objectives of its five critical services.

The checks found nine gaps. Online ordering can be down for 2 days, but its last restore test took 4 days. The rebuild of its recovery goes to the board in October and is due in December. Warehouse dispatch was restored in 5 hours in an August test, inside its 8 hours. After an attack, though, the sign-in directory and the network would have to be rebuilt first, and dispatch would take about 17 hours. The Head of Logistics accepted printed pick lists to carry dispatch through that gap, and the first cyber recovery test will measure the real time in February. Six suppliers’ contracts give no recovery time at all, and the network provider’s 12 hours is longer than dispatch can wait.

Two of the five services have been restored within their objectives in the last year. The test plan reaches all five by March 2027, and stays away from November and December, the peak season.

Start with these three

1. Critical Service Recovery Objectives Matrix (RTO, RPO, MTD): the impact analysis, the objectives, and the checks that find what cannot be met.
2. Resilience Dependency Register: what each service depends on, how fast each part recovers, and the single points of failure.
3. Cyber Recovery Operating Procedure: the seven stages from containment to stand-down, with who does what.

Your first round

What to report

Each quarter, to executive management, and each year to the board or its equivalent:

• critical services with objectives agreed and plans current, out of all of them;
• services whose recovery was tested in the last 12 months, and those restored within their objective;
• services that could not recover in time, by name;
• objective gaps open, and any past due, by name;
• crisis and recovery roles without a deputy.

Everything in the pack

Adapting it

• Incident response: the Incident Response Plan and the Ransomware Response Playbook handle containment, evidence and eradication. This pack starts where they hand over, and changes none of their decisions.
• Exercises: a tabletop exercise tests decisions; a recovery test restores systems and measures the time. Plan both.
• Suppliers: put recovery times into contracts at the next supplier assessment, and compare them with the services that depend on them.
• Certification: ISO 22301 is the international standard for business continuity management systems. This pack does not follow its structure, and using it is not certification.

Framework references

• ISO/IEC 27001:2022: Annex A 5.29 and 5.30.
• ISO 22301:2019 (with Amendment 1:2024), Security and resilience — Business continuity management systems — Requirements.
• NIST CSF 2.0: RC.RP-01.
• NIS2: Article 21(2)(c); for the providers its Article 1 names, Implementing Regulation (EU) 2024/2690, Annex point 4.1.1.
• DORA (financial entities): Articles 11(1) and 12(1).
• GDPR: Article 32(1)(c).