Critical Service Recovery Objectives Matrix (RTO, RPO, MTD)
Records recovery objectives per service and flags inconsistencies between dependent systems.
Available soon
- Format
- Excel
- Size
- 99 KB
- Length
- 13 sheets
- Version
- 1.1
- Updated
What's inside
What changed
- 1.1
RR-11 points to P23 for other restore checks.
- 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 workbook is. One row per critical service, on four linked sheets. Impact Analysis gives each service's maximum tolerable downtime (MTD). Objectives records what its business owner agreed: the recovery time objective (RTO), the recovery point objective (RPO) and the workaround. Dependencies holds what the service needs to recover. Checks tests the objectives against the dependencies and the last recovery test, and gives each service a status. Objective Gaps records what will close each failed check. The rules are those of the Business Continuity & ICT Resilience Policy (RR-01 to RR-20). |
| 2 | Start on the Settings sheet. Enter the as-at date: the date you read the matrix. The 12-month windows of MX-06 and MX-07 count back from it, and a gap is past due once its due date is before it. Then check the other yellow values against your policy: the months between recovery tests, to a first test and between reviews of the objectives, the working days to agree a gap's change, and the hours to rebuild the foundations after an attack. |
| 3 | List your critical services on the Impact Analysis sheet (RR-01), one row each with an ID such as CS-01. With each business owner, rate the harm of an outage at 4, 8, 24, 48, 72, 120 and 168 hours on the risk register's impact areas (shown on the Settings sheet). Enter the worst level at each time point, from 1 (Minor) to 4 (Severe). The MTD calculates: the first time point at which the harm reaches Severe (RR-03). Say what drives the harm, and which area reaches Severe first. |
| 4 | On the Objectives sheet, the business owner agrees an RTO shorter than the MTD and an RPO, with the reason for the RPO (RR-04). IT proposes what is achievable; the business owner decides what is needed. Objectives set by IT alone are not agreed (RR-02). Record the workaround that keeps the harm below Severe until the service returns, and whether it has been tried (RR-06). Enter the date the objectives were last agreed, and the date they were first agreed under the policy: a never-tested service's first recovery test counts from that first date, so re-agreeing does not move it (RR-14). MX-01 calculates: the RTO must be shorter than the MTD. |
| 5 | On the same sheet, record each service's last recovery test: its ID, date, the time it took and the data lost. A recovery test recovers the service or its systems, restores its data and measures the time against the RTO. A tabletop exercise is not a recovery test (RR-14): P10 runs exercises, and they never count here. |
| 6 | On the Dependencies sheet, copy from the Resilience Dependency Register each dependency of each critical service: the services it supports (IDs separated by commas), its kind, who restores it after an attack, its recovery time, the backup interval of a data set, and for a supplier whether it needs a contracted recovery time and what the contract gives. Take the recovery time from a test where one exists, else the contract, else an estimate, and say which in Basis. The foundations row reads its hours from the Settings sheet. |
| 7 | Read the Checks sheet. Each check gives Pass or Fail with a note. The time achieved in the last test stands beside the cyber recovery time: the foundations' rebuild, if the service depends on them, plus the slowest system you restore yourself (MX-05). The status follows from the checks: Achievable, Needs its workaround, Not proven, Not achievable. The next recovery test due follows RR-14. |
| 8 | Find the cause of a failed check on the Dependencies sheet: its Flag column names, for each dependency, the check it fails and the objective it misses. |
| 9 | Record every failed check as an objective gap on the Objective Gaps sheet (RR-15): the checks it closes, the finding, the change that closes it, its owner and due date. The owner agrees the change within [[10]] working days of finding it; the date calculates. Tell the service's risk owner, who reassesses the risk (P05 RM-10). The last column of the Checks sheet names any failed check with no open gap: it should say None. |
| 10 | Review the matrix with each business owner at least every [[12]] months, and after a significant incident, a recovery test that missed an objective, or a significant change to the service, its suppliers or its risks (RR-05). Update the dependencies from the register when it changes (RR-09). Each quarter, report the statuses and gaps as counts with every gap named, never as a score or a share (RR-20). |
| 11 | Delete the EXAMPLE rows before the workbook is approved. This workbook is your own record: keep it with the recovery plans and the dependency register, and keep a copy that can be reached when the main systems are down (RR-16). |
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 two 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 a service can pass its recovery test and still fail MX-05: the test restored it onto trusted systems; after an attack, nothing is trusted until the foundations are rebuilt.
What this workbook does not decide. During an incident, the crisis lead sets the recovery order from these RTOs, foundations first (RR-08, P09 V1). Whether each system is restored or rebuilt, and the copy it is restored from, are decided under P09 D3 and D4 (RR-12). Every decision right in an incident is P09's (RR-17).
Who the law binds. NIS2's Implementing Regulation (EU) 2024/2690 binds only the providers its Article 1 names; other entities may use its Annex as good practice. DORA binds financial entities only, and its Articles 11 and 12 do not apply to the entities of its Article 16(1), which follow Article 16(1)(f) and Articles 39 and 40 of Delegated Regulation (EU) 2024/1774.
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 incident 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. The business owners agreed the objectives on 25 Sep 2026. Their statuses as at 30 Sep 2026: Online ordering, Not achievable; Warehouse dispatch, Needs its workaround; Payments, Not proven; Finance and payroll, Achievable; Customer contact, Not proven. 2 of 5 critical services were restored within their RTO in a test in the last 12 months. The review found 9 objective gaps.
Adapting this template
Settings: set the yellow values to your policy's. The time points of the impact analysis and the Severe level are this pack's defaults under RR-03, which your policy may change. The Severe level is the top level of your own risk register's scale: if your scale has more or fewer levels, enter its top level and adjust the level columns' validation to match. If you change the time points, change the Impact Analysis headers and the MTD formula with them.
Foundations: the EXAMPLE's 12 hours has this basis: Estimate (P09 Ransomware Response Playbook's example target); never tested as a whole. Replace yours with the time measured in your first cyber recovery test.
Small organisation: three to six critical services is usual. A one-hour workshop with each business owner is enough for the impact analysis and the objectives. Keep every check: a small team is more likely to depend on one supplier or one engineer.
IT run by a service provider: enter the provider's systems as Supplier rows with their contracted recovery times, or as System rows restored by the supplier. The cyber recovery time then counts only what you restore yourself, so ask the provider for its own recovery time after a destructive attack and put it in the contract (RR-10, MX-04).
Financial entity: your critical or important functions (DORA Article 3(22)) set which rows the matrix needs, and your recovery time and recovery point objectives must take account of their impact (DORA Article 12(6)). Confirm with counsel which DORA articles apply to you.
Backups: MX-03 compares each data set's backup interval with its service's RPO. How often other restore checks run follows the Backup & Restore Assurance pack, P23 (RR-11).
Settings
Settings
The values the checks read. Yellow cells are yours to set from your policy; grey values are this pack's defaults under the rule named, which your policy may change.
Settings the checks read
| Value | Setting | Rule |
|---|---|---|
| 30 Sep 2026 | As-at date: the date you read the matrix. MX-06 and MX-07 count their windows back from it; a gap is past due once its due date is before it. EXAMPLE: the distributor's quarter end, 30 Sep 2026. | RR-05, RR-14 |
| 12 | Months between recovery tests of each critical service (MX-06). | RR-14 |
| 6 | Months from first agreeing a never-tested service's objectives under the policy to its first recovery test. | RR-14 |
| 12 | Months between business owners' reviews of their objectives and impact analysis (MX-07). | RR-05 |
| 10 | Working days, Monday to Friday, to agree the change that closes an objective gap. Public holidays are not counted out: agree sooner where they fall. | RR-15 |
| 12 | Hours to rebuild the foundations after a destructive attack: the sign-in directory, the core network and firewalls, the backup platform, endpoint protection and monitoring, and the emergency administrator accounts. EXAMPLE basis: Estimate (P09 Ransomware Response Playbook's example target); never tested as a whole. | RR-07, MX-05 |
| 4 | The level on your risk register's impact scale that sets the MTD: the top of your own scale (Severe, level 4, in the pack's default scale below). | RR-03 |
| 4, 8, 24, 48, 72, 120, 168 | The time points, in hours, at which the impact analysis rates each service: this pack's default under RR-03. To change them, change the Impact Analysis headers and the MTD formula with them. | RR-03 |
The impact scale (the risk register's, P02 and P05)
| Level | Name and meaning |
|---|---|
| 1 | Minor: Affects one system of Standard criticality or non-sensitive data; no customer or regulatory effect. |
| 2 | Moderate: Affects a High criticality system or internal confidential data; limited, recoverable disruption. |
| 3 | Major: Affects a Critical system, personal or customer data, or a regulated service; notifiable if it went wrong. |
| 4 | Severe: Could stop a core business service, expose sensitive data at scale, or breach a legal obligation. |
The impact areas, and what Severe means in each (P05)
| Area | What the scale's ends mean in this area |
|---|---|
| Financial | Severe: more than [[€1,000,000]]. Minor: less than [[€50,000]]. |
| Service | Severe: a core customer service stopped for more than [[2]] days. Minor: an internal service degraded for hours. |
| Data | Severe: personal or customer data at scale. Minor: internal, non-personal data. |
| Legal and regulatory | Severe: a notifiable breach, enforcement or contract termination. Minor: no notification or breach. |
| Reputation | Severe: national press, or loss of a major customer. Minor: not noticed outside the team. |
Rate each area at each time point; enter the worst level on the Impact Analysis sheet. Online ordering in the EXAMPLE reaches Severe at 48 hours on the Service area.
Impact Analysis
One row per critical service. Enter the worst level on the impact scale at each time point; the MTD is the first time point at Severe (RR-03).
Levels: 1 Minor, 2 Moderate, 3 Major, 4 Severe. A level at or above Severe shows in bold red, with its number.
| Row | Service ID | Critical service | Worst level at 4 hours | Worst level at 8 hours | Worst level at 24 hours | Worst level at 48 hours | Worst level at 72 hours | Worst level at 120 hours | Worst level at 168 hours | What drives the harm, and the area that reaches Severe first | MTD: first time at Severe, in hours (calc) | Check (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | CS-01 | Online ordering | 2 | 2 | 3 | 4 | 4 | 4 | 4 | Service: most orders arrive through it (P03); stopped for more than 2 days is Severe (P05 R-01) | 48 | OK |
| EXAMPLE | CS-02 | Warehouse dispatch | 2 | 3 | 4 | 4 | 4 | 4 | 4 | Service: customers' kitchens run out of perishable stock within a day | 24 | OK |
| EXAMPLE | CS-03 | Payments | 1 | 1 | 2 | 3 | 4 | 4 | 4 | Financial: card payments stop; most business customers pay on account | 72 | OK |
| EXAMPLE | CS-04 | Finance and payroll | 1 | 1 | 1 | 2 | 3 | 4 | 4 | Legal and regulatory, Financial: payroll must run before pay day | 120 | OK |
| EXAMPLE | CS-05 | Customer contact | 1 | 2 | 3 | 4 | 4 | 4 | 4 | Reputation, Service: customers cannot reach anyone about orders | 48 | OK |
Objectives
One row per critical service, in the order of the Impact Analysis. The business owner agrees the RTO, the RPO and the workaround (RR-02, RR-04, RR-06).
Record the last recovery test of each service: a tabletop exercise is not a recovery test (RR-14). Leave the test cells blank for a service never tested.
| Row | Service ID | Critical service (calc) | Business owner | MTD, hours (calc) | RTO, hours | RPO, hours | Why this RPO | Workaround | Workaround tried? | Objectives last agreed on | First agreed under the policy | Last recovery test | Test date | Time it took, hours | Data lost, hours | MX-01: RTO shorter than the MTD (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | CS-01 | Online ordering | Chief Operating Officer | 48 | 24 | 24 | Orders since the last nightly backup are keyed again from the confirmations customers hold | Telephone and email orders keyed by the customer contact team into the ERP, about [[a fifth]] of a normal day's orders | No | 25 Sep 2026 | 25 Sep 2026 | RV-2026-02 | 20 May 2026 | 96 | 24 | Pass |
| EXAMPLE | CS-02 | Warehouse dispatch | Head of Logistics | 24 | 8 | 4 | Stock movements after the recovery point are found again by a count of the affected aisles | Dispatch from printed pick lists of the next day's orders, printed each evening, for up to [[24]] hours | No | 25 Sep 2026 | 25 Sep 2026 | RV-2026-03 | 27 Aug 2026 | 5 | 24 | Pass |
| EXAMPLE | CS-03 | Payments | Chief Financial Officer | 72 | 24 | 0 | Payments are held by the payment service provider; none may be lost | Business customers are invoiced on account; card customers are called back | Yes | 25 Sep 2026 | 25 Sep 2026 | Never tested | Pass | |||
| EXAMPLE | CS-04 | Finance and payroll | Chief Financial Officer | 120 | 48 | 1 | Postings since the recovery point are re-entered from the source documents | The payroll bureau repeats last month's payroll, corrected the next month | No | 25 Sep 2026 | 25 Sep 2026 | RV-2026-01 | 20 Jan 2026 | 3 | 0 | Pass |
| EXAMPLE | CS-05 | Customer contact | Sales Director | 48 | 24 | 24 | Email held by the provider; call records are not needed | The contact centre answers from a published phone number and logs calls on paper | No | 25 Sep 2026 | 25 Sep 2026 | Never tested | Pass |
Dependencies
What each critical service needs to recover: a compact copy of the Resilience Dependency Register (RR-09). The checks read this sheet; the register keeps the full record.
Separate service IDs with commas. Leave a cell blank where it does not apply: a recovery time for people or a site, a backup interval for anything but data. The foundations row takes its hours from the Settings sheet.
| Row | Dependency ID | Services it supports (IDs) | Kind | Dependency | System: restored after an attack by | Recovery time, hours | Data: backed up every, hours | Supplier: needs a contracted recovery time? | Supplier: contracted recovery time, hours | Basis | Shortest RTO it supports, hours (calc) | Shortest RPO it supports, hours (calc) | Flag (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | DP-01 | CS-01, CS-02, CS-04, CS-05 | Foundations | Foundations: sign-in directory, network, backup platform, endpoint protection | 12 | Estimate | 8 | 1 | None | ||||
| EXAMPLE | DP-02 | CS-01 | System | Online ordering platform | In-house | 96 | Tested 20 May 2026: restored from backup in 4 days (P05 R-01) | 24 | 24 | MX-02: recovers in 96 h, a service it supports needs 24 h | |||
| EXAMPLE | DP-03 | CS-01, CS-04 | Supplier | Cloud hosting provider | 24 | Yes | 24 | Contract: hosting restored within 24 hours | 24 | 1 | None | ||
| EXAMPLE | DP-04 | CS-01, CS-04 | Supplier | Backup service provider | Yes | Not in the contract; assessment planned 3 Nov 2026 (P06) | 24 | 1 | MX-04: no contracted recovery time | ||||
| EXAMPLE | DP-05 | CS-01 | Data | Orders and customer accounts | 24 | Nightly backup (P05 R-01) | 24 | 24 | None | ||||
| EXAMPLE | DP-06 | CS-01 | People | Ordering platform team | Not a recovery time | 24 | 24 | None | |||||
| EXAMPLE | DP-07 | CS-02 | System | Warehouse management system | In-house | 5 | Tested 27 Aug 2026: restored in 5 hours (P03) | 8 | 4 | None | |||
| EXAMPLE | DP-08 | CS-02 | Supplier | Warehouse management system provider | Yes | Not in the contract; assessment planned 20 Oct 2026 (P06) | 8 | 4 | MX-04: no contracted recovery time | ||||
| EXAMPLE | DP-09 | CS-02, CS-04 | Supplier | ERP software provider (hosted) | 8 | Yes | 8 | Contract: restored within 8 hours, at most 15 minutes of data lost (P06 CON-03) | 8 | 1 | None | ||
| EXAMPLE | DP-10 | CS-02 | Data | Stock and dispatch records | 24 | Daily backup | 8 | 4 | MX-03: backed up every 24 h, a service it supports can lose at most 4 h | ||||
| EXAMPLE | DP-11 | CS-01, CS-02 | Supplier | Network connectivity provider | 12 | Yes | 12 | Contract: a failed line restored within 12 hours | 8 | 4 | MX-02: recovers in 12 h, a service it supports needs 8 h; MX-04: contracted 12 h, a service it supports needs 8 h | ||
| EXAMPLE | DP-12 | CS-02 | Supplier | National parcel carrier, express courier, pallet network | No | Three carriers: each can take another's work | 8 | 4 | None | ||||
| EXAMPLE | DP-13 | CS-02 | Site | Warehouses 1 to 3 | Not a recovery time | 8 | 4 | None | |||||
| EXAMPLE | DP-14 | CS-03 | Supplier | Payment service provider | Yes | The contract sets availability, not a recovery time | 24 | 0 | MX-04: no contracted recovery time | ||||
| EXAMPLE | DP-15 | CS-04 | Data | Ledgers and payroll records | 0.25 | The provider's contract: at most 15 minutes lost (P06 CON-03) | 48 | 1 | None | ||||
| EXAMPLE | DP-16 | CS-04 | Supplier | Payroll bureau | Yes | Not in the contract; assessment planned 17 Nov 2026 (P06) | 48 | 1 | MX-04: no contracted recovery time | ||||
| EXAMPLE | DP-17 | CS-05 | Supplier | Email and office software provider | Yes | The contract sets availability, not a recovery time | 24 | 24 | MX-04: no contracted recovery time | ||||
| EXAMPLE | DP-18 | CS-05 | Supplier | Outsourced customer contact centre | Yes | Not in the contract; assessment planned 1 Dec 2026 (P06) | 24 | 24 | MX-04: no contracted recovery time |
Checks
Calculated for each service on the Objectives sheet, as at the Settings sheet's date. Nothing here is typed: change the inputs on the other sheets. A failed check is an objective gap (RR-15).
Two times for each service: the time its last recovery test took, and the cyber recovery time after a destructive attack (RR-07). The statuses are explained on the Definitions sheet.
| Row | Service ID | Critical service | MTD, hours | RTO, hours | RPO, hours | MX-01: Recovery time shorter than the maximum | MX-01 note | MX-02: Dependencies recover in time | MX-02 note | MX-03: Backups as often as the recovery point | MX-03 note | MX-04: Supplier recovery times known and in time | MX-04 note | Time in the last recovery test, hours | Cyber recovery time, hours | Cyber recovery time made up of | MX-05: Cyber recovery within the objective | MX-05 note | Tested in the last 12 months? | MX-06: Tested within objective | MX-06 note | MX-07: Objectives agreed and current | MX-07 note | Status | Next recovery test due | Failed checks with no open objective gap |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | CS-01 | Online ordering | 48 | 24 | 24 | Pass | RTO 24 h, MTD 48 h | Fail | 1 later than the RTO; the slowest takes 96 h | Pass | All within the RPO | Fail | 1 with no contracted recovery time | 96 | 108 | Foundations 12 h + slowest in-house system 96 h | Fail | 108 h after an attack, beyond the MTD: cannot recover in time | Yes | Fail | 20 May 2026: 96 h | Pass | Agreed 25 Sep 2026 | Not achievable | 20 May 2027 | None |
| EXAMPLE | CS-02 | Warehouse dispatch | 24 | 8 | 4 | Pass | RTO 8 h, MTD 24 h | Fail | 1 later than the RTO; the slowest takes 12 h | Fail | 1 backed up less often than the RPO; the longest interval is 24 h | Fail | 1 with no contracted recovery time; 1 contracted for longer than the RTO | 5 | 17 | Foundations 12 h + slowest in-house system 5 h | Fail | 17 h after an attack, beyond the RTO, within the MTD: needs its workaround | Yes | Pass | 27 Aug 2026: 5 h | Pass | Agreed 25 Sep 2026 | Needs its workaround | 27 Aug 2027 | None |
| EXAMPLE | CS-03 | Payments | 72 | 24 | 0 | Pass | RTO 24 h, MTD 72 h | Pass | All within the RTO | Pass | All within the RPO | Fail | 1 with no contracted recovery time | Never tested | 0 | Nothing restored in-house: suppliers recover it (MX-04) | Pass | 0 h after an attack, within the RTO | No | Fail | Never tested | Pass | Agreed 25 Sep 2026 | Not proven | 25 Mar 2027 | None |
| EXAMPLE | CS-04 | Finance and payroll | 120 | 48 | 1 | Pass | RTO 48 h, MTD 120 h | Pass | All within the RTO | Pass | All within the RPO | Fail | 2 with no contracted recovery time | 3 | 12 | Foundations 12 h | Pass | 12 h after an attack, within the RTO | Yes | Pass | 20 Jan 2026: 3 h | Pass | Agreed 25 Sep 2026 | Achievable | 20 Jan 2027 | None |
| EXAMPLE | CS-05 | Customer contact | 48 | 24 | 24 | Pass | RTO 24 h, MTD 48 h | Pass | All within the RTO | Pass | All within the RPO | Fail | 2 with no contracted recovery time | Never tested | 12 | Foundations 12 h | Pass | 12 h after an attack, within the RTO | No | Fail | Never tested | Pass | Agreed 25 Sep 2026 | Not proven | 25 Mar 2027 | None |
Objective Gaps
Every failed check, and every objective a test or a real recovery missed, is an objective gap (RR-15). Its owner agrees the change within 10 working days; tell the service's risk owner (P05 RM-10).
Separate check IDs with commas. Close a gap only when the checks it names pass, or the business owner has re-agreed the objective on a new analysis (RR-05).
| Row | Gap ID | Service ID | Checks it closes | Finding | The change that closes it | Owner | Found on | Change agreed by (calc) | Due date | Status | Linked work in other packs | Past due? (calc) | Named checks still failing? (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 | 9 Oct 2026 | 15 Dec 2026 | Open | P05 TA-01; P12 GAP-03 | Not past due | Every named check still fails |
| 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 | 9 Oct 2026 | 3 Nov 2026 | Open | P06 SUP-011 | Not past due | Every named check still fails |
| 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 | 9 Oct 2026 | 8 Dec 2026 | Open | P06 SUP-014 | Not past due | Every named check still fails |
| 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 | 9 Oct 2026 | 17 Feb 2027 | Open | None | Not past due | Every named check still fails |
| 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 | 9 Oct 2026 | 15 Dec 2026 | Open | None | Not past due | Every named check still fails |
| 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 | 9 Oct 2026 | 20 Oct 2026 | Open | P06 SUP-010 | Not past due | Every named check still fails |
| 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 | 9 Oct 2026 | 13 Jan 2027 | Open | P06 SUP-003 | Not past due | Every named check still fails |
| 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 | 9 Oct 2026 | 17 Nov 2026 | Open | P06 SUP-012; P06 SUP-011 | Not past due | Every named check still fails |
| 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 | 9 Oct 2026 | 1 Dec 2026 | Open | P06 SUP-005; P06 SUP-013 | Not past due | Every named check still fails |
Lists
| YesNo | Kind | RestoredBy | GapStatus |
|---|---|---|---|
| Yes | Foundations | In-house | Open |
| No | System | Supplier | Closed |
Supplier
Data
People
Site
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| 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). |
| Business impact analysis (BIA) | Business impact analysis: for each critical service, how the harm grows over time on the risk register's impact areas, and the point at which it becomes Severe (RR-03). |
| 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). |
| 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). |
| Dependency | Anything a critical service needs to run: a system, a supplier, a data set, a group of people, a site, or the foundations (RR-09). |
| 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). |
| 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). |
| Recovery point | The backup copy a system is restored from: the newest copy taken before the earliest sign of the attacker, checked for integrity and scanned before use (RR-12; P09 D3). |
| Restore | Put data or a system back from a backup copy that has been checked for integrity (P09 IM-10). |
| Rebuild | Wipe a system and install it again from a trusted build source, then restore only its data (P09 D4). |
| MX-01 Recovery time shorter than the maximum | The RTO is shorter than the MTD (RR-04). |
| MX-02 Dependencies recover in time | Every system and supplier dependency recovers within the service's RTO (RR-04). |
| MX-03 Backups as often as the recovery point | Every data set the service needs is backed up at least as often as its RPO (RR-11). |
| MX-04 Supplier recovery times known and in time | Every supplier that runs a system the service needs has a contracted recovery time, no longer than the RTO (RR-10). |
| MX-05 Cyber recovery within the objective | The cyber recovery time (foundations, then the slowest system restored in-house) is within the RTO. Beyond the RTO but within the MTD, the service needs its workaround; beyond the MTD, it cannot recover in time (RR-07). |
| MX-06 Tested within objective | Recovery was tested within the last 12 months, with the time achieved within the RTO (RR-14). |
| MX-07 Objectives agreed and current | The business owner agreed the objectives within the last 12 months (RR-05). |
| 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. |
| Recovery time (of a dependency) | The time the dependency takes to come back: from a test where one exists, else the contract, else an estimate. The Basis column says which. |
| Restored in-house | A system your own team, or a provider working to your instructions, restores after an attack. Its time counts in the cyber recovery time. A system a supplier runs and restores counts under MX-02 and MX-04 instead. |
| As-at date | The date the matrix is read, on the Settings sheet. Every 12-month window counts back from it. |
| CS-nn, DP-nn, OG-nn | The IDs of a critical service, a dependency and an objective gap. Keep them stable: the Resilience Dependency Register, the Cyber Recovery Plan Template and the Resilience Readiness Dashboard use the same IDs. |
| RR-nn | The rules of the Business Continuity & ICT Resilience Policy, RR-01 to RR-20. |
| P09 D3, D4, V1 | Steps of P09's Ransomware Response Playbook: the backup check, the restore-or-rebuild decision, and the recovery order. P09 owns incident response. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| 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. Delete before approval. |
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 | Annex A 5.30 — ICT readiness for business continuity | The whole workbook: the recovery objectives of each critical service, and whether its ICT can recover within them |
| NIST CSF 2.0 | RC.RP-02 — “Recovery actions are selected, scoped, prioritized, and performed” | Objectives and Checks sheets: the RTOs that set the recovery order, and the checks that scope what each recovery needs |
| NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The whole workbook: each critical service's recovery objectives, set from its impact analysis, and the checks that show whether they can be met |
| 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 | The Implementing Regulation applies only to the providers its Article 1 names. For them, the Annex points below; other entities may use them as good practice |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.1.2 — “The relevant entities’ operations shall be restored according to the business continuity and disaster recovery plan.” The plan is based on the risk assessment (point 2.1) and includes, where appropriate: purpose, scope and audience; roles and responsibilities; key contacts and communication channels; conditions for plan activation and deactivation; order of recovery for operations; recovery plans for specific operations, including recovery objectives; required resources, including backups and redundancies; restoring and resuming activities from temporary measures | Objectives sheet: the recovery objectives each service's recovery plan works to; Checks sheet: whether the plan can reach them |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.1.3 — “The relevant entities shall carry out a business impact analysis to assess the potential impact of severe disruptions to their business operations and shall, based on the results of the business impact analysis, establish continuity requirements for the network and information systems.” | Impact Analysis sheet: the harm of a disruption over time, and the maximum tolerable downtime it sets; Objectives sheet: the requirements set from it |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.2 — based on the risk assessment (point 2.1) and the business continuity plan, backup plans that include recovery times; “assurance that backup copies are complete and accurate, including configuration data and data stored in cloud computing service environment”; storing backup copies in a safe location or locations “which are not in the same network as the system, and are at sufficient distance to escape any damage from a disaster at the main site”; physical and logical access controls to backup copies in accordance with the asset classification level; restoring data from backup copies; and retention periods based on business and regulatory requirements | Dependencies sheet and MX-03: each data set's backup interval against its service's recovery point; MX-02 and MX-05: recovery times |
| DORA — Regulation (EU) 2022/2554 | Article 3(22) — “critical or important function”: a function “the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities”, or whose discontinued, defective or failed performance would materially impair continuing compliance with the conditions and obligations of its authorisation or its other obligations under applicable financial services law | Objectives sheet, for financial entities: which of your functions are critical or important decides which rows the matrix needs |
| DORA — Regulation (EU) 2022/2554 | Article 11(5) — “As part of the overall business continuity policy, financial entities shall conduct a business impact analysis (BIA) of their exposures to severe business disruptions.” The BIA uses quantitative and qualitative criteria, internal and external data and scenario analysis; considers the criticality of business functions, support processes, third-party dependencies and information assets and their interdependencies; and ICT assets and services are designed and used in full alignment with it, in particular to ensure “the redundancy of all critical components” | Impact Analysis sheet, for financial entities: the impact of a severe disruption over time; Dependencies sheet: third-party dependencies and what depends on them |
| DORA — Regulation (EU) 2022/2554 | Article 12(6) — “In determining the recovery time and recovery point objectives for each function, financial entities shall take into account whether it is a critical or important function and the potential overall impact on market efficiency. Such time objectives shall ensure that, in extreme scenarios, the agreed service levels are met.” | Objectives sheet, for financial entities: a recovery time and a recovery point objective for each function, and MX-05 for the extreme scenario of a destructive attack |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 24(1)(b)(ii) — alignment between the ICT business continuity plans and the overall business continuity plans, at least on potential failure scenarios and on recovery objectives, “specifying that the financial entity shall be able to recover the operations of its critical or important functions after disruptions within a recovery time objective and a recovery point objective” | Objectives and Checks sheets, for financial entities: each critical function's recovery time and recovery point objectives, and whether its systems can recover within them |
| GDPR — Regulation (EU) 2016/679 | Article 32(1)(c) — the security measures include, as appropriate, “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident” | MX-03 and MX-05: whether the personal data a critical service holds can be restored in time after a physical or technical incident |
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.
The NIS2 Implementing Regulation binds only the providers its Article 1 names. DORA binds financial entities only; the entities of its Article 16(1) follow Article 16(1)(f) and Delegated Regulation Articles 39 and 40 instead of Articles 11 and 12.