- Was ist ein IT-Notfallplan?
- Notfallplan
- Inhalte eines IT-Notfallhandbuchs
- Kritikalität der Geschäftsprozesse
- Die ersten 60 Minuten nach einem Angriff
- Meldepflichten & Fristen
- In 6 Schritten zum IT-Notfallplan
- Muster & kostenloser Download
- Typische Fehler aus der Praxis
- Notfallübungen richtig durchführen
- IT-Notfallplan: Fragen & Antworten
- Unterstützung aus dem kiwiko Netzwerk
Ein IT-Notfallplan ist das verbindliche Dokument, in dem eine Organisation festlegt, wie sie auf schwerwiegende Störungen ihrer IT reagiert: von Cyberangriffen über Ausfälle zentraler Systeme bis zum Datenverlust. Er beantwortet im Ernstfall drei Fragen ohne Diskussion: Wer entscheidet, wer wird alarmiert und in welcher Reihenfolge laufen Geschäftsprozesse wieder an. Damit ist der Notfallplan kein IT-Dokument, sondern ein Steuerungsinstrument der Geschäftsführung.
In den Projekten unserer Partner im kiwiko Netzwerk sehen wir regelmäßig dasselbe Bild: Backups sind vorhanden, Firewalls gepflegt, Verantwortlichkeiten aber nirgends schriftlich fixiert. Genau diese Lücke kostet im Sicherheitsvorfall die teuersten Stunden. Dieser Beitrag zeigt, wie ein belastbarer IT-Notfallplan für KMU und Mittelstand aufgebaut ist, welche Inhalte hineingehören und wie die Umsetzung realistisch gelingt.
Kurzdefinition: Was ist ein IT-Notfallplan?
Ein IT-Notfallplan beschreibt die Notfallorganisation, die Sofortmaßnahmen und die Wiederanlaufpläne eines Unternehmens für den Fall, dass kritische IT-Systeme, Anwendungen oder Daten nicht mehr verfügbar sind. Er regelt Alarmierung, Entscheidungswege, Kommunikation und Wiederherstellung – mit dem Ziel, Ausfallzeiten und Schaden am Geschäftsbetrieb zu minimieren.
Notfallplan, Notfallhandbuch, Notfallkonzept: die Begriffe sauber getrennt
Viele Vorlagen werfen die Begriffe durcheinander. Für die praktische Arbeit lohnt sich eine klare Trennung, weil die Dokumente unterschiedliche Adressaten und unterschiedliche Aktualisierungszyklen haben.
| Dokument | Inhalt | Adressat |
|---|---|---|
| Notfallkonzept | Strategie, Risikobewertung, Kritikalität der Geschäftsprozesse, Zielvorgaben | Geschäftsführung, Risikomanagement |
| Notfallhandbuch | Gesamtdokumentation aus Notfallorganisation, Szenarien und Anhängen | Notfallstab, IT-Leitung |
| Notfallplan / Wiederanlaufplan | Konkrete Anweisungen je Szenario und System, Schritt für Schritt | Notfallteam, Dienstleister |
| Notfallkarte | Eine Seite: Meldewege, Kontaktdaten, Verhalten in den ersten Minuten | alle Mitarbeiter |
Das Notfallhandbuch ist dabei die Klammer. Es folgt in der Struktur sinnvollerweise dem BSI-Standard 200-4 zum Notfallmanagement und dem IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik – auch dann, wenn keine Zertifizierung angestrebt wird. Der Standard liefert eine erprobte Gliederung, die Prüfern, Versicherern und Aufsichtsbehörden vertraut ist.
Diese Inhalte gehören in ein belastbares IT-Notfallhandbuch
Ein Plan, der nur aus guten Absichten besteht, hilft um drei Uhr nachts niemandem. Die folgenden zwei Blöcke bilden das Minimum, das unsere Partner in Projekten mit Mittelständlern umsetzen.
Teil A: Notfallorganisation
- Zusammensetzung und Befugnisse des Notfallstabs inklusive benannter Vertretung für Urlaub und Krankheit
- Alarmierungsketten und Eskalationsstufen mit klaren Kriterien, ab wann aus einer Störung ein Notfall wird
- Meldewege und Erreichbarkeiten außerhalb der Geschäftszeiten – bewusst unabhängig von E-Mail und Telefonanlage
- Kontaktlisten für interne Rollen, externe Dienstleister, Datenschutzbeauftragte, Versicherer und Behörden
- Regeln für die interne und externe Kommunikation, inklusive vorbereiteter Textbausteine für Kunden und Lieferanten
- Notfallkarte am Arbeitsplatz: Was tun bei Verdacht auf einen Cybervorfall, was auf keinen Fall
Teil B: Technische Wiederanlaufpläne
- Inventar aller Systeme, Anwendungen und Abhängigkeiten – inklusive Cloud-Diensten und Standorten
- Kritikalität je Geschäftsprozess mit definierten Wiederanlaufzeiten und tolerierbarem Datenverlust
- Datensicherung: Speicherorte, Offline-Kopie, Prüfprotokolle und dokumentierte Restore-Tests
- Reihenfolge des Wiederanlaufs vom Verzeichnisdienst über die Fachanwendungen bis zu den Arbeitsplätzen
- Notbetrieb und Arbeitsmodi: Wie läuft Auftragsannahme, Versand oder Produktion ohne IT weiter
- Verfahren zur Wiederherstellung von Daten, wenn Backups beschädigt, verschlüsselt oder unvollständig sind
Ergänzt wird das Handbuch um einen Anhang mit Netzplänen, Lizenzinformationen, Zugangswegen zum Serverraum und Verträgen mit Dienstleistern. Diese Dokumentation muss auch dann verfügbar sein, wenn das Dateisystem verschlüsselt ist – ausgedruckt oder auf einem getrennt gelagerten Medium.
Kritikalität zuerst: ohne Business Impact Analyse kein Plan
Der häufigste Grund für unbrauchbare Notfallpläne ist eine fehlende Priorisierung. Wenn alles wichtig ist, ist nichts wichtig. Deshalb steht am Anfang die Frage, welche Geschäftsprozesse das Unternehmen wie lange ohne IT durchhält – und erst danach die Frage nach der Technik.
| Stufe | Geschäftsprozess (Beispiel) | Maximale Ausfallzeit | Konsequenz für den Wiederanlauf |
|---|---|---|---|
| 1 – geschäftskritisch | Auftragsabwicklung, ERP, Produktionssteuerung | bis 4 Stunden | Redundanz, getestete Sofortmaßnahmen, Notbetrieb definiert |
| 2 – wichtig | E-Mail, Warenwirtschaft, Zeiterfassung | bis 24 Stunden | Wiederanlaufplan dokumentiert, Backup tagesaktuell |
| 3 – unterstützend | Dateiablagen, Intranet, Reporting | bis 72 Stunden | Standardwiederherstellung aus der Datensicherung |
| 4 – unkritisch | Testumgebungen, Archive | über 72 Stunden | Wiederanlauf nach Abschluss der Stufen 1 bis 3 |
Diese Einstufung ist keine IT-Entscheidung. Sie gehört auf den Tisch der Geschäftsführung, weil sie unmittelbar Investitionen in Infrastruktur, Lizenzen und Personal auslöst.
Die ersten 60 Minuten nach einem Cyberangriff
Bei Ransomware entscheidet die erste Stunde über Schadenshöhe und Beweislage. Wer erst dann anfängt zu überlegen, verliert genau das Zeitfenster, in dem sich die Ausbreitung noch stoppen lässt. Deshalb steht dieser Ablauf in jedem Notfallplan unserer Partner ganz vorn:
- Isolieren statt ausschalten: betroffene Systeme vom Netz trennen, aber nicht herunterfahren – flüchtige Spuren im Arbeitsspeicher bleiben so für die forensische Analyse erhalten.
- Notfallstab alarmieren und Eskalationsstufe festlegen. Ab hier gilt die im Plan definierte Entscheidungshierarchie, nicht das Organigramm des Normalbetriebs.
- Backups physisch trennen, bevor die Verschlüsselung sie erreicht. Offline-Kopien sind in vielen Vorfällen der einzige verbliebene Rettungsanker.
- Beweissicherung starten: Logdaten, Zeitpunkte, Auffälligkeiten und alle eigenen Maßnahmen protokollieren. Diese Dokumentation brauchen später Versicherer, Aufsichtsbehörden und Ermittler.
- Externe Unterstützung hinzuziehen. Für die Analyse eines aktiven Angriffs braucht es Spezialisten, die rund um die Uhr für Sicherheitsvorfälle erreichbar sind – die Rufnummer gehört auf die Notfallkarte, nicht in eine Suchmaschine im Moment der Krise.
- Kommunikation übernehmen: Mitarbeiter informieren, Gerüchte vermeiden, eine Sprachregelung für Kunden und Lieferanten festlegen.
Meldepflichten: Fristen laufen ab dem ersten Verdacht
Ein Sicherheitsvorfall ist selten nur ein technisches Ereignis. Sobald personenbezogene Daten betroffen sein können, greift Artikel 33 DSGVO mit einer Frist von 72 Stunden gegenüber der zuständigen Aufsichtsbehörde. Je nach Branche und Unternehmensgröße kommen weitere Meldepflichten hinzu, etwa aus der NIS2-Regulierung oder aus Verträgen mit Auftraggebern und Cyberversicherern.
Praktisch bedeutet das: Der Notfallplan enthält eine Übersicht, wer welche Meldung auslöst, welche Angaben mindestens erforderlich sind und wo die Vorlagen dafür liegen. Anlaufstellen wie das BSI, die Allianz für Cybersicherheit, die zentrale Ansprechstelle Cybercrime der Polizei und die regionale IHK gehören mit Kontaktdaten in den Anhang.
In sechs Schritten zum eigenen IT-Notfallplan
- Auftrag der Geschäftsführung einholen. Ohne Mandat, Budget und benannten Verantwortlichen bleibt jedes Notfallmanagement Stückwerk.
- Geschäftsprozesse bewerten. Kritikalität, maximale Ausfallzeit und tolerierbarer Datenverlust je Prozess festlegen.
- Abhängigkeiten aufnehmen. Systeme, Anwendungen, Schnittstellen, Cloud-Dienste und externe Dienstleister vollständig dokumentieren.
- Szenarien ausarbeiten. Für Cyberangriff, Ausfall des Serverraums, Verlust eines Standorts und Ausfall eines Dienstleisters je einen Wiederanlaufplan schreiben.
- Notfallorganisation aufsetzen. Notfallstab benennen, Alarmierung testen, Notfallkarten verteilen, Mitarbeiter schulen.
- Üben und aktualisieren. Mindestens jährlich eine Notfallübung, dazu Aktualisierung bei jeder relevanten Änderung an der Infrastruktur.
Kostenloser Download: Muster für einen IT-Notfallplan
Als Einstieg in die eigene Dokumentation lässt sich ein Muster-PDF für einen IT-Notfallplan herunterladen. Die Vorlage ersetzt keine Analyse der eigenen Prozesse, liefert aber eine tragfähige Gliederung für das erste Notfallhandbuch.
Typische Fehler aus der Projektpraxis
- Der Notfallplan liegt ausschließlich auf dem Fileserver, der im Ernstfall verschlüsselt ist.
- Kontaktlisten sind zwei Jahre alt; benannte Personen arbeiten längst nicht mehr im Unternehmen.
- Backups laufen, wurden aber nie vollständig zurückgespielt – der Wiederanlauf scheitert an ungetesteten Annahmen.
- Es gibt keine Eskalationskriterien, also meldet niemand eine Störung als Notfall.
- Der Plan beschreibt Technik, aber keinen Notbetrieb für Vertrieb, Produktion und Versand.
- Verantwortlichkeiten sind an Abteilungen vergeben statt an Personen mit Vertretungsregelung.
Übungen entscheiden über die Qualität des Plans
Ein Notfallplan ist erst dann belastbar, wenn er unter Zeitdruck funktioniert hat. Der Einstieg gelingt mit einer Tischübung von zwei Stunden: Ein Szenario wird vorgelesen, der Notfallstab arbeitet mit den vorhandenen Dokumenten, jede Lücke wird protokolliert. Aus der Erfahrung unserer Partner entstehen dabei im ersten Durchlauf regelmäßig zwanzig bis dreißig konkrete Korrekturen – von falschen Telefonnummern bis zu fehlenden Administratorzugängen.
Im nächsten Schritt folgt der technische Test: die Wiederherstellung eines geschäftskritischen Systems aus der Datensicherung, mit gestoppter Zeit und dokumentiertem Ergebnis. Erst dieser Nachweis macht aus einer angenommenen Wiederanlaufzeit eine belastbare Zahl.
Häufige Fragen zum IT-Notfallplan
Entscheidend ist nicht der Umfang, sondern die Anwendbarkeit unter Druck. Für viele mittelständische Unternehmen genügen 15 bis 30 Seiten: Notfallorganisation, drei bis fünf Szenarien mit Wiederanlaufplänen sowie ein Anhang mit Kontaktdaten, Netzplänen und Zugangswegen. Wichtiger als Vollständigkeit ist, dass die Dokumentation aktuell und auch ohne funktionierende IT verfügbar ist.
Die Verantwortung liegt bei der Geschäftsführung, weil Entscheidungen über Kritikalität, Budget und Notbetrieb unternehmerische Entscheidungen sind. Die Erstellung und Pflege übernimmt in der Regel die IT-Leitung gemeinsam mit einem externen Dienstleister; die Umsetzung im Ernstfall verantwortet der benannte Notfallstab.
Mindestens einmal jährlich sowie zusätzlich anlassbezogen: bei Personalwechseln in Schlüsselrollen, neuen Anwendungen, Standortveränderungen, Dienstleisterwechseln oder nach jedem realen Vorfall. Kontaktlisten und Erreichbarkeiten sollten quartalsweise geprüft werden, da sie am schnellsten veralten.
Eine Vorlage ist ein guter Startpunkt für die Struktur, ersetzt aber keine Analyse der eigenen Geschäftsprozesse und Abhängigkeiten. Ohne unternehmensspezifische Kritikalitätsbewertung, echte Kontaktdaten und getestete Wiederanlaufpläne bleibt sie ein Dokument ohne Wirkung.
Der Aufwand richtet sich nach Anzahl der Standorte, Systeme und kritischen Prozesse. Für ein typisches mittelständisches Unternehmen liegt der Erstaufwand bei wenigen Beratungstagen inklusive Workshop, Dokumentation und erster Tischübung. Gemessen an den Kosten eines einzigen Ausfalltages ist das in nahezu allen Fällen die günstigere Variante.
Der Notfallplan betrachtet die gesamte Organisation: Alarmierung, Entscheidungswege, Kommunikation und Notbetrieb der Geschäftsprozesse. Der Disaster Recovery Plan ist ein technischer Teilbereich davon und beschreibt konkret die Wiederherstellung von Systemen, Anwendungen und Daten.
Unterstützung aus dem kiwiko Netzwerk
Die Partner im kiwiko Netzwerk sind auf IT-Sicherheit und Notfallmanagement im Mittelstand spezialisiert. Sie begleiten die Risikobewertung, erstellen das Notfallhandbuch gemeinsam mit Ihrer IT, moderieren die erste Notfallübung und prüfen die Wiederanlaufpläne im praktischen Test. Der Vorteil eines Netzwerks: regionale Ansprechpartner vor Ort, im Ernstfall ergänzt um spezialisierte Kompetenz für Forensik, Beweissicherung und Datenrettung.
Wer heute beginnt, hat den Plan vor dem Vorfall. Alle anderen schreiben ihn währenddessen.
