Business Impact Analysis für die IT: von den Folgen einer Betriebsunterbrechung zu MTD, RTO, RPO und Wiederherstellungsstufen

Was eine Business Impact Analysis für die IT liefert

Eine Business Impact Analysis (BIA) für die IT verknüpft jeden Geschäftsprozess mit den Systemen, auf denen er läuft, und misst, wie der Schaden wächst, solange der Prozess stillsteht. Daraus leitet sie eine maximal tolerierbare Ausfallzeit je Prozess ab, außerdem je System ein Recovery Time Objective (RTO), die längste Zeit, die das System ausfallen darf, und ein Recovery Point Objective (RPO), den Zeitpunkt vor der Unterbrechung, auf den seine Daten wiederhergestellt werden müssen, sowie die Reihenfolge, in der die Systeme wieder anlaufen. Nach Zielwerten gruppiert, ergeben sie die Wiederherstellungsstufen des Disaster-Recovery-Designs.

Die Methode folgt hier Abschnitt 3.2 der NIST Special Publication 800-34 Revision 1, des Contingency Planning Guide for Federal Information Systems, dessen Anhang B eine Beispiel-BIA und eine Vorlage enthält. Der Leitfaden wurde im November 2010 aktualisiert und ist im Oktober 2026 auf der Website von NIST weiterhin als finale Fassung geführt. NIST hat ihn für Systeme der US-Bundesbehörden geschrieben, die von ihrer Verfügbarkeitskategorie nach FIPS 199 ausgehen; ein Unternehmen verwendet seine eigene Skala für Auswirkungen. Die Technical Implementation Guidance der ENISA (Version 1.0, Juni 2025) zur NIS2-Durchführungsverordnung verweist auf denselben Leitfaden und auf ISO/TS 22317:2021, die ISO-Leitlinien für die Business Impact Analysis. Die Definitionen von RPO und RTO und ihre Kostenkurve stehen in unserem Leitfaden dazu, wie Sie RPO und RTO je System festlegen.

Die drei BIA-Schritte in NIST SP 800-34 Rev. 1

Abschnitt 3.2 nennt drei Schritte, und ein BIA-Dokument kann derselben Gliederung folgen:

1. Aufgaben- und Geschäftsprozesse und ihre Kritikalität für die Wiederherstellung bestimmen, einschließlich der „Auswirkungen des Ausfalls und der geschätzten Ausfallzeit“; die Ausfallzeit „sollte die maximale Zeit widerspiegeln, die eine Organisation tolerieren kann, während sie ihre Aufgaben weiterhin erfüllt“.
2. Ressourcenbedarf ermitteln, mit den Beispielen von NIST „Betriebsstätten, Personal, Ausrüstung, Software, Dateien, Systemkomponenten und unverzichtbare Unterlagen“.
3. Wiederherstellungsprioritäten für Systemressourcen festlegen, „der letzte Schritt des BIA-Prozesses“, dessen Ergebnis „eine Hierarchie der Wiederherstellungsprioritäten des Informationssystems“ ist.

Bei NIST gehen die Schritte von einem einzelnen Informationssystem aus nach außen. Unternehmensweit führen Sie den ersten Schritt je Geschäftsprozess mit dessen Verantwortlichen durch, ordnen danach die Prozesse den Systemen zu und legen die Prioritäten je System fest, damit die Prozessverantwortlichen nicht für jedes System dieselben Fragen gestellt bekommen. Die BIA misst Folgen und überlässt die Wahrscheinlichkeit der Risikobewertung, und die ENISA stützt die Wiederherstellungsziele auf die Ergebnisse beider.

BIA-Interviewfragen an die Prozessverantwortlichen

Bei NIST bestimmt der Koordinator die akzeptable Ausfallzeit „mit den Prozessverantwortlichen, der Führungsebene und den Fachbereichsleitungen“. Die Eingaben stammen deshalb aus Interviews mit den Menschen, die den jeweiligen Prozess betreiben, und die IT ist dabei, um die Antworten in Systeme zu übersetzen. Halten Sie die Antworten je Prozess in einem einheitlichen Format fest; die Spalte „Ergebnis“ listet die Felder, die eine BIA-Vorlage braucht.

Gliederung nach den BIA-Schritten in NIST SP 800-34 Rev. 1, Abschnitt 3.2; die Fragen und Ergebnisse sind unser Vorschlag.

Auswirkungskategorien und Auswirkungen über die Zeit

NIST überlässt die Skala der Organisation: Auswirkungen „können in Werten oder Maßeinheiten ausgedrückt werden, die für die Organisation aussagekräftig sind“, wie in seiner Beispielkategorie Kosten, „mit Auswirkungswerten, ausgedrückt als Personal-, Überstunden- oder gebührenbezogene Kosten“. Wir schlagen fünf oder sechs Kategorien vor: finanzieller Verlust, Kunden und Verträge, rechtliche und regulatorische Pflichten, Betrieb, wo relevant Gesundheit und Sicherheit, sowie Reputation. Die Geschäftsleitung legt vorab fest, was gering, mittel und schwerwiegend in jeder Kategorie bedeutet, als Beträge, betroffene Kunden oder Tage an Rückstand.

Bewerten Sie jeden Prozess zu festen Zeitpunkten nach Beginn der Betriebsunterbrechung, etwa nach 1 Stunde, 4 Stunden, 1 Tag, 3 Tagen und 1 Woche, und zwar für die ungünstigste plausible Zeit in seinem Kalender der kritischen Zeiträume. NIST nennt den Grund in seinen Ausführungen zur Abwägung der Kosten: „Je länger eine Unterbrechung andauern darf, desto kostspieliger kann sie für die Organisation und ihren Betrieb werden.“ Der erste Zeitpunkt, an dem eine Kategorie als schwerwiegend bewertet wird, setzt eine Obergrenze, und die Prozessverantwortlichen legen die maximal tolerierbare Ausfallzeit zwischen diesen Zeitpunkt und den vorherigen oder auf eine frühere harte Frist aus den Interviews. Jede Bewertung als schwerwiegend sollte ihre Quelle nennen, etwa eine Vertragsklausel, damit die Abteilungen einheitlich bewerten.

Maximal tolerierbare Ausfallzeit (MTD), MTPD, RTO und RPO

Die maximal tolerierbare Ausfallzeit (Maximum Tolerable Downtime, MTD) gehört zum Geschäftsprozess. Das Glossar von NIST definiert sie als „die Zeitspanne, für die ein Aufgaben- oder Geschäftsprozess unterbrochen werden kann, ohne der Aufgabenerfüllung der Organisation erheblichen Schaden zuzufügen“, und Abschnitt 3.2.1 ergänzt, dass sie „alle Überlegungen zu den Auswirkungen umfasst“. Der RTO gehört zu einer Systemressource, und es gilt: „Da der RTO sicherstellen muss, dass die MTD nicht überschritten wird, muss der RTO normalerweise kürzer sein als die MTD.“ Als Beispiel nennt NIST die erneute Verarbeitung von Daten, deren Dauer „zum RTO addiert werden muss, um innerhalb der durch die MTD festgelegten Frist zu bleiben“.

Die Leitlinie der ENISA nennt die geschäftsseitige Grenze Maximum Acceptable Outage (MAO) oder Maximum Tolerable Period of Disruption (MTPD), „die Zeit, die es dauern würde, bis die möglichen Auswirkungen, ein Produkt oder eine Dienstleistung nicht bereitzustellen oder eine Tätigkeit nicht auszuführen, inakzeptabel oder erheblich werden“, und ergänzt: „Typischerweise sind sie länger als RTOs.“ Die Antworten zur Behelfslösung gehören zu ihrem Service Delivery Objective (SDO), „dem Mindestleistungsniveau, das Geschäftsfunktionen im Notbetrieb erreichen müssen“.

Den RPO hält NIST aus dieser Uhr heraus („Anders als der RTO wird der RPO nicht als Teil der MTD betrachtet“) und knüpft ihn daran, „wie viel Datenverlust der Aufgaben- oder Geschäftsprozess während des Wiederherstellungsprozesses tolerieren kann“. Die Frage nach der Nacherfassung beantwortet ihn, und dieselbe Antwort entscheidet, wann sich ein kürzerer RPO lohnt: wenn die Arbeit, die in der Lücke verloren geht oder neu erfasst werden muss, schwerer wiegt als die Kosten häufigeren Kopierens.

Abhängigkeitsanalyse vom Prozess bis zur Infrastruktur

Der zweite Schritt übersetzt jeden Prozess in Ressourcen, und zwar in mehr Schichten, als die Prozessverantwortlichen sehen. Wir schlagen vor, fünf Schichten zu erfassen: Anwendungen mit ihren Datenbanken und Schnittstellen; die Plattform, also Hypervisoren, Speicher, Backup-System und Management-Ebene; gemeinsam genutzte Dienste wie Verzeichnisdienst, DNS, Zertifizierungsstelle, Zeitquellen und Lizenzserver; das Netz, von Core-Switches und Firewalls bis zu WAN-Verbindungen und Fernzugriff; und externe Dienste wie SaaS-, Zahlungs- oder EDI-Dienstleister. Die üblichen Quellen sind Daten aus Inventar, Monitoring und Firewall-Flows sowie die Schnittstellenlisten der Anwendungsverantwortlichen.

Ziehen Sie für jedes System, das auf eine Abhängigkeit angewiesen ist, vom RTO dieses Systems die Zeit ab, die es braucht, um auf ihr wiederhergestellt und gestartet zu werden; das kleinste Ergebnis ist der RTO der Abhängigkeit. Zu den Kriterien der ENISA für die Reihenfolge der Wiederherstellung gehören „Abhängigkeiten (Dienste oder Anlagen und Werte, die für andere unverzichtbar sind, werden zuerst wiederhergestellt)“. Damit kommt Infrastruktur, die kein Prozessverantwortlicher nennt, in die oberste Stufe, zusammen mit dem Backup- und Replikationssystem, denn jede Wiederherstellung wartet darauf. Externe Dienste werden von ihren Dienstleistern wiederhergestellt; halten Sie deshalb die Wiederherstellungszusage jedes Dienstleisters aus dem Vertrag fest. Ist eine Zusage länger als der RTO, den die Abhängigkeitskarte diesem Dienst zuweist, ist das eine Lücke, die im Vertrag oder mit einer Behelfslösung zu schließen ist.

Rechenbeispiel mit drei Prozessen: von den Auswirkungen zu den Stufen

Nehmen wir einen erfundenen Großhändler mit 900 Beschäftigten, einem Rechenzentrum und einer virtualisierten Umgebung, nach den Interviews zu drei Prozessen.

Erfundenes Beispiel; die Bewertungen nach 4 Stunden und 3 Tagen sind weggelassen.

Bestellung bis Versand setzt die kürzeste Grenze, denn nach 8 Stunden sind die Lkw-Abfahrten des Tages verpasst, und die Vertragsstrafklauseln greifen. Das Nacherfassen telefonischer Bestellungen und die Bestandsprüfung dauern nach der Wiederherstellung etwa 2 Stunden, womit dem ERP- und dem Lagerverwaltungssystem ein RTO von 6 Stunden bleibt. Wiederherstellung und Start des ERP-Systems dauern etwa 3 Stunden, sobald Verzeichnisdienst, DNS, Netz, Hypervisoren, Speicher und Backup-System laufen, deshalb erhalten diese 3 Stunden. Die Gehaltsabrechnung wird für den ungünstigsten Zeitpunkt bewertet, und ihre Anwendung erhält 16 Stunden, womit ein Arbeitstag für den Abrechnungslauf bleibt. Die RPOs folgen den Antworten zur Nacherfassung: Bestandsbewegungen, die über 30 Minuten hinaus verloren gingen, würden eine körperliche Inventur erfordern, Eingaben für die Gehaltsabrechnung lassen sich aus dem Zeiterfassungssystem neu erfassen, und die Konstrukteure akzeptieren, einen halben Tag Arbeit zu verlieren.

Erfundenes Beispiel; die RTOs sind kürzer gehalten als die MTD, wie sie es nach NIST SP 800-34 Rev. 1 normalerweise sein müssen. Stufe 1 bedeutet einen RTO bis 8 Stunden, Stufe 2 bis 2 Tage. Das sind keine Zielwerte unseres Service.

Das erste Gespräch ist kostenlos; darin gehen wir kritische Systeme, aktuelles Backup und Ziel-RPO/RTO durch, und Sie erhalten zwei oder drei mögliche DR-Szenarien. Schicken Sie uns Ihre kritischen Prozesse und die Systeme dahinter.

Von der Stufenliste zum DR-Design und zu den Runbooks

Jede Stufe erhält eine Wiederherstellungsstrategie, die zu ihrem RTO und RPO passt, von Wiederherstellungen aus Backup-Kopien bis zu Replikaten, die an einer Warm Site oder Hot Site bereitstehen, wie sie unser Leitfaden zu Hot Site, Warm Site und Cold Site vergleicht. Die Schritte für jedes System kommen in ein Disaster-Recovery-Runbook und werden in jedem Disaster-Recovery-Test gegen den RTO der Stufe gemessen. Verfehlt ein Test sein Ziel, prüfen Sie neben der Technik auch die BIA, denn möglicherweise fehlt eine Komponente in der Abhängigkeitskarte.

Unser Service Cloud Disaster Recovery führt regelmäßige Failover-Tests in isolierter Umgebung durch, mit einem Bericht nach jedem Test: was kam hoch, wie schnell, was ist zu fixen. Nennen Sie uns, welche Stufe Sie zuerst testen würden und wie sie heute wiederhergestellt wird.

Business Impact Analysis nach NIS2 und wann Sie sie wiederholen

Die NIS2-Richtlinie verlangt in Artikel 21 Absatz 2 Buchstabe c Maßnahmen zur Aufrechterhaltung des Betriebs, ohne eine BIA zu nennen. Für die in Artikel 1 der Durchführungsverordnung (EU) 2024/2690 der Kommission genannten Anbieter, darunter Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten und Anbieter verwalteter Dienste, gilt Nummer 4.1.3 des Anhangs, die eine BIA verlangt: „Die betreffenden Einrichtungen führen eine Analyse der betrieblichen Auswirkungen durch, um die möglichen Auswirkungen schwerwiegender Störungen auf ihre Betriebsabläufe zu bewerten, und legen auf der Grundlage der Ergebnisse Kontinuitätsanforderungen für die Netz- und Informationssysteme fest.“ Die unverbindliche Leitlinie der ENISA hält fest, dass ihre Hinweise „von anderen öffentlichen oder privaten Stellen als nützlich angesehen werden können“, und nennt für den Plan ISO 22301:2019 unter den Normen, die zu berücksichtigen sind. Unser Leitfaden zu den NIS2-Anforderungen an Backup und Business Continuity behandelt die übrigen Inhalte der Nummern 4.1 und 4.2. Welcher Text Ihr Unternehmen bindet, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Nach Nummer 4.1.4 ist der Notfallplan für die Aufrechterhaltung und Wiederherstellung des Betriebs „in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken“ zu testen und zu überprüfen, und die Leitlinie der ENISA empfiehlt, das mindestens jährlich zu tun. NIST merkt an, dass die BIA, wenn sich das Design eines Systems während der Entwicklung weiterentwickelt, „möglicherweise erneut durchgeführt werden muss“. Wiederholen Sie sie bei jeder Überprüfung des Plans und immer dann, wenn eine neue Kernanwendung, eine Migration, ein neuer Kundenvertrag oder eine Umorganisation verändert, wer von was abhängt.

Was wir tun

Im DR-Strategie-Design unseres Service Cloud Disaster Recovery definieren wir gemeinsam mit Ihnen kritische Systeme, Ziel-RPO/RTO je Systemstufe und die Katastrophenszenarien, gegen die Sie sich absichern; das Ergebnis ist ein Continuity-Plan, nicht nur Kopien. Unser Engineering-Partner Vixen.UNO richtet danach die Replikation auf Veeam-Technologie an einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen (ISO 27001, PCI DSS) ein, führt planmäßige Testwiederherstellungen durch und leistet Support, wobei RPO und RTO im SLA fixiert sind. Der Preis des technischen Assessments steht vor Beginn der Arbeiten fest. Eurokommerz hält den Vertrag, sodass Standort, Replikation, Tests und Support unter einem Vertrag laufen.

FAQ