Business Continuity ManagementTerms and Contexts

Christian Horres

Expert in Business Continuity Management (BCM), risk management, and organisational resilience, particularly in the context of critical infrastructures. His focus is on Business Impact Analyses (BIA), risk analyses, and the development and enhancement of BCM and crisis management structures. Within the NOVELEDGE network, he supports organisations in the practical implementation of resilient structures, considering international standards such as ISO 22301, ISO 27001, and ISO 31000, as well as applicable regulations.

In Business Continuity Management (BCM), numerous metrics exist that are often used interchangeably or confused with one another. In particular, the terms

Recovery Time Objective (RTO), 
Recovery Point Objective (RPO), 
Recovery Time Actual (RTA) and 
Service Level Agreement (SLA) 

describe different circumstances and each serves its own function within BCM.

A clear distinction of these terms is not only necessary for a high-quality Business Impact Analysis (BIA) but also for developing appropriate recovery strategies and managing internal and external service providers.

Starting Point

One of the most common misconceptions is that recovery times are dictated by IT or service providers.

In fact, it is exactly the opposite.

The maximum permissible recovery times arise from business requirements.

The starting point is therefore always the business with the Business Impact Analysis.

This initially answers the following questions:

• How long can a business process be disrupted at most?
• What impacts arise with increasing downtime?
• At what point do unacceptable damages occur?

From these assessments, the maximum tolerable period of disruption of a business process is derived. Only then is it examined which resources are required to meet these requirements.

The business thus defines the requirements. The resources must meet these requirements. Not the other way around.

The Abbreviations at a Glance

German and English

In German projects, two worlds of terminology collide: the English acronyms from ISO 22301^[1] and the German terms from the BSI-Standard 200-4^[2]. The meaning is the same – but the search is sometimes in one way, sometimes in another. The following table presents both side by side.

The German terms and their assignment to the English acronyms originate from the BSI-Standard 200-4: MTPD, RTO, RPO and emergency operation level from the chapter on Business Impact Analysis, RTA and RPA from the chapter on target-actual comparison.

The German terms are also not uniform. The German version of ISO 22301 translates the same English acronyms differently than the BSI^[2]:

When comparing both documents side by side, one should be aware: The same metric is referred to by the BSI as „restart time“ and in the German ISO version as „recovery time point“. This regularly leads to queries in tenders and audit reports.

Another difference: RPO and MBCO are not mentioned in the standard itself. ISO 22301 only refers to MTPD and RTO in two notes on the Business Impact Analysis; it derives their definitions from the vocabulary standard ISO 22300^[2]. Therefore, anyone who mentions „RPO according to ISO 22301“ is referring to something that is not stated there.

RTO (Recovery Time Objective)

The Recovery Time Objective describes the maximum allowable recovery time for a business process.

The RTO thus answers the question:

„How long can this business process be interrupted at most?“

This is a target set by the business.

The RTO is solely based on the impact on:

• Finances
• Customers
• Production
• Delivery capability
• Legal requirements
• Reputation
• Safety of people
• Environment
• other business-specific impacts

The RTO is therefore not a technical metric but is based on the requirements of business processes. It arises from the Business Impact Analysis and is derived from the MTPD (Maximum Tolerable Period of Disruption) of the time-critical process.

RPO (Recovery Point Objective)

While the RTO describes the time until recovery, the RPO answers a completely different question. It describes the maximum allowable data loss and thus answers the question:

„Up to what point in time can data be lost?“

Examples:

• RPO = 15 minutes
• RPO = 1 hour
• RPO = 4 hours
• RPO = 24 hours

The RPO is determined by the information objects of a resource required for the time-critical process.

It is crucial,

• how frequently data is generated or changed,
• how critical their loss would be,
• whether data can be reconstructed,
• what legal requirements exist.

There is a close connection with

• backup strategies,
• replication,
• databases,
• storage technologies,
• high availability solutions.

The RPO ultimately determines how current the restored information must be.

RTO and RPO exclusively describe availability: how long a failure may last and how much data may be lost. Whether the same data also remains confidential and intact is answered by the information security objectives.

Difference between RTO and RPO

RTO and RPO are often confused. However, they address two completely different questions.

RTO: “How long can the process be down?”

RPO: “How much data can be lost?”

For example, a process must be operational again within four hours (RTO), but at the same time, a maximum of five minutes of data loss is permissible (RPO).

Conversely, a process might only be available again after 48 hours, while no data loss is acceptable.

Both values must therefore be determined independently of each other.

RTA (Recovery Time Actual)

While the RTO is a business requirement, the Recovery Time Actual describes the actually achievable recovery time of a resource and answers the question:

“How quickly can this resource actually be restored?”

This can refer to, for example:

• IT systems
• Applications
• Buildings
• Production facilities / OT (Operation Technology)
• Personnel
• Service providers
• Suppliers
• Operational resources or energy supply
• Communication systems

The RTA thus does not describe a target, but an actually achievable recovery time.

This can be

• technical,
• organisational,
• personnel-related or
• contractual

limited.

Basic Rule in BCM

One of the most important rules is:

RTA ≤ RTO

The recovery time of a resource must never exceed the maximum allowable recovery time of the supported business process.

If the RTA is greater than the RTO,

a supply gap immediately arises.

This must be closed through

• technical measures,
• organisational measures,
• redundancies,
• alternative locations,
• additional service providers,
• emergency procedures or
• adjustment of the BCM strategy.

Noveledge RPO by NOVELEDGE

SLA (Service Level Agreement)

A Service Level Agreement describes the contractually assured service quality.

Typical contents include:

• Availability
• Support hours
• Response times
• Fault resolution times
• Maintenance windows
• Escalation processes

However, an SLA does not necessarily describe the actual recovery time after a failure. A service provider can fully meet an SLA and still violate the requirements of BCM.

For example:

Contractually assured availability: 99.5% This corresponds to around 44 hours of downtime per year.

A continuous outage of two days could thus be contractually compliant. However, the supported business process has an RTO of only 24 hours. Therefore, while the SLA would be met, the BCM goal in the form of its RTO would clearly be missed.

Therefore, an SLA never replaces an RTA.

Difference between RTA and SLA

From a BCM perspective, it is essential to know when a resource is actually available again. The SLA only answers which services the provider fundamentally assures.

The RTA, on the other hand, answers whether this resource can actually be made available within the recovery time required by the business.

Therefore, both values should be documented separately in a Business Impact Analysis.

In the context of a Business Impact Analysis (BIA) and when defining recovery requirements, it is important to distinguish between a Service Level Agreement (SLA) and a Recovery Time Actual (RTA). Both metrics relate to the availability of a resource or service but describe different aspects.

An SLA defines the contractually agreed performance characteristics of a service provider. These include, for example, availability values (e.g. 99.5% per year), response times, support hours, or fault resolution deadlines. Compliance with an SLA does not automatically mean that the requirements of a time-critical business process are met.

The RTA describes the actual or assured recovery time of a resource or service after a failure. From a BCM perspective, the RTA serves as a central metric for assessing whether a resource can be made available again within the time required for the business process.

A typical example illustrates the difference:

A service provider contractually guarantees an annual availability of 99.5%. Mathematically, this corresponds to an allowable downtime of around 44 hours per year. The SLA would thus also allow a continuous outage of nearly two days, provided the contractual conditions permit this.

However, the affected business process has a Recovery Time Objective (RTO) of 24 hours. Therefore, the supporting resource must be available again within 24 hours at the latest. In this case, the SLA alone would not be sufficient, as it does not specify how long a single outage may last. Therefore, an RTA must also be agreed upon to ensure that the resource is restored within the required timeframe.

For BCM purposes, both SLA and RTA should therefore be recorded and evaluated separately:

• SLA: Contractual performance and availability commitments of the service provider.
• RTA: Actual or assured recovery time after a failure.
• RTO: Maximum tolerable recovery time from the business process perspective.

In principle:

The RTA of a resource must be less than or equal to the RTO of the supported business process.

A good SLA does not replace a BCM assessment. Only the combination of SLA and RTA allows for the evaluation of whether a resource truly meets the requirements of a time-critical business process.

MTPD and MTA

The value from which everything else follows

Before discussing RTO and RPO, another question must be answered: How long can the organisation withstand the disruption? This limit is called Maximum Tolerable Period of Disruption (MTPD) internationally, and Maximal Tolerable Ausfallzeit (MTA) in the BSI-Standard 200-4.

It determines how long a business process can be disrupted before intolerable impacts occur for the institution^[1]. It is determined in the Business Impact Analysis by assessing the damage potential of each business process – not by what is technically feasible.

The RTO is then derived from the MTPD. There is a rule that is often overlooked in practice:

The RTO must necessarily be shorter than the MTPD.^[1]

The reason is simple: Time passes between the occurrence of the disruption and the declaration of an emergency – detection, reporting, decision-making. This reaction time is subtracted from the MTPD. Equating RTO and MTPD means the limit is already breached before recovery even begins. The BSI-Standard 200-4 further recommends an additional time buffer, as detection is particularly difficult to predict time-wise.

RPA (Recovery Point Actual)

The actual data loss

The RPO is a requirement. Whether it is met is not indicated by it. For this, there is the counterpart: Recovery Point Actual (RPA), referred to as actual data loss in the BSI-Standard 200-4.

The relationship is the same as between RTO and RTA:

• RTO and RPO are target values from the Business Impact Analysis.
• RTA and RPA are actual values from the reality of the respective resource.
• The comparison of both sides is called target-actual comparison in the BSI-Standard 200-4^[1].

A requirement is only fulfilled when RTA is less than or equal to RTO, RPA is less than or equal to RPO – and additionally, the defined emergency operation level is reached. Two out of three are not enough.

MBCO and Emergency Operation Level

How much performance the emergency operation needs

Recovery does not mean normal operation. What actually needs to be achieved in emergency operation is determined by the Emergency Operation Level – in English, Minimum Business Continuity Objective (MBCO).

The BSI-Standard 200-4 describes it as the determination of how capable the emergency operation should be to ensure a meaningful business operation^[1]. It is determined individually for each business process, either as a percentage of normal performance or by prioritising individual activities.

This factor determines the effort. A process that must handle 30 percent of the normal load in emergency operation requires a completely different solution than one that needs 90 percent – with the same RTO. Those who do not define the emergency operation level end up negotiating costs without knowing the requirement.

MAO, WRT, MTN and MTW

Terms from other sources

In projects, additional abbreviations appear that are not found in the text of the BSI Standard 200-4. Anyone using them should clarify what they refer to.

• MAO (Maximum Acceptable Outage): encountered in English-language literature as a term for the same limit as MTPD. Neither the DIN EN ISO 22301 nor the BSI Standard 200-4 include the term.^[1][2]
• WRT (Work Recovery Time): the time after the technical restart until work can resume – data entry, reconciliation, approvals. A practical term from IT disaster recovery management; it is not defined in any of the standards referenced here. The American NIST guide refers to the Maximum Tolerable Downtime (MTD) in a comparable context.^[3]
• MTN (maximum tolerable emergency operation time) and MTW (maximum tolerable recovery time): both terms from the older BSI Standard 100-4. There, the MTW results from the sum of recovery time and MTN.^[4]

For your own documentation, it is advisable to establish a set of terms and stick to it. Most misunderstandings in BCM projects do not arise from the numbers, but from two participants understanding the same abbreviation differently.

Where the Terms Come From

BSI Standard 200-4 and ISO 22301

Two sources shape the terms in German-speaking Business Continuity Management:

• BSI Standard 200-4: provides the German terms and assigns them to the English abbreviations. MTPD, RTO, RPO, and the emergency operation level are introduced in the chapter on Business Impact Analysis, RTA and RPA in the chapter on target-actual comparison.
• ISO 22301: the international standard for Business Continuity Management Systems. It consistently uses the English terms.
• NIST SP 800-34: the American guide to contingency planning. It also defines RTO and RPO and additionally introduces the Maximum Tolerable Downtime (MTD)^[3]. Freely available – hence, many English-language explanations on the web ultimately originate from there.
• ISO 22316: describes organisational resilience with principles and attributes, without its own time metrics. The BSI Standard 200-4 itself refers to it^[5]. It provides the framework in which the metrics have any purpose at all.

The similarity of the sources is evident in the NIST guide. There, the outage limit of the business process is called Maximum Tolerable Downtime (MTD): the time the responsible entity is willing to tolerate an interruption. The RTO is the time a single system resource can be down before other resources, the supported business processes, and thus the MTD are affected. And because the RTO must ensure that the MTD is not exceeded, it generally has to be shorter than the MTD – the same derivation rule as between MTPD and RTO in the BSI Standard 200-4, just with different names. The RPO is described by NIST as the point in time before the disruption to which data can be restored using the most recent backup available.

Both describe the same logic. Those searching for „RPO abbreviation“ and those searching for „maximum allowable data loss“ mean the same value.

These metrics are not gathered at the desk but in the Business Impact Analysis. How this is structured is shown by the Business Impact Analysis template as an Excel template and the option to have a Business Impact Analysis conducted. The technical contact is Christian Horres.

Typical Mistakes

In practice, the same mistakes occur regularly:

• RTO is specified by IT.
• SLA is equated with recovery time.
• RPO is understood as the backup interval, without considering the actual data loss.
• Resources are evaluated before business processes have been analysed.
• Recovery times are estimated rather than technically proven.
• Dependencies between resources are disregarded.

These errors often result in Business Continuity Plans being formally present but failing to meet actual business requirements in an emergency.

The Correct Sequence

A methodically sound BCM always follows the same sequence:

1. Identify business processes.
2. Evaluate dependencies.
3. Determine MTPD/MTA.
4. Derive RTO from business requirements.
5. Identify required resources.
6. Determine RTA and, where relevant, RPO for each resource.
7. Compare SLA and RTA with business requirements.
8. Identify deviations.
9. Develop recovery strategies.
10. Create and regularly test Business Continuity Plans.

This sequence ensures that technical and organisational measures are consistently aligned with business requirements, rather than the other way around.

Conclusion

The business defines the requirements. The resources must meet these requirements.

The RTO arises from the impact of a process failure and describes the maximum allowable recovery time of a business process. The RPO specifies how much data loss is acceptable and serves as the basis for backup and replication strategies. The RTA describes the actually achievable recovery time of a resource and must always be less than or equal to the RTO of the supported process. The SLA finally regulates the contractual service delivery of a service provider, but does not replace the RTA nor does it automatically guarantee compliance with BCM requirements.

A mature Business Continuity Management therefore does not consider these metrics in isolation, but systematically links them with the results of the Business Impact Analysis. Only through this linkage can robust recovery strategies be developed and the actual resilience of an organisation be assessed.

Sources

The terms and relationships in this article are based on the following sources. Paid standards are not quoted verbatim; their contents are paraphrased.

1. DIN EN ISO 22301:2020-06 – Security and Resilience – Business Continuity Management System – Requirements (ISO 22301:2019). German version EN ISO 22301:2019. Publisher: DIN Deutsches Institut für Normung e. V., Berlin. Available for purchase through standards trade. ↑
2. Federal Office for Information Security: BSI Standard 200-4 – Business Continuity Management. Version 1.0, May 2023. Referenced: Chapter 7 (Business Impact Analysis) and Chapter 8 (Gap Analysis). Freely available at BSI. ↑
3. National Institute of Standards and Technology: NIST Special Publication 800-34 Rev. 1 – Contingency Planning Guide for Federal Information Systems. 2010. Freely available at NIST. ↑
4. Federal Office for Information Security: Online Course Emergency Management, Section 3.4 „Determine Restart Parameters“ and Glossary, based on BSI Standard 100-4. Freely available at BSI. ↑
5. ISO 22316:2017 – Security and resilience – Organizational resilience – Principles and attributes. Publisher: International Organization for Standardization, Geneva. Available for purchase through standards trade. ↑