IT-Notfallplan: Was vor einem Ausfall geklärt sein sollte

Ein IT-Notfallplan muss nicht mit einem dicken Handbuch anfangen. Für ein kleines Unternehmen ist zunächst wichtiger, dass im Ausfall niemand raten muss: Wer entscheidet? Wen rufen wir an? Welche Systeme müssen zuerst wieder laufen? Wo liegen Backups und Notfallzugänge? Und wie arbeiten wir weiter, solange die Technik noch nicht vollständig zurück ist?

Der BSI-Standard 200-4 zum Business Continuity Management geht deutlich weiter als ein kompakter IT-Notfallplan. Die Grundidee ist aber auch für kleinere Unternehmen hilfreich: zeitkritische Abläufe erkennen, Alarmierung und Eskalation klären, einen Notbetrieb vorbereiten und den Wiederanlauf nicht erst während des Ausfalls erfinden.

Wann aus einer Störung ein IT-Notfall wird

Nicht jeder Druckerfehler und nicht jede kurze Internetstörung braucht einen Notfallplan. Sinnvoll ist eine einfache Schwelle, ab der der normale Supportprozess nicht mehr reicht.

Das kann zum Beispiel der Fall sein, wenn ein zentraler Server länger ausfällt, mehrere Mitarbeitende nicht arbeiten können, wichtige Geschäftsdaten nicht erreichbar sind oder ein Sicherheitsvorfall eine normale Weiterarbeit unsicher macht. Die genaue Grenze hängt vom Unternehmen ab. Entscheidend ist, dass sie vorher vereinbart wurde.

Sonst passiert im Ernstfall etwas sehr Menschliches: Alle merken, dass die Lage ernst ist, aber niemand weiß, wer sie offiziell zum Notfall erklärt und die nächsten Schritte koordiniert. Eine Person oder Rolle sollte diese Entscheidung treffen dürfen und die vorgesehenen Ansprechpartner aktivieren.

Nicht mit der Serverliste anfangen

Ein Notfallplan wird schnell technisch, obwohl die erste Frage geschäftlich ist: Was muss wieder funktionieren, damit das Unternehmen sinnvoll weiterarbeiten kann?

Bei einem kleinen Betrieb kann die Auftragsbearbeitung zum Beispiel von Internetzugang, E-Mail, einer Fachanwendung und einer zentralen Dateiablage abhängen. Für die Buchhaltung sind möglicherweise andere Systeme wichtiger. Eine Telefonanlage kann technisch einfach wirken, aber plötzlich hohe Priorität bekommen, wenn Kunden sonst niemanden erreichen.

Erst aus diesen Abläufen ergibt sich eine sinnvolle Reihenfolge für den Wiederanlauf. Ein großer Server ist nicht automatisch wichtiger als ein kleiner Dienst, von dem ein kompletter Geschäftsprozess abhängt.

Für jedes wirklich wichtige System sollten deshalb drei Dinge grob bekannt sein: Wie lange darf es ausfallen? Wie viel Datenverlust wäre im schlechtesten Fall noch verkraftbar? Und wovon hängt seine Wiederherstellung ab? Die Begriffe RTO und RPO beschreiben genau diese beiden Zeitfragen, für einen ersten Plan reicht aber die verständliche Antwort in Stunden oder Tagen.

Ansprechpartner und Entscheidungswege gehören in den Plan

Im Notfall braucht es nicht nur technische Kontaktdaten. Es sollte klar sein, wer im Unternehmen Entscheidungen trifft, wer den IT-Dienstleister koordiniert und wer Mitarbeitende informiert.

Dazu gehören je nach Umgebung auch externe Kontakte: Internetanbieter, Cloud- oder Hosting-Anbieter, Anbieter einer Fachanwendung, Telefoniepartner und gegebenenfalls der Cyberversicherer. Für kritische Dienstleister sollten Vertrags- oder Kundennummern auffindbar sein, damit im Ausfall nicht erst nach Stammdaten gesucht werden muss.

Die Liste sollte kurz genug bleiben, dass sie tatsächlich gepflegt wird. Namen ändern sich, Mobilnummern wechseln und Zuständigkeiten verschieben sich. Ein alter Notfallkontakt ist im Ernstfall kaum besser als gar keiner.

Der Notfallplan darf nicht nur im ausgefallenen System liegen

Eine der einfachsten Fallen ist ein perfekt gepflegter Notfallplan, der ausschließlich in SharePoint, auf dem Dateiserver oder im Ticketsystem liegt. Fällt genau diese Umgebung aus, ist auch die Anleitung weg.

Mindestens eine aktuelle Kopie sollte deshalb unabhängig von den Systemen erreichbar sein, deren Ausfall der Plan behandelt. Das kann ein kontrollierter Ausdruck, ein sicher abgelegter Export oder eine andere getrennte Ablage sein. Dabei gehören Kennwörter nicht im Klartext in den Notfallplan. Der Plan sollte stattdessen beschreiben, wie berechtigte Personen an notwendige Notfallzugänge, Wiederherstellungscodes oder Schlüssel gelangen.

Dasselbe gilt für Telefonnummern. Wenn alle Kontakte nur im Firmenkonto gespeichert sind und die Anmeldung gerade nicht funktioniert, wird aus einem kleinen organisatorischen Versäumnis schnell ein echtes Hindernis.

Auch ein eingeschränkter Notbetrieb kann viel helfen

Wiederherstellung dauert. Deshalb sollte der Plan nicht nur den Weg zurück zum Normalbetrieb beschreiben, sondern auch klären, wie das Unternehmen einige Stunden oder im ungünstigen Fall länger eingeschränkt weiterarbeiten kann.

Vielleicht können Aufträge vorübergehend auf einem festgelegten Ersatzweg angenommen werden. Vielleicht gibt es eine alternative Telefonnummer für die interne Abstimmung. Für einzelne Prozesse kann auch ein klar definiertes manuelles Verfahren sinnvoll sein, das später sauber in das eigentliche System nachgetragen wird.

Solche Übergangslösungen müssen nicht für jeden theoretischen Ausfall vorbereitet werden. Für die wenigen Prozesse, bei denen schon einige Stunden Stillstand problematisch wären, lohnt sich die Frage aber sehr.

Beim Wiederanlauf zählt die Reihenfolge

Nach einem größeren Ausfall einfach alle Systeme gleichzeitig wieder einzuschalten, ist selten ein Plan. Systeme hängen voneinander ab. Ein Anwendungsserver braucht möglicherweise zunächst Netzwerk, DNS, Verzeichnisdienste oder eine Datenbank. Eine Fachanwendung kann technisch laufen und trotzdem nutzlos sein, solange ihre Dateiablage oder Anmeldung fehlt.

Der Notfallplan sollte deshalb für die wichtigsten Systeme eine grobe Reihenfolge festhalten. Die technischen Details dürfen in einer separaten Wiederherstellungsdokumentation stehen. Im Hauptplan reicht oft eine verständliche Kette, etwa: Basisnetz und Internet prüfen, zentrale Identität und Serverdienste wiederherstellen, Fachanwendung starten, Funktion testen, anschließend Benutzerzugriffe freigeben.

Backups spielen dabei eine wichtige Rolle, lösen den Wiederanlauf aber nicht allein. Ein erfolgreicher Sicherungsjob sagt noch nicht, wie lange ein Restore dauert oder ob eine Anwendung danach funktioniert. Bei Backup & Disaster Recovery betrachten wir deshalb auch Wiederherstellungswege, Zuständigkeiten und Restore-Tests.

Externe IT-Dienstleister müssen in den Ablauf passen

Wenn die IT ganz oder teilweise ausgelagert ist, sollte der Notfallplan festhalten, wer den Dienstleister alarmiert, über welchen Kanal das geschieht und welche Reaktions- oder Wiederherstellungsziele tatsächlich vereinbart sind. In seinen Vorschlägen zu Business-Continuity-Strategien nennt das BSI für zeitkritische ausgelagerte Leistungen unter anderem Kontaktpersonen, Melde- und Eskalationswege, Rollen sowie abgestimmte Wiederanlaufziele als wichtige Punkte.

Das bedeutet nicht, dass jedes kleine Unternehmen einen umfangreichen SLA-Katalog braucht. Es sollte aber keine Überraschung sein, ob der IT-Partner im Notfall nur während der Geschäftszeiten erreichbar ist, welche Systeme zum vereinbarten Umfang gehören und wer Entscheidungen freigeben darf.

Eine kompakte Vorlage für den ersten IT-Notfallplan

Für den Anfang kann eine überschaubare Tabelle mehr helfen als ein langes Dokument:

Diese Übersicht ersetzt keine technische Wiederherstellungsanleitung. Sie verbindet die organisatorischen Entscheidungen mit den technischen Aufgaben und schafft damit eine Grundlage für die eigentlichen Wiederanlaufdetails.

Ein Notfallplan muss einmal ausprobiert werden

Der erste Test kann erstaunlich unspektakulär sein. Man nimmt ein realistisches Szenario, zum Beispiel einen ausgefallenen zentralen Server oder einen längeren Internet- und Cloud-Ausfall, und geht den Plan am Tisch durch. Wer würde wen anrufen? Welche Information fehlt? Ist die Kontaktliste erreichbar? Kann jemand die Priorität der Systeme erklären?

Danach sollten die technischen Teile separat praktisch getestet werden. Dazu gehören vor allem Restore-Wege und der Start wichtiger Systeme. Ein Plan, der nur auf Papier funktioniert, ist noch nicht fertig.

Nach größeren Änderungen sollte er erneut angesehen werden. Ein neuer Cloud-Dienst, ein gewechselter Internetanbieter, eine neue Fachanwendung oder ein anderer IT-Dienstleister können einen vorher sinnvollen Ablauf schnell veralten lassen.

Was Wernecke IT dabei abdecken kann

Ein vollständiges Business-Continuity-Management umfasst mehr als IT und gehört organisatorisch zum Unternehmen. Unser Schwerpunkt liegt auf dem technischen Teil: Systeme und Abhängigkeiten aufnehmen, Zuständigkeiten dokumentieren, Backup- und Wiederherstellungswege klären und die laufende IT-Dokumentation aktuell halten.

Das kann je nach Umgebung über Managed IT Services mit der laufenden Betreuung und Dokumentation sowie über Backup & Disaster Recovery für die eigentliche Wiederherstellung abgedeckt werden. Wenn Sie für Ihr Unternehmen in Berlin oder Brandenburg einen vorhandenen IT-Notfallablauf technisch prüfen oder einen ersten belastbaren Stand aufbauen möchten, können wir die Umgebung gemeinsam durchgehen. Kontakt aufnehmen.