HÖLL IT und Technik


Kevin Donnell
Aktualisiert: 7. August 2026

IT-Notfallplan: Was in den ersten 24 Stunden zählt

Das Wichtigste In Kürze

  • Eingrenzen, nicht reparieren – Reparaturversuche zerstören die Spuren zur Aufklärung
  • Backup nicht sofort einspielen: ist die Ursache noch aktiv, wird die Rücksicherung mitverschlüsselt
  • Zwei Fristen laufen parallel: 24 Stunden nach NIS2, 72 Stunden nach DSGVO
  • Beide Fristen beginnen mit der Kenntnis des Vorfalls, nicht mit seiner Aufklärung
  • Offline verfügbar – ein Plan auf dem verschlüsselten Server ist wertlos
Lesezeit: 8 Minuten

Ein IT-Notfallplan wird nicht gebraucht, weil ein Vorfall kompliziert ist. Er wird gebraucht, weil im Vorfall niemand mehr in der Lage ist, gute Entscheidungen zu treffen. Freitagabend, Systeme verschlüsselt, Geschäftsführung im Urlaub, der IT-Dienstleister im Wochenende – das ist der Moment, in dem Improvisation teuer wird.

Der Wert des Plans liegt deshalb nicht im Dokument. Er liegt darin, dass die Entscheidungen vorher getroffen wurden: Wer wird angerufen. Wer darf Systeme abschalten. Wer spricht mit Kunden. Wer meldet an Behörden – und innerhalb welcher Frist.

Dieser Artikel beschreibt, was in den ersten Stunden zählt, welche Meldefristen parallel laufen, und was in einen Notfallplan gehört, der im Ernstfall auch funktioniert.

Warum der Plan vorher existieren muss

Die Bitkom-Studie „Wirtschaftsschutz 2025" nennt eine Zahl, die die Wahrscheinlichkeitsfrage beendet: 87 Prozent der befragten Unternehmen waren in den vorangegangenen zwölf Monaten von Datendiebstahl, Spionage oder Sabotage betroffen, 34 Prozent von Ransomware. 15 Prozent haben Lösegeld gezahlt.

Der wichtigste Grund für einen Plan ist aber ein anderer: Im Vorfall ist die IT-Umgebung genau das, was nicht mehr funktioniert. Wenn Kontaktdaten, Verträge, Passwörter und Netzwerkdokumentation auf dem Server liegen, der gerade verschlüsselt wurde, ist der Notfallplan wertlos – selbst wenn er existiert. Ein Notfallplan muss offline und außerhalb der betroffenen Umgebung verfügbar sein. Ausgedruckt im Ordner, auf einem separaten Gerät, im Zweifel beim Dienstleister.

Die erste Stunde – und was Sie nicht tun sollten

Das erste Ziel ist Eingrenzung, nicht Reparatur. Reparaturversuche in der ersten Stunde zerstören regelmäßig genau die Informationen, die man später zur Aufklärung braucht.

Zuerst tun

  • Betroffene Systeme vom Netzwerk trennen – Kabel ziehen, WLAN deaktivieren
  • Uhrzeit, Beobachtungen und Maßnahmen schriftlich mitprotokollieren
  • Festlegen, wer ab jetzt entscheidet – eine Person
  • Fachliche Unterstützung anrufen, bevor eigene Reparaturversuche starten
  • Prüfen, ob personenbezogene Daten betroffen sein könnten

Nicht tun

  • Betroffene Systeme herunterfahren oder neu starten – das löscht flüchtige Spuren
  • Verschlüsselte Dateien löschen oder überschreiben
  • Backups einspielen, bevor die Ursache eingegrenzt ist
  • Lösegeld zahlen oder mit Angreifern verhandeln, ohne fachliche Begleitung
  • Intern breit informieren, bevor der Sachstand geklärt ist

Der Punkt „Backup nicht sofort einspielen" ist der, der am meisten Widerstand auslöst – und der wichtigste. Wenn die Ursache noch aktiv im Netz ist, wird die frische Rücksicherung mitverschlüsselt. Dann ist auch das Backup verloren.

Die ersten 24 Stunden im Ablauf

Zeitraum Was passiert Wer
0–1 Stunde Eingrenzen, Netz trennen, Protokoll beginnen, Entscheider festlegen, Hilfe rufen Wer den Vorfall entdeckt + benannter Entscheider
1–4 Stunden Umfang bestimmen: Welche Systeme, welche Daten, welcher Zeitpunkt? Betroffenheit personenbezogener Daten bewerten IT-Dienstleister, Incident Response
4–12 Stunden Meldewege prüfen und Meldungen vorbereiten, Kommunikation nach innen abstimmen, Notbetrieb organisieren Geschäftsführung, Datenschutzbeauftragter
12–24 Stunden Fristgerechte Meldungen abgeben, Wiederherstellung planen (nicht starten, bevor die Ursache geklärt ist) Geschäftsführung + Dienstleister

Zwei Meldefristen, die parallel laufen

Das ist der Teil, der in der Praxis am häufigsten übersehen wird: Bei einem Vorfall können zwei voneinander unabhängige Meldepflichten gleichzeitig greifen – an unterschiedliche Stellen, mit unterschiedlichen Fristen.

Regelung Frist An wen Wann relevant
NIS2 (NIS2UmsuCG) 24 Stunden Erstmeldung, 72 Stunden ausführliche Meldung, 30 Tage Abschlussmeldung BSI Nur für NIS2-betroffene Einrichtungen
DSGVO (Art. 33) 72 Stunden Zuständige Datenschutz-Aufsichtsbehörde Sobald personenbezogene Daten betroffen sind – größenunabhängig

Zwei Konsequenzen daraus. Erstens: Auch Unternehmen, die nicht unter NIS2 fallen, haben im Vorfall eine harte Frist – über die DSGVO. Zweitens: Beide Fristen beginnen mit der Kenntnis des Vorfalls, nicht mit seiner Aufklärung. Wer erst meldet, wenn der Sachverhalt vollständig geklärt ist, meldet zu spät. Eine Erstmeldung mit unvollständigem Bild ist ausdrücklich vorgesehen.

Was in den Notfallplan gehört

Notfallplan: Mindestinhalt

Menschen und Erreichbarkeit

Technische Grundlagen

Ablauf und Kommunikation

Der letzte Punkt entscheidet über den Wert des Ganzen. Ein Plan, den niemand gelesen hat, wird im Vorfall auch nicht gelesen. Ein einmaliges Durchsprechen von 30 Minuten im Jahr genügt – es geht nicht um eine Übung, sondern darum, dass die Beteiligten wissen, dass es den Plan gibt und wo er liegt.

Wer im Ernstfall hilft

Ein ernsthafter Sicherheitsvorfall ist keine Wartungsaufgabe. Er braucht Leute, die Spuren sichern, den Angriffsweg eingrenzen und eine Wiederherstellung planen können, ohne die Ursache mitzunehmen. Das ist eine eigene Disziplin – Incident Response.

Höll ist über die Zugehörigkeit zur Compass Gruppe Mitglied im Deutschen Incident Response Team (DIRT.). Für Kunden bedeutet das: Im Vorfall steht nicht nur der reguläre Support zur Verfügung, sondern ein Zugang zu spezialisierten Kräften – ohne dass im Ernstfall erst ein Dienstleister gesucht werden muss.

Wer den Stand seiner Vorbereitung strukturiert erfassen will, findet im CyberRisikoCheck nach DIN SPEC 27076 den passenden Rahmen: Notfallkontakte und Zuständigkeiten sind dort ausdrücklich Teil der geprüften Anforderungen.

Die häufigsten Fehler

  • Der Plan liegt digital – im betroffenen System. Der Klassiker. Damit ist er im einzigen Moment nicht verfügbar, in dem er gebraucht wird.
  • Keine benannte Person, nur eine Rolle. „Die Geschäftsführung entscheidet" reicht nicht, wenn die Geschäftsführung aus drei Personen besteht und zwei im Ausland sind.
  • Backups vorhanden, Rücksicherung nie getestet. Der Vorfall ist der schlechteste Zeitpunkt, das erste Mal zurückzuspielen.
  • Meldefristen nicht bedacht. Die DSGVO-Frist von 72 Stunden gilt unabhängig von der Unternehmensgröße – vielen ist das im Vorfall nicht bewusst.
  • Zu schnelle Entwarnung. Systeme wieder freizugeben, bevor der Zugangsweg geschlossen ist, führt regelmäßig zum zweiten Vorfall innerhalb weniger Wochen.

Fazit

Der IT-Notfallplan ist kein Sicherheitsprodukt, sondern eine Sammlung vorab getroffener Entscheidungen. Entscheidend sind vier Dinge: Er ist offline verfügbar, er benennt Personen statt Rollen, er kennt beide Meldefristen – 24 Stunden nach NIS2 und 72 Stunden nach DSGVO – und er wurde mindestens einmal durchgesprochen.

Höll unterstützt Unternehmen in Karlsruhe, Baden-Baden, Rastatt und Offenburg bei IT-Krisenmanagement und Notfallvorsorge – von der Erstellung des Notfallplans bis zur Unterstützung im laufenden Vorfall. Im Ernstfall fahren eigene Techniker raus, keine Subunternehmer: mehr dazu beim IT-Dienstleister für Karlsruhe und Mittelbaden.

Häufige Fragen

Was gehört in einen IT-Notfallplan?

Benannte Entscheider mit Vertretung und privaten Rufnummern, Kontakte zu IT-Dienstleister und Datenschutzbeauftragtem, Versicherungsdaten, offline verfügbare Netzwerkdokumentation, Backup-Informationen, Zugangsdaten für Meldeportale sowie eine einseitige Erstmaßnahmen-Anweisung.

Was sollte man bei einem Ransomware-Angriff zuerst tun?

Betroffene Systeme vom Netzwerk trennen, ab diesem Zeitpunkt schriftlich protokollieren, einen Entscheider festlegen und fachliche Unterstützung anrufen – bevor eigene Reparaturversuche starten.

Warum sollte man betroffene Systeme nicht herunterfahren?

Ein Neustart oder Herunterfahren löscht flüchtige Spuren im Arbeitsspeicher, die zur Aufklärung des Angriffswegs gebraucht werden. Trennen vom Netzwerk grenzt ein, ohne diese Informationen zu zerstören.

Welche Meldefristen gelten bei einem IT-Vorfall?

Für NIS2-betroffene Einrichtungen gegenüber dem BSI: 24 Stunden Erstmeldung, 72 Stunden ausführliche Meldung, 30 Tage Abschlussmeldung. Unabhängig davon gilt nach Art. 33 DSGVO eine Frist von 72 Stunden gegenüber der Datenschutz-Aufsichtsbehörde, sobald personenbezogene Daten betroffen sind.

Gilt die DSGVO-Meldefrist auch für kleine Unternehmen?

Ja. Die 72-Stunden-Frist nach Art. 33 DSGVO ist größenunabhängig und greift, sobald personenbezogene Daten betroffen sein können.

Sollte man Lösegeld zahlen?

Nicht ohne fachliche und rechtliche Begleitung. Eine Zahlung garantiert keine Wiederherstellung und kann eigene rechtliche Folgen haben. Laut Bitkom-Studie „Wirtschaftsschutz 2025“ haben 15 Prozent der betroffenen Unternehmen gezahlt.