Der Notfallplan ist nur so gut wie das Abhängigkeitswissen dahinter
Wiederanlaufpläne scheitern in der Übung selten an der Technik — sie scheitern an der Reihenfolge. Welches System braucht welches, was muss vor was wieder stehen, und wen ruft man an? Das steht in keinem Backup und in keinem Runbook, sondern nur in einem gepflegten Bild der Landschaft. Warum Business Continuity nach BSI-Standard 200-4 mit der Strukturanalyse steht und fällt.
Es gibt einen Moment in fast jeder ernsthaften Notfallübung, der den Wert der gesamten Planung offenlegt. Er kommt nicht beim Einspielen des Backups und nicht beim Failover — er kommt bei der Frage: „Gut, das System ist wieder da. Was jetzt?" Wenn die Antwort improvisiert wird, war der Plan Papier.
Wiederanlauf ist ein Reihenfolgeproblem
Die Technik des Wiederherstellens ist heute gut beherrscht — Sicherungen, Replikation, Infrastruktur aus Vorlagen. Was regelmäßig fehlt, ist das Wissen darüber: In welcher Reihenfolge müssen Systeme anlaufen, damit die Kette trägt? Der Verzeichnisdienst vor allem anderen, die Datenbank vor der Anwendung, die Anwendung vor ihren Schnittstellen — und quer dazu die unscheinbaren Glieder, die in keinem Notfallplan stehen, bis sie fehlen: der Lizenzserver, die Middleware, der Zeitdienst.
Diese Reihenfolge ist nichts anderes als das Abhängigkeitsmodell der Landschaft, gelesen von unten nach oben. Sie steht in keinem Backup und in keinem Runbook je System — sie existiert nur dort, wo die Verbindungen zwischen Prozessen, Anwendungen und Infrastruktur als gepflegte Angaben geführt werden. Häuser ohne dieses Bild schreiben Wiederanlaufpläne je System und erleben in der Übung, dass zehn korrekte Einzelpläne zusammen keinen funktionierenden Gesamtplan ergeben.
Was der Standard strukturell verlangt
Der BSI-Standard 200-4 beschreibt den Weg zum Business Continuity Management: Business-Impact-Analyse, Kontinuitätsstrategien, Notfallpläne, Übungen. Die Logik der Kette ist unbestechlich — jeder Schritt erbt die Qualität des vorigen. Die Business-Impact-Analyse bestimmt, welche Prozesse wie schnell wieder laufen müssen; dafür muss bekannt sein, welche Ressourcen jeden Prozess tragen. Das NIST Cybersecurity Framework setzt denselben Anker noch früher: Vor allen Schutz- und Wiederherstellungsfunktionen steht „Identify" — wissen, was existiert und was wovon abhängt.
In der Praxis wird diese Grundlage meist per Workshop erhoben: Interviews mit Prozessverantwortlichen, Excel-Matrizen, ein Ergebnisdokument. Das ist methodisch sauber und hat ein eingebautes Verfallsdatum — dieselbe Einmalbefüllungs-Falle, an der EAM-Einführungen sterben. Zwischen zwei BIA-Runden wechseln Systeme, Verantwortliche und Anbieter; im Ernstfall zählt aber der Stand von heute, nachts, unter Stress.
Der Notfallplan als Sicht auf den Bestand
Die tragfähige Alternative folgt dem Muster, das sich durch alle Pflichten dieser Art zieht: Die Notfall-Grundlagen werden nicht als eigenes Dokument gepflegt, sondern als Sicht auf den laufend gepflegten Bestand. Kritikalität ist eine Angabe an der Geschäftsfähigkeit, Abhängigkeiten sind Angaben an der Anwendung, Ansprechpartner sind bestätigte Verantwortliche am Objekt. Der Notfallplan zieht daraus seine Reihenfolgen und Kontaktketten — und ist damit so aktuell wie der Bestand selbst.
Der Nebengewinn ist beträchtlich: Dasselbe Abhängigkeitsbild beantwortet die NIS2-Frage nach den Auswirkungen eines Vorfalls, die Wartungsende-Frage („was hängt an dem System, das 2027 ausläuft?") und die Migrationplanung. Business Continuity ist damit kein Sonderprojekt mit eigener Datenhaltung — es ist einer von mehreren Konsumenten desselben gepflegten Bilds. Und wie bei allen Konsumenten gilt: Die Übung prüft am Ende nicht den Plan. Sie prüft, ob die Daten stimmen, auf denen er steht.
Häufige Fragen
Was hat Enterprise Architecture Management mit Notfallplanung zu tun?
Die Notfallplanung beantwortet, was in welcher Reihenfolge wieder anlaufen muss — und diese Reihenfolge ergibt sich aus den Abhängigkeiten zwischen Geschäftsprozessen, Anwendungen und Infrastruktur. Genau diese Abhängigkeiten führt ein gepflegtes Landschaftsmodell. Ohne es beruht die Business-Impact-Analyse auf Interviews mit Verfallsdatum; mit ihm ist sie eine Auswertung.
Was verlangt der BSI-Standard 200-4?
Der Standard beschreibt den Aufbau eines Business Continuity Management Systems — von der Business-Impact-Analyse über Kontinuitätsstrategien bis zu Notfallplänen und Übungen. Strukturell setzt jeder dieser Schritte voraus, dass die zu schützenden Prozesse und die sie tragenden Ressourcen identifiziert sind; die Qualität dieser Grundlage bestimmt die Qualität aller Folgeschritte.
Warum scheitern Notfallübungen so oft an der Reihenfolge?
Weil Wiederanlaufpläne gern je System geschrieben werden, die Realität aber in Ketten anläuft — Verzeichnisdienst vor Datenbank vor Anwendung vor Schnittstelle. Fehlt ein Glied im dokumentierten Bild (klassisch: die unscheinbare Middleware, der Lizenzserver), stockt die Kette an einer Stelle, die niemand auf dem Plan hatte. Übungen decken solche Lücken auf; ein gepflegtes Abhängigkeitsmodell verhindert, dass es erst die Übung sein muss.
Wie aktuell muss das Abhängigkeitswissen sein?
So aktuell wie die Landschaft selbst — und das ist der Punkt, an dem jährliche BIA-Workshops systematisch verlieren. Zwischen zwei Workshops ändern sich Systeme, Verantwortliche und Telefonnummern; im Ernstfall gilt aber der Stand von heute. Deshalb gehören Abhängigkeiten und Ansprechpartner als laufend bestätigte Angaben in den Bestand, nicht als Anhang in ein PDF von letztem Jahr.
Erst das Bild, dann der Plan
blueprAInt liefert der Notfallplanung das, was kein Runbook enthält — das aktuelle, bestätigte Abhängigkeitsbild der Landschaft.
- Die Wiederanlauf-Reihenfolge aus dem Bestand: Anwendungen kennen in blueprAInt ihre Abhängigkeiten und Geschäftsfähigkeiten — welche Kette vor welcher stehen muss, ist eine Auswertung, kein Workshop-Ergebnis von vorletztem Jahr.
- Ansprechpartner, die noch stimmen: Verantwortliche und Betreiber stehen bestätigt am System — die Telefonliste des Notfallplans veraltet nicht mehr getrennt von der Wirklichkeit.
- Kritikalität mit Herkunft: Welche Fähigkeit ein System trägt und wie kritisch sie ist, trägt Bestätigungsgrad und Datum — die Business-Impact-Analyse steht auf Belegen statt auf Bauchgefühl.