Resilience Readiness Dashboard
Reports plan currency, test results and recovery-objective achievement per critical service.
Available soon
- Format
- Excel
- Size
- 102 KB
- Length
- 12 sheets
- Version
- 1.0
- Updated
Follow this documentFree account. We can email you when it changes.
What's inside
What changed
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | What this dashboard is. The readiness report the resilience coordinator keeps and sends to [[executive management]] each quarter and to [[the approver]] each year (RR-20). It holds a copy of the key fields of the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD), the recovery plans (Cyber Recovery Plan Template), the test records and the Crisis & Recovery Responsibility Matrix, and works out every measure from them. |
| 2 | On the Dashboard sheet, enter the As-at date (the quarter's last day) and the quarter's name. Type both; never a formula that changes them. Enter the first and last month of your peak-season freeze, if you have one. Every status, date and measure is worked out at the As-at date. |
| 3 | On the Services sheet, copy each critical service from the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD): its business owner, maximum tolerable downtime (MTD), recovery time objective (RTO) and recovery point objective (RPO) in hours, the date the business owner last agreed them and the date they were first agreed under the policy, and its cyber recovery time from check MX-05. Add whether the freeze covers it, whether its workaround has been tried, and the date its plan was last reviewed. Status, next test due, plan review due and open gaps calculate. |
| 4 | On the Tests sheet, add one row per recovery test, held or planned. For a held test enter the time achieved and the data lost, in hours. For a planned test the sheet shows the service's due date and whether the test falls in the freeze. Never enter a tabletop exercise or a drill: it is not a recovery test (RR-14). |
| 5 | On the Gaps and Roles sheet, copy each objective gap from the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD), with its owner, the date it was found, its due date and its status. Below them, list each crisis and recovery role from the Crisis & Recovery Responsibility Matrix with its first holder and deputy. |
| 6 | Read the Dashboard: the seven headline measures, the per-service view, the year's recovery tests and the months of the freeze. Write the commentary beside each measure: what changed since last quarter and what you ask management to decide. |
| 7 | Complete the Reports sheet: the quarterly page for [[executive management]] and, once a year, the page for [[the approver]]. The figures fill themselves; write where you stand and what you ask in the yellow cells. Keep each quarter's copy of the workbook, with the test records it reports, for [[3]] years (RR-20). |
| 8 | To start your own dashboard, delete the contents of the first column and of every yellow cell on the Services, Tests and Gaps and Roles sheets, the commentary on the Dashboard and the text on the Reports sheet. The formulas stay. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Limitations: This document helps you plan and test 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, ISO 22301 or any standard. Which continuity and recovery duties apply to you depends on your sector and your national law: confirm them with counsel or your supervisor.
Why both times. 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 each service shows the time its last test achieved and its cyber recovery time: the foundations' rebuild, where it depends on them, plus the slowest system restored in-house (MX-05).
What this dashboard is not is set out at the foot of the Dashboard sheet. It does not say that any service, plan or law's requirement is met.
EXAMPLE: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, an important entity under NIS2 in its Member State; not a financial entity, so DORA's reporting duties do not apply. After INC-2026-014, its Head of Risk, who runs no system in scope, coordinated a resilience review from 14 Sep 2026 to 25 Sep 2026, and the business owners agreed the objectives on 25 Sep 2026. The dashboard is as at 30 Sep 2026.
Adapting this template
Small organisation: the seven measures are the minimum. Where one person coordinates and also runs the recovery, have someone outside IT read the dashboard before it goes to management.
Intervals: the Business Continuity & ICT Resilience Policy sets them (RR-05, RR-14, RR-16). Where you change one there, change it in the settings at the foot of the Dashboard; every date follows.
Financial entity under DORA: the yearly page can feed the management body's oversight of the ICT business continuity policy and the response and recovery plans (Article 5(2)(e)), and the report of test deficiencies (Delegated Regulation Article 25(5), or Article 40(3) for the entities of DORA Article 16(1)). It is neither of them on its own.
No peak season: leave both freeze months blank. Every planned test then shows "Clear".
This workbook is your own record. Keep it with the test records it reports.
Dashboard
Resilience readiness: quarterly dashboard
For [[executive management]] each quarter and [[the approver]] each year (RR-20). Yellow cells are yours; everything else calculates from the Services, Tests and Gaps and Roles sheets. Every figure is a count with names, and every status is in words; the colour only repeats it.
Report settings
| Setting | Value | Note | ||
|---|---|---|---|---|
| As-at date (the quarter's last day) | 30 Sep 2026 | Every status, date and measure is worked out at this date. | ||
| Quarter reported | Q3 2026 | Your words. | ||
| Three months after the As-at date (calc) | 30 Dec 2026 | A plan due for review by this date is named under RRM-02. | ||
| Peak-season freeze: first month (1 to 12) | 11 | EXAMPLE: November and December are the peak season (P10): no recovery test touches online ordering, dispatch or payments then. | ||
| Peak-season freeze: last month (1 to 12) | 12 | Leave both blank if you have no freeze. | ||
Headline measures (RR-20: counts with names, never a score or a share)
| Measure | Result at the As-at date | Target | Named | What it means | The decision it supports | Coordinator's commentary |
|---|---|---|---|---|---|---|
| RRM-01 Objectives agreed and current | 5 of 5 | All | None | How many critical services have objectives their business owner agreed within the review interval. An objective IT set alone does not count (RR-02). | Which business owners must review their analysis and objectives before the next report (RR-05). | EXAMPLE: re-agreed by the business owners at the review of 14 Sep 2026 to 25 Sep 2026 after INC-2026-014, adding the maximum tolerable downtime. Last agreed 30 Oct 2025. |
| RRM-02 Plans current | 5 of 5; 3 due by 30 Oct 2026 | All | Payments (30 Oct 2026); Finance and payroll (30 Oct 2026); Customer contact (30 Oct 2026) | How many critical services have a recovery plan reviewed within the interval, and which plans fall due for review in the next three months. | Whether the coordinator has the time booked with each business owner to review the plans falling due (RR-16). | EXAMPLE: online ordering and dispatch rewritten on the Cyber Recovery Plan Template on 25 Sep 2026. The other three plans date from 30 Oct 2025 and fall due by 30 Oct 2026. |
| RRM-03 Recovery tested | 3 of 5 | All | Not tested: Payments, Customer contact | How many critical services had their recovery tested in the last 12 months. A tabletop exercise is not a recovery test and is not counted (RR-14). | Whether the test plan reaches every untested service before its due date, and whether to bring a test forward. | EXAMPLE: payments and customer contact have never been tested. Their tests: RV-2027-01 on 13 Jan 2027 and RV-2026-04 on 28 Oct 2026. |
| RRM-04 Restored within objective | 2 of 5 | All | Missed the RTO: Online ordering (96 h against 24) | How many critical services came back within their recovery time objective in their last test, within 12 months. A service never tested counts as not restored within objective. | Which services need a fix and a retest, and which results the business can rely on. | EXAMPLE: the same 2 of 5 that P03 reports as BM-06. Online ordering: 96 hours against 24; Warehouse dispatch: 5 hours against 8; Finance and payroll: 3 hours against 48. |
| RRM-05 Could not recover in time | Online ordering | None | Online ordering: MTD 48 h; last test 96 h; after an attack 108 h | Services a test or the cyber recovery time shows would be back after their maximum tolerable downtime. Harm would reach Severe before they returned. | Whether the change that closes the gap is funded and on time, and what the business does meanwhile (RR-06, RR-15). | EXAMPLE: OG-01. The rebuild of the platform's recovery is P05 TA-01, due 15 Dec 2026; it is then tested in RV-2027-04 on 10 Mar 2027. |
| RRM-06 Objective gaps open and past due | 9 open; none past due | None past due | None past due. Next due 20 Oct 2026 | Objective gaps not yet closed, and those whose due date has passed (RR-15). | For a gap past due: escalate it, fund the fix, or agree a new date with the risk owner told (P05 RM-10). | EXAMPLE: all 9 found by the review on 25 Sep 2026; the change for each was due to be agreed by 9 Oct 2026 (RR-15). The first falls due on 20 Oct 2026 (OG-06). |
| RRM-07 Roles without a deputy | Communications lead | None | Communications lead (Head of Marketing and Communications) | Crisis and recovery roles with no named deputy. If the holder cannot act, nobody can act for them (RR-19). | Who will be named as deputy, and by when. | EXAMPLE: the Head of Marketing and Communications holds the role alone. Name a deputy, who then takes part in exercises with the holder (RR-19, P10 EX-07). |
Each figure counts named services, plans, tests, gaps or roles. Add none of them together, and never show one as a percentage or a colour total (RR-20).
Replace the EXAMPLE commentary with yours each quarter: what changed since last quarter, and what you ask management to decide.
Each critical service: tested time and cyber recovery time side by side
| Critical service | Business owner | MTD, hours | RTO, hours | Last test held | Time achieved, hours | Last test against the objectives | Cyber recovery time, hours | After a destructive attack | Status | Workaround tried | Next test due (RR-14) | Next test planned | Plan review due (RR-16) | Open objective gaps |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CS-01 Online ordering | Chief Operating Officer | 48 | 24 | 20 May 2026 | 96 | After the MTD | 108 | After the MTD | Not achievable | No | 20 May 2027 | 10 Mar 2027 | 25 Sep 2027 | 2: OG-01, OG-02 |
| CS-02 Warehouse dispatch | Head of Logistics | 24 | 8 | 27 Aug 2026 | 5 | Within the RTO | 17 | Within the MTD only | Needs its workaround | No | 27 Aug 2027 | 17 Feb 2027 | 25 Sep 2027 | 4: OG-03, OG-04, OG-05, OG-06 |
| CS-03 Payments | Chief Financial Officer | 72 | 24 | Never tested | 0 | Within the RTO | Not proven | Yes | 25 Mar 2027 | 13 Jan 2027 | 30 Oct 2026 | 1: OG-07 | ||
| CS-04 Finance and payroll | Chief Financial Officer | 120 | 48 | 20 Jan 2026 | 3 | Within the RTO | 12 | Within the RTO | Achievable | No | 20 Jan 2027 | 20 Jan 2027 | 30 Oct 2026 | 1: OG-08 |
| CS-05 Customer contact | Sales Director | 48 | 24 | Never tested | 12 | Within the RTO | Not proven | No | 25 Mar 2027 | 28 Oct 2026 | 30 Oct 2026 | 1: OG-09 |
Achievable: Tested within its RTO in the last 12 months, and its cyber recovery time is within the RTO. Needs its workaround: Tested in the last 12 months, but its test or its cyber recovery time puts it back after its RTO and within its MTD, so its workaround carries the gap.
Not proven: Not tested in the last 12 months. The objectives may be right; nobody has shown they can be met. Not achievable: Its test in the last 12 months or its cyber recovery time shows it would be back after its MTD.
The year's recovery tests, against each service's due date (RR-14)
| Critical service | Planned on | Test | Kind of test | What is recovered | Service's next test due | Against its due date | Peak-season freeze |
|---|---|---|---|---|---|---|---|
| CS-05 Customer contact | 28 Oct 2026 | RV-2026-04 | System restore | Mailboxes and the contact centre's call routing restored to a test tenancy, with the providers | 25 Mar 2027 | Before its due date | Clear |
| CS-03 Payments | 13 Jan 2027 | RV-2027-01 | Supplier recovery test | 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 | 25 Mar 2027 | Before its due date | Clear |
| CS-04 Finance and payroll | 20 Jan 2027 | RV-2027-02 | Supplier recovery test | The ERP provider's failover, with the payroll bureau running a test payroll from it | 20 Jan 2027 | Before its due date | Clear |
| CS-02 Warehouse dispatch | 17 Feb 2027 | RV-2027-03 | Cyber recovery | Foundations rebuilt in an isolated recovery environment, then the warehouse management system: the first measure of the cyber recovery time | 27 Aug 2027 | Before its due date | Clear |
| CS-01 Online ordering | 10 Mar 2027 | RV-2027-04 | Full restore | The ordering platform recovered on the rebuilt recovery set-up (P05 TA-01), against its 24 hours | 20 May 2027 | Before its due date | Clear |
Every test the Tests sheet marks Planned, earliest first. A service's due date is 12 months after its last test, or 6 months after its objectives were first agreed under the policy if it has never been tested (RR-14).
"In the freeze": a test of a service the freeze covers, planned in a freeze month. Move it. EXAMPLE: November and December are the peak season (P10): no recovery test touches online ordering, dispatch or payments then.
Month by month: the next 12 months
| Month | Peak-season freeze | Recovery tests planned | Of them, on a frozen service in the freeze |
|---|---|---|---|
| 1 Oct 2026 | 1 | 0 | |
| 1 Nov 2026 | Peak-season freeze | 0 | 0 |
| 1 Dec 2026 | Peak-season freeze | 0 | 0 |
| 1 Jan 2027 | 2 | 0 | |
| 1 Feb 2027 | 1 | 0 | |
| 1 Mar 2027 | 1 | 0 | |
| 1 Apr 2027 | 0 | 0 | |
| 1 May 2027 | 0 | 0 | |
| 1 Jun 2027 | 0 | 0 | |
| 1 Jul 2027 | 0 | 0 | |
| 1 Aug 2027 | 0 | 0 | |
| 1 Sep 2027 | 0 | 0 |
What this dashboard is not
It is not a score. Readiness is reported to [[executive management]] each quarter and to [[the approver]] each year, as counts with every gap named: no score and no share of readiness. Test records and crisis logs are kept for [[3]] years, or longer where law or a contract asks. (RR-20)
A tabletop exercise or a drill is not a recovery test, and is never counted here (RR-14). Exercises are the incident response exercise programme's (P10).
A service restored within its RTO in a test may still not come back in time after a destructive attack: that is why each service shows its cyber recovery time beside its tested time (RR-07, MX-05).
It does not say that any service, plan or requirement of NIS2, DORA or any standard is met. It counts what is agreed, current and tested, and names what is not.
It does not run a recovery. Decisions during an incident are the incident response plan's (P09) and the crisis lead's (RR-17).
Settings the formulas read (from the Business Continuity & ICT Resilience Policy)
| Setting | Value | Rule |
|---|---|---|
| Months between recovery tests of a service | 12 | RR-14 |
| Months from agreeing a never-tested service's objectives to its first test | 6 | RR-14 |
| Months between reviews of a recovery plan | 12 | RR-16 |
| Months between business owners' reviews of their objectives | 12 | RR-05 |
| Working days to agree the change that closes a gap | 10 | RR-15 |
These are the Business Continuity & ICT Resilience Policy's values. Public holidays are yours to add to the working-day count. Records are kept for [[3]] years (RR-20).
Reports
Quarterly readiness report
Page 1 goes to [[executive management]] each quarter; page 2 to [[the approver]] once a year (RR-20). The figures come from the Dashboard. Write the yellow cells in your own words; the EXAMPLE shows the kind of thing to say.
| For | [[executive management]] |
| Meeting on | 30 Sep 2026 |
| Quarter and As-at date | Q3 2026, as at 30 Sep 2026 |
The measures
| Measure | Result | Named | Target |
|---|---|---|---|
| RRM-01 Objectives agreed and current | 5 of 5 | None | All |
| RRM-02 Plans current | 5 of 5; 3 due by 30 Oct 2026 | Payments (30 Oct 2026); Finance and payroll (30 Oct 2026); Customer contact (30 Oct 2026) | All |
| RRM-03 Recovery tested | 3 of 5 | Not tested: Payments, Customer contact | All |
| RRM-04 Restored within objective | 2 of 5 | Missed the RTO: Online ordering (96 h against 24) | All |
| RRM-05 Could not recover in time | Online ordering | Online ordering: MTD 48 h; last test 96 h; after an attack 108 h | None |
| RRM-06 Objective gaps open and past due | 9 open; none past due | None past due. Next due 20 Oct 2026 | None past due |
| RRM-07 Roles without a deputy | Communications lead | Communications lead (Head of Marketing and Communications) | None |
| Where we stand | After INC-2026-014, the business owners re-agreed the objectives of all 5 critical services at workshops from 14 Sep 2026 to 25 Sep 2026, coordinated by the Head of Risk. Objectives agreed and current: 5 of 5. Plans current: 5 of 5. The plans for payments, for finance and payroll and for customer contact are due for review by 30 Oct 2026. Recovery tested in the last 12 months: 3 of 5. Restored within objective: 2 of 5, the same figure P03 reports as BM-06. Online ordering could not recover in time. Its test on 20 May 2026 took 96 hours, and after a destructive attack it would take 108, against a maximum tolerable downtime of 48 hours (OG-01). The fix is P05 TA-01, due 15 Dec 2026. Warehouse dispatch met its objective in test, but after an attack would take 17 hours against its 8, so it relies on its workaround, which has never been tried (OG-04). Objective gaps open: 9, none past due. The communications lead has no deputy. | ||
| What we ask you to decide | Name a deputy for the communications lead (RR-19). Note that online ordering cannot be back within its maximum tolerable downtime until P05 TA-01 is done and tested (OG-01). Note that warehouse dispatch relies on an untried workaround after an attack until RV-2027-03 measures the foundations' time (OG-04). | ||
| Open objective gaps, by name | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026; OG-04 Warehouse dispatch, due 17 Feb 2027; OG-05 Warehouse dispatch, due 15 Dec 2026; OG-06 Warehouse dispatch, due 20 Oct 2026; OG-07 Payments, due 13 Jan 2027; OG-08 Finance and payroll, due 17 Nov 2026; OG-09 Customer contact, due 1 Dec 2026 | ||
Yearly readiness report
| For | [[the approver]] |
| Meeting on | 29 Oct 2026 |
| The 12 months to | 30 Sep 2026 |
The year in counts
| Count | In the 12 months to the As-at date | Where to look |
|---|---|---|
| Critical services | 5 | Services |
| Recovery tests held | 3 | Tests |
| of which within the RTO | 2 | Tests |
| Recovery plans reviewed | 5 | Services |
| Objective gaps found | 9 | Gaps and Roles |
| Objective gaps closed | 0 | Gaps and Roles |
| Recovery tests planned for the next 12 months | 5 | Dashboard: the year's recovery tests |
The critical services, for approval with their objectives (RR-01, RR-05)
| Critical service | MTD, RTO and RPO, hours | Status | Objectives agreed on |
|---|---|---|---|
| CS-01 Online ordering | MTD 48; RTO 24; RPO 24 | Not achievable | 25 Sep 2026 |
| CS-02 Warehouse dispatch | MTD 24; RTO 8; RPO 4 | Needs its workaround | 25 Sep 2026 |
| CS-03 Payments | MTD 72; RTO 24; RPO 0 | Not proven | 25 Sep 2026 |
| CS-04 Finance and payroll | MTD 120; RTO 48; RPO 1 | Achievable | 25 Sep 2026 |
| CS-05 Customer contact | MTD 48; RTO 24; RPO 24 | Not proven | 25 Sep 2026 |
The measures at the year end
| Measure | Result | Named | Target |
|---|---|---|---|
| RRM-01 Objectives agreed and current | 5 of 5 | None | All |
| RRM-02 Plans current | 5 of 5; 3 due by 30 Oct 2026 | Payments (30 Oct 2026); Finance and payroll (30 Oct 2026); Customer contact (30 Oct 2026) | All |
| RRM-03 Recovery tested | 3 of 5 | Not tested: Payments, Customer contact | All |
| RRM-04 Restored within objective | 2 of 5 | Missed the RTO: Online ordering (96 h against 24) | All |
| RRM-05 Could not recover in time | Online ordering | Online ordering: MTD 48 h; last test 96 h; after an attack 108 h | None |
| RRM-06 Objective gaps open and past due | 9 open; none past due | None past due. Next due 20 Oct 2026 | None past due |
| RRM-07 Roles without a deputy | Communications lead | Communications lead (Head of Marketing and Communications) | None |
| The year in words | In the 12 months to 30 Sep 2026, 3 recovery tests were held: finance and payroll on 20 Jan 2026 (3 hours against 48), online ordering on 20 May 2026 (96 hours against 24) and warehouse dispatch on 27 Aug 2026 (5 hours against 8). INC-2026-014 was a significant incident, so the plans and objectives were reviewed from 14 Sep 2026 to 25 Sep 2026. The review found 9 objective gaps, each with an owner and a due date. Online ordering cannot recover within its maximum tolerable downtime (OG-01); P05 TA-01 rebuilds its recovery by 15 Dec 2026. Payments and customer contact have never been tested. | ||
| For your approval | Approve the 5 critical services and the objectives their business owners agreed on 25 Sep 2026 (RR-01, RR-05). Approve the year's 5 recovery tests, 28 Oct 2026 to 10 Mar 2027: every service before its due date, and none in November or December on online ordering, dispatch or payments (RR-14). Note the open gaps and the role without a deputy, named below. | ||
| Open objective gaps, by name | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026; OG-04 Warehouse dispatch, due 17 Feb 2027; OG-05 Warehouse dispatch, due 15 Dec 2026; OG-06 Warehouse dispatch, due 20 Oct 2026; OG-07 Payments, due 13 Jan 2027; OG-08 Finance and payroll, due 17 Nov 2026; OG-09 Customer contact, due 1 Dec 2026 | ||
| Roles without a deputy | Communications lead (Head of Marketing and Communications) | ||
Keep this report, the workbook it comes from and the test records it counts for [[3]] years, or longer where law or a contract asks (RR-20).
Services
One row per critical service, from the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD). Yellow columns are yours; white columns calculate at the As-at date on the Dashboard. Times are in hours.
| Row | Service ID | Critical service | Business owner | MTD, hours | RTO, hours | RPO, hours | Objectives last agreed by the business owner on | Objectives first agreed under the policy on | Cyber recovery time, hours (MX-05) | Covered by the peak-season freeze | Workaround tried | Plan last reviewed on | Objectives current (calc, RRM-01) | Last test held (calc) | Time achieved, hours (calc) | Tested in the last 12 months (calc, RRM-03) | Last test against the objectives (calc) | Restored within objective (calc, RRM-04) | After a destructive attack (calc, MX-05) | Status (calc) | Next test due (calc, RR-14) | Next test planned (calc) | Planned test against its due date (calc) | Plan review due (calc, RR-16) | Plan current (calc, RRM-02) | Plan review due within three months (calc) | Open gaps (calc) | Objectives not current, so far (working) | Plans due or past review, so far (working) | Not tested, so far (working) | Tested but missed the RTO, so far (working) | Could not recover in time, so far (working) | The same, with the times (working) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | CS-01 | Online ordering | Chief Operating Officer | 48 | 24 | 24 | 25 Sep 2026 | 25 Sep 2026 | 108 | Yes | No | 25 Sep 2026 | Yes | 20 May 2026 | 96 | Yes | After the MTD | No | After the MTD | Not achievable | 20 May 2027 | 10 Mar 2027 | Before its due date | 25 Sep 2027 | Yes | No | 2: OG-01, OG-02 | Online ordering (96 h against 24) | Online ordering | Online ordering: MTD 48 h; last test 96 h; after an attack 108 h | |||
| EXAMPLE | CS-02 | Warehouse dispatch | Head of Logistics | 24 | 8 | 4 | 25 Sep 2026 | 25 Sep 2026 | 17 | Yes | No | 25 Sep 2026 | Yes | 27 Aug 2026 | 5 | Yes | Within the RTO | Yes | Within the MTD only | Needs its workaround | 27 Aug 2027 | 17 Feb 2027 | Before its due date | 25 Sep 2027 | Yes | No | 4: OG-03, OG-04, OG-05, OG-06 | Online ordering (96 h against 24) | Online ordering | Online ordering: MTD 48 h; last test 96 h; after an attack 108 h | |||
| EXAMPLE | CS-03 | Payments | Chief Financial Officer | 72 | 24 | 0 | 25 Sep 2026 | 25 Sep 2026 | 0 | Yes | Yes | 30 Oct 2025 | Yes | No | Never tested | No | Within the RTO | Not proven | 25 Mar 2027 | 13 Jan 2027 | Before its due date | 30 Oct 2026 | Yes | Yes | 1: OG-07 | Payments (30 Oct 2026) | Payments | Online ordering (96 h against 24) | Online ordering | Online ordering: MTD 48 h; last test 96 h; after an attack 108 h | |||
| EXAMPLE | CS-04 | Finance and payroll | Chief Financial Officer | 120 | 48 | 1 | 25 Sep 2026 | 25 Sep 2026 | 12 | No | No | 30 Oct 2025 | Yes | 20 Jan 2026 | 3 | Yes | Within the RTO | Yes | Within the RTO | Achievable | 20 Jan 2027 | 20 Jan 2027 | Before its due date | 30 Oct 2026 | Yes | Yes | 1: OG-08 | Payments (30 Oct 2026); Finance and payroll (30 Oct 2026) | Payments | Online ordering (96 h against 24) | Online ordering | Online ordering: MTD 48 h; last test 96 h; after an attack 108 h | |
| EXAMPLE | CS-05 | Customer contact | Sales Director | 48 | 24 | 24 | 25 Sep 2026 | 25 Sep 2026 | 12 | No | No | 30 Oct 2025 | Yes | No | Never tested | No | Within the RTO | Not proven | 25 Mar 2027 | 28 Oct 2026 | Before its due date | 30 Oct 2026 | Yes | Yes | 1: OG-09 | Payments (30 Oct 2026); Finance and payroll (30 Oct 2026); Customer contact (30 Oct 2026) | Payments, Customer contact | Online ordering (96 h against 24) | Online ordering | Online ordering: MTD 48 h; last test 96 h; after an attack 108 h |
Tests
One row per recovery test, held or planned. A test recovers the service or its systems and measures the time against the objectives. A tabletop exercise is not a recovery test: never enter one (RR-14).
| Row | Test ID | Service ID | Date | Kind of test | Status | What is recovered | Time achieved, hours | Data lost, hours | Service (calc) | RTO, hours (calc) | Time against the objectives (calc) | Data lost against the RPO (calc) | Held in the 12 months to the As-at date (calc) | Service's next test due (calc, RR-14) | Against its due date (calc) | Peak-season freeze (calc) | Order among planned tests (working) | Service and date (working) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | RV-2026-01 | CS-04 | 20 Jan 2026 | Supplier recovery test | Held | The ERP provider's failover between its data centres, with results shared (P06 CON-05) | 3 | 0 | Finance and payroll | 48 | Within the RTO | Within the RPO | Yes | CS-04|46042 | ||||
| EXAMPLE | RV-2026-02 | CS-01 | 20 May 2026 | Full restore | Held | The ordering platform restored from its nightly backup into the hosting provider's spare environment | 96 | 24 | Online ordering | 24 | After the MTD | Within the RPO | Yes | CS-01|46162 | ||||
| EXAMPLE | RV-2026-03 | CS-02 | 27 Aug 2026 | System restore | Held | The warehouse management system restored from backup and checked by the warehouse team | 5 | 24 | Warehouse dispatch | 8 | Within the RTO | Beyond the RPO | Yes | CS-02|46261 | ||||
| EXAMPLE | RV-2026-04 | CS-05 | 28 Oct 2026 | System restore | Planned | Mailboxes and the contact centre's call routing restored to a test tenancy, with the providers | Customer contact | 24 | 25 Mar 2027 | Before its due date | Clear | 1 | ||||||
| EXAMPLE | RV-2027-01 | CS-03 | 13 Jan 2027 | Supplier recovery test | Planned | 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 | Payments | 24 | 25 Mar 2027 | Before its due date | Clear | 2 | ||||||
| EXAMPLE | RV-2027-02 | CS-04 | 20 Jan 2027 | Supplier recovery test | Planned | The ERP provider's failover, with the payroll bureau running a test payroll from it | Finance and payroll | 48 | 20 Jan 2027 | Before its due date | Clear | 3 | ||||||
| EXAMPLE | RV-2027-03 | CS-02 | 17 Feb 2027 | Cyber recovery | Planned | Foundations rebuilt in an isolated recovery environment, then the warehouse management system: the first measure of the cyber recovery time | Warehouse dispatch | 8 | 27 Aug 2027 | Before its due date | Clear | 4 | ||||||
| EXAMPLE | RV-2027-04 | CS-01 | 10 Mar 2027 | Full restore | Planned | The ordering platform recovered on the rebuilt recovery set-up (P05 TA-01), against its 24 hours | Online ordering | 24 | 20 May 2027 | Before its due date | Clear | 5 |
Gaps and Roles
One row per objective gap, from the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) (RR-15). The roles and their deputies are below the gaps, from the Crisis & Recovery Responsibility Matrix (RR-19).
| Row | Gap ID | Service ID | Checks failed | Finding | The change that closes it | Owner | Found on | Due | Status | Closed on | Linked work | Service (calc) | Change agreed by (calc, RR-15) | Open (calc) | Past its due date (calc) | Days to due date (calc) | Open gap number for its service (working) | Service and number (working) | Open gaps, so far (working) | Past due, so far (working) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | OG-01 | CS-01 | MX-02, MX-05, MX-06 | The ordering platform took 4 days to restore in May; the MTD is 2 days. | Rebuild the platform's recovery (P05 TA-01), then test it (RV-2027-04) | Head of IT | 25 Sep 2026 | 15 Dec 2026 | Open | P05 TA-01; P12 GAP-03 | Online ordering | 9 Oct 2026 | Yes | No | 76 | 1 | CS-01|1 | OG-01 Online ordering, due 15 Dec 2026 | ||
| EXAMPLE | OG-02 | CS-01 | MX-04 | The backup service provider's contract gives no recovery time. | Agree a restore time at the supplier's assessment and put it in the contract | Procurement Manager | 25 Sep 2026 | 3 Nov 2026 | Open | P06 SUP-011 | Online ordering | 9 Oct 2026 | Yes | No | 34 | 2 | CS-01|2 | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026 | ||
| EXAMPLE | OG-03 | CS-02 | MX-02, MX-04 | The network provider restores a failed line within 12 hours; dispatch needs 8. | A second line from another provider, or a shorter contracted time | Head of IT | 25 Sep 2026 | 8 Dec 2026 | Open | P06 SUP-014 | Warehouse dispatch | 9 Oct 2026 | Yes | No | 69 | 1 | CS-02|1 | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026 | ||
| EXAMPLE | OG-04 | CS-02 | MX-05 | After an attack, dispatch would take 17 hours: 12 to rebuild the foundations and 5 for the warehouse system. Its RTO is 8 and its MTD 24. | The Head of Logistics accepts the printed pick-list workaround after an attack; the foundations' time is measured in RV-2027-03 | Head of Logistics | 25 Sep 2026 | 17 Feb 2027 | Open | None | Warehouse dispatch | 9 Oct 2026 | Yes | No | 140 | 2 | CS-02|2 | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026; OG-04 Warehouse dispatch, due 17 Feb 2027 | ||
| EXAMPLE | OG-05 | CS-02 | MX-03 | Stock and dispatch records are backed up daily; dispatch can lose at most 4 hours. | Back up the warehouse management system's database every 4 hours | Head of IT | 25 Sep 2026 | 15 Dec 2026 | Open | None | Warehouse dispatch | 9 Oct 2026 | Yes | No | 76 | 3 | CS-02|3 | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026; OG-04 Warehouse dispatch, due 17 Feb 2027; OG-05 Warehouse dispatch, due 15 Dec 2026 | ||
| EXAMPLE | OG-06 | CS-02 | MX-04 | The warehouse management system provider's contract gives no recovery time. | Agree a recovery time at the supplier's assessment | Procurement Manager | 25 Sep 2026 | 20 Oct 2026 | Open | P06 SUP-010 | Warehouse dispatch | 9 Oct 2026 | Yes | No | 20 | 4 | CS-02|4 | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026; OG-04 Warehouse dispatch, due 17 Feb 2027; OG-05 Warehouse dispatch, due 15 Dec 2026; OG-06 Warehouse dispatch, due 20 Oct 2026 | ||
| EXAMPLE | OG-07 | CS-03 | MX-04, MX-06 | Never tested, and the payment provider's contract gives no recovery time. | Have the provider's recovery test checked against the objective (RV-2027-01) and ask for its recovery commitment in the contract | Chief Financial Officer | 25 Sep 2026 | 13 Jan 2027 | Open | P06 SUP-003 | Payments | 9 Oct 2026 | Yes | No | 105 | 1 | CS-03|1 | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026; OG-04 Warehouse dispatch, due 17 Feb 2027; OG-05 Warehouse dispatch, due 15 Dec 2026; OG-06 Warehouse dispatch, due 20 Oct 2026; OG-07 Payments, due 13 Jan 2027 | ||
| EXAMPLE | OG-08 | CS-04 | MX-04 | Neither the payroll bureau's nor the backup service provider's contract gives a recovery time. | Agree recovery times at the two suppliers' assessments | Procurement Manager | 25 Sep 2026 | 17 Nov 2026 | Open | P06 SUP-012; P06 SUP-011 | Finance and payroll | 9 Oct 2026 | Yes | No | 48 | 1 | CS-04|1 | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026; OG-04 Warehouse dispatch, due 17 Feb 2027; OG-05 Warehouse dispatch, due 15 Dec 2026; OG-06 Warehouse dispatch, due 20 Oct 2026; OG-07 Payments, due 13 Jan 2027; OG-08 Finance and payroll, due 17 Nov 2026 | ||
| EXAMPLE | OG-09 | CS-05 | MX-04, MX-06 | Never tested, and neither the email provider's nor the contact centre's contract gives a recovery time. | Test the restore (RV-2026-04) and agree recovery times at the contact centre's assessment | Sales Director | 25 Sep 2026 | 1 Dec 2026 | Open | P06 SUP-005; P06 SUP-013 | Customer contact | 9 Oct 2026 | Yes | No | 62 | 1 | CS-05|1 | OG-01 Online ordering, due 15 Dec 2026; OG-02 Online ordering, due 3 Nov 2026; OG-03 Warehouse dispatch, due 8 Dec 2026; OG-04 Warehouse dispatch, due 17 Feb 2027; OG-05 Warehouse dispatch, due 15 Dec 2026; OG-06 Warehouse dispatch, due 20 Oct 2026; OG-07 Payments, due 13 Jan 2027; OG-08 Finance and payroll, due 17 Nov 2026; OG-09 Customer contact, due 1 Dec 2026 |
Crisis and recovery roles, with deputies (RR-19)
Every crisis and recovery role has a named deputy, and no one is the first holder of two roles that must act in the same hour. Role holders and deputies take part in an exercise at least as often as P10 EX-07 sets. Copy each role from the Crisis & Recovery Responsibility Matrix.
| Row | Role | First holder | Deputy | Deputy named (calc) | Roles without a deputy, so far (working) | The same, with the holder (working) | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | Approver | The board | The board's chair calls an extraordinary meeting | Yes | ||||||||||||||||
| EXAMPLE | Policy owner | Chief Operating Officer | Chief Financial Officer | Yes | ||||||||||||||||
| EXAMPLE | Crisis lead | Chief Operating Officer | Chief Financial Officer | Yes | ||||||||||||||||
| EXAMPLE | Incident manager | Information Security Manager | Head of Information Security | Yes | ||||||||||||||||
| EXAMPLE | Technical recovery lead | Head of IT | IT Operations Manager | Yes | ||||||||||||||||
| EXAMPLE | Resilience coordinator | Head of Risk | Quality and Compliance Manager | Yes | ||||||||||||||||
| EXAMPLE | Communications lead | Head of Marketing and Communications | No | Communications lead | Communications lead (Head of Marketing and Communications) | |||||||||||||||
| EXAMPLE | Supplier liaison | Procurement Manager | Finance Manager | Yes | Communications lead | Communications lead (Head of Marketing and Communications) | ||||||||||||||
| EXAMPLE | Head of Information Security | Head of Information Security | Information Security Manager | Yes | Communications lead | Communications lead (Head of Marketing and Communications) | ||||||||||||||
Lists
| YesNo | TestKind | TestStatus | GapStatus |
|---|---|---|---|
| Yes | Supplier recovery test | Planned | Open |
| No | Full restore | Held | Closed |
| System restore | Cancelled |
Cyber recovery
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| RRM-01 Objectives agreed and current | Critical services whose business owner agreed the objectives in the last 12 months, out of all critical services. Target: All. |
| RRM-02 Plans current | Critical services whose recovery plan was reviewed in the last 12 months, out of all, with any due within the next quarter named. Target: All. |
| RRM-03 Recovery tested | Critical services whose recovery was tested in the last 12 months, out of all. Target: All. |
| RRM-04 Restored within objective | Critical services restored within their RTO in a test in the last 12 months, out of all. Target: All. |
| RRM-05 Could not recover in time | Critical services that a test or the cyber recovery time shows would be back after their MTD, by name. Target: None. |
| RRM-06 Objective gaps open and past due | Objective gaps not yet closed, with those past their due date by name. Target: None past due. |
| RRM-07 Roles without a deputy | Crisis and recovery roles with no named deputy, by name. Target: None. |
| 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. |
| 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). |
| Maximum tolerable downtime (MTD) | Maximum tolerable downtime: 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). |
| Recovery time objective (RTO) | Recovery time objective: the time within which the service must be back, counted from the decision to recover it. Always shorter than the MTD (RR-04). |
| Recovery point objective (RPO) | Recovery point objective: 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). |
| 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. |
| 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). |
| 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). |
| 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. An exercise, a tabletop or a drill, is not a recovery test (RR-14). |
| 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). |
| Status: Achievable | Tested within its RTO in the last 12 months, and its cyber recovery time is within the RTO. |
| Status: Needs its workaround | Tested in the last 12 months, but its test or its cyber recovery time puts it back after its RTO and within its MTD, so its workaround carries the gap. |
| Status: Not proven | Not tested in the last 12 months. The objectives may be right; nobody has shown they can be met. |
| Status: Not achievable | Its test in the last 12 months or its cyber recovery time shows it would be back after its MTD. |
| Within the RTO | The time achieved, or the cyber recovery time, is no longer than the RTO. |
| Missed the RTO | The test took longer than the RTO but no longer than the MTD. The service counts as not restored within objective (RRM-04) and needs its workaround. |
| After the MTD | The test, or the cyber recovery time, is longer than the MTD: the harm would reach Severe before the service returned (RRM-05). |
| Within the MTD only | After an attack the service would be back after its RTO but within its MTD, so its workaround must carry the gap (MX-05). |
| Tested in the last 12 months | A held test of the service dated after the day 12 months before the As-at date, and not after the As-at date. |
| Next test due | 12 months after the service's last held test; for a service never tested, 6 months after its objectives were first agreed under the policy (RR-14). |
| Plan current, plan review due | A plan is current while its review date, 12 months after its last review, is after the As-at date (RR-16). RRM-02 names those due within three months. |
| In the freeze | A planned test of a service the peak-season freeze covers, dated in a freeze month. Move it outside the freeze. |
| Change agreed by | 10 working days after a gap was found, the date by which its owner agrees the change that closes it (RR-15). Public holidays are not counted. |
| As-at date | The date every status, date and measure is worked out at: the quarter's last day. |
| Resilience coordinator | Keeps the objectives matrix, the dependency register, the plans and the test schedule current; keeps the crisis log during a disruption; reports readiness. |
| Approver | Approves the policy and the critical services' objectives, and receives the readiness dashboard. |
| (calc), (working) | A column or cell the workbook calculates. Do not type or paste over it. Working columns hold running lists other cells read. |
| RR-nn, MX-nn, RRM-nn | The rules, objective checks and headline measures of the Business Continuity & ICT Resilience Policy and the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD). CS-nn are critical services, RV-nnnn-nn recovery tests and OG-nn objective gaps. |
| EXAMPLE | A worked example: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, as at 30 Sep 2026, after its resilience review of 14 Sep 2026 to 25 Sep 2026. Delete before use. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Clause 9.1 — Monitoring, measurement, analysis and evaluation | The dashboard as a whole: what is measured about recovery readiness, when, and how the results are evaluated and reported |
| ISO/IEC 27001:2022 | Clause 9.3 — Management review | Reports sheet: the yearly page gives [[the approver]] results on recovery readiness to consider at management review |
| NIST CSF 2.0 | GV.OV-03 — “Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed” | Dashboard and Reports sheets: readiness evaluated each quarter and reviewed by management, with the decision each measure supports |
| NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The dashboard as a whole: a regular count of whether the continuity and recovery arrangements this point names are agreed, current and tested, with every gap named |
| 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 | Applies to the providers its Article 1 names. For them, the Annex points below; for others, a useful guide only |
| 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.” | RRM-02 and the Services sheet: each plan's last review and when the next falls due, including the review after a significant incident (providers Article 1 names) |
| 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.” | Tests sheet, RRM-03 and RRM-04: recovery tests recorded with the time achieved and the data lost against the objectives, and the gaps they raise on the Gaps and Roles sheet (providers Article 1 names) |
| DORA — Regulation (EU) 2022/2554 | Article 5(2)(e) — the management body shall “approve, oversee and periodically review the implementation of the financial entity’s ICT business continuity policy and ICT response and recovery plans, referred to, respectively, in Article 11(1) and (3)” | Reports sheet, for financial entities: the yearly report gives the management body counts it can use to oversee the ICT business continuity policy and the response and recovery plans. It informs that oversight; it does not discharge it |
| 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 | Tests sheet and the year's schedule on the Dashboard, for financial entities other than those of Article 16(1): when each service was last tested and when its next test falls due |
| 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.” | Gaps and Roles and Reports sheets, for financial entities: test results recorded, and each gap a test found named and reported to the management body |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 40(3) — the results of the testing are documented, and identified deficiencies “shall be analysed, addressed, and reported to the management body” | The same, for the entities of DORA Article 16(1), which test under Delegated Regulation Article 40 |
Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; ISO 22301:2019 incl. Amd 1:2024 (number and title 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)
ISO/IEC 27001 references name the clause or control this document relates to; ISO 22301 is named by number and title only. Neither says that meeting one meets any other framework's requirement.
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard.