NIS2-Meldepflicht: Die 24-Stunden-Frist operativ einhalten
NIS2 Artikel 23 verlangt eine Frühwarnung innerhalb von 24 Stunden, eine qualifizierte Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats. Die meisten Unternehmen haben einen Incident-Response-Plan. Die wenigsten können unter Druck tatsächlich melden.
NIS2-Meldepflicht: Die 24-Stunden-Frist operativ einhalten
Ein Incident-Response-Plan steht in jedem ISMS. Er beschreibt, wer im Ernstfall was tut, welche Eskalationswege gelten und wie der Vorfall dokumentiert wird. Alles richtig, alles wichtig – und alles nicht das, was NIS2 tatsächlich prüft.
NIS2 prüft nicht, ob ein Plan existiert. NIS2 prüft, ob ein Unternehmen innerhalb von 24 Stunden eine koordinierte, faktenbasierte Frühwarnung an die zuständige Behörde liefern kann – während der Vorfall noch läuft. Das ist kein Dokumentationsproblem. Das ist ein Betriebssystem-Problem.
Direkt zu:
- Das dreistufige Melderegime im Detail
- Warum 24 Stunden kürzer sind, als man denkt
- Was ein Incident-Management-System leisten muss
- Die fünf Fragen, die in den ersten 24 Stunden beantwortet werden müssen
Was sich mit NIS2 geändert hat
Unter der ursprünglichen NIS-Richtlinie gab es Meldepflichten – aber sie waren weniger spezifisch, betrafen weniger Unternehmen und wurden in der Praxis selten durchgesetzt. NIS2 hat das grundlegend verändert.
Artikel 23 der NIS2-Richtlinie, umgesetzt in § 32 BSIG, führt ein verbindliches dreistufiges Melderegime ein – mit konkreten Fristen, konkreten Inhalten und konkreten Konsequenzen bei Nichteinhaltung. Die Meldung erfolgt an das BSI als zentrale Meldestelle (CSIRT).
Gleichzeitig hat sich der Kreis der Betroffenen massiv erweitert: Rund 30.000 Unternehmen in Deutschland fallen unter die neuen Anforderungen. Für viele davon ist die strukturierte Meldung eines Sicherheitsvorfalls an eine Behörde komplettes Neuland.
Das dreistufige Melderegime im Detail {#das-melderegime}
Stufe 1: Frühwarnung – innerhalb von 24 Stunden
Sobald ein Unternehmen Kenntnis von einem erheblichen Sicherheitsvorfall erlangt, muss innerhalb von 24 Stunden eine Frühwarnung an das BSI erfolgen. „Erheblich" im Sinne von NIS2 bedeutet: Der Vorfall hat schwere Betriebsstörungen oder finanzielle Verluste verursacht oder kann dies verursachen, oder er hat andere natürliche oder juristische Personen durch erheblichen materiellen oder immateriellen Schaden beeinträchtigt oder kann dies.
Die Frühwarnung muss enthalten: ob der Vorfall vermutlich auf rechtswidrige oder böswillige Handlungen zurückzuführen ist und ob er grenzüberschreitende Auswirkungen haben könnte.
Die Frühwarnung ist bewusst als schnelle Erstmeldung konzipiert – Geschwindigkeit vor Vollständigkeit. Aber „schnell" bedeutet nicht „formlos": Die Meldung muss über das BSI-Meldeportal erfolgen und die genannten Pflichtinhalte enthalten.
Stufe 2: Qualifizierte Meldung – innerhalb von 72 Stunden
Innerhalb von 72 Stunden nach Kenntniserlangung folgt die qualifizierte Vorfallmeldung. Diese aktualisiert die Frühwarnung und enthält eine erste Bewertung des Vorfalls: Schwere und Auswirkungen, betroffene Systeme und Dienste sowie – soweit verfügbar – Kompromittierungsindikatoren (Indicators of Compromise).
Hier wird der Unterschied zwischen Dokumentation und operativer Fähigkeit zum ersten Mal wirklich spürbar: Innerhalb von 72 Stunden muss ein Unternehmen nicht nur den Vorfall technisch analysiert haben, sondern auch in der Lage sein, die Ergebnisse strukturiert, nachvollziehbar und behördentauglich aufzubereiten.
Stufe 3: Abschlussbericht – innerhalb eines Monats
Spätestens einen Monat nach der Erstmeldung ist ein Abschlussbericht fällig. Dieser umfasst eine detaillierte Beschreibung des Vorfalls, die Ursachenanalyse (Root Cause), die ergriffenen Gegenmaßnahmen und – sofern relevant – die grenzüberschreitenden Auswirkungen.
Zusätzlich kann das BSI jederzeit Zwischenberichte anfordern. KRITIS-Betreiber unterliegen weiteren Detailanforderungen.
Warum 24 Stunden kürzer sind, als man denkt {#warum-24-stunden-kurz-sind}
24 Stunden klingt nach einem ganzen Tag. In der Realität eines laufenden Sicherheitsvorfalls ist das ein extrem kurzes Zeitfenster. Hier ist, was typischerweise in diesen 24 Stunden passiert – und zwar gleichzeitig:
Stunde 0–4: Erkennung und erste Einordnung. Ein Alert schlägt an – oder jemand meldet etwas Ungewöhnliches. Das Security-Team beginnt mit der Triage: Ist das ein echter Vorfall? Wie schwer ist er? Welche Systeme sind betroffen? In vielen Unternehmen ist schon diese Phase chaotisch, weil Zuständigkeiten unklar sind oder die richtigen Leute nicht erreichbar.
Stunde 4–12: Parallele Eskalation. Während die technische Analyse weiterläuft, müssen parallel Entscheidungen getroffen werden: Wer informiert die Geschäftsführung? Wer koordiniert mit Legal und Kommunikation? Gibt es vertragliche Meldepflichten gegenüber Kunden? Muss der Datenschutzbeauftragte einbezogen werden? Jede dieser Fragen erfordert Abstimmung zwischen Bereichen, die im Tagesgeschäft selten zusammenarbeiten.
Stunde 12–20: Faktensammlung unter Unsicherheit. Die technischen Fakten sind noch unvollständig. Die Geschäftsführung will Klarheit. Legal will wissen, was man sagen darf und was nicht. Die Kommunikationsabteilung braucht eine Sprachregelung. Gleichzeitig muss die Frühwarnung vorbereitet werden – mit Pflichtinhalten, die trotz unvollständiger Informationslage belastbar formuliert sein müssen.
Stunde 20–24: Meldung. Die Frühwarnung muss über das BSI-Portal eingereicht werden. Sie muss die Pflichtinhalte enthalten, sie muss von einer autorisierten Person abgegeben werden, und sie muss dokumentiert sein – für die eigene Nachweisführung.
Das ist der Grund, warum ein Incident-Response-Plan als PDF nicht reicht. Nicht weil der Plan schlecht wäre, sondern weil die operative Herausforderung in der Koordination liegt – und Koordination unter Zeitdruck funktioniert nur mit einem System, nicht mit einem Dokument.
Die fünf Fragen, die in den ersten 24 Stunden beantwortet werden müssen {#die-fuenf-fragen}
Jede dieser Fragen klingt einfach. Keine davon ist es, wenn der Vorfall gerade läuft:
1. Was ist passiert – und wie schwer ist es?
Triage und erste Einordnung: Handelt es sich um einen erheblichen Vorfall im Sinne von NIS2? Welche Systeme, Dienste und Daten sind betroffen? Gibt es Hinweise auf eine aktive Bedrohung? Diese Einschätzung muss schnell erfolgen, obwohl die Informationslage dünn ist.
2. Wer entscheidet was – und auf welcher Grundlage?
Die Geschäftsführung haftet persönlich (§ 38 BSIG). Aber die Geschäftsführung kann nicht allein entscheiden – sie braucht aufbereitete Informationen aus Security, IT, Legal und ggf. Datenschutz. Wer liefert diese Informationen? In welchem Format? Über welchen Kanal? Und wer hat die Autorität, die Frühwarnung freizugeben?
3. Welche externen Meldepflichten gelten?
NIS2 ist nicht die einzige Meldepflicht. Parallel kann eine DSGVO-Meldung an die Datenschutzbehörde erforderlich sein (72-Stunden-Frist). Es können vertragliche Notification-Pflichten gegenüber Kunden bestehen. Bei KRITIS-Betreibern gelten zusätzliche Anforderungen. All das muss parallel gesteuert werden – nicht sequenziell.
4. Wie koordinieren sich die beteiligten Bereiche?
Security analysiert. Legal bewertet. Kommunikation formuliert. Die Geschäftsführung entscheidet. IT sichert. In der Theorie ist das klar. In der Praxis – um 3 Uhr morgens, mit unvollständigen Informationen und hohem Zeitdruck – bricht genau diese Koordination regelmäßig zusammen. Was es braucht: definierte Rollen, definierte Kommunikationskanäle und ein System, das den Überblick behält, wer was wann getan hat.
5. Wie wird alles dokumentiert – während es passiert?
NIS2 verlangt Nachweisbarkeit. Das bedeutet: Die gesamte Vorfallbehandlung muss dokumentiert sein – nicht nachträglich rekonstruiert. Wer hat wann welche Entscheidung getroffen? Auf welcher Informationsgrundlage? Welche Kommunikation hat stattgefunden? Welche Version des Lagebilds war zum Zeitpunkt der Meldung aktuell? Diese Dokumentation ist nicht nur für die Behörde relevant – sie schützt die Geschäftsführung bei der Frage der persönlichen Haftung.
Incident-Response-Plan vs. Incident-Management-System {#was-ein-ims-leisten-muss}
Die Unterscheidung ist zentral – und sie wird im Markt zu selten gemacht:
Ein Incident-Response-Plan (IRP) beschreibt, was im Ernstfall passieren soll: Rollen, Eskalationswege, Prozessschritte, Kontaktlisten. Er ist ein Dokument – und als solches unverzichtbar. ISO 27001 verlangt ihn, und er bildet die Grundlage für jede Vorfallbehandlung.
Ein Incident-Management-System (IMS) ist die operative Infrastruktur, die den Plan umsetzt: Echtzeit-Koordination zwischen Bereichen, strukturierte Kommunikation, versionierte Dokumentation, integrierte Nachweisführung, Statusübersicht für die Geschäftsführung, und die Fähigkeit, innerhalb der regulatorischen Fristen belastbare Meldungen zu produzieren.
| Fähigkeit | Incident-Response-Plan | Incident-Management-System |
|---|---|---|
| Rollen und Zuständigkeiten definiert | ✅ | ✅ |
| Eskalationswege beschrieben | ✅ | ✅ |
| Prozessschritte dokumentiert | ✅ | ✅ |
| Echtzeit-Koordination zwischen Bereichen | ❌ | ✅ |
| Versionierte Dokumentation während des Vorfalls | ❌ | ✅ |
| Parallelsteuerung mehrerer Meldepflichten | ❌ | ✅ |
| Integrierte Nachweisführung für Behörden | ❌ | ✅ |
| Statusübersicht für Geschäftsführung in Echtzeit | ❌ | ✅ |
| Fristgerechte Meldung unter Zeitdruck | ❌ Hängt von Personen ab | ✅ Systemgestützt |
Ein IRP sagt „so soll es laufen." Ein IMS sorgt dafür, dass es tatsächlich so läuft – auch um 3 Uhr morgens, auch wenn der CISO im Urlaub ist, auch wenn drei Meldepflichten gleichzeitig greifen.
NIS2 prüft nicht den Plan. NIS2 prüft die Fähigkeit.
Was Unternehmen jetzt konkret tun sollten
1. Den eigenen IRP gegen die NIS2-Fristen testen
Nicht theoretisch, sondern praktisch: Tabletop-Übung mit einem realistischen Szenario und der konkreten Frage – können wir innerhalb von 24 Stunden eine Frühwarnung produzieren, die die Pflichtinhalte enthält? Wo bricht der Prozess? Wer ist nicht erreichbar? Wo fehlen Informationen?
2. Rollen für die Meldekette definieren
Wer hat die Autorität, die Frühwarnung freizugeben? Wer bereitet die Inhalte auf? Wer gibt sie über das BSI-Portal ein? Diese Rollen müssen namentlich benannt sein – mit Stellvertretung. „Das macht Security" ist keine Rollenklärung.
3. Parallele Meldepflichten kartieren
NIS2, DSGVO, vertragliche Pflichten, branchenspezifische Anforderungen – welche Meldepflichten greifen bei welchem Vorfalltyp? In welcher Frist? An welche Stelle? Diese Übersicht muss vor dem Ernstfall stehen, nicht währenddessen erarbeitet werden.
4. Vorlagen vorbereiten
Templates für die 24-Stunden-Frühwarnung, die 72-Stunden-Meldung und den Abschlussbericht – vorab erstellt, vorab freigegeben, vorab getestet. Wer im Ernstfall das Format erst definieren muss, verliert kritische Zeit.
5. Dokumentation als Echtzeit-Prozess etablieren
Die Vorfallbehandlung muss dokumentiert werden, während sie stattfindet – nicht nachträglich. Das bedeutet: ein zentraler, versionierter Ort für Lagebilder, Entscheidungen, Kommunikation und Nachweise. Verstreute E-Mails, Chat-Nachrichten und persönliche Notizen sind unter NIS2 nicht nachweistauglich.
6. Regelmäßig üben
Tabletop-Übungen mindestens zweimal jährlich – mit wechselnden Szenarien, unter Einbeziehung aller relevanten Bereiche einschließlich Geschäftsführung. Jede Übung offenbart Lücken, die im Ernstfall Zeit kosten.
Die regulatorischen Konsequenzen
Die Konsequenzen bei Nichteinhaltung der Meldepflichten sind klar geregelt:
Für besonders wichtige Einrichtungen: Bußgelder bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes. Für wichtige Einrichtungen: bis zu 7 Millionen Euro oder 1,4 %. Zusätzlich: persönliche Haftung der Geschäftsführung nach § 38 BSIG.
Aber die regulatorische Konsequenz ist nicht das einzige Risiko. Ein Unternehmen, das nach einem Sicherheitsvorfall nicht fristgerecht melden kann, hat ein doppeltes Problem: den Vorfall selbst – und den Nachweis, dass es seine Pflichten nicht erfüllen konnte. Das zweite Problem ist oft das größere.
Quellen
- Richtlinie (EU) 2022/2555 (NIS2-Richtlinie) – Volltext – Amtsblatt der Europäischen Union. Artikel 23 zu den Meldepflichten bei erheblichen Sicherheitsvorfällen.
- BSI – NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) – § 32 BSIG zum dreistufigen Melderegime.
- BSI – #nis2know Infopaket: NIS-2-Meldepflicht – Informationspaket des BSI zur Umsetzung der Meldepflichten.
- ENISA – Implementing Guidance on NIS2 Security Measures – Umsetzungsempfehlungen der ENISA, insbesondere zu Incident Handling und Reporting.
- ENISA – NIS2 Technical Implementation Guidance – Technische Hinweise zu Meldeformaten, Fristen und Nachweisführung.