Ein Incident-Response-Plan im Ordner ist schnell erstellt. Er hilft im Ernstfall nichts, wenn niemand weiß, wer ihn wann öffnet. Genau das ist der Unterschied, den ein NIS-2-Auditor prüft: nicht ob ein Plan existiert, sondern ob er im Ernstfall tatsächlich funktioniert.
Für Mittelständler, die zum ersten Mal unter die NIS-2-Meldepflicht fallen, ist das eine unangenehme Überraschung. Ein Dokument reicht als Nachweis nicht, wenn niemand die Fristen aus Artikel 23 im Kopf hat oder wenn die Meldung an die zuständige Behörde noch nie geprobt wurde.
Executive Summary
1. Ausgangslage: der Plan existiert, die Übung fehlt
Die meisten Unternehmen, die wir im Rahmen von Audit-Vorbereitungen sehen, haben irgendeine Form von Incident-Response-Dokument. Häufig stammt es aus einem ISO-27001-Projekt oder wurde von einem IT-Dienstleister mitgeliefert. Das Problem liegt selten im Text, sondern in der Ausführung: Wer meldet an wen, in welcher Reihenfolge, und woher weiß die verantwortliche Person, dass die Uhr bereits läuft?
2. Wer ist betroffen?
- Betreiber wesentlicher und wichtiger Einrichtungen im Sinne der NIS-2-Richtlinie
- IT-Sicherheitsbeauftragte und Incident-Response-Teams
- Geschäftsführung, die nach Artikel 21 persönlich für die Umsetzung angemessener Maßnahmen haftet
- Auditoren und Zertifizierer, die Nachweise über gelebte Prozesse einfordern
3. Wie hoch ist die Priorität?
Sofort. Die Meldefristen aus Artikel 23 der NIS-2-Richtlinie beginnen mit Kenntnis des Vorfalls, nicht mit Abschluss der internen Klärung. Wer diese Frist erst im Ernstfall zum ersten Mal nachliest, hat sie in der Praxis bereits verpasst.
4. Warum ist das wichtig?
Ein Auditor prüft nicht die Existenz eines Dokuments, sondern Belege für gelebte Praxis: Schulungsnachweise, Protokolle einer Übung, eine klar dokumentierte Eskalationskette mit Namen statt Rollenbezeichnungen. Fehlen diese Nachweise, wird der Incident-Response-Prozess als nicht wirksam bewertet, unabhängig davon, wie gut der Text selbst formuliert ist.
Das eigentliche Risiko liegt selten in der Meldung an sich, sondern in der verlorenen Zeit davor: Wenn niemand weiß, wer die Behörde kontaktiert, vergehen oft mehrere Stunden allein für die interne Abstimmung, bevor die Uhr aus Artikel 23 überhaupt bewusst wahrgenommen wird.
5. Was muss konkret getan werden?
- ✓ Eskalationskette mit konkreten Namen und Erreichbarkeiten dokumentieren, nicht nur mit Rollen
- ✓ Eine Meldeübung mit realistischem Szenario mindestens einmal jährlich durchführen
- ✓ Kontaktdaten der zuständigen NIS-2-Meldestelle vorab hinterlegen, nicht erst im Ernstfall suchen
- ✓ Vorlage für die 24-Stunden-Frühwarnung vorbereiten, damit im Ernstfall nur noch Fakten eingetragen werden
- ✓ Schulungsnachweise für alle Beteiligten der Eskalationskette führen
BAM Core
Incident-Response-Prozesse als Teil des Compliance-Datenmodells
NIS-2-Meldefristen, Eskalationsketten und Nachweispflichten strukturiert statt als Fließtext im Ordner.
Executable Compliance ansehen →6. Welche Dokumente werden benötigt?
- Incident-Response-Plan mit dokumentierter Eskalationskette
- Protokoll der letzten Meldeübung, inklusive Datum und Teilnehmerliste
- Kontaktverzeichnis der zuständigen nationalen Meldestelle
- Schulungsnachweise für alle in der Eskalationskette benannten Personen
7. BAM-Mapping
| Framework | Kapitel | Kontrolle | Dokument | Verantwortlich | Priorität |
|---|---|---|---|---|---|
| NIS-2 | Art. 23 | Meldepflicht bei Sicherheitsvorfällen | Incident-Response-Plan | IT-Sicherheitsbeauftragter | hoch |
| NIS-2 | Art. 21 | Risikomanagementmaßnahmen | Eskalationskette | Geschäftsführung | hoch |
| ISO 27001 | A.5.24–A.5.26 | Incident Management Planning | Übungsprotokoll | Informationssicherheitsbeauftragter | mittel |
Verknüpfte Frameworks: NIS-2 · ISO 27001
8. Unsere Empfehlung
Unsere Empfehlung
- Eskalationskette mit Namen statt Rollen dokumentieren und quartalsweise aktualisieren
- Mindestens eine realistische Meldeübung pro Jahr durchführen und protokollieren
- Eine vorbereitete Vorlage für die 24-Stunden-Frühwarnung bereithalten
- Schulungsnachweise als eigenständigen Audit-Beleg führen, nicht nur als Anhang zum Plan
Quellen
- Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS-2), Art. 23 (Meldepflichten)
- Richtlinie (EU) 2022/2555, Art. 21 (Risikomanagementmaßnahmen)
- ISO/IEC 27001:2022, Anhang A.5.24–A.5.26 (Incident Management Planning and Preparation)
- BSI, Orientierungshilfe zur Umsetzung der NIS-2-Meldepflichten