Die Wiederanlaufzeit ist nicht die Ausfallzeit
Grundbegriffe, Folge 10: MTPD, RTO, RPO und das Notbetriebsniveau. Vier Kenngrößen aus der Business-Impact-Analyse, die ständig verwechselt werden, und eine fünfte, die fast immer fehlt: die Zeit, bis überhaupt jemand den Notfall ausruft. Wie BSI-Standard 200-4 sie definiert und warum die Wiederanlaufzeit zwingend kürzer sein muss als die Ausfallzeit.
In der Business-Impact-Analyse steht beim Abrechnungsverfahren „vier Stunden“. Die IT liest das als Wiederanlaufzeit und plant die Rücksicherung auf vier Stunden. Der Fachbereich meinte aber, dass der Prozess nach vier Stunden Stillstand nicht mehr tragbar ist. Zwischen beiden Lesarten liegt genau die Zeit, die im Ernstfall fehlt.
MTPD: wie lange der Prozess ausfallen darf
BSI-Standard 200-4 definiert in Kapitel 7, Business-Impact-Analyse, zuerst die Maximum Tolerable Period of Disruption, deutsch maximal tolerierbare Ausfallzeit. Sie
„legt fest, wie lange ein Geschäftsprozess maximal ausfallen darf, bevor nicht tolerierbare Auswirkungen für die Institution auftreten.“
Die MTPD ist eine Eigenschaft des Geschäftsprozesses, nicht der Technik. Sie wird aus dem Schadenspotenzial abgeleitet, und festlegen muss sie der Fachbereich mit der Leitung, nicht die IT.
RTO: wie lange der Wiederanlauf dauern darf
Die Recovery Time Objective, deutsch geforderte Wiederanlaufzeit, wird aus der MTPD abgeleitet. Sie umfasst laut 200-4 den Zeitraum vom Ausrufen des Notfalls bis zur geforderten Inbetriebnahme der Ersatzlösung, bei IT etwa den Schwenk auf ein Ausweichsystem oder das Zurücksetzen auf den letzten gesicherten Stand. Und dann der entscheidende Satz:
„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.“
Die Zeit davor: BAO-Reaktionszeit
Die Reaktionszeit, die da abgezogen wird, hat in 200-4 einen eigenen Namen: BAO-Reaktionszeit. Sie umfasst den Zeitraum „vom Erkennen und Alarmieren des Ereignisses, über das Konstituieren der BAO und die Entscheidungsfindung bis zum Ausrufen des Notfalls“. Das sind die Minuten oder Stunden, in denen der Ausfall schon läuft, aber noch niemand offiziell zuständig ist. Der Standard empfiehlt einen zusätzlichen Puffer, weil gerade die Erkennung unsicher ist.
Im Beispiel oben: Darf der Prozess vier Stunden ausfallen und dauert es erfahrungsgemäß eine Stunde, bis der Stab den Notfall ausruft, bleiben für den Wiederanlauf weniger als drei Stunden, nicht vier.
RPO: wie alt die Daten sein dürfen
Die Recovery Point Objective, deutsch maximal zulässiger Datenverlust, legt fest, wie alt verfügbare Daten höchstens sein dürfen, um im Notbetrieb sinnvoll damit zu arbeiten. Aus ihr ergibt sich der nötige Sicherungszyklus. Sie hat mit der Ausfallzeit nichts zu tun: Ein Prozess kann tagelang stehen dürfen und trotzdem keine Stunde Datenverlust vertragen.
Notbetriebsniveau: wie viel reicht
Das Notbetriebsniveau, englisch Minimum Business Continuity Objective, beschreibt, wie leistungsfähig der Notbetrieb sein muss, etwa als Prozentsatz oder als Liste der Tätigkeiten, die zuerst wieder laufen müssen. Ohne diese Angabe plant die IT den Wiederanlauf auf hundert Prozent, wo fünfzig gereicht hätten, oder umgekehrt.
Die Prüffrage
Steht in Ihrer BIA neben jeder Zeitangabe, ob es die MTPD oder die RTO ist, und wer hat die BAO-Reaktionszeit zuletzt in einer Alarmierungsübung gemessen?
In isidaten schlägt die BIA MTPD und RTO aus der Auswirkungsmatrix vor und erfasst den tolerierbaren Datenverlust eigens; wer abweicht, begründet es.
Quellen
BSI-Standard 200-4, Business Continuity Management, Version 1.0 (Mai 2023), Kapitel 5.4.1 (BAO-Reaktionszeit) und Kapitel 7 (Kenngrößen der Business-Impact-Analyse).
Nächsten Sonntag in den Grundbegriffen: BIA und Risikoanalyse, und warum die BIA zuerst kommt.
Fragen zu dieser Neuerung?
Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.


