How do we find the dependencies that decide whether a service can meet its recovery time?

Start

Check what a service needs to come back within its RTO

A service comes back no faster than its slowest dependency. Most missed recovery times come from something the plan did not list: a supplier, a data feed, one engineer. A dependency nobody wrote down is found during the recovery, when it is too late to plan for it.

• Then: Start from the service's agreed MTD, RTO and RPO

Step

Start from the service's agreed MTD, RTO and RPO

Copy the maximum tolerable downtime, recovery time objective and recovery point objective exactly as the business owner agreed them. The dependency register measures against them; it does not set them. If they are not agreed yet, agree them first.

• Then: Ask the business owner what the service's people rely on

Step

Ask the business owner what the service's people rely on

Hold it in the workshop that agrees the objectives, with IT in the room. Ask which systems staff open in a normal day, which data they could key in again by hand, which outside companies they would ring if one stopped, who the service stalls without, where the work is done, what they do today when the system is down, and what changed in the last year.

• Then: Walk one real transaction from start to finish

Step

Walk one real transaction from start to finish

Follow one real transaction, such as a customer order, from taken to invoiced. At each step write down the system, the data, the people, the site and any outside company. Ask IT what each system needs to run: hosting, the network line, the sign-in directory, the backup platform, interfaces. Walk the workaround too. Then check the list against the last recovery test or outage: anything that slowed it and is missing is a dependency.

• Then: Record each one by kind, once, with every service it supports

Step

Record each one by kind, once, with every service it supports

The kinds are systems, suppliers, data sets, people, sites and the foundations. A dependency two services share is one row, linked to both. Point each row to its entry in the supplier register or the asset inventory, and name who keeps it current.

• Then: Does a system you restore need the directory, network or backups?

Decision

Does a system you restore need the directory, network or backups?

The foundations are 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. After a destructive attack, a system you restore yourself cannot come back until they are trusted again. If you are unsure, take the cautious branch.

• Yes, or not known: Link the service to the foundations and their rebuild time
• No: Give each a recovery time from a test, a contract or an estimate

Step

Link the service to the foundations and their rebuild time

Keep one foundations row, linked to every service whose systems you restore yourself, with its rebuild time. In the pack's example it is a 12-hour estimate that has never been tested as a whole: replace an estimate with the time your first cyber recovery test measures.

• Then: Give each a recovery time from a test, a contract or an estimate

Step

Give each a recovery time from a test, a contract or an estimate

Record each system's recovery time, its basis and who restores it after an attack: your team or the supplier that runs it. Record each data set's backup interval. People and sites have no recovery time: record their alternative. An estimate stays marked as one until a recovery test measures it, and a tested time is better evidence than a contract alone.

• Then: Ask each supplier its contracted time and its own suppliers

Step

Ask each supplier its contracted time and its own suppliers

A supplier that runs a system the service needs must have a recovery time in its contract. Write Not known where it has none. Ask what it would restore after ransomware and in what order among its customers, where your backups are held, and which of its own suppliers could stop your service. Two of your suppliers may share one data centre or cloud platform.

• Then: Compare each time with the RTO and each backup with the RPO

Step

Compare each time with the RTO and each backup with the RPO

Every system and supplier must recover within the shortest RTO of the services it supports (MX-02). Every data set must be backed up at least as often as the shortest RPO (MX-03). Every supplier that runs a system the service needs must have a contracted time no longer than the RTO (MX-04). Each one that fails is flagged against the objective it misses.

• Then: Add the foundations' rebuild to the slowest system you restore

Step

Add the foundations' rebuild to the slowest system you restore

That sum is the cyber recovery time. Suppliers recover in parallel and are checked against their contracts. Failover to a second site does not count: replication copies the damage. In the pack's example, dispatch passes its test in 5 hours but needs 17 after an attack: 12 for the foundations and 5 for its warehouse system.

• Then: Is the cyber recovery time within the RTO?

Decision

Is the cyber recovery time within the RTO?

Within the RTO, the service can recover in time even after a destructive attack. Beyond the RTO but within the MTD, it needs its workaround. Beyond the MTD, it cannot recover in time. If a time in the sum is missing, take the cautious branch. An estimate counts, and stays marked as one until a recovery test measures it.

• Yes: Would the service stop without it, with nothing to replace it?
• Beyond the RTO, within the MTD: Tell the business owner the service needs its workaround
• Beyond the MTD, or not known: Tell the owner it cannot recover in time after an attack

Step

Tell the business owner the service needs its workaround

Beyond the RTO, the business owner records a workaround that keeps the harm below Severe until the service returns, and who starts it. A workaround has dependencies of its own: one that needs a system the attack also takes down is no workaround.

• Then: Would the service stop without it, with nothing to replace it?

Step

Tell the owner it cannot recover in time after an attack

A service whose cyber recovery time is beyond its MTD is Not achievable. Tell its business owner; the failed check is an objective gap, so the service's risk owner is told too. It still needs its workaround, which must hold for longer. In the pack's example, online ordering would take 108 hours after an attack against a maximum of 48.

• Then: Tell the business owner the service needs its workaround

Decision

Would the service stop without it, with nothing to replace it?

Ask it of every dependency. If the service would stop and nothing else could take its place, it is a single point of failure. The alternative may be a second supplier, another site, a trained deputy or the workaround; it counts only if it would work today.

• Yes, or not known: Mark it, with its alternative or None
• No: Do two or more critical services share it?

Step

Mark it, with its alternative or None

Record the single point of failure with its alternative and whether that alternative is in place, or write None. A single point of failure with no alternative is a risk the business owner should know about before the outage, and for them to close or accept.

• Then: Do two or more critical services share it?

Decision

Do two or more critical services share it?

A dependency several services share stops them all at once. Apply the test to every kind, not only suppliers: a system, a data set, a team or the foundations can be shared too. Look for hidden sharing, such as several suppliers on one cloud platform.

• Yes, or not known: Plan its recovery early, and check its alternative or exit
• No: Did any dependency fail a check?

Step

Plan its recovery early, and check its alternative or exit

Every service it supports waits for it, so the crisis lead weighs it when setting the recovery order after the foundations. Give it an alternative or record that it has none. For a supplier, check its exit plan and that its contracted time is within the shortest RTO it serves. If it has no alternative, name it in the quarterly readiness report.

• Then: Did any dependency fail a check?

Decision

Did any dependency fail a check?

Look at the flags for recovery time, backups, supplier times and the cyber recovery time. A Not known supplier time counts as a failure.

• Yes, or not known: Record each failed check as a gap with an owner and due date
• No: Copy the rows into the plan; review at least every 12 months

Outcome

Record each failed check as a gap with an owner and due date

Each failed check is an objective gap in your objectives matrix. Its owner agrees the change that closes it within 10 working days, the pack's default, with a due date, and the service's risk owner is told. Then copy the dependencies into the service's recovery plan and review the register at least every 12 months.

Outcome

Copy the rows into the plan; review at least every 12 months

Copy the service's dependencies into its recovery plan, with their recovery times, single points of failure and alternatives. Review the register at least every 12 months, the pack's default, after every recovery test and real recovery, and whenever a system, supplier, team or site changes.