Die Praxis zeigt allerdings: Viele kleine und mittlere Unternehmen haben keinen solchen Plan. Oft existieren lose Notizen, eine Liste mit Telefonnummern oder eine vage Vorstellung davon, was im Ernstfall zu tun wäre. Das reicht nicht.
Ein IT-Notfallplan ist ein dokumentiertes Regelwerk. Er beschreibt, wie Ihr Unternehmen auf schwerwiegende IT-Störungen reagiert. Er legt fest, wer entscheidet, wer handelt, welche Systeme Priorität haben und wie die Kommunikation abläuft. Das Ziel ist einfach: In einer Stresssituation soll niemand mehr überlegen müssen, was als Nächstes zu tun ist.
Was ein Notfallplan leisten muss
Der wichtigste Zweck eines IT-Notfallplans ist Klarheit. Wenn Systeme ausfallen und Mitarbeiter verunsichert sind, darf es keine Diskussionen darüber geben, wer welche Entscheidung trifft. Der Plan beantwortet genau diese Fragen:
- Wer stellt fest, dass ein Notfall vorliegt?
- Wer übernimmt die Koordination?
- Wer informiert Mitarbeiter, Kunden und Behörden?
- In welcher Reihenfolge werden Systeme wiederhergestellt?
Häufig wird der Begriff „IT-Notfallplan“ mit dem „IT-Notfallhandbuch“ verwechselt. Der Unterschied ist wichtig. Der Notfallplan ist das strategische und organisatorische Dokument. Er regelt Verantwortlichkeiten, Kommunikationswege und Prioritäten auf übergeordneter Ebene. Das Notfallhandbuch dagegen enthält die operative Schritt-für-Schritt-Anleitung. Dort steht, wie genau ein bestimmter Server wiederhergestellt wird oder welche Befehle einzugeben sind. Beide Dokumente gehören zusammen, erfüllen aber unterschiedliche Aufgaben.
Warum ein individueller Plan? Fertige Vorlagen gibt es zuhauf im Internet. Sie geben eine sinnvolle Struktur vor und sind als Ausgangspunkt nützlich. Ein einfach übernommener Mustertext hilft im Ernstfall aber niemandem. Jedes Unternehmen hat andere Systeme, andere Abhängigkeiten, andere Prozesse. Ein Notfallplan, der Ihre IT-Landschaft nicht präzise abbildet, ist im Zweifel wertlos. Die Vorlage ist der Rohbau, die Individualisierung ist die eigentliche Arbeit.
Wann greift der IT-Notfallplan?
Nicht jede Störung ist ein Notfall. Wenn ein Drucker streikt oder ein einzelner Arbeitsplatz nicht hochfährt, ist das ärgerlich, aber kein Fall für den Notfallplan. Der Plan greift erst dann, wenn der reguläre IT-Betrieb nicht mehr aufrechterhalten werden kann oder wenn ein Ereignis geschäftskritische Folgen haben könnte.
Typische Situationen, in denen der IT-Notfallplan zum Einsatz kommt:
- Ein Ransomware-Angriff hat Daten verschlüsselt und Systeme lahmgelegt.
- Der zentrale Server ist ausgefallen und Mitarbeiter können nicht mehr arbeiten.
- Ein wichtiger Cloud-Dienst ist über längere Zeit nicht erreichbar.
- Ein Hardwareschaden betrifft das Warenwirtschafts- oder ERP-System.
- Es besteht der Verdacht auf einen Datenabfluss.
- Das Firmengebäude ist wegen eines physischen Schadens nicht zugänglich.
Es lohnt sich, die Schwellen für den Notfall im Vorfeld klar zu definieren. Sonst entsteht in kritischen Momenten eine Diskussion darüber, ob der Plan überhaupt greift. Das kostet Zeit, die Sie im Ernstfall nicht haben.
Checkliste: Was in einen IT-Notfallplan gehört
Ein belastbarer Notfallplan enthält mindestens folgende Bausteine. Die Liste ist kein starres Schema, sondern eine Orientierung. Je nach Branche, Größe und Abhängigkeitsgrad der IT kommen weitere Punkte hinzu.
1. Risikoanalyse und Notfall-Szenarien
Welche Ereignisse sind realistisch und würden den Betrieb ernsthaft treffen? Ransomware, Serverausfall, längerer Stromausfall, Brand im Serverraum, Ausfall des IT-Dienstleisters, Sperrung eines Cloud-Dienstes. Für die wahrscheinlichsten und schwerwiegendsten Szenarien sollte der Plan jeweils konkrete Vorgehensweisen vorsehen.
2. Identifikation kritischer Systeme und Prozesse
Welche Anwendungen müssen als Erstes wieder laufen? Welche sind für einen oder zwei Tage verzichtbar? Hilfreich ist es, für jedes wichtige System zwei Werte festzulegen: die maximal tolerierbare Ausfallzeit und den maximal tolerierbaren Datenverlust. In der Fachsprache heißen diese Werte RTO und RPO. Aus ihnen ergibt sich die Reihenfolge der Wiederherstellung.
3. Verantwortlichkeiten und Notfallteam
Sinnvoll ist ein kleines Notfallteam mit klar verteilten Rollen: Krisenkoordination, technische Umsetzung, interne und externe Kommunikation, Dokumentation der Ereignisse. Jede Rolle braucht eine Vertretung für den Fall, dass jemand im Urlaub, krank oder schlicht nicht erreichbar ist. Wichtig sind außerdem definierte Entscheidungsbefugnisse: Wer darf wann welche Maßnahme freigeben, auch außerhalb der Geschäftszeiten?
4. Dokumentation der Kontakte
Dazu gehören IT-Dienstleister mit Notfallnummer rund um die Uhr, Datenschutzbeauftragter, Cyber-Versicherung, zentrale Lieferanten, Betriebsrat und bei Bedarf eine Stelle für Presseanfragen. Die Liste sollte auch offline verfügbar sein, etwa als Ausdruck im Büro der Geschäftsführung oder im Tresor. Wenn im Ernstfall alle Systeme verschlüsselt oder abgeschaltet sind, hilft kein Kontaktbuch in der Cloud.
5. Zugangsdaten und Notfallzugänge
Was passiert, wenn der Administrator nicht erreichbar ist? Passwörter für kritische Systeme müssen im Ernstfall verfügbar sein, etwa über einen versiegelten Umschlag im Safe oder einen hinterlegten Master-Zugang. Gleichzeitig muss dieser Zugang gegen Missbrauch abgesichert sein, etwa durch das Vier-Augen-Prinzip.
6. Kommunikationsregeln
Wie informieren Sie intern die Mitarbeiter, wenn E-Mail und Intranet nicht funktionieren? Über eine Telefonkette, eine SMS-Liste, einen externen Messenger? Was sagen Sie extern Kunden, Partnern und Behörden, und wer gibt diese Information heraus? Vorformulierte Textbausteine für typische Szenarien sparen im Ernstfall viel Zeit und verhindern widersprüchliche Aussagen nach außen.
7. Backup-Strategie und Wiederherstellungsreihenfolge
Wo liegen die Backups, wer hat Zugriff, wann wurden sie zuletzt erfolgreich zurückgespielt? Bewährt hat sich die 3-2-1-Regel: drei Kopien der Daten auf zwei unterschiedlichen Medientypen, eine davon räumlich getrennt oder offline. Die Reihenfolge der Wiederherstellung ergibt sich aus der Priorisierung der kritischen Systeme.
8. Ausweichlösungen für den Übergang
Wie können Mitarbeiter weiterarbeiten, solange die Hauptsysteme ausfallen? Telefon statt E-Mail, Papierformulare statt digitaler Workflow, Homeoffice bei einem Gebäudeausfall, ein alternativer Rechner im Lager. Solche Übergangslösungen sollten im Plan benannt sein, damit sie nicht erst in der Krise erfunden werden.
9. Meldepflichten
Bei einem Datenschutzvorfall greift die 72-Stunden-Frist der DSGVO gegenüber der zuständigen Aufsichtsbehörde. Je nach Branche und Unternehmensgröße kommen weitere Meldepflichten hinzu, etwa gegenüber dem BSI im Rahmen der NIS2-Richtlinie. Auch Cyber-Versicherungen verlangen in der Regel eine unverzügliche Meldung, sonst kann der Versicherungsschutz entfallen.
10. Wiederaufnahme des Normalbetriebs
Wann gilt ein Notfall als beendet? Wer erklärt die Rückkehr zum Normalbetrieb? Ohne klare Kriterien bleibt die Organisation länger im Krisenmodus als nötig. Ebenso gehört die Nachbereitung in den Plan: Was ist passiert, was hat gut funktioniert, was muss verbessert werden? Diese Lessons Learned fließen in die nächste Version des Plans ein.
11. Verweis auf das Notfallhandbuch
Die technische Schritt-für-Schritt-Anleitung gehört als separates, aber verbundenes Dokument dazu. Dort stehen die konkreten operativen Anweisungen: welche Dienste in welcher Reihenfolge gestartet werden, wo die Wiederherstellungsskripte liegen, welche Kommandos einzugeben sind.
Eine Checkliste allein macht noch keinen funktionierenden Plan. Jeder Punkt muss mit den tatsächlichen Gegebenheiten in Ihrem Unternehmen gefüllt werden. Ein Eintrag wie „Backup wird wiederhergestellt“ hilft niemandem. Konkret muss stehen, welches Backup, von wem, mit welchem Tool, in welcher Reihenfolge. Nur dann trägt der Plan im Ernstfall.
Häufige Fehler beim Erstellen eines IT-Notfallplans
Wer einen IT-Notfallplan erstellt, stößt immer wieder auf dieselben Fallstricke. Einige davon lassen sich leicht vermeiden, wenn man sie kennt.
Der häufigste Fehler: Eine Vorlage wird heruntergeladen und kaum angepasst. Das Dokument existiert dann zwar, aber die darin genannten Systeme, Prozesse oder Ansprechpartner haben mit der Realität des Unternehmens wenig zu tun.
Ein zweiter Klassiker sind unklare Verantwortlichkeiten. Oft steht „die IT“ als Zuständige im Plan, ohne dass konkrete Personen benannt sind. Oder alles hängt an der einen IT-Fachkraft, die im Ernstfall zufällig im Urlaub ist.
Drittens werden nicht alle kritischen Systeme erfasst. Das ERP-System steht drin, aber die Schnittstelle zum Online-Shop fehlt. Oder das Kassensystem ist dokumentiert, das zentrale Ticketsystem nicht. Solche Lücken zeigen sich meist erst im Ernstfall.
Der vierte Punkt: Der Plan wurde nie getestet. Ein Notfallplan, der nur auf dem Papier existiert, vermittelt eine trügerische Sicherheit. Ohne regelmäßigen Testlauf weiß niemand, ob er tatsächlich funktioniert.
Und schließlich ist oft der externe IT-Dienstleister nicht eingebunden. Das ist besonders kritisch, wenn wesentliche Teile des IT-Betriebs ausgelagert sind. Der Dienstleister kennt die Infrastruktur meist besser als das Unternehmen selbst und gehört daher in den Plan.
Fazit
Ein IT-Notfallplan ist kein Dokument, das man einmal schreibt und dann in der Schublade ablegt. IT-Landschaften verändern sich, neue Systeme kommen hinzu, Verantwortlichkeiten wechseln. Ein Plan, der vor drei Jahren erstellt wurde und seitdem nicht aktualisiert ist, ist oft unbrauchbar. Planen Sie eine regelmäßige Überprüfung fest ein, mindestens einmal im Jahr oder nach größeren Veränderungen in der IT.
Grundlage jedes tragfähigen Notfallplans ist eine vollständige Analyse der bestehenden IT-Landschaft. Ohne dieses Fundament bleibt jede Planung Stückwerk. Erst wenn klar ist, welche Systeme es gibt, wie sie zusammenhängen und welche Risiken bestehen, lässt sich ein verlässlicher Plan ableiten.
Ein Beitrag vom Team
Bei GFAD begleiten wir Unternehmen beim Erstellen von IT-Notfallplänen. Wir arbeiten mit bewährten Vorlagen als Startpunkt und passen diese konsequent an die individuelle Situation unserer Kunden an. Wenn Sie den Eindruck haben, dass Ihr Unternehmen im Ernstfall nicht ausreichend vorbereitet ist, sprechen Sie uns gerne an.