Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

Business Continuity, Disaster Recovery & Cyber Resilience Pack — Guide

  • Version 1.3
  • Updated
  • 14 documents
  • Word, Excel

Business Continuity, Disaster Recovery & Cyber Resilience

A fire at a warehouse, a failed storage array, a carrier that cannot collect, a ransomware attack: each stops a service customers rely on, and each is recovered differently. This pack plans for all of them: how long each service can be down, what each site and team does without its building, people, suppliers or systems, when to fail over, and what to tell people. A destructive attack is the hardest case. Replication copies the damage, last night’s backup may hold the attacker, and the accounts you would recover with may be theirs, so the foundations are rebuilt first and each system goes 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;
  • a warehouse, an office or a team has no plan for the day it loses its building or half its staff;
  • nobody has decided when you would fail over to a second site, or how long recovery takes if the sign-in directory must be rebuilt;
  • NIS2, DORA or HIPAA applies to you, or a customer wants an auditor’s report on availability, and you cannot show a tested plan for each critical service.

How it works

Start with the business, not the systems. For each critical service, its business owner goes through the processes it is made of, in the Business Impact Analysis Questionnaire: what each does, when it is busiest, the least it needs, and how the harm grows from 4 hours to a week on your risk register’s impact scale. The service takes its worst process at each point, and the first point at which the harm becomes Severe is its maximum tolerable downtime. The recovery time objective must be shorter; the recovery point objective says how much data can be lost.

Then check them against reality: every system, supplier and data set must recover in time, every backup run often enough, every supplier contract give a recovery time. Each failed check is a gap with an owner and a date. The documents number their rules, such as RR-17 for who invokes a plan; the Business Continuity & ICT Resilience Policy lists them, and the other documents cite them instead of repeating them.

Each site and business unit keeps a continuity plan for four losses: its building, a large part of its people, a supplier and its systems. After a failure that is not an attack, the IT disaster recovery procedure has the crisis lead decide, on the technical recovery lead’s estimate, whether to repair, fail over or recover elsewhere; failing back is planned like any change. After an attack, nothing fails over until the incident manager confirms the copy can be trusted, and recovery runs in seven stages with twenty-two gates. The incident response plan keeps every decision it makes.

Staff hear within an hour of a declared disruption, customers within two, with updates at least every four hours, from the outage templates. Every test and trial has a written plan and report, with a stop point and a way back.

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 led a review. In two weeks of workshops the business owners re-agreed the objectives of its five critical services; the Head of Logistics went through dispatch process by process.

The checks found nine gaps. Online ordering can be down for 2 days, but its last restore test took 4. Dispatch was restored in 5 hours in a test, inside its 8, but after an attack it would take about 17. Its workaround, printed pick lists, has never been tried; a two-hour trial is planned for October. The warehouse the incident cut off has a rewritten site plan; the other four site and unit plans fall due for review in October.

Start with these three

  1. Business Impact Analysis Questionnaire: each service’s harm over time, gathered with its business owner process by process.
  2. Critical Service Recovery Objectives Matrix (RTO, RPO, MTD): the objectives, and the checks that find what cannot be met.
  3. Site & Business Unit Continuity Plan Template: what a site or team does without its building, people, a supplier or its systems.

Your first round

WhenWhat to doYou’re done when
Week 1Name your critical services and a business owner for each. Go through each service’s processes with its owner and rate the harm over time.Every critical service has an owner and a maximum tolerable downtime.
Week 2Agree recovery time and recovery point objectives with each owner. List each service’s dependencies, with how fast each recovers.Objectives agreed; the register lists systems, suppliers, data, people and sites.
Week 3Run the checks. Work out each service’s cyber recovery time. Raise a gap with an owner and a date for every check that fails.Every failed check is a gap with an owner.
Week 4Write or update the plan of the service most at risk and of the site it needs most. Schedule a recovery test for every service within the year.One service plan and one site plan, and a test date for every service.

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;
  • services whose recovery was tested in the last 12 months, and those restored within their objective;
  • services that could not recover in time, and gaps open or past due, by name;
  • crisis and recovery roles without a deputy;
  • site and unit plans current, and workarounds tried, out of all.

Everything in the pack

Adapting it

  • Incident response: the Incident Response Plan and the Ransomware Response Playbook handle containment, evidence, eradication and what is said in a cyber incident. This pack changes none of their decisions.
  • Exercises: a tabletop exercise tests decisions, a recovery test measures the time, a workaround trial runs the workaround for real. Plan all three.
  • Suppliers: put recovery times into contracts at the next supplier assessment, and compare them with the services that need them.
  • United States: HIPAA’s contingency plan standard applies to covered entities and business associates only. A report on availability is the auditor’s opinion; your plans, tests and records are what the auditor examines.
  • 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; the ISO 22301 Alignment Map places each document beside the standard’s clause numbers and titles.

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).
  • HIPAA (covered entities and business associates): 45 CFR 164.308(a)(7).
  • AICPA Trust Services Criteria: SOC 2 A1.3, Additional Criteria for Availability.

Prepared by Zero One Cybersecurity · Published by CISO Times

CISO Times Resource Licence — Internal Use