Resilience Dependency Register
Maps each critical service to its systems, suppliers, people and data dependencies.
Available soon
- Format
- Excel
- Size
- 100 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 register is. Every critical service has its dependencies recorded: systems, suppliers, data, people, sites and the foundations. Each has a recovery time; a single point of failure is marked with its alternative, or as having none. The register is reviewed at least every [[12]] months and when a dependency changes. The resilience coordinator keeps it. The Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) reads it for its checks MX-02 to MX-05, and each service's recovery plan, written from the Cyber Recovery Plan Template, copies its rows into section PS-4. |
| 2 | Start on the Services sheet. Set the as-at date, then enter each critical service's ID, name, business owner and its maximum tolerable downtime (MTD), recovery time objective (RTO) and recovery point objective (RPO), in hours, exactly as the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) records them. The business owner agrees these; this register does not set them (RR-02). |
| 3 | Find the dependencies with each business owner and IT, using the Finding dependencies sheet: the questions, the walk through one transaction end to end, and the questions for suppliers about their own suppliers. |
| 4 | On the Register sheet, add one row per dependency. Give it an ID (DP-nn), a kind from the list, a name, and the IDs of every critical service it supports, separated by commas, such as "CS-01, CS-02". A dependency two services share is one row, not two. |
| 5 | Put the reference to the other record it comes from: the supplier's entry in the supplier register (P06 SUP-nnn), the system's entry in the asset inventory (P07 SYS-nn), or the document that sets it. |
| 6 | Fill the columns that apply to its kind (the Finding dependencies sheet says which). A system: its recovery time, the basis (Tested, Contract or Estimate) and who restores it after an attack. A data set: how often it is backed up. A supplier: whether it runs a system the service needs and, if so, the recovery time its contract gives, or "Not known". |
| 7 | Mark every single point of failure: if it stopped, the service would stop and nothing else could take its place. Write the alternative, or None, and say whether the alternative is in place today. |
| 8 | Name the owner of each entry, the person who keeps it current, and the date it was last reviewed. The next review falls 12 months later (RR-09), or sooner when the dependency changes. |
| 9 | Read the flags. White columns calculate: MX-02 (dependencies recover in time), MX-03 (backups as often as the recovery point), MX-04 (supplier recovery times known and in time), and the single point of failure check. An MX flag on any row is an objective gap: the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) records it with an owner, the change that closes it and a due date (RR-15). A single point of failure with no alternative is for its business owner to close or accept. |
| 10 | Read the Service grid sheet to check which services each dependency supports, and the Services sheet for each service's checks and its cyber recovery time beside its RTO and MTD. A service beyond its RTO after an attack needs its workaround (RR-06); one beyond its MTD cannot recover in time. |
| 11 | Read the Concentration sheet: every dependency two or more critical services share. Each one stops several services at once: the crisis lead weighs it when setting the recovery order (RR-08), and it needs an alternative or an exit plan. |
| 12 | Review the register at least every [[12]] months, after every recovery test and real recovery, and whenever a system, supplier, team or site changes. Replace an Estimate with the time a test measures. |
| 13 | To clear the EXAMPLE, delete the Register sheet's EXAMPLE rows and the Services sheet's EXAMPLE services once your own are entered. 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 the cyber recovery time: 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.
This register records dependencies. It does not decide anything P09 decides: whether a system is restored or rebuilt (P09 D4), which backup to restore from (P09 D3) or when a system is clean (P09 IM-10).
EXAMPLE: the distributor of the worked example, an important entity under NIS2 in its Member State and not a financial entity, so DORA's reporting duties do not apply. Its Head of Risk, who runs no system in scope, coordinated the resilience review of 14 Sep 2026 to 25 Sep 2026 after INC-2026-014. The business owners agreed their objectives on 25 Sep 2026, and the register's 18 dependencies were reviewed in the same workshops. As at 30 Sep 2026.
Adapting this template:
• Small organisation: start with the critical services and their systems, suppliers and data; add people and sites at the first review. A service with only a supplier and a data set still needs both recorded.
• Several sites or business units: keep one register, with one row per dependency. A dependency used by two units' services is still one row; the grid and the concentration sheet show the sharing.
• More than 12 critical services, or more than 80 dependencies: copy a formula row down within the Register table and add a service column on the Service grid sheet, copying the column beside it. Check the Services sheet totals afterwards.
• A supplier that runs several of your systems: one Supplier row for each contract, and one System row for each system, so each recovery time sits on its own row.
• Regulated entities (NIS2, DORA): the register records dependencies and their recovery times. Whether it is what your regulator expects is for you and your counsel to confirm.
This workbook is your own record. Keep it with your recovery plans and objectives matrix, and keep a copy that can be reached when the main systems are down (RR-16).
Register
EXAMPLE: 18 dependencies of 5 critical services, as at 30 Sep 2026. Yellow columns are inputs; white columns calculate from the Services sheet's objectives. One row per dependency (RR-09).
| Example | Dependency ID | Kind | Dependency | Critical services it supports (IDs, separated by commas) | Reference in the other pack's record (P06 SUP-nnn, P07 SYS-nn) | Who restores it after an attack (systems) | Recovery time (hours) | Basis of the recovery time | Basis in detail | Backup interval (hours, data) | Runs a system the service needs (suppliers) | Contracted recovery time (hours, or Not known) | Single point of failure | Alternative, or None | Alternative in place | Owner of this entry | Last reviewed | Critical services it supports (calc) | Shortest RTO among them, hours (calc) | Shortest RPO among them, hours (calc) | Recovery time against the RTO (MX-02, calc) | Backup against the RPO (MX-03, calc) | Supplier's contracted time (MX-04, calc) | Single point of failure (RR-09, calc) | Next review due (RR-09, calc) | Review status (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | DP-01 | Foundations | Foundations: sign-in directory, network, backup platform, endpoint protection | CS-01, CS-02, CS-04, CS-05 | P09 Ransomware Response Playbook | 12 | Estimate | Estimate | Yes | None: every in-house system needs them first | No | [[e.g. Head of IT]] | 25 Sep 2026 | 4 | 8 | 1 | No alternative (RR-09) | 25 Sep 2027 | In date | |||||||
| EXAMPLE | DP-02 | System | Online ordering platform | CS-01 | P11 critical systems; hosted (P06 SUP-002) | In-house | 96 | Tested | Tested 20 May 2026: restored from backup in 4 days (P05 R-01) | Yes | None | No | [[e.g. Head of IT]] | 25 Sep 2026 | 1 | 24 | 24 | Later than the RTO (MX-02) | No alternative (RR-09) | 25 Sep 2027 | In date | |||||
| EXAMPLE | DP-03 | Supplier | Cloud hosting provider | CS-01, CS-04 | P06 SUP-002 | 24 | Contract | Contract: hosting restored within 24 hours | Yes | 24 | Yes | None within the RTO | No | [[e.g. Procurement Manager]] | 25 Sep 2026 | 2 | 24 | 1 | OK | OK | No alternative (RR-09) | 25 Sep 2027 | In date | |||
| EXAMPLE | DP-04 | Supplier | Backup service provider | CS-01, CS-04 | P06 SUP-011 | Not in the contract; assessment planned 3 Nov 2026 (P06) | Yes | Not known | Yes | None | No | [[e.g. Procurement Manager]] | 25 Sep 2026 | 2 | 24 | 1 | Not known: see MX-04 | Recovery time not known (MX-04) | No alternative (RR-09) | 25 Sep 2027 | In date | |||||
| EXAMPLE | DP-05 | Data | Orders and customer accounts | CS-01 | Ordering platform database | Nightly backup (P05 R-01) | 24 | No | Customers' order confirmations | Yes | [[the manager accountable for each critical service]] | 25 Sep 2026 | 1 | 24 | 24 | OK | Not a single point | 25 Sep 2027 | In date | |||||||
| EXAMPLE | DP-06 | People | Ordering platform team | CS-01 | Two engineers left in 2026 (P03, P05 TA-03) | Not a recovery time | Yes | Managed IT service provider's engineers, with the plan's runbook | Yes | [[the manager accountable for each critical service]] | 25 Sep 2026 | 1 | 24 | 24 | Alternative in place | 25 Sep 2027 | In date | |||||||||
| EXAMPLE | DP-07 | System | Warehouse management system | CS-02 | P07 SYS-02 | In-house | 5 | Tested | Tested 27 Aug 2026: restored in 5 hours (P03) | Yes | Printed pick lists (the workaround) | Yes | [[e.g. Head of IT]] | 25 Sep 2026 | 1 | 8 | 4 | OK | Alternative in place | 25 Sep 2027 | In date | |||||
| EXAMPLE | DP-08 | Supplier | Warehouse management system provider | CS-02 | P06 SUP-010 | Not in the contract; assessment planned 20 Oct 2026 (P06) | Yes | Not known | Yes | None | No | [[e.g. Procurement Manager]] | 25 Sep 2026 | 1 | 8 | 4 | Not known: see MX-04 | Recovery time not known (MX-04) | No alternative (RR-09) | 25 Sep 2027 | In date | |||||
| EXAMPLE | DP-09 | Supplier | ERP software provider (hosted) | CS-02, CS-04 | P07 SYS-01; P06 SUP-004 | 8 | Contract | Contract: restored within 8 hours, at most 15 minutes of data lost (P06 CON-03) | Yes | 8 | Yes | None | No | [[e.g. Procurement Manager]] | 25 Sep 2026 | 2 | 8 | 1 | OK | OK | No alternative (RR-09) | 25 Sep 2027 | In date | |||
| EXAMPLE | DP-10 | Data | Stock and dispatch records | CS-02 | Warehouse management system database | Daily backup | 24 | No | A count of the affected aisles | Yes | [[the manager accountable for each critical service]] | 25 Sep 2026 | 1 | 8 | 4 | Backed up less often than the RPO (MX-03) | Not a single point | 25 Sep 2027 | In date | |||||||
| EXAMPLE | DP-11 | Supplier | Network connectivity provider | CS-01, CS-02 | P06 SUP-014 | 12 | Contract | Contract: a failed line restored within 12 hours | Yes | 12 | Yes | None: a second line from another provider is not in place | No | [[e.g. Procurement Manager]] | 25 Sep 2026 | 2 | 8 | 4 | Later than the RTO (MX-02) | Longer than the RTO (MX-04) | No alternative (RR-09) | 25 Sep 2027 | In date | |||
| EXAMPLE | DP-12 | Supplier | National parcel carrier, express courier, pallet network | CS-02 | P06 SUP-007, SUP-008, SUP-009 | Three carriers: each can take another's work | No | No | The other two carriers | Yes | [[e.g. Procurement Manager]] | 25 Sep 2026 | 1 | 8 | 4 | No recovery time needed | Not a single point | 25 Sep 2027 | In date | |||||||
| EXAMPLE | DP-13 | Site | Warehouses 1 to 3 | CS-02 | P09 sites | Not a recovery time | No | The other two warehouses take a site's dispatch at [[reduced volume]] | Yes | [[the manager accountable for each critical service]] | 25 Sep 2026 | 1 | 8 | 4 | Not a single point | 25 Sep 2027 | In date | |||||||||
| EXAMPLE | DP-14 | Supplier | Payment service provider | CS-03 | P06 SUP-003 | The contract sets availability, not a recovery time | Yes | Not known | Yes | Invoicing on account (the workaround) | Yes | [[e.g. Procurement Manager]] | 25 Sep 2026 | 1 | 24 | 0 | Not known: see MX-04 | Recovery time not known (MX-04) | Alternative in place | 25 Sep 2027 | In date | |||||
| EXAMPLE | DP-15 | Data | Ledgers and payroll records | CS-04 | ERP | The provider's contract: at most 15 minutes lost (P06 CON-03) | 0.25 | No | Source documents | Yes | [[the manager accountable for each critical service]] | 25 Sep 2026 | 1 | 48 | 1 | OK | Not a single point | 25 Sep 2027 | In date | |||||||
| EXAMPLE | DP-16 | Supplier | Payroll bureau | CS-04 | P06 SUP-012 | Not in the contract; assessment planned 17 Nov 2026 (P06) | Yes | Not known | Yes | Repeat last month's payroll (the workaround) | Yes | [[e.g. Procurement Manager]] | 25 Sep 2026 | 1 | 48 | 1 | Not known: see MX-04 | Recovery time not known (MX-04) | Alternative in place | 25 Sep 2027 | In date | |||||
| EXAMPLE | DP-17 | Supplier | Email and office software provider | CS-05 | P06 SUP-005 | The contract sets availability, not a recovery time | Yes | Not known | Yes | Telephone and paper logs | Yes | [[e.g. Procurement Manager]] | 25 Sep 2026 | 1 | 24 | 24 | Not known: see MX-04 | Recovery time not known (MX-04) | Alternative in place | 25 Sep 2027 | In date | |||||
| EXAMPLE | DP-18 | Supplier | Outsourced customer contact centre | CS-05 | P06 SUP-013 | Not in the contract; assessment planned 1 Dec 2026 (P06) | Yes | Not known | No | Customer contact team answers directly | Yes | [[e.g. Procurement Manager]] | 25 Sep 2026 | 1 | 24 | 24 | Not known: see MX-04 | Recovery time not known (MX-04) | Not a single point | 25 Sep 2027 | In date |
Service grid
Which critical services each dependency supports
Calculated from the Register sheet's "Critical services it supports" column. A dot means the dependency supports that service. Do not type here: change the Register sheet.
| RTO (hours) | 24 | 8 | 24 | 48 | 24 | ||||||||||||
| RPO (hours) | 24 | 4 | 0 | 1 | 24 | ||||||||||||
| Dependency ID | Kind | Dependency | Services (as typed) | CS-01 | CS-02 | CS-03 | CS-04 | CS-05 | Services it supports | Shared: order on the Concentration sheet | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DP-01 | Foundations | Foundations: sign-in directory, network, backup platform, endpoint protection | CS-01, CS-02, CS-04, CS-05 | ● | ● | ● | ● | 4 | 1 | ||||||||
| DP-02 | System | Online ordering platform | CS-01 | ● | 1 | ||||||||||||
| DP-03 | Supplier | Cloud hosting provider | CS-01, CS-04 | ● | ● | 2 | 2 | ||||||||||
| DP-04 | Supplier | Backup service provider | CS-01, CS-04 | ● | ● | 2 | 3 | ||||||||||
| DP-05 | Data | Orders and customer accounts | CS-01 | ● | 1 | ||||||||||||
| DP-06 | People | Ordering platform team | CS-01 | ● | 1 | ||||||||||||
| DP-07 | System | Warehouse management system | CS-02 | ● | 1 | ||||||||||||
| DP-08 | Supplier | Warehouse management system provider | CS-02 | ● | 1 | ||||||||||||
| DP-09 | Supplier | ERP software provider (hosted) | CS-02, CS-04 | ● | ● | 2 | 4 | ||||||||||
| DP-10 | Data | Stock and dispatch records | CS-02 | ● | 1 | ||||||||||||
| DP-11 | Supplier | Network connectivity provider | CS-01, CS-02 | ● | ● | 2 | 5 | ||||||||||
| DP-12 | Supplier | National parcel carrier, express courier, pallet network | CS-02 | ● | 1 | ||||||||||||
| DP-13 | Site | Warehouses 1 to 3 | CS-02 | ● | 1 | ||||||||||||
| DP-14 | Supplier | Payment service provider | CS-03 | ● | 1 | ||||||||||||
| DP-15 | Data | Ledgers and payroll records | CS-04 | ● | 1 | ||||||||||||
| DP-16 | Supplier | Payroll bureau | CS-04 | ● | 1 | ||||||||||||
| DP-17 | Supplier | Email and office software provider | CS-05 | ● | 1 | ||||||||||||
| DP-18 | Supplier | Outsourced customer contact centre | CS-05 | ● | 1 |
Services it supports counts the dots. Two or more makes the dependency shared: it is listed on the Concentration sheet in this order.
Services
Critical services: objectives, checks and cyber recovery time
Enter each critical service and its objectives (yellow), as the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) records them. The white columns count its dependencies, apply the checks MX-02 to MX-05 to them, and work out its cyber recovery time. Counts only: no score and no percentage (RR-20).
Settings
| As-at date | 30 Sep 2026 | Review status is worked out at this date. EXAMPLE: the quarter end. Type a date, never a formula. | |
| Months between reviews of each entry (RR-09) | 12 | Review sooner when a dependency changes, and after every recovery test and real recovery. | |
Critical services
| Service ID | Critical service | Business owner | MTD (hours) | RTO (hours) | RPO (hours) | Dependencies | MX-02 Dependencies recover in time | MX-03 Backups as often as the recovery point | MX-04 Supplier recovery times known and in time | Single points with no alternative | Depends on the foundations | Slowest system or supplier, no attack (hours) | Cyber recovery time (hours, MX-05) | MX-05 Cyber recovery within the objective | Checks failed, MX-02 to MX-05 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CS-01 | Online ordering | Chief Operating Officer | 48 | 24 | 24 | 7 | Fail: 1 dependency later than the RTO | Pass | Fail: 1 not known, 0 longer than the RTO | 5 | Yes | 96 | 108 | Beyond the MTD: cannot recover in time | 3 |
| CS-02 | Warehouse dispatch | Head of Logistics | 24 | 8 | 4 | 8 | Fail: 1 dependency later than the RTO | Fail: 1 data set backed up less often than the RPO | Fail: 1 not known, 1 longer than the RTO | 4 | Yes | 12 | 17 | Beyond the RTO: needs its workaround | 4 |
| CS-03 | Payments | Chief Financial Officer | 72 | 24 | 0 | 1 | Pass | Pass | Fail: 1 not known, 0 longer than the RTO | 0 | No | None recorded | 0 | Within the RTO | 1 |
| CS-04 | Finance and payroll | Chief Financial Officer | 120 | 48 | 1 | 6 | Pass | Pass | Fail: 2 not known, 0 longer than the RTO | 4 | Yes | 24 | 12 | Within the RTO | 1 |
| CS-05 | Customer contact | Sales Director | 48 | 24 | 24 | 3 | Pass | Pass | Fail: 2 not known, 0 longer than the RTO | 1 | Yes | None recorded | 12 | Within the RTO | 1 |
Each "Fail" and each service beyond its RTO is an objective gap: record it in the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) with an owner, the change that closes it and a due date (RR-15). The two times differ on purpose: the slowest system or supplier is the recovery from a failure; the cyber recovery time adds the foundations' rebuild first (RR-07).
The 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.
| Rebuild time (hours) | 12 | From the Register sheet's Foundations row. Every service linked to it waits this long before its own systems can be restored after an attack. | |||||||
| Basis | Estimate (P09 Ransomware Response Playbook's example target); never tested as a whole | ||||||||
| Part | Rebuilt or restored by | |||||
|---|---|---|---|---|---|---|
| Sign-in directory | Managed IT service provider (P06 SUP-001) | |||||
| Core network and firewalls | Managed IT service provider (P06 SUP-001) | |||||
| Backup platform | Backup service provider (P06 SUP-011) | |||||
| Endpoint protection and monitoring | Security monitoring provider (P06 SUP-006) | |||||
| Emergency administrator accounts (P14 PA-12) | Head of IT | |||||
EXAMPLE: the foundations as the P09 Ransomware Response Playbook lists them, with its example target. Rebuilt in the order the Cyber Recovery Operating Procedure sets, and checked against the Clean-Room Recovery & Rebuild Checklist.
The checks this sheet applies
| Check | Name | Test | Rule | |||||
|---|---|---|---|---|---|---|---|---|
| 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-01, MX-06 and MX-07 need the objectives, the tests and the agreement dates, not the dependencies: the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) applies them.
Concentration
Dependencies two or more critical services share
The supplier pack measures concentration as P06 TPM-04, "Providers that two or more critical services depend on", reported to executive management every quarter (P06 TP-12), each with an exit plan (P06 TP-11). This sheet applies the same test to every dependency, not only suppliers: a system, a data set, a team or the foundations that several services share stops them all at once.
| Order | Dependency ID | Kind | Dependency | Critical services | Number of services | Single point of failure | Alternative | Reference |
|---|---|---|---|---|---|---|---|---|
| 1 | DP-01 | Foundations | Foundations: sign-in directory, network, backup platform, endpoint protection | CS-01, CS-02, CS-04, CS-05 | 4 | No alternative (RR-09) | None: every in-house system needs them first | P09 Ransomware Response Playbook |
| 2 | DP-03 | Supplier | Cloud hosting provider | CS-01, CS-04 | 2 | No alternative (RR-09) | None within the RTO | P06 SUP-002 |
| 3 | DP-04 | Supplier | Backup service provider | CS-01, CS-04 | 2 | No alternative (RR-09) | None | P06 SUP-011 |
| 4 | DP-09 | Supplier | ERP software provider (hosted) | CS-02, CS-04 | 2 | No alternative (RR-09) | None | P07 SYS-01; P06 SUP-004 |
| 5 | DP-11 | Supplier | Network connectivity provider | CS-01, CS-02 | 2 | No alternative (RR-09) | None: a second line from another provider is not in place | P06 SUP-014 |
6
7
8
9
10
11
12
What to do with each one
What to do
| 1 | Plan its recovery early. Every service it supports waits for it, so the crisis lead weighs it when setting the recovery order after the foundations (RR-08). | |||||||
| 2 | Give it an alternative, or record that it has none (RR-09). A shared single point of failure with no alternative is the first one for its business owners to close or accept, with an owner and a date. | |||||||
| 3 | For a supplier, check its exit plan (P06 TP-11: "Every Tier 1 and Tier 2 contract must have an exit plan: data return or deletion, access removal, and a transition period.") and that its contracted recovery time is within the shortest RTO of the services it supports (RR-10). | |||||||
| 4 | Test it once for all. A recovery test of a shared dependency counts for each service it supports only where the test measured that service's recovery (RR-14). | |||||||
| 5 | Report it. Name each shared single point of failure with no alternative in the quarterly readiness report by name (RR-20), and give the supplier ones to P06's concentration measure, TPM-04. | |||||||
EXAMPLE: 5 of the 18 dependencies are shared, 5 of them single points of failure with no alternative.
Finding dependencies
Finding the dependencies
A dependency nobody wrote down is found during the recovery, when it is too late to plan for it. Build the register with each business owner and IT together, in the workshop that agrees the service's objectives, and check it against every recovery test and real outage. 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).
The kinds of dependency, and the columns each fills
| Kind | What it is | What to record |
|---|---|---|
| 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. One row, linked to every service whose systems you restore yourself. | Recovery time and its basis. It adds to the cyber recovery time of every service it supports (MX-05). |
| System | An application or platform the service runs on, such as the ordering platform or the warehouse management system. | Recovery time and its basis, and who restores it after an attack. A system you restore yourself counts towards the cyber recovery time (MX-05). |
| Supplier | A third party whose service the critical service needs: a hosting provider, a software provider, a network carrier, a payment provider. | Whether it runs a system the service needs (then it needs a recovery time in its contract, RR-10), the contracted recovery time, or "Not known". |
| Data | A data set the service cannot run without, such as orders and customer accounts, or stock records. | How often it is backed up, in hours (MX-03). |
| People | A team or person whose knowledge the service needs to run or to recover, such as the only two engineers who know the ordering platform. | No recovery time. Mark a single point of failure and name the alternative. |
| Site | A building the service runs from: a warehouse, an office, a data room. | No recovery time. Mark a single point of failure and name the alternative. |
1. Ask each business owner
| Question | What it finds | |
|---|---|---|
| 1 | What does the service deliver, to whom, and what is the first thing a customer notices when it stops? | Fixes the start and the end of the service, so the walk-through below covers all of it. |
| 2 | Which systems do your staff open in a normal day to deliver it? Which ones would stop them if they were down for an hour? | The systems the service runs on. Ask for the screens, not the system names IT uses. |
| 3 | Which data do you look up or change, and how much of it could you key in again by hand? | The data sets and, with the recovery point, how often each must be backed up (MX-03). |
| 4 | Which outside companies do you rely on: hosting, software, carriers, payment, a bureau? Who would you ring if one stopped? | The suppliers. Check each against the supplier register; the business owner often knows a supplier procurement does not. |
| 5 | Who are the people without whom the service, or its recovery, stalls? What happens if they are on leave or have left? | People dependencies and single points of knowledge. |
| 6 | Where is the work done? Could another site take it, and at what volume? | Site dependencies and their alternatives. |
| 7 | What do you do today when the system is down? Has anyone tried it for a full shift? | The workaround (RR-06), and whether it is tried or untried. |
| 8 | What has changed in the last year: a new supplier, a new system, a team that left? | Changes the last review missed (RR-09 asks for a review when a dependency changes). |
2. Walk the service end to end
| Step | What to do | |
|---|---|---|
| 1 | Pick one real transaction, such as one customer order, and follow it from the moment it starts to the moment it is finished: taken, checked, paid, picked, dispatched, invoiced. | |
| 2 | At each step, write down the screen or system used, the data read or written, the people involved, the site, and any outside company that touches it. | |
| 3 | For each system, ask IT what it needs to run: the hosting or servers, the network line, the sign-in directory, the backup platform, the interfaces to other systems. Those are dependencies of the service too, even if the business owner never sees them. | |
| 4 | Mark every system that cannot be restored until the sign-in directory, the network and the backup platform are trusted again. Link those services to the Foundations row: after a destructive attack, they wait for the foundations first (RR-07, RR-08). | |
| 5 | For each system, record who restores it after an attack: your own team, or the supplier that runs it. Only the systems you restore yourself add to the cyber recovery time after the foundations (MX-05). | |
| 6 | Record each dependency's recovery time with its basis: Tested when a recovery test measured it, Contract when a supplier's contract states it, Estimate otherwise. An estimate stays marked Estimate until a recovery test measures it (RR-14), and the checks use it meanwhile: plan a test to replace it. | |
| 7 | Ask, for each dependency, "if this one stopped, would the service stop?" If yes and nothing else can take its place, it is a single point of failure. Name the alternative, or write None. | |
| 8 | Walk the workaround too. A workaround that needs a system, a printer or a phone line has dependencies of its own. | |
| 9 | Check the register against the service's last recovery test or real outage: anything that slowed the recovery and is not in the register is a missing dependency. | |
3. Ask suppliers about their own suppliers
| Question for the supplier | Why it matters | |
|---|---|---|
| 1 | Which of your own suppliers would stop your service to us if they failed: hosting, data centres, software, support contractors? | Your supplier's single points of failure are yours too. Two of your suppliers may share one data centre or one cloud platform. |
| 2 | What recovery time do you commit to, in the contract, for the service we buy? Has it been tested, and can we see the result? | The contracted recovery time the register records (RR-10, MX-04). A tested time is better evidence than a contract alone. |
| 3 | If you were hit by ransomware, which of our systems or data would you restore, from what, and in what order among your customers? | Whether the supplier restores the system after an attack, and whether you would wait behind other customers. |
| 4 | Whom do we call, and how much notice will you give us of an outage or an incident? | The contact and notice the service's plan holds (P06 TP-10). |
| 5 | Where are our backups held, and can they be changed or deleted with the same administrator credentials as the live service? | Whether a copy survives an attack on the supplier (RR-11). |
| Record a supplier's own supplier as a dependency only where it could stop a critical service and you can act on it; otherwise note it in the supplier's row. Raise the questions through the supplier liaison at the supplier's next assessment (P06 TP-09). | ||
Lists
| Kind | RestoredBy | Basis | YesNo |
|---|---|---|---|
| Foundations | In-house | Tested | Yes |
| System | Supplier | Contract | No |
| Supplier | Estimate |
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). |
| 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. |
| 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). |
| 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). |
| Recovery time | How long the dependency takes to come back, in hours, from the moment its recovery starts. |
| Basis | Where the recovery time comes from. Tested: a recovery test measured it. Contract: a supplier's contract states it. Estimate: neither. It stays marked Estimate until a recovery test measures it (RR-14), and the checks use it meanwhile. |
| Who restores it after an attack | In-house: your own team or a provider working on your systems restores it, so it waits for the foundations and adds to the cyber recovery time. Supplier: the supplier restores it on its own platform. |
| Backup interval | The longest time between two backups of a data set, in hours. Use 0.25 for 15 minutes. It must be no longer than the RPO of every service that needs the data (MX-03). |
| Contracted recovery time | The recovery time a supplier's contract commits to for the service you buy, in hours. "Not known" where the contract gives none (MX-04, RR-10). |
| Single point of failure | A dependency whose loss stops the service, with nothing else able to take its place. |
| Alternative | What takes a single point's place: a second supplier, another site, a trained deputy, or the workaround. "In place" means it would work today. |
| Shared dependency | A dependency two or more critical services rely on (the Concentration sheet; P06 TPM-04 for suppliers). |
| Shortest RTO among them | The shortest RTO of the services a dependency supports: the time the dependency has to meet. |
| As-at date | The date review status is worked out at. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| DP-nn, CS-nn, MX-nn, RR-nn | Dependencies, critical services, the checks of the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) and the rules of the Business Continuity & ICT Resilience Policy. P06 SUP-nnn and P07 SYS-nn are entries in the supplier register and the asset inventory. |
| EXAMPLE | A worked example: the distributor's register as at 30 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 | Annex A 5.30 — ICT readiness for business continuity | Services sheet: each critical service's dependencies checked against its recovery objectives, and its recovery time after an attack |
| ISO/IEC 27001:2022 | Annex A 8.14 — Redundancy of information processing facilities | Register and Concentration sheets: single points of failure, their alternatives, and the dependencies several services share |
| NIST CSF 2.0 | ID.AM-05 — “Assets are prioritized based on classification, criticality, resources, and impact on the mission” | Service grid and Concentration sheets: the systems, suppliers, data, people and sites each critical service depends on, and which are shared |
| NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | Register and Services sheets: what each critical service needs to be recovered, how long each part takes and whether the backups are frequent enough, as input to business continuity and disaster recovery |
| 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 only to the providers its Article 1 names. For them, the Annex point below; others may use it as good practice |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.4 — based on the risk assessment (point 2.1) and the business continuity plan, “sufficient availability of resources by at least partial redundancy” of network and information systems; assets, including facilities, equipment and supplies; personnel with the necessary responsibility, authority and competence; and appropriate communication channels | Register and Concentration sheets: single points of failure and their alternatives across systems, suppliers, people and sites, which show where redundancy is missing. For the providers Article 1 names (NIS2 IR 1) |
| 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” | Register, Service grid and Concentration sheets, for financial entities: third-party dependencies, information assets and their interdependencies for each service, which the business impact analysis considers. The analysis itself is in the Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) |
| DORA — Regulation (EU) 2022/2554 | Article 16(1)(e) — the entities under the simplified ICT risk management framework “identify key dependencies on ICT third-party service providers” | Register sheet, for financial entities under the simplified framework: each ICT third-party service provider a critical service depends on, with its contracted recovery time |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 26(4) — “financial entities shall consider and implement continuity measures to mitigate failures of ICT third-party service providers of ICT services supporting critical or important functions of the financial entity” | Register sheet, for financial entities: suppliers' contracted recovery times beside each service's RTO (MX-04), and their alternatives, which show where continuity measures for a supplier's failure are needed |
| GDPR — Regulation (EU) 2016/679 | Article 32(1)(b) — the security measures include, as appropriate, “the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services” | Services sheet: the recovery time of the systems and services that process personal data, worked out from their dependencies |
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.