Continuity & Disaster Recovery Test Plan and Report
Plans each recovery test, failover test or workaround trial so it cannot cause the outage it rehearses, and reports the time achieved, the data lost and the findings.
Available soon
- Format
- Word
- Size
- 70 KB
- Length
- 22 pages
- Version
- 1.1
- Updated
What's inside
- About this template
- Legal note
- How to use this template
- Keeping a test from causing the outage it rehearses
- Part A: the test plan
- Part B: the test report
- Worked example: the plan of a recovery test
- Worked example: the report of a recovery test
- Worked example: the plan of a workaround trial
- Adapting this template
- Framework references
- Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
About this template
This template is the form in which [[Organisation Name]] plans and reports each test of business continuity and disaster recovery. Every recovery test, failover test and workaround trial has a written plan, approved by the service's business owner before it runs, and a report written within 10 working days of it. The Business Continuity & ICT Resilience Policy sets that rule (RR-26). Use one copy for each test or trial: Part A before it, Part B after it.
Three kinds of test
RR-26 names three kinds. They show different things, and only one is always a recovery test.
Kind | What it shows | What it does not show | A recovery test under RR-14? |
|---|---|---|---|
Recovery test | That the service, or the systems behind it, can be recovered and its data restored, and how long that takes and how much data is lost, against the service's objectives. | How long recovery takes after a destructive attack, unless the test first rebuilds the foundations in an isolated recovery environment (RR-07, RR-13). | Yes. It is the test RR-14 asks for. |
Failover test | That a system switches to its second site, region or copy and back again, how long the switch takes, and how much data it loses (RR-24). | Recovery after an attack, because replication copies the damage to the second site. On its own, it does not show that the whole service recovers. | Only when it recovers everything the service needs and measures the time and the data lost against the service's objectives. Otherwise it shows that one recovery method works, which is no longer untested (RR-24). |
Workaround trial | That the service's workaround runs for real: the people, the forms, the phones and the records are there, and it keeps the agreed reduced level for the time set. | Anything about recovering the systems. | No. A trial tries the workaround; it does not test recovery (RR-14). |
Say it plainly in every plan: only a timed recovery of the service proves its recovery time, so a workaround trial or a tabletop is not a recovery test under RR-14. This is the pack's rule. It is not a statement of what any law or standard requires. The Cyber Incident Exercises & Tabletop Scenario Library pack (P10) runs exercises, tabletops and drills, and reports them in its Exercise After-Action Report Template. They are good for deciding, for roles, for communication and for finding gaps. They restore nothing, so they cannot show a recovery time. A trial can run beside a test. EXAMPLE: the distributor's RV-2027-01 on 13 Jan 2027 is “the payment provider's own recovery test, its results shared and checked against the 24 hours; invoicing on account tried for a day alongside, as a workaround trial”.
What this template leaves to others
- The objectives. Each service's maximum tolerable downtime, recovery time objective and recovery point objective are recorded in the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD), agreed by its business owner (RR-02). A test reads them from there and never sets them.
- Restore testing of data sets. The Backup & Restore Assurance pack (P23) owns restore testing beyond each service's recovery test: how often other restore checks run, and how they are judged (RR-11). Where a recovery test also restores a data set P23 tracks, cite its P23 record in Part B; P23 reports its own tests in its Restore Test Evidence Report Template. This template does not restate P23's rules.
- Exercises. P10 plans and reports them. This template never counts one as a test.
- Incident response. If an attack is suspected during a test, the test stops and the Security Incident Management pack (P09) runs the incident (RR-23).
- Messages in a real disruption. A test is announced in advance (Part A4). A real disruption uses the Outage Communications Template Set, or P09's templates in a cyber incident (RR-27).
Legal note
This document helps you plan and test business continuity and recovery from a disruption, including a destructive cyberattack. It is not legal advice, and following it is not a statement that you comply with NIS2, DORA, the GDPR, HIPAA, ISO 22301 or any other law, standard or set of criteria. Which continuity and recovery duties apply to you depends on your sector and the law that applies to you: confirm them with counsel, your auditor or your supervisor.
The NIS2 Implementing Regulation (EU) 2024/2690 binds only the providers its Article 1 names, such as cloud computing, data centre and managed service providers; others may use its Annex as good practice. DORA and its Delegated Regulation (EU) 2024/1774, whose testing articles are cited below, bind financial entities only. HIPAA binds covered entities and business associates only. EXAMPLE: the distributor is an important entity under NIS2 in its Member State. It is not a financial entity, so DORA does not apply to it. It is not a covered entity or business associate under HIPAA.
How to use this template
Part A is the plan. The resilience coordinator writes it with the people who will run the test, and the business owner approves it before anything runs (RA-24). Part B is the report. Part A has five groups of fields, A1 to A5; Part B has seven, B1 to B7. Your entries are in [[double brackets]]. Delete the guidance boxes and the worked examples before approval.
From booking to the record
The steps for every test and trial, who does each, and the rule or responsibility that sets it.
Step | Who | Rule | |
|---|---|---|---|
1 | Book it. Put the test on the schedule before it falls due under RR-14, away from the service's busiest periods and any freeze, and not on the day of an exercise or another test. | Resilience coordinator | RR-14 |
2 | Write the plan. Complete Part A with the technical recovery lead, and for a trial with the site or unit continuity lead. | Resilience coordinator | RA-24 |
3 | Approve it. The business owner approves Part A before the test runs. The crisis lead is told. | Business owner | RR-26; RA-24 |
4 | Run it. Run the test as planned, and time it from logs or the test record. Stop at the stop point. | Technical recovery lead For a trial: business owner and site or unit continuity lead | RR-26; RA-18 |
5 | Write the report. Complete Part B within [[10]] working days of the test. | Resilience coordinator | RR-26; RA-18 |
6 | Raise the gaps. Each finding that misses an objective becomes an objective gap. Its owner agrees the change that closes it within [[10]] working days, and the service's risk owner is told. | Business owner | RR-15; RA-19 |
7 | Update the plans and records. Write the lessons into the service's plan, and update each record Part B5 lists. | Resilience coordinator | RR-16 |
8 | Keep the record. Keep the approved plan, the report and the evidence for [[3]] years, or longer where law or a contract asks. | Resilience coordinator | RR-20 |
Measuring the time and the data lost
RR-26 asks every report for the time achieved and the data lost. Measure them the same way every time, so that one test can be compared with the next.
Measure | How |
|---|---|
Time achieved | From the moment the test treats as the decision to recover, which is when the recovery time objective starts, to the business owner's confirmation that the service works. Take both times from logs or the test record, never from memory. |
Data lost | From the newest data the restored copy holds to the moment the test treats as the failure. Compare it with the recovery point objective. |
Against the maximum | Whether the time achieved is beyond the maximum tolerable downtime. If it is, the service's status in the objectives matrix becomes Not achievable. |
A workaround trial | How long the workaround ran, and whether it kept the agreed reduced level. A trial records no recovery time. |
The worked examples
EXAMPLE. The examples are the pack's wholesale distributor with about 900 staff, three warehouses and an online ordering service, after its ransomware incident INC-2026-014 (P09). Its Head of Risk, who runs no system in scope, coordinated a resilience review from 14 Sep 2026 to 25 Sep 2026; figures are as at 30 Sep 2026. Three examples follow the blank forms: the plan of the next recovery test, RV-2026-04 for Customer contact on 28 Oct 2026; the report of the warehouse management system's restore of 27 Aug 2026 (RV-2026-03), written again in this template in the review; and the plan of the first trial of dispatch's workaround, WT-2026-01 on 24 Oct 2026. Where the pack records no value, the example keeps a placeholder.
Keeping a test from causing the outage it rehearses
A test that takes the service down becomes the outage it was meant to prepare for. The mistake to avoid: testing failover on the live service in its busiest weeks, with no way back. Plan every test with a stop point and a way back, approved by the business owner (RR-26).
Parts A3 and A4 record each of these safeguards:
Safeguard | What to do |
|---|---|
Run it on a copy | Recover into a test tenancy, a spare environment or standby servers, never over live data. Check first that nothing in the copy can write back to production, send mail to customers or reach a supplier's live interface. |
Or run it in a quiet period | Where the test must touch the live service, as a failover test or a workaround trial does, run it when the service is least used. Take the busiest periods from the Business Impact Analysis Questionnaire, process by process (RR-21), and keep out of any freeze. Take a backup and check it before anything live changes. |
Set a stop point | A signal written down before the test, which anyone in it can check: a time, a measure, or a named sign that the live service is affected. At the stop point the test stops, and nobody debates it. |
Have a way back | How the service returns to normal, who does it and how long it takes. For a failover test the way back is the failback: plan it as RR-25 plans a real one, with the data written meanwhile copied back and reconciled. |
Name who may stop it | One role, with a deputy, who may stop the test at any point. Anyone who sees the stop point reached tells them at once. |
Tell people first | Tell the people who could mistake the test for a real outage: the service desk, the staff who use the service, the suppliers taking part, and the crisis lead (RA-24). |
If a real disruption or an attack starts during a test
If a real disruption starts, stop the test and take the way back; the crisis lead decides what happens next (RR-17). If an attack is suspected, stop the test and call the incident manager: P09 runs the incident, and RR-23 applies: “Where an attack is suspected, nothing fails over or is restored until the incident manager confirms that the copy or site to be used can be trusted (RR-07; P09 D3).” The copy or second site the test was using may be the attacker's too.
Tests and a destructive attack
Classic disaster recovery assumes the systems you recover with can be trusted: fail over to the second site, restore last night's backup, and carry on. A destructive cyberattack breaks that assumption. Replication copies the damage to the second site, the attacker may have been inside for weeks before the encryption, and the sign-in directory and administrator accounts you would recover with may be the attacker's. Recovery then starts with the foundations, rebuilt from sources you can trust, and every system is checked before it goes back.
So a test in normal conditions shows how long recovery takes after a technical failure, with trusted tools and a known-good copy. It does not show the service's cyber recovery time, which the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) works out from the foundations and the slowest system restored in-house (MX-05). Only a test that rebuilds the foundations in an isolated recovery environment, from trusted sources, measures it (RR-13). A failover test never does: replication copies the damage. Work out the cyber recovery time from a clean rebuild (RR-07, MX-05).
EXAMPLE. The distributor plans RV-2027-03 for 17 Feb 2027: foundations rebuilt in an isolated recovery environment, then the warehouse management system: the first measure of the cyber recovery time. Until then the foundations' 12 hours are an estimate.
Part A: the test plan
Complete Part A before the test, and have it approved before anything runs. Every field applies to every kind of test; where one does not, say why.
Guidance — delete before approval
What good looks like. Success is written as numbers against the service's objectives before the test, so nobody judges it afterwards by how it felt. The plan says how the live service is kept safe, where the test stops and how to go back. One named role may stop it. The business owner has signed it.
The rules behind it. RR-26: “Every recovery test (RR-14), failover test and workaround trial has a written plan, approved by the service's business owner before it runs: what it tests, how success is judged against the objectives, how it is kept from causing the outage it rehearses (a copy or a quiet period, a point at which it stops, and a way back), and who may stop it. Its report, written within [[10]] working days, records the time achieved, the data lost and every finding; a finding that misses an objective is an objective gap (RR-15). A workaround tried in a trial is no longer untried (RR-06).”
RR-14: “The recovery of every critical service is tested at least every [[12]] months, and after a significant change to it. A service never tested is tested within [[6]] months of its objectives first being agreed under this policy; agreeing them again does not move that date. A test recovers the service or its systems, restores its data, and records the time achieved and the data lost against the objectives. Where a supplier runs the systems, the test is the supplier's own recovery test, with its results shared and checked against the objectives. Only a timed recovery of the service proves its recovery time. An exercise under P10, a tabletop or a drill, is not a recovery test under this rule. It tests decisions and communication.”
A1 The test or trial | |||
|---|---|---|---|
ID | [[RV-YYYY-nn / WT-YYYY-nn]] | Kind recovery test, failover test and workaround trial | [[Recovery test / Failover test / Workaround trial]] |
Critical service name and ID, as in the objectives matrix | [[name (CS-nn)]] | Business owner | [[role]] |
What is recovered or tried systems, data, or the workaround | [[what the test recovers, where, and from which copy; or the workaround and for how long]] | ||
Recovery method or workaround as the IT Disaster Recovery Procedure or the plan records it | [[repair in place / fail over / restore elsewhere / rebuild / supplier's own recovery; or the workaround]] | ||
Site or unit for a workaround trial | [[site or unit (SU-nn), and its continuity lead]] | ||
Why now the rule or the gap that makes it due | [[due under RR-14; a significant change; a method never tested (RR-24); a workaround never tried (RR-06); a gap (OG-nn)]] | ||
A2 Success, judged against the objectives | |||
|---|---|---|---|
Objectives from the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) | [[MTD, RTO and RPO in hours; date agreed; status]] | ||
Success means each a measure with a number | [[e.g. back within the RTO; no more data lost than the RPO; for a trial, the agreed reduced level kept for the time set]] | ||
Time is measured from and to | [[from the decision to recover, to the business owner's confirmation]] | Data lost is measured from and to | [[from the newest data restored, to the failure]] |
What it will not show including recovery after an attack | [[e.g. the cyber recovery time; the parts of the service left out]] | ||
A3 Keeping it from causing the outage it rehearses | |||
|---|---|---|---|
Copy or quiet period where it runs, and why the live service is safe | [[a test tenancy, spare environment or standby servers; or a quiet period, with the backup taken first]] | ||
Stop point a signal anyone can check | [[a time, a measure, or a sign the live service is affected]] | ||
Way back and how long it takes | [[how the service returns to normal, who does it, how long; for a failover test, the failback (RR-25)]] | ||
If a real disruption or an attack starts | Stop, and take the way back. The crisis lead decides what happens next (RR-17). If an attack is suspected, P09 runs the incident: nothing fails over or is restored until the incident manager confirms the copy or site can be trusted (RR-23). | ||
A4 People and timing | |||
|---|---|---|---|
May stop it a role, with a deputy | [[role]]; deputy [[role]] | ||
Participants roles and suppliers | [[roles; suppliers (P06 SUP-nnn)]] | ||
Times and records it a participant who is not doing the recovery | [[role]] | ||
Date and time away from the busiest periods and any freeze | [[YYYY-MM-DD, start and end; why this time]] | ||
Told beforehand anyone who could mistake it for an outage | [[service desk, users, suppliers; when]] | ||
A5 Approval | |||
|---|---|---|---|
Approved by the business owner, before it runs (RA-24) | [[role, signature, YYYY-MM-DD]] | ||
Consulted technical recovery lead; site or unit lead | [[roles]] | Crisis lead told | [[role, YYYY-MM-DD]] |
Report due within 10 working days of the test (RR-26) | [[YYYY-MM-DD]] | ||
Part B: the test report
Complete Part B within 10 working days of the test. Record every finding, including what went as planned, so the next test starts from the truth.
Guidance — delete before approval
What good looks like. The time achieved and the data lost are numbers from the logs, each set against its objective. Each finding is a fact a reader can check. Each missed objective is an objective gap with an owner and a date. The plan has changed, and Part B5 says where.
The rules behind it. RR-15: “Every failed check in the objectives matrix, and every objective a test or a real recovery missed, is an objective gap. Its owner agrees the change that closes it within [[10]] working days, with a due date; the service's risk owner is told and the risk is reassessed (P05 RM-10).”
RR-16: “Each critical service has a recovery plan, reviewed at least every [[12]] months, after every test and real recovery, and after a significant incident or change. Lessons from tests are written into the plan. A copy of every plan and of the contact lists can be reached when the main systems are down.”
After a trial, RR-26 adds: “A workaround tried in a trial is no longer untried (RR-06).”
B1 The test as held | |||
|---|---|---|---|
ID | [[RV-YYYY-nn / WT-YYYY-nn]] | Kind | [[Recovery test / Failover test / Workaround trial]] |
Critical service | [[name (CS-nn)]] | Business owner | [[role]] |
Held on | [[YYYY-MM-DD]] | Plan approved | [[YYYY-MM-DD]] |
Report due 10 working days (RR-26) | [[YYYY-MM-DD]] | Report written | [[YYYY-MM-DD]] |
What was recovered or tried and the method | [[as Part A1, and what differed]] | ||
Changes from the plan stopped early, and why | [[none; or what changed and why]] | ||
B2 Result against the objectives. The time achieved and the data lost, each against its objective, from the logs. For a trial, the reduced level kept and for how long.
Objective | Target | Achieved | Result |
|---|---|---|---|
Recovery time objective | [[hours]] | [[hours]] | [[Met / Missed]] |
Recovery point objective | [[hours]] | [[hours]] | [[Met / Missed]] |
Maximum tolerable downtime | [[hours]] | [[hours]] | [[Within / Beyond]] |
Cyber recovery time only a test that rebuilds the foundations measures it | [[within the RTO]] | [[hours, or Not measured]] | [[Met / Missed / Not measured]] |
For a trial: the reduced level | [[the level, for how long]] | [[what was kept, for how long]] | [[Kept / Not kept]] |
B3 Findings. Every finding, including what went as planned. A finding that misses an objective is an objective gap (RR-26, RR-15).
Finding | What was found | Objective met? | Objective gap |
|---|---|---|---|
F-[[n]] | [[a fact a reader can check, with the measure]] | [[Yes / No / Not about an objective]] | [[OG-nn, or None]] |
F-[[n]] | [[…]] | [[…]] | [[…]] |
B4 Objective gaps raised. Each gap's owner agrees the change that closes it within 10 working days, with a due date, and the service's risk owner is told (RR-15).
Gap | Check | Change that closes it | Owner | Dates | Risk owner told |
|---|---|---|---|---|---|
OG-[[nn]] | [[MX-nn]] | [[the change]] | [[role]] | [[found; plan by; due]] | [[risk reference; YYYY-MM-DD]] |
B5 What changes because of this test. Write the lessons into the service's plan, and bring each record up to date (RR-16).
Record | What changes | Rule | Done |
|---|---|---|---|
Cyber Recovery Plan Template | The service's recovery plan: the last test, its result against the objectives, the next test, and the lessons written in (PS-11) | RR-16 | [[YYYY-MM-DD, or Not needed: why]] |
Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) | The objectives matrix: the last test, the time achieved and the data lost; after a trial, the workaround marked as tried | RR-14, RR-06 | [[YYYY-MM-DD, or Not needed: why]] |
Resilience Dependency Register | The dependency register: a recovery time measured in a test replaces a contract's or an estimate, with its basis | RR-09 | [[YYYY-MM-DD, or Not needed: why]] |
IT Disaster Recovery Procedure | The IT disaster recovery procedure: the recovery method marked as tested, with the time it took | RR-24 | [[YYYY-MM-DD, or Not needed: why]] |
Site & Business Unit Continuity Plan Template | The site or unit plan that ran a trial: when the workaround was last tried, and what changed | RR-22 | [[YYYY-MM-DD, or Not needed: why]] |
Crisis & Recovery Responsibility Matrix | The responsibility matrix, where the test showed a role or a deputy missing | RR-19 | [[YYYY-MM-DD, or Not needed: why]] |
Resilience Readiness Dashboard | The readiness dashboard's counts, at the next quarter | RR-20 | [[YYYY-MM-DD, or Not needed: why]] |
B6 What the test did not show. A report that claims no limits is one a careful reader doubts.
Ask | Why it matters | Your answer |
|---|---|---|
Did it run in normal conditions, with trusted tools and a known-good copy? | Then it does not show recovery after a destructive attack, when the foundations come first (RR-07). | [[answer]] |
Did it recover the whole service, or one system or one copy? | A part recovered in time does not show the service recovers in time. | [[answer]] |
Did a supplier's own test stand in for yours? | Say what you relied on, and what you saw of it. | [[answer]] |
Did it run in a quiet period? | Recovery at the busiest time may take longer, and a workaround may not keep up. | [[answer]] |
Was any step skipped, shortened or timed from memory? | Say which, so nobody reads the time as firmer than it is. | [[answer]] |
B7 Sign-off | |||
|---|---|---|---|
Written by the resilience coordinator | [[role, YYYY-MM-DD]] | ||
Checked by the technical recovery lead | [[role, signature, YYYY-MM-DD]] | ||
Findings and gaps accepted by the business owner | [[role, signature, YYYY-MM-DD]] | ||
Sent to the crisis lead, and the risk owner of each gap | [[YYYY-MM-DD]] | ||
Worked example: the plan of a recovery test
EXAMPLE. The plan of RV-2026-04, the first recovery test of Customer contact, as its business owner, the Sales Director, approved it for 28 Oct 2026. The service runs on two suppliers' systems, and both take part (P06 SUP-005 and P06 SUP-013).
Guidance — delete before approval
Delete the worked examples from your adopted template. They show the level of detail a plan needs; the [[placeholders]] are values the pack does not record. In both example plans, A3's line for a real disruption or an attack is the standard one: “Stop, and take the way back. The crisis lead decides what happens next (RR-17). If an attack is suspected, P09 runs the incident: nothing fails over or is restored until the incident manager confirms the copy or site can be trusted (RR-23).”
Field | EXAMPLE: RV-2026-04 |
|---|---|
A1 Kind | Recovery test (system restore) |
A1 Critical service and business owner | Customer contact (CS-05) Sales Director |
A1 Site or unit | Not applicable: a recovery test |
A1 What is recovered or tried | Mailboxes and the contact centre's call routing restored to a test tenancy, with the providers |
A1 Recovery method or workaround | Email and office software provider: supplier's own recovery Outsourced customer contact centre: supplier's own recovery |
A1 Why now | Never tested. Its first test is due within 6 months of its objectives first being agreed on 25 Sep 2026, so by 25 Mar 2027 (RR-14). It is part of the change that closes gap OG-09. |
A2 Objectives | MTD 48 hours (2 days); RTO 24 hours (1 day); RPO 24 hours (1 day). Agreed 25 Sep 2026. Status: Not proven |
A2 Success means | Mailboxes and call routing back within 24 hours No more than 24 hours of email lost |
A2 Time and data lost | [[from and to, e.g. from the start of the restore to the Customer Contact Manager's confirmation that mail and call routing work]] [[the newest mail the restored copy holds, against the moment the test treats as the failure]] |
A2 What it will not show | Recovery after a destructive attack: the objectives matrix puts the service's cyber recovery time at 12 hours, all of it the foundations' rebuild, an estimate never tested as a whole (MX-05). [[anything else left out]] |
A3 Copy or quiet period | A test tenancy only: live mail and call routing are not touched |
A3 Stop point | Any sign that live mail flow or call routing is affected |
A3 Way back | None needed, because nothing live changes; the test tenancy is deleted afterwards |
A4 May stop it | Head of IT; deputy [[role]] |
A4 Participants | Email and office software provider (P06 SUP-005) Outsourced customer contact centre (P06 SUP-013) IT Operations Manager Customer Contact Manager |
A4 Times and records it | [[a participant who is not doing the restore]] |
A4 Date and time | 28 Oct 2026, a Wednesday, [[start time]]. Nothing live is touched, and the date is before the peak season of November and December |
A4 Told beforehand | [[who is told, and when, e.g. the customer contact team and the two providers]] |
A5 Approved by | Sales Director, [[date approved]] |
A5 Consulted; crisis lead told | Head of IT (technical recovery lead); Customer Contact Manager (Customer contact team continuity lead) Chief Operating Officer |
A5 Report due | By 11 Nov 2026 |
EXAMPLE. Because the test runs in a test tenancy, its way back is short. Customer contact's status in the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) stays Not proven until the report is written. The report, due by 11 Nov 2026, then records the time achieved against the recovery time objective of 24 hours and the data lost against the recovery point objective of 24 hours.
Worked example: the report of a recovery test
EXAMPLE. The report of RV-2026-03, the restore of the warehouse management system on 27 Aug 2026. Its first report was due by 10 Sep 2026, and the example does not record it. In the review the Head of Risk wrote the report again in this template, on 25 Sep 2026, and read the result against the objectives the Head of Logistics agreed that day. The restore met the recovery time objective and missed the recovery point objective, which became objective gap OG-05.
Guidance — delete before approval
Delete this worked example from your adopted template.
B1 The test as held — EXAMPLE | |||
|---|---|---|---|
ID | RV-2026-03 | Kind | Recovery test (system restore) |
Critical service | Warehouse dispatch (CS-02) | Business owner | Head of Logistics |
Held on | 27 Aug 2026 | Plan approved | [[YYYY-MM-DD: the example does not record it]] |
Report due 10 working days (RR-26) | By 10 Sep 2026 | Report written | 25 Sep 2026, again in this template, in the September review |
What was recovered or tried and the method | The warehouse management system restored from backup and checked by the warehouse team. Method: restore elsewhere, on [[standby servers]] | ||
Changes from the plan stopped early, and why | [[none recorded]] | ||
B2 Result against the objectives. The time achieved and the data lost, each against its objective, from the logs.
Objective | Target | Achieved | Result |
|---|---|---|---|
EXAMPLE Recovery time objective | 8 hours | 5 hours | Met (F-1) |
EXAMPLE Recovery point objective | 4 hours | 24 hours | Missed (F-2): objective gap OG-05 |
EXAMPLE Maximum tolerable downtime | 24 hours | 5 hours | Within |
EXAMPLE Cyber recovery time | Within the RTO of 8 hours | Not measured: estimated at 17 hours | Beyond the RTO, within the MTD: objective gap OG-04 |
B3 Findings. Every finding, including what went as planned. A finding that misses an objective is an objective gap (RR-26, RR-15).
Finding | What was found | Objective met? | Objective gap |
|---|---|---|---|
EXAMPLE F-1 | Restored in 5 hours, within dispatch's 8-hour recovery time objective. | Yes | None |
EXAMPLE F-2 | 24 hours of stock and dispatch records would be lost, against the 4-hour recovery point: the database is backed up daily. | No | OG-05 |
B4 Objective gaps raised. Each gap's owner agrees the change that closes it within 10 working days, with a due date, and the service's risk owner is told (RR-15).
Gap | Check | Change that closes it | Owner | Dates | Risk owner told |
|---|---|---|---|---|---|
EXAMPLE OG-05 | MX-03 | Back up the warehouse management system's database every 4 hours | Head of IT | Found 25 Sep 2026 Plan by 9 Oct 2026 Due 15 Dec 2026 Open | [[risk reference; YYYY-MM-DD]] |
B5 What changes because of this test. Write the lessons into the service's plan, and bring each record up to date (RR-16).
Record | Rule | What changed |
|---|---|---|
EXAMPLE Cyber Recovery Plan Template | RR-16 | Warehouse dispatch's plan was rewritten in this pack's template on 25 Sep 2026, in the review. Next review by 25 Sep 2027, or sooner after RV-2027-03. |
EXAMPLE Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) | RR-14, RR-06 | Last test RV-2026-03, 27 Aug 2026: 5 hours, 24 hours of data lost. MX-06 passes and MX-03 fails (OG-05). Status: Needs its workaround. Next test due by 27 Aug 2027; planned: RV-2027-03, 17 Feb 2027. |
EXAMPLE Resilience Dependency Register | RR-09 | DP-07 Warehouse management system: “Tested 27 Aug 2026: restored in 5 hours (P03)” |
EXAMPLE IT Disaster Recovery Procedure | RR-24 | DP-07 Warehouse management system: restore elsewhere, on [[standby servers]], tested in RV-2026-03 in 5 hours |
EXAMPLE Site & Business Unit Continuity Plan Template | RR-22 | Not applicable: a recovery test tries no workaround |
EXAMPLE Crisis & Recovery Responsibility Matrix | RR-19 | [[none recorded]] |
EXAMPLE Resilience Readiness Dashboard | RR-20 | At the quarter end: Recovery tested, 3 of 5; Restored within objective, 2 of 5, dispatch among them |
B6 What the test did not show. A report that claims no limits is one a careful reader doubts.
What the test did not show | What would show it |
|---|---|
EXAMPLE Recovery after an attack. The restore ran in normal conditions, with trusted tools | After an attack dispatch would take 17 hours: 12 to rebuild the foundations and 5 for the warehouse system, against an RTO of 8 and an MTD of 24 (OG-04). RV-2027-03, on 17 Feb 2027, is the first measure. |
EXAMPLE The workaround. It was not part of the test | Dispatch's printed pick lists have never been tried. WT-2026-01, on 24 Oct 2026, tries them. |
EXAMPLE [[anything else left out]] | [[what would show it]] |
B7 Sign-off — EXAMPLE | |||
|---|---|---|---|
Written by the resilience coordinator | Head of Risk (resilience coordinator), 25 Sep 2026 | ||
Checked by the technical recovery lead | Head of IT: [[signature, YYYY-MM-DD]] | ||
Findings and gaps accepted by the business owner | Head of Logistics: [[signature, YYYY-MM-DD]] | ||
Sent to the crisis lead, and the risk owner of each gap | Chief Operating Officer; the risk owner for OG-05: [[YYYY-MM-DD]] | ||
EXAMPLE. The Backup & Restore Assurance pack records the same restore as RT-04 in its own register, and links its finding BF-02 to OG-05. Part B cites that record and leaves its judgement to P23.
Worked example: the plan of a workaround trial
EXAMPLE. The plan of WT-2026-01, the first trial of dispatch's workaround, at Warehouse 2 on 24 Oct 2026. As at 30 Sep 2026 it is planned, to be approved by the Head of Logistics. The same form serves a trial: success is the reduced level the workaround keeps, and no recovery time is measured.
Guidance — delete before approval
Delete this worked example from your adopted template.
Field | EXAMPLE: WT-2026-01 |
|---|---|
A1 Kind | Workaround trial |
A1 Critical service and business owner | Warehouse dispatch (CS-02) Head of Logistics |
A1 Site or unit | Warehouse 2 (SU-02). Its continuity lead is the Warehouse 2 Manager; its plan records the workaround as untried |
A1 What is recovered or tried | Dispatch from the printed pick lists for the first two hours of the Saturday early shift, with the warehouse management system running alongside to compare |
A1 Recovery method or workaround | The workaround: dispatch from printed pick lists of the next day's orders, printed each evening, for up to [[24]] hours |
A1 Why now | The workaround has never been tried (RR-06). After an attack dispatch would take 17 hours against its 8-hour recovery time objective, and the workaround carries the gap (OG-04). |
A2 Objectives | MTD 24 hours (1 day); RTO 8 hours; RPO 4 hours. Agreed 25 Sep 2026. Status: Needs its workaround |
A2 Success means | Warehouse 2's plan, for a loss of systems: “Perishable orders out on time” The agreed reduced level: “Perishable orders dispatched on time; other orders up to a day later” [[what the comparison with the system must show]] |
A2 Time and data lost | Not measured: a trial records no recovery time Not applicable: a trial restores no data |
A2 What it will not show | The recovery of the warehouse management system: a trial is not a recovery test (RR-14). Two quiet hours on a Saturday do not show the workaround through a weekday early shift, or for the [[24]] hours it may need to run |
A3 Copy or quiet period | A quiet period: the first two hours of the Saturday early shift. The business impact analysis gives picking's busiest times as “November and December; the early shift on weekdays” |
A3 Stop point | [[the signal, e.g. a perishable order at risk of missing its carrier collection]] |
A3 Way back | The warehouse management system runs alongside throughout, so the shift goes back to it at once |
A4 May stop it | [[role, e.g. the Warehouse 2 Manager]]; deputy [[role]] |
A4 Participants | [[the early shift at Warehouse 2: pickers, packers, loaders and the shift supervisor]] |
A4 Times and records it | [[someone outside the shift, who compares the lists with the system]] |
A4 Date and time | 24 Oct 2026: the first two hours of the Saturday early shift. October is outside the peak season of November and December |
A4 Told beforehand | [[the carriers and the shift, and when]] |
A5 Approved by | Head of Logistics, [[date approved, before 24 Oct 2026]] |
A5 Consulted; crisis lead told | Head of IT (technical recovery lead); Warehouse 2 Manager (site or unit continuity lead) Chief Operating Officer |
A5 Report due | By 6 Nov 2026 |
EXAMPLE. The trial's report is due by 6 Nov 2026. However it goes, dispatch's workaround is then tried (RR-26): the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD), dispatch's plan (PS-5) and Warehouse 2's plan record the date, and the dashboard's count of workarounds tried (RRM-09) goes from 1 of 5 to 2 of 5. Any finding is raised with an owner and a date, and a finding that misses an objective is an objective gap (RR-15). The trial does not move dispatch's next recovery test, RV-2027-03 on 17 Feb 2027.
Adapting this template
Guidance — delete before approval
Small organisation: keep both parts, each short; a quiet-day trial can be planned on one page. Keep the stop point, the way back and the business owner's approval, because they stop a test becoming an outage. One person may write the plan and run the test, but someone else times it.
Guidance — delete before approval
IT run by a service provider: where a supplier runs the systems, the recovery test is the supplier's own, with its results shared and checked against your objectives (RR-14). Ask for its plan before it runs and its results after, fill Part B from them, and say in B6 what you relied on. The supplier liaison calls on its commitments (RA-14).
Guidance — delete before approval
Regulated entity under NIS2: a provider named in Implementing Regulation Article 1 checks its tests against Annex points 4.1.4 (plans tested, reviewed and updated, with the lessons from tests) and 4.2.6 (the recovery of backup copies and redundancies tested regularly, results documented, corrective action taken where needed). Parts B2 to B5 are where you record those results and lessons.
Guidance — delete before approval
Financial entity under DORA: Article 11(6) asks for yearly tests of the ICT systems supporting all functions and, for entities other than microenterprises, scenarios of cyber-attacks and switchovers. Delegated Regulation Article 25 asks that tests take the business impact analysis into account and use severe but plausible scenarios, and that results are documented and deficiencies reported to the management body. Entities under Article 16(1) follow Delegated Regulation Article 40(1) instead: their business continuity plans are tested, the backup and restore procedures at least once a year. Confirm which applies to you with counsel.
Guidance — delete before approval
Covered entity or business associate under HIPAA: § 164.308(a)(7)(ii)(D), testing and revision procedures, is an addressable specification. Keep each approved plan and report as your record, and read the note under the framework references.
Guidance — delete before approval
Service organisation reporting on availability: where your report on the Trust Services Criteria includes availability, the auditor decides what evidence of recovery testing it needs. The criterion is named under the framework references by number and series title only.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; ISO 22301:2019 incl. Amd 1:2024 (clause numbers and titles only); NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774; Regulation (EU) 2016/679 (GDPR); 45 CFR Part 164 (HIPAA Security Rule, eCFR current to 6 October 2026); AICPA Trust Services Criteria (number and series title only).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.30 — ICT readiness for business continuity | The whole template: each service's recovery tested against its objectives |
NIST CSF 2.0 | ID.IM-02 — “Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties” | Parts B3 to B5: improvements found in each test and trial, including those run with suppliers |
NIST CSF 2.0 | ID.IM-04 — “Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved” | Part B5: the plans improved after each test |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The whole template: business continuity and disaster recovery tested |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | Legal note: who the Annex binds |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.1.4 — “The business continuity plan and disaster recovery plan shall be tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents or significant changes to operations or risks. The relevant entities shall ensure that the plans incorporate lessons learnt from such tests.” | Part B5: plans reviewed after each test, with the lessons written in |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.6 — “The relevant entities shall carry out regular testing of the recovery of backup copies and redundancies to ensure that, in recovery conditions, they can be relied upon and cover the copies, processes and knowledge to perform an effective recovery. The relevant entities shall document the results of the tests and, where needed, take corrective action.” | Parts A and B: the recovery of backup copies and redundancies tested, results documented and gaps raised |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.3.4 — “The relevant entities shall test, review and, where appropriate, update the crisis management plan on a regular basis or following significant incidents or significant changes to operations or risks.” | Part B5: the crisis roles reviewed where a test showed a gap |
DORA — Regulation (EU) 2022/2554 | Article 11(6) — test the ICT business continuity plans and the ICT response and recovery plans “in relation to ICT systems supporting all functions at least yearly, as well as in the event of any substantive changes to ICT systems supporting critical or important functions”, and test the crisis communication plans (Article 14); financial entities other than microenterprises include in the testing plans “scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities”; the policy and plans are regularly reviewed taking into account test results and recommendations from audit checks or supervisory reviews | Parts A and B, for financial entities: each test planned and reported, including failover tests |
DORA — Delegated Regulation (EU) 2024/1774 | Article 25(1) — “When testing the ICT business continuity plans in accordance with Article 11(6), of Regulation (EU) 2022/2554, financial entities shall take into account the financial entity’s business impact analysis (BIA) and the ICT risk assessment referred to in Article 3(1), point (b), of this Regulation.” | Part A2, for financial entities: success judged against the objectives the impact analysis gives |
DORA — Delegated Regulation (EU) 2024/1774 | Article 25(2) — the testing assesses whether the entity can ensure the continuity of its critical or important functions, “performed on the basis of test scenarios that simulate potential disruptions, including an adequate set of severe but plausible scenarios”, includes ICT services provided by ICT third-party service providers where applicable, includes switchover scenarios for entities other than microenterprises, and is “designed to challenge the assumptions on which the business continuity plans are based, including governance arrangements and crisis communication plans” | Part A, for financial entities: the kinds of test, including failover and tests of cyber recovery |
DORA — Delegated Regulation (EU) 2024/1774 | Article 25(5) — “Financial entities shall document the results of the testing referred to in paragraph 1. Any identified deficiencies resulting from that testing shall be analysed, addressed, and reported to the management body.” | Parts B3 and B4, for financial entities: results documented, deficiencies raised as objective gaps |
DORA — Delegated Regulation (EU) 2024/1774 | Article 40(1) — the entities under the simplified framework test their business continuity plans, including the scenarios referred to in Article 39, “at least once every year for the back-up and restore procedures, or upon every major change of the business continuity plan” | Adapting this template: entities under the simplified framework |
GDPR — Regulation (EU) 2016/679 | Article 32(1)(d) — the security measures include, as appropriate, “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing” | The whole template: a regular test with a record |
HIPAA — 45 CFR Parts 160 and 164 | § 164.308(a)(7)(ii)(D) — testing and revision procedures (addressable): “Implement procedures for periodic testing and revision of contingency plans.” | Parts A and B: periodic tests of the plans; Part B5: the plans revised |
AICPA Trust Services Criteria | SOC 2 A1.3, Additional Criteria for Availability | Parts A and B: each recovery test planned, run and reported |
ISO 22301:2019 incl. Amd 1:2024 | Clause 8.5 — Exercise programme (clause number and title only) | Parts A and B: the tests and trials the schedule holds |
ISO/IEC 27001 references name the clause or control this document relates to; ISO 22301 is named by clause number and title only, and its text is not reproduced. Neither says that meeting one meets any other framework's requirement.
HIPAA binds covered entities and business associates that create, receive, maintain or transmit electronic protected health information; others may read it as a reference. An addressable specification is not optional: it is put in place where reasonable and appropriate, or the reason is documented and an equivalent measure used where one is (§ 164.306(d)(3)). Using this document is not a statement that you comply with the Security Rule.
Trust Services Criteria are named by number and series title only; their statements are not reproduced. A report on them is an independent auditor's opinion on your controls, and nothing in this document says that a criterion is met.
Definitions
Term | Meaning in this template |
|---|---|
Business owner | The manager accountable for a critical service. Sets and agrees its objectives, accepts its workaround, and confirms it works before it returns to users (RR-02). |
Critical service | A service the organisation delivers whose disruption beyond its maximum tolerable downtime would cause Severe harm on the risk register's impact scale (RR-01). It is a business service, such as online ordering, not a system. |
Cyber recovery time | The time a service would take to come back after a destructive attack: the foundations' rebuild, if the service depends on them, plus the slowest of the systems the organisation restores itself (MX-05). |
Disaster recovery | Recovering the systems a critical service needs after a failure that is not an attack: repair where they are, fail over, restore elsewhere, or the supplier's own recovery (RR-23, RR-24). After an attack, cyber recovery applies instead (RR-07). |
Failback | Returning a system from its failover set-up to its normal one, with the data written meanwhile copied back and reconciled (RR-25). |
Failover | Switching a system to a second site, region or copy that runs it while the first is down (RR-23, RR-24). |
Foundations | What every other recovery needs first: the sign-in directory, the core network and firewalls, the backup platform, endpoint protection and monitoring, and the emergency administrator accounts. |
Maximum tolerable downtime (MTD) | the longest a critical service can be unavailable before the harm reaches Severe on the impact scale. Found by the business impact analysis (RR-03). |
Objective gap | A check in the objectives matrix that fails: an objective the service cannot meet as things stand. Recorded with an owner, a due date and the change that closes it (RR-15). |
Recovery point objective (RPO) | the most data, measured in time, the service can lose. The backup interval of every data set it needs must be no longer (RR-04, MX-03). |
Recovery test | A technical test that recovers a critical service, or the systems behind it, and measures the time achieved and the data lost against its objectives; for a service a supplier runs, the supplier's own recovery test with its results shared. A tabletop or a drill under P10 tests decisions and communication. Only a timed recovery proves a recovery time, so under this rule it is not a recovery test (RR-14). |
Recovery time objective (RTO) | the time within which the service must be back, counted from the decision to recover it. Always shorter than the MTD (RR-04). |
Workaround | A way of running the service, or its most important part, without its systems for a set time, such as dispatch from printed pick lists. Owned and accepted by the business owner (RR-06). |
Workaround trial | Running a service's workaround for real, for a set time and with a way back, to show it works. It tries the workaround; it does not test recovery (RR-14, RR-26). |