The recovery time is not the downtime

In the business impact analysis, the billing process says "four hours". IT reads that as the recovery time and plans the restore for four hours. But the business unit meant that the process becomes intolerable after four hours of standstill. Between the two readings lies exactly the time that will be missing in a real incident.

MTPD: how long the process may be down

BSI Standard 200-4 first defines, in chapter 7 on the business impact analysis, the maximum tolerable period of disruption. It sets how long a business process may be down at most before intolerable consequences arise for the organisation. In German:

„legt fest, wie lange ein Geschäftsprozess maximal ausfallen darf, bevor nicht tolerierbare Auswirkungen für die Institution auftreten.“

The MTPD is a property of the business process, not of the technology. It is derived from the damage potential, and the business unit has to set it with management, not IT.

RTO: how long recovery may take

The recovery time objective is derived from the MTPD. According to 200-4, it covers the period from declaring the emergency to the required start of the continuity solution, for IT for example switching to an alternative system or restoring to the last backed-up state. And then the decisive sentence: the RTO must be shorter than the MTPD of the relevant business process, because the reaction time is subtracted from the MTPD so that the MTPD can still be met with the RTO. In German:

„Die RTO muss zwingend kürzer sein als die MTPD des relevanten Geschäftsprozesses, denn die Reaktionszeit wird von der MTPD abgezogen, um mit der RTO die MTPD noch erreichen zu können.“

The time before: BAO reaction time

The reaction time being subtracted has its own name in 200-4: the BAO reaction time. It covers the period from detecting and alerting on the incident, through convening the crisis organisation and taking decisions, to declaring the emergency. These are the minutes or hours in which the outage is already running but nobody is officially in charge yet. The standard recommends an additional buffer because detection in particular is uncertain.

In the example above: if the process may be down for four hours and it usually takes an hour until the team declares the emergency, less than three hours remain for recovery, not four.

RPO: how old the data may be

The recovery point objective defines how old available data may be at most to work with it meaningfully in emergency operation. The required backup cycle follows from it. It has nothing to do with downtime: a process may be allowed to stand still for days and still not tolerate an hour of data loss.

Minimum business continuity objective: how much is enough

The minimum business continuity objective describes how capable emergency operation must be, for example as a percentage or as a list of the activities that must run again first. Without it, IT plans recovery to one hundred percent where fifty would have been enough, or the other way round.

The test question

Does your BIA state next to every time figure whether it is the MTPD or the RTO, and who last measured the BAO reaction time in an alerting exercise?

In isidaten, the BIA proposes MTPD and RTO from the impact matrix and records the tolerable data loss separately; anyone who deviates gives a reason.

Sources

BSI Standard 200-4, Business Continuity Management (German), version 1.0 (May 2023), chapter 5.4.1 (BAO reaction time) and chapter 7 (key figures of the business impact analysis).

Next Sunday in Basic terms: BIA and risk analysis, and why the BIA comes first.