How do we agree recovery time and data-loss targets with the business?

Start

A critical service needs agreed recovery targets

Three numbers describe how long a service can be without its systems. The maximum tolerable downtime (MTD) is the longest it can be down before the harm is Severe. The recovery time objective (RTO) is when it must be back, counted from the decision to recover it. The recovery point objective (RPO) is the most data, measured in time, it can lose. Only the business can say what it needs; IT can say what that costs.

• Then: Does the service have a named business owner?

Decision

Does the service have a named business owner?

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. If you are unsure who it is, take the cautious branch.

• Yes: Rate the harm at 4, 8, 24, 48, 72, 120 and 168 hours
• No, or not known: Name the manager whose team stops working when it stops

Step

Name the manager whose team stops working when it stops

The business owner is usually the manager whose team stops working when the service stops. IT proposes; it does not set the objectives alone. Have someone who runs no system in scope, such as a risk manager, coordinate the workshops: they will be checking objectives that IT proposes.

• Then: Rate the harm at 4, 8, 24, 48, 72, 120 and 168 hours

Step

Rate the harm at 4, 8, 24, 48, 72, 120 and 168 hours

This is the business impact analysis. With the business owner, rate how bad an outage would be at each time point on your risk register's impact areas, such as financial, service, data, legal and reputation, and record the worst level at each point. The time points are the pack's defaults; keep one at each day of the first week. Using the risk register's scale means a service's harm is judged the same way in risk management and in recovery. Write down what drives the harm.

• Then: Does any area reach Severe within 168 hours?

Decision

Does any area reach Severe within 168 hours?

A critical service is one whose disruption beyond its maximum tolerable downtime would cause Severe harm on the risk register's impact scale. If the harm never reaches Severe in the first week, the method gives the service no maximum. If the owner cannot say, keep the service on the list and take the cautious branch.

• Yes, or not known: Set the MTD at the first point the harm reaches Severe
• No: Raise it at the next review of the critical services list

Outcome

Raise it at the next review of the critical services list

On this method the service does not meet the test of a critical service. The list of critical services is approved with the policy and reviewed with the objectives, so propose the change there rather than inventing objectives for it. Check first that the harm was rated on the worst area at each point.

Step

Set the MTD at the first point the harm reaches Severe

The MTD is the first time point at which any area reaches Severe. Every other objective is set below it. If the owner hesitates between two points, taking the earlier one is the safer judgement. In the pack's example, online ordering reaches Severe on the service area at 48 hours, which matches the risk register's scenario of ordering being offline for more than 2 days.

• Then: IT proposes achievable times and what a faster one costs

Step

IT proposes achievable times and what a faster one costs

Only the business knows how long it can manage without a service; IT knows what a faster recovery costs. Bring the last recovery test's time, the backup intervals and the supplier contracts to the workshop, so the owner sees what is achievable today and what it would take to do better.

• Then: The owner agrees an RTO, an RPO and why that loss is bearable

Step

The owner agrees an RTO, an RPO and why that loss is bearable

The business owner agrees the RTO and the RPO, and records how the data lost would be found again, such as orders keyed again from customers' confirmations. Record the date they were agreed. An RTO equal to the maximum leaves no margin for anything to go wrong.

• Then: Is the RTO shorter than the MTD?

Decision

Is the RTO shorter than the MTD?

This is the matrix's first check, MX-01. A recovery time equal to or longer than the maximum means the service would already be causing Severe harm when it came back. Agree a shorter one.

• Yes: Check the targets against dependencies, backups and attack
• No: The owner agrees an RTO, an RPO and why that loss is bearable (back to an earlier step)

Step

Check the targets against dependencies, backups and attack

A service comes back no faster than its slowest dependency, and loses at least the data since its least frequent backup. Check that every system and supplier recovers within the RTO (MX-02), every data set is backed up at least as often as the RPO (MX-03), every supplier has a contracted time within the RTO (MX-04), and the cyber recovery time is within the RTO (MX-05).

• Then: Do the dependency, backup, supplier and attack checks pass?

Decision

Do the dependency, backup, supplier and attack checks pass?

The cyber recovery time is the foundations' rebuild, such as the sign-in directory and the network, plus the slowest system you restore yourself. A service can pass its recovery test and still fail it: the test restored onto trusted systems, while after an attack nothing is trusted until the foundations are rebuilt. A supplier time the contract does not give fails the check. An estimate counts in the check until a recovery test measures it; plan that test (RR-14).

• Yes: Has a test in the last 12 months met the RTO?
• No, or not known: Record each failed check as a gap with an owner and due date

Decision

Has a test in the last 12 months met the RTO?

An untested recovery time is an estimate. A recovery test recovers the service or its systems, restores its data, and measures the time and the data lost against the objectives (MX-06). A tabletop exercise is not a recovery test.

• Yes: Send the objectives for approval; review them every 12 months
• Not tested, or not known: Plan a recovery test, within 6 months if never tested
• Tested, and it missed the RTO: Record each failed check as a gap with an owner and due date

Step

Plan a recovery test, within 6 months if never tested

Under the pack's defaults, a service never tested is tested within 6 months of its objectives being agreed, and every critical service at least every 12 months. Until then its status is Not proven: the objectives may be right, but nobody has shown they can be met. The missing test is a failed check, so record it as a gap whose change is the test, as the pack's example does for payments.

• Then: Send the objectives for approval; review them every 12 months

Step

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

Every failed check, and every objective a test missed, is an objective gap. Its owner agrees the change that closes it within 10 working days, the pack's default, with a due date. Tell the service's risk owner, who reassesses the risk. Do not lower the objective to fit what IT can do: a gap closes when its checks pass, or when the business owner re-agrees the objective on a new impact analysis.

• Then: Could the service be back later than its RTO?

Decision

Could the service be back later than its RTO?

Look at the last test's time, the dependency and supplier times and the cyber recovery time. If any is longer than the RTO, or not known, the service needs a workaround. A gap in backup frequency alone loses data but does not delay the return.

• Yes, or not known: The owner records a workaround that keeps harm below Severe
• No: Will the business pay for the change that closes the gap?

Step

The owner records a workaround that keeps harm below Severe

A workaround runs the service, or its most important part, without its systems for a set time, such as dispatch from printed pick lists. The business owner records it, who starts it and how long it can run before harm reaches Severe. Beyond the MTD the status is Not achievable, and the workaround must hold for longer. One never tried is recorded as untried. The gap stays open until its change is done.

• Then: Will the business pay for the change that closes the gap?

Decision

Will the business pay for the change that closes the gap?

IT prices the options, such as a faster platform, more frequent backups or a shorter contracted supplier time. The business owner weighs the cost against the harm the impact analysis showed. If nobody will commit to the cost, take the cautious branch: the gap is a risk decision, not an IT task.

• Yes: Agree the change, its owner, cost and due date
• No, or not known: Take it to the risk owner to treat or accept at the right level

Step

Agree the change, its owner, cost and due date

Record the change in your objectives matrix, and the treatment action in your risk register with an owner, a due date, a cost and the residual score expected. In the pack's example, online ordering's gap closes by rebuilding the platform's recovery and then testing it against its 24 hours.

• Then: Send the objectives for approval; review them every 12 months

Outcome

Take it to the risk owner to treat or accept at the right level

The risk owner reassesses the risk and decides how to treat it. Accepting it is recorded and approved at the level the residual rating sets. Outside tolerance, only the board or its equivalent may accept: the board, or a board risk committee it has delegated to; the management board in a two-tier structure; executive management where there is no board. An objective gap is not an exception, so it needs no waiver.

Outcome

Send the objectives for approval; review them every 12 months

The approver approves the critical services and their objectives with the policy: the board, or a board risk committee it has delegated to; the management board in a two-tier structure; executive management where there is no board. The business owner reviews the analysis and objectives at least every 12 months, the pack's default, and after a significant incident, a missed test, or a change to the service, its suppliers or its risks.