Dieser Leitfaden gibt Ihnen eine Gliederung, die Sie direkt übernehmen können, erklärt Rollen und Eskalation und zeigt, worauf Sie in Produktionsumgebungen achten. Die Beispiele sind erfunden.
Was Gesetz und Standards verlangen
- BSIG: § 30 Abs. 2 Nr. 2 BSIG nennt die Bewältigung von Sicherheitsvorfällen als Mindestmaßnahme für wichtige und besonders wichtige Einrichtungen. Grundlage ist Art. 21 Abs. 2 lit. b NIS2-Richtlinie.
- Durchführungsverordnung (EU) 2024/2690: Für bestimmte digitale Dienste, etwa Cloud- und Rechenzentrumsanbieter oder Managed Service Provider, wird sie konkret. Nach Anhang Nr. 3.1 braucht es ein Konzept mit Rollen, Verantwortlichkeiten und Verfahren für Erkennung, Analyse, Eindämmung, Wiederherstellung, Dokumentation und Meldung. Nr. 3.1.2 nennt ausdrücklich Kommunikationspläne für Eskalation und Meldung, Eskalationsschemata, Kontaktlisten und Vorlagen. Für alle anderen Einrichtungen ist das ein guter Maßstab.
- Meldepflichten: § 32 BSIG verlangt bei erheblichen Sicherheitsvorfällen eine frühe Erstmeldung binnen 24 Stunden nach Kenntnis, eine Meldung binnen 72 Stunden und eine Abschlussmeldung spätestens einen Monat nach der Meldung. Hersteller melden nach Art. 14 CRA, Verantwortliche Datenpannen nach Art. 33 DSGVO. Ihr Plan muss diese Wege enthalten.
- BSI und Normen: Der IT-Grundschutz-Baustein DER.2.1 „Behandlung von Sicherheitsvorfällen“ beschreibt das Vorgehen aus Sicht des BSI. ISO/IEC 27001 führt im Anhang A die Controls 5.24 bis 5.28, von der Planung bis zur Sicherung von Beweisen.
Die sechs Phasen
Die Einteilung in Phasen ist in der Praxis verbreitet; sie geht auf die NIST-Publikation SP 800-61 Rev. 2 zurück, die dieselben Schritte in vier Phasen zusammenfasste (die Revision 3 von April 2025 ordnet die Aufgaben den Funktionen des NIST Cybersecurity Framework 2.0 zu). Der Sache nach findet sie sich auch in der Durchführungsverordnung (EU) 2024/2690, Anhang Nr. 3.5 und 3.6.
- Vorbereitung. Rollen, Kontaktlisten, Zugänge für den Notfall, Logging, Backups und Übungen stehen, bevor etwas passiert.
- Erkennung und Analyse. Eine Meldung oder ein Alarm wird bewertet: Ist es ein Vorfall, wie schwer ist er, was ist betroffen? Ab hier läuft die Uhr für mögliche Meldefristen.
- Eindämmung. Die Ausbreitung wird gestoppt, etwa durch Trennen von Netzsegmenten, Sperren von Konten oder Abschalten von Fernzugängen. Beweise werden gesichert, bevor Systeme neu aufgesetzt werden.
- Beseitigung. Die Ursache wird entfernt: Schadsoftware, kompromittierte Zugangsdaten, offene Schwachstellen.
- Wiederherstellung. Systeme gehen geprüft und schrittweise wieder in Betrieb, aus sauberen Backups und unter Beobachtung.
- Nachbereitung (Lessons Learned). Was lief gut, was schlecht, was war die Ursache, was ändern wir? Die Ergebnisse fließen in Plan, Risikobewertung und Maßnahmen.
Gliederung für Ihren Plan
Die folgende Gliederung hat sich bewährt. Halten Sie den Hauptteil kurz und legen Sie Details in Anhänge, damit im Ernstfall niemand blättern muss.
| Kapitel | Inhalt | Wer pflegt |
|---|---|---|
| 1. Zweck und Geltungsbereich | Standorte, Systeme, IT und OT, Bezug zum Notfallmanagement | ISB |
| 2. Begriffe und Schweregrade | Was ist ein Ereignis, was ein Vorfall; drei bis vier Stufen mit Beispielen | ISB |
| 3. Rollen und Vertretungen | Incident Manager, technisches Team, Geschäftsleitung, Kommunikation, Datenschutz | ISB mit Geschäftsleitung |
| 4. Eskalation | Wer entscheidet ab welcher Stufe, wann der Krisenstab übernimmt | ISB |
| 5. Ablauf je Phase | Erste Schritte, Eindämmung, Beseitigung, Wiederherstellung, Nachbereitung | IT und OT |
| 6. Meldungen | NIS2, CRA, DSGVO, Versicherung, Kunden; wer prüft, wer meldet | ISB und Datenschutz |
| 7. Kommunikation | Intern, Kunden, Lieferanten, Presse; Freigabe von Texten | Kommunikation |
| 8. Dokumentation und Beweise | Protokoll mit Uhrzeit, Sicherung von Logs und Datenträgern | IT und OT |
| Anhang A | Kontaktliste intern und extern | ISB, quartalsweise |
| Anhang B | Kurzanleitungen für typische Szenarien | IT und OT |
| Anhang C | Vorlagen: Erstbewertung, Lageprotokoll, Meldeinhalte | ISB |
Rollen und Eskalation
- Incident Manager: führt den Vorfall, hält das Protokoll und trifft operative Entscheidungen. Eine Person mit Vertretung, nicht „die IT“.
- Technisches Team: IT, OT und, falls vorhanden, ein externer Dienstleister für Incident Response oder Forensik.
- Geschäftsleitung: entscheidet über Abschaltungen mit Auswirkung auf den Betrieb, über Meldungen und über externe Kommunikation.
- Datenschutz: prüft, ob personenbezogene Daten betroffen sind.
- Kommunikation: gibt Texte für Mitarbeitende, Kunden und Presse frei.
Legen Sie die Eskalation über Schweregrade fest. Ein Beispiel: Stufe 1 bearbeitet das technische Team allein, ab Stufe 2 ist der Incident Manager informiert, ab Stufe 3 die Geschäftsleitung, ab Stufe 4 tritt der Krisenstab zusammen. Schreiben Sie dazu, wer außerhalb der Geschäftszeiten erreichbar ist und wer entscheidet, wenn niemand erreichbar ist.
Kontaktlisten, die im Ernstfall funktionieren
- Intern: Incident Manager, Vertretungen, Geschäftsleitung, IT, OT, Datenschutz, Kommunikation, mit Mobilnummer.
- Extern: IT-Dienstleister, Maschinen- und Anlagenlieferanten, Dienstleister für Forensik, Cyberversicherung, Rechtsberatung.
- Behörden: Meldestelle nach § 32 BSIG, Datenschutzaufsicht, Polizei. Für die Polizei gibt es in den Ländern Zentrale Ansprechstellen Cybercrime (ZAC).
- Offline verfügbar: Ein Ausdruck liegt an zwei Stellen. Wenn E-Mail und Telefonanlage ausfallen, hilft keine Liste im Netz.
- Geprüft: Rufen Sie die Nummern mindestens einmal im Jahr an. Veraltete Kontakte sind der häufigste Fehler in Übungen.
Besonderheiten in der OT
In der Produktion gelten andere Prioritäten als in der Büro-IT. Der Plan muss das ausdrücklich regeln.
- Sicherheit vor Verfügbarkeit vor Vertraulichkeit: Menschen und Anlage zuerst. Ein Herunterfahren kann gefährlicher sein als ein kontrollierter Weiterbetrieb.
- Abschalten nur abgestimmt: Netztrennungen und Abschaltungen entscheidet der Betrieb mit. Halten Sie vorab fest, wo Sie trennen können, ohne Prozesse zu gefährden, typischerweise an den Übergängen zwischen Zonen.
- Inselbetrieb planen: Kann die Linie ohne MES, ohne zentrale Benutzerverwaltung und ohne Fernzugang weiterlaufen?
- Fernzugänge der Lieferanten: Wie werden sie sofort gesperrt, und wer gibt sie wieder frei?
- Wiederherstellung: Steuerungsprogramme, Projektdateien und Konfigurationen brauchen eigene, geprüfte Backups. Halten Sie fest, wer sie einspielen darf und ob der Hersteller dabei sein muss.
- Beweise: Viele Steuerungen speichern kaum Logs. Ein passiver Netzwerkmitschnitt an den Zonengrenzen hilft bei der Analyse.
Beispiel aus der Industrie
Das Beispiel ist erfunden. Ein Kunststoffverarbeiter mit drei Linien bekommt in der Nacht einen Alarm seines IT-Dienstleisters: Auf dem Dateiserver werden Dateien verschlüsselt.
- Erkennung: Die Rufbereitschaft stuft den Vorfall um 02:30 Uhr als Stufe 4 ein und ruft den Incident Manager an.
- Eindämmung: Nach Plan wird die Verbindung zwischen Büro-IT und Produktionsnetz an der Firewall getrennt. Die Linien laufen im Inselbetrieb mit lokal gespeicherten Rezepturen weiter.
- Meldung: Die Geschäftsleitung bewertet den Vorfall am Morgen als erheblich. Die frühe Erstmeldung geht innerhalb von 24 Stunden an die Meldestelle, die Versicherung ist parallel informiert.
- Wiederherstellung: Der Dateiserver kommt aus einem unveränderbaren Backup zurück. Die Verbindung zur Produktion wird erst nach einer Prüfung der Engineering-Stationen wieder geöffnet.
- Nachbereitung: Die Mobilnummer des Maschinenlieferanten war veraltet, ein Fernzugang lief über ein vergessenes Modem. Beides wird zur Maßnahme mit Termin und verantwortlicher Person.
Checkliste
- Geltungsbereich umfasst IT und OT.
- Schweregrade sind mit Beispielen beschrieben.
- Jede Rolle hat eine Person und eine Vertretung.
- Die Eskalation regelt auch Nächte, Wochenenden und Urlaub.
- Meldewege für NIS2, CRA und DSGVO sind mit zuständiger Person hinterlegt.
- Kontaktlisten sind aktuell, geprüft und offline verfügbar.
- Trennpunkte und Inselbetrieb der OT sind mit dem Betrieb abgestimmt.
- Backups der Steuerungen und Konfigurationen sind vorhanden und getestet.
- Der Plan ist mit dem Notfallmanagement abgestimmt.
- Mindestens eine Übung im Jahr, Ergebnisse als Maßnahmen erfasst.
Incident-Response in Complass
Ein Plan in der Dateiablage und Vorfälle in E-Mail-Verläufen: Im Ernstfall sucht dann jeder an einer anderen Stelle. In Complass liegt alles an einem Ort:
- Vorfall erfassen: Erheblicher Sicherheitsvorfall nach § 32 BSIG, Meldungen nach Art. 14 CRA, Datenpannen nach Art. 33 DSGVO und interne Vorfälle. Angeboten wird, was zu Ihren Modulen passt.
- Meldepflicht geführt prüfen: Prüffragen aus dem Gesetzestext führen zur Entscheidung, mit Pflichtbegründung.
- Fristen im Blick: Meldestufen mit berechneter Frist, Erinnerung per E-Mail an die Verantwortlichen. Die Meldung selbst geben Sie im Meldeportal der Behörde ab.
- Alles am Vorfall: Betroffene Assets, Kommentare, Nachweisdateien, Zeitleiste, Maßnahmen direkt in den Maßnahmenplan und ein PDF-Bericht.
- Lessons Learned: Nach dem Abschluss erfassen Sie, was gut und was schlecht lief, die Grundursache und Verbesserungen.
- Krisenstab und Kontakte: Mit dem Notfallmanagement pflegen Sie Krisenstab, Notfallteams und externe Kontakte mit Vertretung und Erreichbarkeit, zusammengefasst im Notfallhandbuch als PDF oder Word-Datei zum Ausdrucken.

Häufige Fragen
Wie lang sollte ein Incident-Response-Plan sein?
So kurz wie möglich. Der Hauptteil sollte sich in wenigen Minuten lesen lassen. Details wie Kurzanleitungen und Vorlagen gehören in Anhänge.
Brauchen wir einen eigenen Plan für die OT?
Nicht unbedingt einen eigenen, aber eigene Abschnitte. Trennpunkte, Inselbetrieb, Fernzugänge der Lieferanten und die Wiederherstellung von Steuerungen sind in der OT anders geregelt als in der Büro-IT.
Wie hängen Incident Response und Notfallmanagement zusammen?
Incident Response bewältigt den Sicherheitsvorfall. Das Notfallmanagement hält den Betrieb aufrecht, wenn Prozesse ausfallen. Ab einer festgelegten Schwelle übernimmt der Krisenstab. Die Durchführungsverordnung (EU) 2024/2690 verlangt, dass beide Pläne im Einklang stehen.
Wie oft sollten wir den Plan üben?
Eine feste Zahl nennt das BSIG nicht. Bewährt ist mindestens eine Übung im Jahr, etwa eine Planbesprechung am Tisch, und eine Überprüfung nach jedem größeren Vorfall oder jeder wesentlichen Änderung.
Wer muss den Plan freigeben?
Die Geschäftsleitung. Nach § 38 Abs. 1 BSIG muss sie die Maßnahmen nach § 30 BSIG umsetzen und überwachen, dazu gehört die Bewältigung von Sicherheitsvorfällen.
In einer Demo zeigen wir Ihnen an der Demo-Firma, wie ein Vorfall vom ersten Alarm bis zur Nachbereitung in Complass läuft.
Weiterlesen
- Leitfaden „NIS2-Meldepflicht in der Praxis“
- Leitfaden „CRA-Meldepflicht für Hersteller nach Art. 14“
- Leitfaden „Notfallmanagement nach NIS2: BIA, Pläne und Übungen“
- Whitepaper Meldepflichten
- Incident-Management in Complass
- NIS2 in Complass
Keine Rechtsberatung. Dieser Leitfaden gibt einen allgemeinen Überblick und ersetzt nicht die Prüfung im Einzelfall. Maßgeblich sind der aktuelle Wortlaut des BSIG, der NIS2-Richtlinie, der Durchführungsverordnung (EU) 2024/2690, des CRA und der DSGVO, die Veröffentlichungen des BSI und Ihre lizenzierten Ausgaben der Normen. Stand: November 2026.
