ISO 27031 Realitätscheck: Die gefährliche Lücke des RTO zwischen Business und IT

Zwei Welten, eine Kennzahl: Wann startet die Uhr wirklich?

Die Kontroverse lässt sich auf eine einfache Frage reduzieren: Wann beginnt die RTO? Die Antwort darauf spaltet Organisationen oft in zwei Lager, die sich an den Standards von ISO und der gängigen Praxis des BSI orientieren.

• Die Business-Perspektive (gemäß ISO 22301 & ISO 27031): Für das Business beginnt der Schaden exakt zum Zeitpunkt des Störfalls. Jede Sekunde Ausfall kostet Geld, Vertrauen und Marktanteile. Internationale Standards wie die ISO 22301:2019 und die neue ISO 27031:2025 sind hier unmissverständlich: Die RTO-Zeitmessung startet mit dem "incident occurs" – dem Moment des Schadensereignisses. Diese Perspektive ist die einzig logische Grundlage für eine valide Business Impact Analyse (BIA), da sie die gesamte Dauer der Nichtverfügbarkeit erfasst.

• Die IT-Perspektive (gängige Praxis, oft im BSI-Umfeld): Für die IT-Abteilung ist die RTO oft ein Service Level Objective (SLO), dessen Einhaltung gemessen und berichtet werden muss. In der Praxis startet die Uhr daher häufig erst, nachdem der Vorfall entdeckt, analysiert und ein Notfall formal ausgerufen wurde. Die Phasen der Detektion, Analyse und Entscheidung werden nicht in die RTO der IT eingerechnet.

Diese unterschiedlichen Startpunkte erzeugen eine "versteckte Ausfallzeit" (Hidden Downtime) – ein Zeitraum, in dem das Unternehmen bereits Schaden erleidet, die IT-Wiederherstellungsuhr aber noch gar nicht läuft.

Die fatalen Nachteile der Diskrepanz

Diese Hidden Downtime ist die Wurzel einer Kaskade von strategischen Fehlern und operativen Risiken:

• Die Illusion der Sicherheit entsteht, wenn die IT die Einhaltung ihrer 4-Stunden-RTO meldet, weil die technische Wiederherstellung nach der Notfall-Ausrufung nur 3,5 Stunden gedauert hat. Das Business hat zu diesem Zeitpunkt aber bereits 6,5 Stunden Ausfall erlitten (3 Stunden "versteckte Ausfallzeit" + 3,5 Stunden Wiederherstellung) und die in der BIA definierte maximale Toleranzgrenze längst überschritten. Die IT-Ampel steht auf Grün, während das Unternehmen rote Zahlen schreibt.

• Wertlose Business Impact Analysen und Fehlplanung bei Lösungsoptionen sind die Folge, denn wenn die Fachbereiche ihre RTO-Anforderungen definieren, gehen sie von der Gesamtausfallzeit aus. Wenn die IT diese Anforderung mit einer anderen Zeitrechnung bestätigt, basieren alle nachfolgenden Lösungsoptionen auf einer falschen Prämisse. Die BIA wird so von einem Steuerungsinstrument zu einem Instrument der Selbsttäuschung.

• Ein vorprogrammierter Krisenkonflikt ist unausweichlich, wenn im Ernstfall die unterschiedlichen Erwartungen aufeinanderprallen. Die Geschäftsführung erwartet den Wiederanlauf basierend auf dem Business-RTO, während die IT nach ihrer eigenen Zeitrechnung arbeitet. Das Ergebnis sind Vertrauensverlust, ineffektives Krisenmanagement und Schuldzuweisungen genau dann, wenn eine geschlossene Zusammenarbeit überlebenswichtig wäre.

• Unterschätzte Risiken und unzureichende Budgets sind das Resultat, da die Hidden Downtime ein nicht einkalkuliertes Risiko darstellt. Die Kosten, die in dieser Phase entstehen, werden in der Risikobewertung nicht erfasst. Folglich werden Budgets für notwendige Maßnahmen – wie schnellere Detektionsmechanismen oder manuelle Workarounds zur Überbrückung genau dieser Zeit – als z. B. unnötig abgetan.

Fazit: Ein Weckruf für Führungsebene und Verantwortliche

Die unterschiedliche Interpretation der RTO ist keine semantische Kleinigkeit, sondern ein fundamentales Governance-Problem. Die neue ISO 27031:2025 erkennt diese Realität an und fordert Konsequenzen: Kann die IT die vom Business geforderte RTO (ab Schadensereignis) nicht erfüllen, ist die Organisation verpflichtet, einen Plan zur Überbrückung dieser Lücke zu haben – den manuellen Workaround.

Handlungsempfehlungen für Führungsebene und Verantwortliche:

• Eine einheitliche Sprache zu schaffen ist entscheidend. Initiieren Sie einen Workshop zwischen Business-Verantwortlichen und der IT-Leitung mit dem einzigen Ziel, eine unternehmensweit verbindliche RTO-Definition zu verabschieden, die am Schadensereignis beginnt. Verankern Sie diese Definition in Ihrer BCM- und ITSCM-Policy.

• Die Realität zu messen ist unerlässlich. Führen Sie die Kennzahl Recovery Time Actual (RTA) ein. Messen Sie in Tests und Übungen die tatsächliche Zeit vom simulierten Vorfall bis zum Wiederanlauf. Diese RTA ist der ehrliche Maßstab für Ihre Resilienz.

• Die Lücke transparent zu machen ist ein Muss. Erstellen Sie eine Gap-Analyse, die die Anforderung des Business (RTO) der realen Leistungsfähigkeit (RTA) gegenüberstellt. Diese Methode ist die Grundlage für jede strategische Entscheidung – sei es eine Investition in schnellere IT oder in die Entwicklung robuster manueller Prozesse.

• Verantwortung zu übernehmen ist fundamental. Die Entwicklung von Workarounds ist keine IT-Aufgabe, sondern die Verantwortung der Prozessverantwortlichen in den Fachbereichen. Die Führungsebene muss hierfür die notwendigen Budgets und Ressourcen bereitstellen und eine Testkultur etablieren, die Schwachstellen als Lernchancen begreift.

Schließen Sie die Resilienz-Lücke

Die Lücke zwischen Business-Anforderungen und IT-Realität zu schließen, ist eine komplexe Herausforderung. Unser Team aus erfahrenen BCM- und IRBC-Spezialisten unterstützt Sie gezielt dabei, die Theorie in die Praxis umzusetzen. Von der Moderation eines entscheidenden RTO-Alignment-Workshops über die Durchführung einer fundierten Gap-Analyse bis hin zur Entwicklung praxistauglicher Business Continuity Pläne – wir helfen Ihnen, echte, messbare Resilienz aufzubauen.

Kontaktieren Sie uns für eine unverbindliche Erstberatung und machen Sie den ersten Schritt von einem Plan auf dem Papier zu einer gelebten, krisenfesten Strategie.