Christian Horres

Experte für Business Continuity Management (BCM), Risikomanagement und organisatorische Resilienz, insbesondere im Umfeld kritischer Infrastrukturen. Sein Schwerpunkt liegt auf Business Impact Analysen (BIA), Risikoanalysen sowie dem Aufbau und der Weiterentwicklung von BCM- und Krisenmanagementstrukturen. Im NOVELEDGE Network unterstützt er Organisationen bei der praktischen Umsetzung resilienter Strukturen unter Berücksichtigung internationaler Standards wie ISO 22301, ISO 27001 und ISO 31000 und geltender Regulatorik.

Im Business Continuity Management (BCM) existieren zahlreiche Kennzahlen, die häufig synonym verwendet oder miteinander verwechselt werden. Insbesondere die Begriffe

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

beschreiben unterschiedliche Sachverhalte und erfüllen jeweils eine eigene Funktion innerhalb des BCM.

Eine saubere Trennung dieser Begriffe ist nicht nur für eine qualitativ hochwertige Business Impact Analyse (BIA) erforderlich, sondern auch für die Entwicklung geeigneter Wiederherstellungsstrategien sowie für die Steuerung interner und externer Dienstleister.

Ausgangspunkt

Eine der häufigsten Fehlannahmen besteht darin, dass Wiederherstellungszeiten von der IT oder von Dienstleistern vorgegeben werden.

Tatsächlich verhält es sich genau umgekehrt.

Die maximal zulässigen Wiederherstellungszeiten entstehen aus den Anforderungen des Geschäfts.

Der Ausgangspunkt ist deshalb immer das mit Business mit der Business Impact Analyse.

Diese beantwortet zunächst folgende Fragen:

• Wie lange darf ein Geschäftsprozess maximal ausfallen?
• Welche Auswirkungen entstehen bei zunehmender Ausfalldauer?
• Ab welchem Zeitpunkt entstehen nicht mehr akzeptable Schäden?

Aus diesen Bewertungen ergibt sich die maximale tolerierbare Ausfallzeit eines Geschäftsprozesses. Erst anschließend wird untersucht, welche Ressourcen erforderlich sind, um diese Anforderungen einzuhalten.

Das Business definiert somit die Anforderungen. Die Ressourcen müssen diese Anforderungen erfüllen. Nicht umgekehrt.

RTO (Recovery Time Objective)

Das Recovery Time Objective beschreibt die maximal zulässige Wiederherstellungszeit eines Geschäftsprozesses.

Das RTO beantwortet somit die Frage:

„Wie lange darf dieser Geschäftsprozess maximal unterbrochen sein?”

Dabei handelt es sich um eine Zielvorgabe des Business.

Das RTO orientiert sich ausschließlich an den Auswirkungen auf:

• Finanzen
• Kunden
• Produktion
• Lieferfähigkeit
• Rechtliche Anforderungen
• Reputation
• Sicherheit von Menschen
• Umwelt
• weitere geschäftsspezifische Auswirkungen

Das RTO ist somit keine technische Kennzahl, sondern orientiert sich an den Anforderungen der Business Prozesse. Es entsteht aus der Business Impact Analyse und wird aus der MTA (Maximal tolerierbaren Ausfallzeit) des zeitkritischen Prozesses abgeleitet.

RPO (Recovery Point Objective)

Während das RTO die Zeit bis zur Wiederherstellung beschreibt, beantwortet das RPO eine völlig andere Fragestellung. Es beschreibt den maximal zulässigen Datenverlust und beantwortet damit die Frage:

„Bis zu welchem Zeitpunkt dürfen Daten verloren gehen?”

Beispiele:

• RPO = 15 Minuten
• RPO = 1 Stunde
• RPO = 4 Stunden
• RPO = 24 Stunden

Das RPO richtet sich nach den Informationsobjekten einer Ressource die für den zeitkritischen Prozess erforderlich ist.

Dabei ist entscheidend,

• wie häufig Daten entstehen oder geändert werden,
• wie kritisch deren Verlust wäre,
• ob Daten rekonstruiert werden können,
• welche gesetzlichen Anforderungen bestehen.

Hier besteht ein enger Zusammenhang mit

• Backup-Strategien,
• Replikation,
• Datenbanken,
• Speichertechnologien,
• Hochverfügbarkeitslösungen.

Das RPO bestimmt letztlich, wie aktuell die wiederhergestellten Informationen sein müssen.

Unterschied zwischen RTO und RPO

RTO und RPO werden häufig verwechselt. Dabei beantworten sie zwei vollkommen unterschiedliche Fragestellungen.

RTO: “Wie lange darf der Prozess ausfallen?”

RPO: “Wie viele Daten dürfen verloren gehen?”

Ein Prozess muss beispielsweise innerhalb von vier Stunden wieder laufen (RTO), gleichzeitig dürfen jedoch maximal fünf Minuten an Daten verloren gehen (RPO).

Umgekehrt kann ein Prozess erst nach 48 Stunden wieder verfügbar sein, während überhaupt kein Datenverlust akzeptiert wird.

Beide Werte müssen daher unabhängig voneinander bestimmt werden.

RTA (Recovery Time Actual)

Während das RTO eine Anforderung des Business darstellt, beschreibt die Recovery Time Actual die tatsächlich erreichbare Wiederherstellungszeit einer Ressource und beantwortet die Frage:

„Wie schnell kann diese Ressource tatsächlich wieder bereitgestellt werden?”

Dabei kann es sich beispielsweise handeln um:

• IT-Systeme
• Anwendungen
• Gebäude
• Produktionsanlagen / OT (Operation Technology)
• Personal
• Dienstleister
• Lieferanten
• Betriebsmittel oder Energieversorgung
• Kommunikationssysteme

Die RTA beschreibt somit keine Zielvorgabe, sondern eine tatsächlich erreichbare Wiederherstellungszeit.

Diese kann

• technisch,
• organisatorisch,
• personell oder
• vertraglich

begrenzt sein.

Grundregel im BCM

Eine der wichtigsten Regeln lautet:

RTA ≤ RTO

Die Wiederherstellungszeit einer Ressource darf niemals größer sein als die maximal zulässige Wiederherstellungszeit des unterstützten Geschäftsprozesses.

Ist die RTA größer als das RTO,

entsteht unmittelbar eine Versorgungslücke.

Diese muss geschlossen werden durch

• technische Maßnahmen,
• organisatorische Maßnahmen,
• Redundanzen,
• alternative Standorte,
• zusätzliche Dienstleister,
• Notfallverfahren oder
• Anpassung der BCM-Strategie.

Noveledge RPO von NOVELEDGE

SLA (Service Level Agreement)

Ein Service Level Agreement beschreibt die vertraglich zugesicherte Servicequalität.

Typische Inhalte sind:

• Verfügbarkeit
• Supportzeiten
• Reaktionszeiten
• Entstörzeiten
• Wartungsfenster
• Eskalationsprozesse

Ein SLA beschreibt jedoch nicht zwangsläufig die tatsächliche Wiederherstellungszeit nach einem Ausfall. Ein Dienstleister kann ein SLA vollständig erfüllen und dennoch die Anforderungen des BCM verletzen.

Beispielsweise:

Vertraglich zugesicherte Verfügbarkeit: 99,5 % Dies entspricht rund 44 Stunden Ausfall pro Jahr.

Ein zusammenhängender Ausfall von zwei Tagen könnte somit vertragskonform sein. Der unterstützte Geschäftsprozess besitzt jedoch ein RTO von lediglich 24 Stunden. Damit wäre das SLA zwar eingehalten, das BCM-Ziel in Form seiner RTO jedoch eindeutig verfehlt.

Deshalb ersetzt ein SLA niemals eine RTA.

Unterschied zwischen RTA und SLA

Aus BCM-Sicht muss bekannt sein, wann eine Ressource tatsächlich wieder verfügbar ist. Das SLA beantwortet lediglich, welche Leistungen der Dienstleister grundsätzlich zusichert.

Die RTA beantwortet hingegen, ob diese Ressource innerhalb der durch das Business geforderten Wiederherstellungszeit tatsächlich verfügbar gemacht werden kann.

Deshalb sollten in einer Business Impact Analyse beide Werte getrennt dokumentiert werden.

Im Rahmen einer Business Impact Analyse (BIA) sowie bei der Definition von Wiederherstellungsanforderungen ist zwischen einem Service Level Agreement (SLA) und einer Recovery Time Actual (RTA) zu unterscheiden. Beide Kennzahlen beziehen sich zwar auf die Verfügbarkeit einer Ressource oder Dienstleistung, beschreiben jedoch unterschiedliche Aspekte.

Ein SLA definiert vertraglich vereinbarte Leistungsmerkmale eines Dienstleisters. Hierzu gehören beispielsweise Verfügbarkeitswerte (z. B. 99,5 % pro Jahr), Reaktionszeiten, Supportzeiten oder Entstörungsfristen. Die Einhaltung eines SLA bedeutet jedoch nicht automatisch, dass die Anforderungen eines zeitkritischen Geschäftsprozesses erfüllt werden.

Die RTA beschreibt dagegen die tatsächliche bzw. zugesicherte Wiederherstellungszeit einer Ressource oder eines Services nach einem Ausfall. Die RTA dient aus BCM-Sicht als zentrale Kenngröße zur Bewertung, ob eine Ressource innerhalb der für den Geschäftsprozess erforderlichen Zeit wieder verfügbar gemacht werden kann.

Ein typisches Beispiel verdeutlicht den Unterschied:

Ein Dienstleister garantiert vertraglich eine jährliche Verfügbarkeit von 99,5 %. Rechnerisch entspricht dies einer zulässigen Ausfallzeit von rund 44 Stunden pro Jahr. Das SLA würde somit auch einen zusammenhängenden Ausfall von nahezu zwei Tagen erlauben, sofern die vertraglichen Bedingungen dies zulassen.

Der betroffene Geschäftsprozess besitzt jedoch einen Recovery Time Objective (RTO) von 24 Stunden. Damit muss die unterstützende Ressource spätestens innerhalb von 24 Stunden wieder verfügbar sein. In diesem Fall wäre das SLA allein nicht ausreichend, da es keine Aussage darüber trifft, wie lange ein einzelner Ausfall andauern darf. Zusätzlich muss daher eine RTA vereinbart werden, die sicherstellt, dass die Ressource innerhalb des geforderten Zeitraums wiederhergestellt wird.

Für BCM-Zwecke sollten daher sowohl SLA als auch RTA getrennt erfasst und bewertet werden:

• SLA: Vertragliche Leistungs- und Verfügbarkeitszusagen des Dienstleisters.
• RTA: Tatsächliche bzw. zugesicherte Wiederherstellungszeit nach einem Ausfall.
• RTO: Maximale tolerierbare Wiederherstellungszeit aus Sicht des Geschäftsprozesses.

Grundsätzlich gilt:

Die RTA einer Ressource muss kleiner oder gleich dem RTO des unterstützten Geschäftsprozesses sein.

Ein gutes SLA ersetzt daher keine BCM-Betrachtung. Erst die Kombination aus SLA und RTA ermöglicht die Bewertung, ob eine Ressource die Anforderungen eines zeitkritischen Geschäftsprozesses tatsächlich erfüllt.

Typische Fehler

In der Praxis treten regelmäßig dieselben Fehler auf:

• RTO wird durch die IT vorgegeben.
• SLA wird mit Wiederherstellungszeit gleichgesetzt.
• RPO wird als Backup-Intervall verstanden, ohne den tatsächlichen Datenverlust zu betrachten.
• Ressourcen werden bewertet, bevor die Geschäftsprozesse analysiert wurden.
• Wiederherstellungszeiten werden geschätzt, anstatt sie technisch nachzuweisen.
• Abhängigkeiten zwischen Ressourcen bleiben unberücksichtigt.

Diese Fehler führen häufig dazu, dass Business Continuity Pläne zwar formal vorhanden sind, im Ernstfall jedoch die eigentlichen Geschäftsanforderungen nicht erfüllen.

Die richtige Reihenfolge

Ein methodisch sauberes BCM folgt stets derselben Reihenfolge:

1. Geschäftsprozesse identifizieren.
2. Abhängigkeiten bewerten.
3. MTPD/MTA bestimmen.
4. RTO aus den Business-Anforderungen ableiten.
5. Benötigte Ressourcen identifizieren.
6. Für jede Ressource RTA und – soweit relevant – RPO ermitteln.
7. SLA und RTA mit den Business-Anforderungen vergleichen.
8. Abweichungen identifizieren.
9. Recovery-Strategien entwickeln.
10. Business Continuity Plans erstellen und regelmäßig testen.

Diese Reihenfolge stellt sicher, dass sich technische und organisatorische Maßnahmen konsequent an den Anforderungen des Geschäfts orientieren und nicht umgekehrt.

Fazit

Das Business definiert die Anforderungen. Die Ressourcen müssen diese Anforderungen erfüllen.

Das RTO entsteht aus den Auswirkungen eines Prozessausfalls und beschreibt die maximal zulässige Wiederherstellungszeit eines Geschäftsprozesses. Das RPO legt fest, wie viel Datenverlust akzeptabel ist und dient als Grundlage für Backup- und Replikationsstrategien. Die RTA beschreibt die tatsächlich erreichbare Wiederherstellungszeit einer Ressource und muss stets kleiner oder gleich dem RTO des unterstützten Prozesses sein. Das SLA regelt schließlich die vertragliche Leistungserbringung eines Dienstleisters, ersetzt jedoch weder die RTA noch garantiert es automatisch die Einhaltung der BCM-Anforderungen.

Ein reifes Business Continuity Management betrachtet diese Kennzahlen daher nicht isoliert, sondern verbindet sie systematisch mit den Ergebnissen der Business Impact Analyse. Erst durch diese Verknüpfung lassen sich belastbare Recovery-Strategien entwickeln und die tatsächliche Resilienz einer Organisation bewerten.