Server fallen selten zur passenden Zeit aus. Entscheidend ist, was dann geschieht: Wer bemerkt den Ausfall, wer wird informiert, wer entscheidet – und in welcher Reihenfolge werden die Systeme wieder in Betrieb genommen? Unternehmen mit einem geübten Ablauf beantworten diese Fragen in Minuten. Ohne Plan vergeht die erste Stunde mit Telefonketten und Zuständigkeitsfragen, während sich ein Schaden ausbreitet oder Spuren eines Angriffs verloren gehen.
Der IT-Notfallplan hat einen klar begrenzten Gegenstand: die Reaktion auf einen IT-Ausfall oder Sicherheitsvorfall und den geordneten technischen Wiederanlauf. Wie Vertrieb, Produktion oder Buchhaltung in der Zwischenzeit weiterarbeiten, ist eine andere Frage. Sie gehört in die Business-Continuity-Planung, die von den Fachbereichen getragen wird. Beide Dokumente greifen ineinander, sollten aber nicht vermischt werden: Der Notfallplan liegt in der Verantwortung der IT, der Notbetrieb in der des Geschäfts.
Die erste Stunde in drei Abschnitten
Ein brauchbarer Plan beschreibt nicht jedes denkbare Szenario, sondern einen Ablauf, der für die meisten Ereignisse trägt – vom defekten Speichersystem bis zum Verschlüsselungsangriff. Bewährt hat sich eine Gliederung nach Zeitabschnitten. Die Minutenangaben sind Orientierungswerte, keine Normvorgaben.
- Erste Viertelstunde – erkennen und melden: Wer eine Störung bemerkt, meldet sie über einen bekannten Weg an eine feste Stelle. Die IT-Notfallkarte des BSI fasst die Regeln für Beschäftigte in der Art eines Aushangs für den Brandfall zusammen: Arbeit am betroffenen System einstellen, Beobachtungen festhalten, Maßnahmen nur nach Anweisung der zuständigen Stelle.
- Bis zur halben Stunde – bewerten und entscheiden: Die zuständige Person prüft, ob eine Störung im Rahmen des Normalbetriebs vorliegt oder ein Notfall. Diese Unterscheidung braucht vorab festgelegte Kriterien, etwa die Zahl der betroffenen Arbeitsplätze, den Ausfall eines Kernsystems oder Anzeichen eines Angriffs. Mit der Entscheidung für den Notfall gelten die Regeln des Plans.
- Bis zum Ende der ersten Stunde – eindämmen und sichern: Bei Verdacht auf einen Angriff betroffene Systeme in der Regel vom Netz trennen, statt sie auszuschalten, damit Spuren erhalten bleiben. Externe Unterstützung anfordern, sobald die Kriterien dafür erfüllt sind. Prüfen, ob Meldefristen ausgelöst wurden, etwa nach der DSGVO. Eine erste interne Information an Belegschaft und Geschäftsleitung herausgeben.
Mindestens so wichtig wie der Ablauf sind die Befugnisse. Darf die IT-Leitung ohne Rückfrage die Internetverbindung kappen, auch wenn dadurch der Webshop ausfällt? Wer darf einen externen Spezialisten für die Vorfallsbehandlung beauftragen, und bis zu welchem Rahmen? Solche Fragen lassen sich in ruhigen Zeiten in wenigen Minuten entscheiden. Im Ernstfall kosten sie Stunden, weil niemand die Verantwortung übernehmen möchte.
Was in den Plan gehört
- Alarmierungsliste mit Rufnummern und Vertretungen – intern, bei Dienstleistern, bei der Versicherung und gegebenenfalls bei Behörden.
- Rollen und Entscheidungsbefugnisse: wer den Notfall ausruft, wer technisch führt, wer nach innen und außen kommuniziert.
- Übersicht der Systeme mit ihren Abhängigkeiten und der Wiederanlaufreihenfolge. Netz, Anmeldedienste und Namensauflösung kommen vor den Fachanwendungen, die ohne sie nicht starten.
- Fundorte von Sicherungen, Lizenzschlüsseln und Notfallzugängen. Für Administratorkonten, die ausschließlich im Notfall genutzt werden, empfiehlt sich eine versiegelte Hinterlegung.
- Ersatzkommunikation für den Fall, dass E-Mail, Telefonanlage oder Chat selbst betroffen sind.
- Vorbereitete Formulierungen für Belegschaft, Kunden und gegebenenfalls Aufsichtsbehörden.
- Eine Vorlage für das Ereignisprotokoll: Wer hat wann was festgestellt, entschieden und veranlasst? Diese Aufzeichnungen werden später für Meldungen, für die Versicherung und für die Auswertung gebraucht.
- Kriterien für die Rückkehr in den Normalbetrieb und eine Vorlage für die Nachbereitung.
Der Plan muss auch dann verfügbar sein, wenn die IT nicht läuft. Ein Ordner im Schrank schlägt im Ernstfall jedes Wiki, das gerade nicht erreichbar ist – ergänzt um eine Kopie an einem zweiten Ort, etwa bei der Geschäftsleitung. Wer den Plan ausschließlich auf dem Dateiserver ablegt, hat ihn genau in dem Moment nicht, in dem er gebraucht wird.
Umfang ist dabei kein Qualitätsmerkmal. Ein Plan von zehn Seiten, den die Beteiligten kennen, leistet mehr als ein Handbuch von hundert Seiten, das niemand aufschlägt. Detaillierte technische Anleitungen für einzelne Systeme gehören in die Systemdokumentation; der Notfallplan verweist darauf und hält die Kopien griffbereit.
Üben statt hoffen
Der Unterschied zwischen einem Dokument und einem funktionierenden Ablauf ist die Übung. Dafür muss kein Produktivsystem abgeschaltet werden. Drei Formen haben sich bewährt, mit steigendem Aufwand:
- Alarmierungstest: Stimmen die Nummern, und wer ist tatsächlich erreichbar, auch am Abend oder am Wochenende?
- Planbesprechung am Tisch: Ein Szenario wird durchgesprochen, etwa ein verschlüsselter Dateiserver am Montagmorgen. Jede Rolle erklärt, was sie tun würde und wo sie im Plan nachschlägt.
- Technischer Wiederanlauftest: Ein System wird aus der Sicherung in einer Testumgebung wiederhergestellt, die benötigte Zeit gemessen und mit der Planung verglichen.
Einmal jährlich eine solche Übung, angekündigt und mit anschließender Auswertung, deckt fast immer Lücken auf: veraltete Nummern, fehlende Passwörter, unklare Entscheidungswege, Wiederanlaufzeiten, die länger sind als angenommen. Jede gefundene Lücke ist ein Gewinn, denn im echten Notfall wäre sie teuer geworden. Die Ergebnisse gehören zurück in den Plan, mit Datum und Namen – sonst war die Übung nur ein Termin im Kalender.
Verwandte Themen: Wer hier weiterdenkt, liest bei Business Continuity, Ausfallkosten und IT-Monitoring weiter.
Quellen
- DER.4 Notfallmanagement · BSIamtlich
- BSI-Standard 200-4: Business Continuity Management · BSIamtlich
