Can this service recover in time?

How this was calculated, and what it is not

The check runs the seven checks of the recovery objectives matrix on one service, with the matrix's own rules, and gives the status the matrix gives. A failed check is an objective gap.

The four statuses

Achievable

Tested within its RTO in the last 12 months, and its cyber recovery time is within the RTO.

Needs its workaround

Tested in the last 12 months, but its test or its cyber recovery time puts it back after its RTO and within its MTD, so its workaround carries the gap.

Not proven

Not tested in the last 12 months. The objectives may be right; nobody has shown they can be met.

Not achievable

Its test in the last 12 months or its cyber recovery time shows it would be back after its MTD.

Why the cyber recovery time differs

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.

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).

The rules the checks apply

• RR-02 Every critical service has a named business owner, who sets and agrees its objectives. IT proposes what is achievable; the business owner decides what is needed. Objectives set by IT alone are not agreed.
• RR-04 Each critical service has a recovery time objective shorter than its maximum tolerable downtime, and a recovery point objective. The service's dependencies must recover within its recovery time, and the backup interval of each data set it needs must be no longer than its recovery point.
• RR-05 Business owners review their service's analysis and objectives 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-06 Where a service cannot be back within its recovery time, its business owner records a workaround that keeps the harm below Severe until the service returns, and who starts it. A workaround that has never been tried is recorded as untried.
• RR-07 Plans assume a destructive cyberattack as well as a technical failure: production, its replicas and its administrator accounts may not be trusted. Each critical service's cyber recovery time is worked out and compared with its objectives (MX-05).
• RR-10 A supplier that runs a system a critical service needs has a recovery time in its contract no longer than that service's recovery time, and is named in the service's plan with a contact and the notice it must give (P06 TP-10). Where the contract gives no time, or a longer one, the gap is recorded (MX-04).
• RR-11 Each critical data set is backed up at least as often as its service's recovery point requires, and at least one copy cannot be changed or deleted with production administrator credentials. Copies are checked for integrity before they are restored (P09 IM-10). How often other restore checks run, and how they are judged, is set by the Backup & Restore Assurance pack (P23).
• RR-14 The recovery of every critical service is tested at least every 12 months, and after a significant change to it. A service never tested is tested within 6 months of its objectives first being agreed under this policy; agreeing them again does not move that date. A test recovers the service or its systems, restores its data, and records the time achieved and the data lost against the objectives. Where a supplier runs the systems, the test is the supplier's own recovery test, with its results shared and checked against the objectives. Only a timed recovery of the service proves its recovery time. An exercise under P10, a tabletop or a drill, is not a recovery test under this rule. It tests decisions and communication.
• RR-15 Every failed check in the objectives matrix, and every objective a test or a real recovery missed, is an objective gap. Its owner agrees the change that closes it within 10 working days, with a due date; the service's risk owner is told and the risk is reassessed (P05 RM-10).

What it leaves to the matrix

• Where the maximum tolerable downtime comes from. The matrix works it out from the business impact analysis: the first time point at which the harm reaches Severe. The check takes it as you give it.
• Every critical service, and the order they come back in. The check reads one service at a time. The matrix holds all of them, and the recovery order runs foundations first, then the shortest recovery time.
• The gaps themselves. The matrix records each failed check with the change that closes it, its owner and its due date, and when the next recovery test is due. A check that stores nothing cannot.
• Which system is which. Systems, suppliers and data sets are numbered here, not named. The matrix names each, from the dependency register.

What it is not

This document helps you plan and test business continuity and recovery from a disruption, including a destructive cyberattack. It is not legal advice, and following it is not a statement that you comply with NIS2, DORA, the GDPR, HIPAA, ISO 22301 or any other law, standard or set of criteria. Which continuity and recovery duties apply to you depends on your sector and the law that applies to you: confirm them with counsel, your auditor or your supervisor.