Notfallplan, Wiederanlaufplan, Runbook — was in fast jedem Plan fehlt

Ein Backup, das zurückspielt, nützt wenig, wenn niemand weiß, womit angefangen wird.

Ein Notfallplan entsteht meistens unter Zeitdruck, weil ein Kunde ihn verlangt. Dann steht am Ende ein Dokument, das die Meldewege beschreibt: wer wen anruft, wer entscheidet, wer die Geschäftsführung informiert. Das ist richtig und reicht nicht.

Denn im Ernstfall stellt sich eine ganz andere Frage zuerst: Womit fangen wir an?

Der Wiederanlauf hat eine Reihenfolge, und die steht selten irgendwo

Systeme hängen voneinander ab. Wer die Abhängigkeiten nicht vorher aufgeschrieben hat, sortiert sie im Ernstfall — unter Druck, mit einem wartenden Kunden und einer Uhr, die läuft.

Das offensichtlichste Beispiel: Namensauflösung und Verzeichnisdienst müssen vor allem anderen laufen. Fast jedes andere System hängt daran. Wer den Dateiserver zuerst zurückholt, sieht ihn starten und danach nichts mehr tun, weil niemand sich anmelden kann.

Die Kette geht weiter, und sie ist bei jedem Kunden anders: Datenbank vor Anwendung. Lizenzserver vor der Software, die ihn fragt. Zeitsynchronisation vor allem, was Kerberos benutzt. Bei einem Metallbetrieb kommt die Maschinensteuerung dazu — und die hat oft eine eigene Abhängigkeit, die in keinem IT-Diagramm steht.

Diese Liste heißt Runbook. Sie ist der Teil des Notfallplans, der im Ernstfall tatsächlich gelesen wird, und der Teil, der am häufigsten fehlt.

Was gehört in einen Wiederanlaufplan?

Ein Wiederanlaufplan ist der Teil des Notfallplans, der festlegt, in welcher Reihenfolge welche Systeme zurückkommen, wer das tut und woran man erkennt, dass es geklappt hat. Er beantwortet nicht, wer angerufen wird, sondern was danach passiert. Mindestens gehört hinein:

1. Die Systemliste mit Abhängigkeiten — was braucht was, bevor es startet. Daraus ergibt sich die Reihenfolge, nicht aus dem Bauchgefühl.
2. RTO und RPO je System, vom Kunden entschieden und unterschrieben. Ohne sie ist jede Reihenfolge nur eine Meinung.
3. Je Schritt ein Prüfpunkt: Welche Anmeldung, welcher Aufruf, welcher Auftrag muss funktionieren, bevor der nächste Schritt beginnt.
4. Verantwortliche und Vertretung je Schritt — mit Erreichbarkeit außerhalb der Arbeitszeit, denn Störfälle halten sich nicht an Bürozeiten.
5. Die Cyber-Variante: Was ändert sich, wenn die Ursache ein Angriff ist und die Umgebung erst als sauber gelten muss, bevor ein System zurückgespielt werden darf.

Alles Weitere — Meldewege, Pressekontakt, Versicherer — gehört in den Notfallplan darum herum. Der Wiederanlaufplan ist das Stück, das im Ernstfall aufgeschlagen bleibt.

Ohne RTO und RPO ist alles davor geraten

Zwei Werte entscheiden, ob eine Sicherungsstrategie zum Betrieb passt:

RPO — wie viel Datenverlust ist hinnehmbar? Das bestimmt, wie oft gesichert wird. RTO — wie lange darf es dauern, bis wieder gearbeitet wird? Das bestimmt, wie zurückgeholt wird.

Beide Werte gelten je System, nicht pauschal für den Kunden. Die Fertigung verträgt oft keine zwei Stunden Stillstand, während die Buchhaltung einen Tag überbrücken kann. Wer eine Zahl für alles festlegt, überzahlt an der einen Stelle und unterversorgt an der anderen.

Und beide Werte gehören vom Kunden bestätigt, nicht vom Dienstleister geschätzt. Sie sind die Grundlage dafür, was im Ernstfall zugesagt werden kann — und die einzige belastbare Antwort auf die Frage, warum die Sicherung so viel kostet, wie sie kostet.

Cyber ist kein Sonderfall von Feuer

Bei Feuer, Wasser und Hardwaredefekt ist die Sicherung das, was übrig bleibt. Bei einem Angriff ist sie selbst ein Ziel — und das dreht den Plan um.

Wer sich Zugang verschafft, sucht zuerst die Sicherungen und macht sie unbrauchbar, bevor er sich zeigt. Ein Plan, der Wiederanlauf beschreibt, aber nicht die Frage beantwortet, welcher Stand überhaupt noch vertrauenswürdig ist, hilft an dieser Stelle nicht.

Dazu gehören Fragen, die im Brandfall niemand stellt: Wie weit muss zurückgegangen werden, damit der Stand sicher vor dem Eindringen liegt? Woran wird das erkannt? Wohin wird zurückgespielt, wenn die Umgebung selbst noch nicht als sauber gilt? Und wer entscheidet das — im Zweifel gegen den Wunsch, schnell wieder produzieren zu können.

Warum er trotzdem selten geschrieben wird

Am Wissen liegt es nicht. Es liegt daran, dass die Erhebung Zeit kostet, die im Tagesbetrieb nicht da ist — und dass niemand gern anfängt, wenn unklar ist, wie weit es geht.

Dabei ist der Kern kürzer, als er wirkt: die beiden Werte je System, die Abhängigkeiten, die Reihenfolge, der vertrauenswürdige Stand. Wer das hat, hat den Plan; alles andere ist Ausschmückung.

Ein Punkt gehört noch dazu, klingt altmodisch und ist der praktischste von allen: Der fertige Plan gehört ausgedruckt. Ein Notfallplan, der im verschlüsselten Dateiserver liegt, ist im Ernstfall genau so verfügbar wie alles andere dort.

Der Workshop

Die Struktur oben lässt sich lesen. Sie einmal für einen echten Kunden durchzuziehen ist etwas anderes — und genau daran scheitert es meistens, nicht am Wissen.

Deshalb gibt es das als Werkstatt, nicht als Schulung: ein halber Tag online, kleine Runde, und jeder bringt einen echten Kunden mit. Am Ende hast du keinen Foliensatz, sondern einen ausgefüllten Notfallplan für diesen Kunden.

Die Bedingung ist der echte Kunde. Ohne ihn bleibt es Theorie — und Theorie zu diesem Thema gibt es genug. Mit ihm gehst du mit etwas raus, das am nächsten Tag benutzbar ist.

Halber Tag, online, höchstens acht Teilnehmer — damit jeder an seinem Fall arbeiten kann und nicht zusieht. Termin und Preis stehen noch nicht fest; wer sich einträgt, erfährt beides zuerst und entscheidet dann.