IT-Notfallplan: was tun, wenn die IT steht

Ein IT-Notfallplan legt vorher fest, wer entscheidet, welche Systeme zuerst wieder ans Laufen gebracht werden, und wie alle Beteiligten sich erreichen, wenn genau die Kommunikationswege ausfallen, auf die man sich normalerweise verlässt. Ohne einen solchen Plan wird jeder IT-Ausfall zusätzlich zu einem Organisationsproblem: Wer ruft wen an, wer darf entscheiden, dass ein System heruntergefahren wird, und woher weiß der externe Dienstleister überhaupt, wie das Netzwerk aufgebaut ist – Fragen, die im Ernstfall wertvolle Zeit kosten, wenn sie erst dann zum ersten Mal gestellt werden.

Wer entscheidet, wenn die IT steht

Der erste und oft am meisten unterschätzte Punkt in einem Notfallplan ist die klare Rollenverteilung: Wer trifft die Entscheidung, ein System vom Netz zu nehmen, wer informiert die Geschäftsführung, und wer ist berechtigt, einen externen IT-Dienstleister mit einer Reaktion zu beauftragen? Fehlt diese Klarheit, entsteht in der ersten Stunde eines Vorfalls oft Stillstand – nicht, weil niemand handeln will, sondern weil niemand sicher ist, ob er handeln darf. Ein Notfallplan legt diese Verantwortlichkeiten vorher fest, inklusive Vertretung für den Fall, dass die zuständige Person selbst nicht erreichbar ist.

Welche Systeme zuerst wieder laufen müssen

Nicht jedes System ist gleich kritisch, aber in der Hektik eines Ausfalls wird oft das lauteste Problem zuerst bearbeitet statt das wichtigste. Eine Priorisierung, die vorher festgelegt wird, verhindert das: Sie legt fest, welche Systeme den Betrieb unmittelbar lahmlegen, wenn sie ausfallen, und welche kurzfristig warten können, ohne den Betrieb ernsthaft zu gefährden.

• Kritische Systeme benennen, die den Betrieb bei Ausfall unmittelbar stoppen (z. B. Warenwirtschaft, Produktionssteuerung, Telefonie)
• Für jedes kritische System festhalten, wer es betreibt, wo die Zugangsdaten liegen und wer im Ernstfall kontaktiert wird
• Abhängigkeiten dokumentieren – etwa einen Server, der zuerst laufen muss, damit ein anderes System überhaupt starten kann
• Reihenfolge der Wiederanlaufschritte vorher festlegen, statt sie im Ernstfall zu improvisieren

Kontaktketten: warum „wir rufen dann jemanden an” nicht reicht

Im Ernstfall fallen häufig genau die Kommunikationswege aus, auf die man sich normalerweise verlässt: das interne E-Mail-System, die IP-Telefonanlage, das gemeinsame Chat-Tool. Eine Kontaktkette legt vorher fest, wer wen über welchen alternativen Weg erreicht, wenn der übliche Weg nicht funktioniert – und das nicht nur für die eigene IT, sondern auch für externe Dienstleister, Versicherung und gegebenenfalls Kunden, die über eine Störung informiert werden müssen.

• Kontaktliste mit alternativen Erreichbarkeiten (private Mobilnummer, nicht nur die dienstliche Durchwahl) pflegen und aktuell halten
• Kontaktkette in physischer Form (ausgedruckt oder offline verfügbar) vorhalten, nicht nur digital auf einem System, das gerade ausgefallen ist
• Externen IT-Dienstleister und dessen Erreichbarkeit außerhalb der Geschäftszeiten fest im Plan verankern
• Klar festlegen, wer Kunden oder Partner im Ernstfall informiert, damit das nicht mehrfach unkoordiniert passiert

Den Notfallplan testen, bevor er gebraucht wird

Ein Notfallplan, der nur auf dem Papier existiert, zeigt seine Lücken meistens genau dann, wenn dafür keine Zeit mehr ist. Eine regelmäßige Übung – und sei es nur eine einstündige Simulation am Schreibtisch, bei der die Beteiligten den Ablauf gemeinsam durchgehen – deckt genau die Stellen auf, die in der Theorie plausibel klingen, aber in der Praxis nicht funktionieren: eine veraltete Telefonnummer, ein Zugang, den niemand mehr hat, ein Schritt, der auf einen anderen wartet, der aber gar nicht dokumentiert wurde.

• Mindestens einmal im Jahr eine Simulation durchführen, auch wenn sie nur ein einzelnes Szenario abdeckt
• Bei der Übung bewusst einen Ausfall der üblichen Kommunikationswege mit einbeziehen
• Erkenntnisse aus der Übung tatsächlich in den Plan einarbeiten, statt sie nur zu notieren
• Neue Mitarbeiter mit Notfallverantwortung aktiv in den Plan und die nächste Übung einbeziehen

Dokumentation als Voraussetzung für jeden Notfallplan

Ein Notfallplan ist nur so gut wie die Dokumentation, auf die er sich stützt. Wenn niemand außer einer einzelnen Person weiß, wie das Netzwerk aufgebaut ist, wo welche Konfiguration liegt und welches Passwort zu welchem System gehört, hilft der beste Plan wenig, sobald genau diese Person im Ernstfall nicht erreichbar ist. Vollständige, aktuelle Dokumentation der Infrastruktur ist deshalb keine separate Aufgabe neben dem Notfallplan, sondern dessen Grundlage.

• Netzwerkplan und Systemübersicht aktuell halten, nicht nur beim ursprünglichen Aufbau einmal erstellen
• Zugangsdaten sicher, aber für berechtigte Vertretungspersonen im Ernstfall erreichbar hinterlegen
• Verträge und Ansprechpartner für kritische Dienstleister (Internet, Hosting, Software) an einem zentralen, bekannten Ort ablegen
• Dokumentation nach jeder größeren Änderung an der Infrastruktur aktualisieren, nicht erst wieder beim nächsten Vorfall

Der Notfallplan als lebendes Dokument

Ein Notfallplan, der einmal erstellt und dann in einer Schublade vergessen wird, verliert seinen Wert, sobald sich die Infrastruktur ändert – ein neuer Server, ein neuer Dienstleister, ein umgebauter Netzwerkbereich, und schon stimmen Teile des Plans nicht mehr. Sinnvoll ist ein fester Rhythmus, in dem der Plan durchgegangen und mit der aktuellen Infrastruktur abgeglichen wird, ergänzt um zumindest eine grobe Übung, wie ein Wiederanlauf in der Praxis tatsächlich abläuft. Wer den Plan an einen festen Termin im Jahr koppelt, etwa an eine ohnehin geplante Wartung, sorgt dafür, dass die Aktualisierung nicht dem Zufall überlassen bleibt. So bleibt der Plan im Ernstfall das, was er sein soll: eine Anleitung, der man folgen kann, statt eines Dokuments, das man erst noch verstehen und aktualisieren muss.