IT-Notfallplan erstellen: Aufbau und Inhalt

Leitfaden für Unternehmen mit 3-200 Mitarbeitern

Ein IT-Notfallplan beantwortet drei Fragen, bevor er Technik beschreibt: Welcher Prozess muss zuerst wieder laufen, wie lange darf das dauern, und wie viele Daten dürfen fehlen. Der handlungsleitende Teil passt auf zwei bis vier Seiten und enthält Entscheidungsbefugnis, Telefonliste, Sofortmaßnahmen, Verbote und Meldefristen. Er liegt ausgedruckt vor, weil er sonst genau dann nicht erreichbar ist, wenn er gebraucht wird. Pläne scheitern fast nie am Inhalt, sondern daran, dass sie nur digital vorliegen, zu lang sind, veraltete Nummern enthalten oder nie geübt wurden.

Der Test, den die meisten Pläne nicht bestehen

Stell Dir vor, es ist Samstag, 3 Uhr. Die Server sind verschlüsselt, das Active Directory ist tot, die Telefonanlage hängt daran, und Dein Notfallplan liegt als PDF auf dem Dateiserver.

Das ist kein konstruierter Fall, sondern der Normalfall. Ransomware wird bevorzugt an Wochenenden und Feiertagen ausgelöst, weil dann niemand hinsieht. Und ein Plan, der im Ernstfall nicht erreichbar ist, ist kein Plan, sondern eine Absichtserklärung.

Daraus folgt die erste und unbequemste Regel: Der Notfallplan liegt ausgedruckt vor. Im Serverraum, zu Hause bei der Geschäftsführung, bei der IT-Leitung. Mit Datum, damit man weiß, ob es die aktuelle Fassung ist.

Erst die Frage, dann die Technik

Bevor Du irgendetwas aufschreibst, beantworte drei Fragen für Dein Unternehmen. Ohne sie wird jeder Plan zu einer Liste von Systemen ohne Rangfolge.

Was muss zuerst wieder laufen? Nicht alles gleichzeitig, sondern in einer Reihenfolge. Die Antwort kommt nicht aus der IT, sondern aus dem Geschäft: Produktion vor Buchhaltung, Warenausgang vor Intranet, und in manchen Häusern ist die Zeiterfassung wichtiger, als die IT vermutet.

Wie lange darf es dauern? Pro Prozess, in Stunden. Das ist die Wiederanlaufzeit.

Wie viele Daten dürfen fehlen? Auch pro Prozess. Das ist der tolerierbare Datenverlust und bestimmt, wie oft gesichert wird. Ein Backup alle 24 Stunden bedeutet im schlimmsten Fall einen verlorenen Arbeitstag. Ob das tragbar ist, entscheidet nicht der Techniker.

Diese drei Antworten sind der eigentliche Plan. Der Rest ist Ausführung.

Was auf die ersten zwei Seiten gehört

Die ersten beiden Seiten werden in Panik gelesen. Sie enthalten deshalb nur das, was in den ersten dreißig Minuten gebraucht wird.

Wer entscheidet. Eine benannte Person mit Vertretung, und die Befugnis, Systeme abzuschalten und Geld freizugeben, ohne jemanden zu fragen. Wer erst eine Freigabekette durchlaufen muss, verliert die Zeit, in der Eindämmung noch etwas nützt.

Wer wird angerufen, in welcher Reihenfolge. Mit Mobilnummern, nicht mit Durchwahlen. Mindestens: Entscheider, IT-Verantwortlicher, IT-Dienstleister, Cyberversicherung, Datenschutzbeauftragter, Rechtsbeistand.

Die Versicherung gehört bewusst weit nach oben: viele Policen erstatten nur, wenn der Dienstleister vorher freigegeben wurde. Was sonst noch in der Police steht, findest Du in der Checkliste zur Cyberversicherung.

Die Sofortmaßnahmen, als Schrittfolge zum Abarbeiten. Sie unterscheiden sich danach, ob der Angriff noch läuft oder schon durch ist, und die Reihenfolge dreht sich dabei um. Die ausführliche Fassung steht unter Ransomware: was tun?.

Was nicht getan wird. Nicht neu aufsetzen, nicht löschen, keine Passwörter vom befallenen Gerät aus ändern, nicht mit dem Angreifer reden. Der Verbotsteil verhindert im Ernstfall mehr Schaden als der Gebotsteil.

Die Fristen. 72 Stunden nach Art. 33 DSGVO, bei NIS2-Pflicht zusätzlich 24 Stunden Erstmeldung ans BSI. Ab Kenntnis, nicht ab Abschluss der Untersuchung. Einzelheiten unter Datenpanne melden.

Was dahinter steht

Die Wiederanlaufreihenfolge aus den drei Fragen oben, und zwar technisch aufgelöst. Welches System hängt an welchem. Verzeichnisdienst vor Anwendung, Anwendung vor Schnittstelle. Wer das erst im Ernstfall herausfindet, startet dreimal neu.

Wo die Sicherungen liegen und wie man an sie herankommt. Einschließlich der Zugangsdaten zur Backup-Umgebung, die üblicherweise im Passwortmanager liegen, der auf dem Server läuft, der gerade verschlüsselt ist. Diesen Zirkelschluss muss der Plan auflösen, sonst fällt er genau an der Stelle auseinander, an der er gebraucht wird.

Der Ersatzkommunikationsweg. Wenn die Mailumgebung Teil des Vorfalls ist, darf die Lagekommunikation nicht darüber laufen. Eine vorbereitete Gruppe auf privaten Mobiltelefonen reicht, muss aber vorher existieren.

Vorbereitete Texte. Für Beschäftigte, Kunden und gegebenenfalls Betroffene. In der Lage formuliert niemand gut, und eine unbedachte Formulierung am ersten Tag begleitet den Fall über Monate.

Ein Protokoll. Wer hat wann was getan. Auf Papier mitlaufend geführt, weil die Systeme, die es sonst festhalten würden, im Vorfall stecken. Dieses Protokoll ist später die Grundlage für Versicherung, Aufsichtsbehörde und die forensische Aufarbeitung.

Warum Pläne trotzdem scheitern

Fast nie am Inhalt. Fast immer an einem dieser vier Punkte.

Er ist nur digital vorhanden. Siehe oben.
Er ist zu lang. Achtzig Seiten werden nachts nicht gelesen. Der Kern gehört auf zwei Seiten, alles andere in den Anhang.
Die Telefonnummern sind alt. Ein Plan, dessen Kontaktliste zwei Jahre nicht angefasst wurde, ist ungeprüft.
Er wurde nie geübt. Und damit weiß niemand, dass die Wiederherstellung acht Stunden dauert statt zwei, oder dass das Backup des Verzeichnisdienstes seit Monaten leer zurückkommt.

Eine Übung muss keine Katastrophenübung sein. Eine Stunde am Tisch, ein durchgesprochenes Szenario, eine Liste der Stellen, an denen niemand weiterwusste. Das findet mehr als jede weitere Überarbeitung des Dokuments.

Und einmal im Jahr die eine Probe, die nicht am Tisch stattfindet: eine echte Wiederherstellung auf Ersatzhardware, mit gestoppter Zeit. Bis das einmal gelaufen ist, ist die Wiederanlaufzeit im Plan eine Schätzung. Mehr dazu unter Backup und Wiederherstellung.

Der Rahmen, wenn es förmlich sein muss

Für ein strukturiertes Vorgehen gibt es den BSI-Standard 200-4 zum Business Continuity Management. Er ist deutlich umfangreicher als das hier Beschriebene und für kleinere Häuser in der Vollfassung überdimensioniert, kennt aber ausdrücklich abgestufte Reifegrade.

Wer NIS2 oder ISO 27001 im Blick hat, braucht den Notfallplan ohnehin, dort ist er Pflichtbestandteil und nicht Kür.

Häufige Fragen

Wie lang sollte ein Notfallplan sein? Der handlungsleitende Teil zwei bis vier Seiten. Wiederanlaufreihenfolge, Systemdokumentation und Vertragsdaten kommen in den Anhang. Entscheidend ist, dass die ersten Schritte ohne Blättern lesbar sind.

Wer schreibt ihn? Die IT liefert die Technik, das Geschäft liefert die Rangfolge. Ein Plan, den die IT allein schreibt, priorisiert Systeme statt Prozesse und startet im Ernstfall das Falsche zuerst.

Wie oft aktualisieren? Die Kontaktliste bei jeder Änderung, der Rest einmal jährlich und nach jeder größeren Umstellung. Ein Datum auf Seite eins macht sichtbar, wann es zuletzt geschah.

Brauchen wir das auch mit 15 Mitarbeitern? Gerade dann. Kleine Häuser haben keine Redundanz in den Köpfen: Ist die eine Person, die weiß, wie das Backup zurückgespielt wird, im Urlaub, steht alles. Der Plan ersetzt dieses fehlende zweite Gedächtnis.

Wir haben einen IT-Dienstleister, macht der das nicht? Er führt aus, was im Plan steht. Die Entscheidungen darin, also Reihenfolge, tolerierbarer Datenverlust und wer abschalten darf, kann er nicht für Dich treffen. Fehlen sie, improvisiert er im Ernstfall, und zwar nach seiner Einschätzung Deines Geschäfts.

Verwandt

Akut betroffen? Soforthilfe bei Cyberangriff. Vorbereitung: Ransomware: was tun? · Datenpanne melden · Backup und Wiederherstellung · Cyberversicherung