NIS2-Meldepflicht: Was muss bei einem Sicherheitsvorfall gemeldet werden?

Praxis-Check: Ist Ihr Unternehmen im Ernstfall meldefähig?

Vier Fragen zeigen schnell, ob der Meldeprozess belastbar vorbereitet ist:

1. Wer entscheidet, ob ein Sicherheitsvorfall als erheblich einzustufen ist?
2. Wer dokumentiert den Zeitpunkt der Kenntniserlangung und überwacht die 24- und 72-Stunden-Fristen?
3. Wer darf eine externe Meldung freigeben und übermitteln?
4. Wer prüft parallel mögliche Meldepflichten nach DSGVO oder sektorspezifischen Regelungen?

Wenn diese Fragen erst während eines laufenden Cyberangriffs geklärt werden müssen, besteht ein erhebliches Risiko für verspätete, unvollständige oder widersprüchliche Meldungen.

Wer muss Sicherheitsvorfälle nach NIS2 melden?

Die Meldepflicht nach § 32 BSIG betrifft grundsätzlich Unternehmen und Einrichtungen, die nach § 28 BSIG als besonders wichtige oder wichtige Einrichtungen einzuordnen sind.

Ob ein Unternehmen darunter fällt, hängt insbesondere ab von:

• Sektor und konkreter Tätigkeit,
• Unternehmensgröße,
• Umsatz und Bilanzsumme,
• Konzern- und Beteiligungsstrukturen,
• dem Betrieb kritischer Anlagen,
• möglichen Sonderregelungen.

Die Betroffenheit sollte deshalb bereits vor einem Sicherheitsvorfall geprüft und dokumentiert sein. Wer erst während eines Angriffs klären muss, ob § 32 BSIG überhaupt anwendbar ist, verliert wertvolle Zeit.

Zu beachten sind außerdem gesetzliche Ausnahmen. Für bestimmte Telekommunikations- und Energieunternehmen gelten spezielle sektorale Regelungen. Auch für Finanzunternehmen, die dem DORA-Regime unterliegen, finden die Meldepflichten nach § 32 BSIG grundsätzlich keine Anwendung.

Eine ausführliche Einordnung finden Sie im Beitrag „Bin ich von NIS2 betroffen? Betroffenheitscheck für Unternehmen“.

Wann ist ein Sicherheitsvorfall meldepflichtig?

Nicht jede IT-Störung löst eine NIS2-Meldung aus. Entscheidend ist, ob ein erheblicher Sicherheitsvorfall vorliegt.

Nach dem BSIG ist ein Sicherheitsvorfall insbesondere erheblich, wenn er

• schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die betreffende Einrichtung verursacht hat oder verursachen kann oder
• andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann.

Mögliche Praxisfälle sind beispielsweise:

• Ransomware-Angriffe mit verschlüsselten oder ausgefallenen Systemen,
• erfolgreicher unbefugter Zugriff auf zentrale IT-Systeme,
• Kompromittierung privilegierter oder administrativer Zugänge,
• länger andauernde Ausfälle wesentlicher Dienste,
• Angriffe auf Produktions- oder Logistiksysteme,
• schwerwiegende Vorfälle bei zentralen IT- oder Cloud-Dienstleistern,
• erhebliche Datenabflüsse,
• Angriffe mit erheblichen Auswirkungen auf Kunden oder andere Unternehmen.

Entscheidend ist nicht allein die technische Angriffsmethode. Maßgeblich sind insbesondere die tatsächlichen oder möglichen Auswirkungen auf Dienste, Unternehmen und Dritte.

Praxisempfehlung: Unternehmen sollten interne Bewertungskriterien definieren. Dazu gehören beispielsweise Dauer und Umfang der Störung, betroffene Dienste, Zahl der betroffenen Kunden, mögliche finanzielle Schäden, Datenbezug, Lieferkettenauswirkungen und potenzielle Folgeschäden.

Welche Fristen gelten bei der NIS2-Meldepflicht?

§ 32 BSIG sieht mehrere aufeinanderfolgende Meldestufen vor:

Für die Fristen ist die Kenntniserlangung von einem erheblichen Sicherheitsvorfall maßgeblich. Unternehmen sollten deshalb dokumentieren, wann welche Informationen intern vorlagen und wann die Voraussetzungen für die Einstufung als erheblicher Sicherheitsvorfall erkannt wurden.

Gerade dieser Zeitpunkt kann später für die Frage entscheidend werden, ob fristgerecht gemeldet wurde.

Welche Angaben müssen in den einzelnen Meldungen enthalten sein?

Die Meldungen bauen aufeinander auf. Die erste Meldung soll bewusst früh erfolgen; die späteren Meldungen enthalten zunehmend belastbare Informationen.

24-Stunden-Erstmeldung

Die frühe Erstmeldung dient vor allem dazu, den Vorfall schnell anzuzeigen.

Nach § 32 BSIG ist insbesondere anzugeben, ob der Verdacht besteht, dass

• der Sicherheitsvorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist oder
• grenzüberschreitende Auswirkungen bestehen könnten.

Für einen funktionierenden internen Prozess sollten darüber hinaus grundlegende Informationen kurzfristig verfügbar sein, beispielsweise:

• betroffene Gesellschaft oder Einrichtung,
• Zeitpunkt der Kenntniserlangung,
• kurze Beschreibung des Vorfalls,
• betroffene Dienste oder Systeme,
• erste Einschätzung der Auswirkungen,
• bereits eingeleitete Sofortmaßnahmen,
• verantwortliche Kontaktperson.

Die entscheidende Praxisregel lautet: Nicht auf die vollständige technische Analyse warten.

Die Erstmeldung ist gerade dafür vorgesehen, einen erheblichen Sicherheitsvorfall frühzeitig anzuzeigen, obwohl noch nicht sämtliche Ursachen und Auswirkungen feststehen.

72-Stunden-Meldung

Innerhalb von spätestens 72 Stunden müssen die Angaben aus der Erstmeldung bestätigt oder aktualisiert werden.

Zusätzlich verlangt § 32 BSIG eine erste Bewertung des Sicherheitsvorfalls einschließlich

• seines Schweregrads,
• seiner Auswirkungen und
• gegebenenfalls vorhandener Kompromittierungsindikatoren.

In der Praxis sollten bis dahin insbesondere folgende Punkte geklärt oder zumindest eingegrenzt sein:

• welche Systeme und Dienste betroffen sind,
• welche Betriebsbeeinträchtigungen bestehen,
• welche Ursache oder Angriffsart wahrscheinlich ist,
• ob Daten betroffen sind,
• welche Eindämmungsmaßnahmen bereits umgesetzt wurden,
• welche weiteren Maßnahmen geplant sind,
• ob andere Unternehmen, Kunden oder Staaten betroffen sein können.

Die 72-Stunden-Meldung ist damit ein wichtiger Nachweis dafür, dass der Vorfall nicht nur technisch, sondern auch organisatorisch und rechtlich gesteuert wird.

Zwischenmeldung

Das BSI kann während der Bearbeitung eine Zwischenmeldung mit relevanten Statusaktualisierungen verlangen.

Der Meldeprozess muss deshalb auch nach der 72-Stunden-Meldung weitergeführt werden. Neue Erkenntnisse, wesentliche Änderungen der Auswirkungen und der Stand der Gegenmaßnahmen sollten fortlaufend dokumentiert werden.

Abschluss- und Fortschrittsmeldung

Grundsätzlich spätestens einen Monat nach der 72-Stunden-Meldung ist eine Abschlussmeldung vorzulegen.

Sie muss insbesondere enthalten:

• eine ausführliche Beschreibung des Sicherheitsvorfalls einschließlich Schweregrad und Auswirkungen,
• Angaben zur Art der Bedrohung beziehungsweise zur wahrscheinlichen Ursache,
• Angaben zu den getroffenen und laufenden Abhilfemaßnahmen,
• gegebenenfalls Angaben zu grenzüberschreitenden Auswirkungen.

Dauert der Sicherheitsvorfall zu diesem Zeitpunkt noch an, wird zunächst eine Fortschrittsmeldung vorgelegt. Die Abschlussmeldung folgt nach der abschließenden Bearbeitung.

Für die interne Nachbereitung empfiehlt es sich zusätzlich, Erkenntnisse aus dem Vorfall, Verbesserungsmaßnahmen und notwendige Anpassungen des Incident-Response-Prozesses zu dokumentieren.

An wen muss gemeldet werden?

§ 32 BSIG sieht die Meldung an eine gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) vor.

Unternehmen sollten vor einem Vorfall insbesondere klären:

• welcher konkrete Meldeweg für sie vorgesehen ist,
• wer Zugriff auf das jeweilige Meldeportal besitzt,
• welche Vertretungsregelungen bestehen,
• wer Meldungen vorbereitet,
• wer sie fachlich und rechtlich prüft,
• wer sie freigibt und übermittelt.

Informationen zu Meldewegen stellt das BSI unter anderem über sein BSI-Portal und seine Übersicht zu Meldestellen bereit.

Besondere Aufmerksamkeit ist bei Unternehmen erforderlich, für die sektorspezifische Meldewege gelten. Dies betrifft insbesondere Teile des Finanz-, Telekommunikations- und Energiesektors.

Müssen auch Kunden oder Nutzer informiert werden?

Die Information von Kunden oder anderen Empfängern der Dienste ist von der Behördenmeldung zu unterscheiden.

Bei einem eingetretenen erheblichen Sicherheitsvorfall kann das BSI nach § 35 Abs. 1 BSIG anordnen, dass besonders wichtige oder wichtige Einrichtungen die Empfänger ihrer Dienste unverzüglich über den Vorfall informieren, wenn dieser die Erbringung des jeweiligen Dienstes beeinträchtigen könnte.

Eine solche Information ist deshalb nicht bei jedem erheblichen Sicherheitsvorfall automatisch erforderlich.

Daneben bestehen besondere Unterrichtungspflichten bei erheblichen Cyberbedrohungen für bestimmte Sektoren. Dort kann insbesondere relevant sein, ob Empfänger selbst Schutz- oder Abhilfemaßnahmen ergreifen können.

Unabhängig davon können Informationspflichten aus anderen Rechtsgrundlagen, Verträgen oder der konkreten Kundenbeziehung bestehen.

Für die Praxis bedeutet das: Behördenmeldung, Datenschutzkommunikation, Kundeninformation und externe Krisenkommunikation sollten in einem gemeinsamen Kommunikationsprozess koordiniert werden.

Wie verhalten sich NIS2-Meldung und DSGVO-Meldung zueinander?

Ein Cybervorfall kann gleichzeitig einen erheblichen Sicherheitsvorfall nach dem BSIG und eine Verletzung des Schutzes personenbezogener Daten nach der DSGVO darstellen.

Das ist beispielsweise möglich bei:

• Datenabfluss,
• kompromittierten Benutzerkonten,
• Ransomware mit möglicher Datenexfiltration,
• unbefugtem Zugriff auf personenbezogene Daten,
• Verlust oder Manipulation personenbezogener Daten.

Eine DSGVO-Meldung ist jedoch nicht allein deshalb erforderlich, weil personenbezogene Daten betroffen sind. Entscheidend ist insbesondere, ob eine Verletzung des Schutzes personenbezogener Daten vorliegt und welches Risiko daraus für die Rechte und Freiheiten natürlicher Personen entsteht.

Praxisempfehlung: Unternehmen sollten NIS2 und Datenschutz nicht in vollständig getrennten Incident-Prozessen behandeln. Sinnvoller ist ein gemeinsamer Incident-Response-Prozess, aus dem je nach Vorfall unterschiedliche rechtliche Meldepfade ausgelöst werden.

So lassen sich insbesondere unterschiedliche Bewertungen, Zeitangaben oder Sachverhaltsdarstellungen vermeiden.

Was gilt für Finanzunternehmen und DORA?

Für Finanzunternehmen im Anwendungsbereich der Verordnung über die digitale operationale Resilienz im Finanzsektor – DORA – gilt eine wichtige Besonderheit.

§ 28 Abs. 6 BSIG nimmt die dort genannten DORA-Unternehmen grundsätzlich von den Pflichten nach §§ 30 bis 32 BSIG aus. Für schwerwiegende IKT-bezogene Vorfälle gilt damit insbesondere das sektorspezifische Meldewesen nach DORA.

Die Aussage „DORA und NIS2 müssen immer parallel gemeldet werden“ wäre daher zu pauschal.

Trotzdem bleibt eine Abgrenzungsprüfung wichtig. In Unternehmensgruppen können beispielsweise eigenständige IT-Gesellschaften, Dienstleister oder andere Gesellschaften bestehen, die selbst nicht unter die DORA-Ausnahme fallen und eigenständig nach dem BSIG zu bewerten sind.

Parallel kann außerdem die DSGVO relevant bleiben.

Für Unternehmensgruppen sollte deshalb bereits im Incident-Response-Konzept dokumentiert werden, welche Gesellschaft welchem Melde- und Aufsichtsregime unterliegt.

Welche Rolle hat die Geschäftsleitung?

Die Geschäftsleitung muss eine Vorfallsmeldung nicht selbst technisch erstellen oder in einem Portal eingeben.

Sie muss jedoch sicherstellen, dass das Unternehmen organisatorisch in der Lage ist, erhebliche Sicherheitsvorfälle rechtzeitig

• zu erkennen,
• zu bewerten,
• zu eskalieren,
• zu melden und
• nachvollziehbar zu dokumentieren.

Dazu gehören insbesondere klare Rollen, Vertretungsregelungen, Meldewege und Eskalationsprozesse.

Die Geschäftsleitung sollte außerdem rechtzeitig über erhebliche Vorfälle, Meldeentscheidungen, mögliche Auswirkungen und wesentliche externe Kommunikation informiert werden.

Fehlt ein belastbarer Prozess, wird aus einem technischen Sicherheitsvorfall schnell auch ein Organisations- und Governance-Problem.

Die persönliche Verantwortung von Geschäftsleitern behandeln wir ausführlich im Beitrag „NIS2-Haftung: Pflichten für Geschäftsführer und Vorstände“.

Welche Folgen drohen bei Meldefehlern?

§ 65 BSIG erfasst unter anderem Meldungen nach § 32 BSIG, die nicht, nicht richtig, nicht vollständig oder nicht rechtzeitig vorgenommen werden.

Für Unternehmen ist deshalb nicht nur entscheidend, ob sie melden, sondern auch, ob der Meldeprozess nachvollziehbar und fristgerecht durchgeführt wird.

Besonders wichtig ist die Dokumentation. Festgehalten werden sollten zumindest:

• Zeitpunkt und Umstände der Kenntniserlangung,
• zu welchem Zeitpunkt welche Informationen vorlagen,
• Bewertung der Erheblichkeit,
• beteiligte Personen und Funktionen,
• getroffene Entscheidungen,
• Zeitpunkt und Inhalt externer Meldungen,
• spätere Ergänzungen und Korrekturen.

Gerade bei einer späteren aufsichtsrechtlichen Prüfung lässt sich dadurch nachvollziehen, auf welcher Informationsgrundlage das Unternehmen zu welchem Zeitpunkt gehandelt hat.

Die Bußgeldrahmen und weiteren Sanktionsrisiken behandeln wir ausführlich im Beitrag „NIS2-Bußgelder: Welche Strafen drohen Unternehmen bei Verstößen?“.

Was müssen Unternehmen intern vorbereiten?

Ein belastbarer NIS2-Meldeprozess sollte mindestens folgende Bausteine enthalten:

1. Betroffenheit dokumentieren

Vor dem Ernstfall sollte geklärt sein, welche Gesellschaften oder Einrichtungen nach dem BSIG meldepflichtig sind und wo Sonderregelungen greifen.

2. Vorfälle klassifizieren

Definieren Sie Kriterien dafür, welche Ereignisse intern eskaliert und auf einen erheblichen Sicherheitsvorfall geprüft werden müssen.

3. Zeitpunkt der Kenntniserlangung dokumentieren

Der Beginn der Meldefrist muss nachvollziehbar sein. Deshalb sollte festgelegt werden, wie Zeitpunkt, Informationsstand und interne Eskalation dokumentiert werden.

4. 24/7-Eskalation sicherstellen

Schwerwiegende Cybervorfälle halten sich nicht an Geschäftszeiten. Es muss klar sein, wer nachts, an Wochenenden und Feiertagen erreichbar ist.

5. Rollen und Freigaben definieren

Legen Sie fest, wer einen Vorfall bewertet, wer Recht und Datenschutz einbindet, wer die Geschäftsleitung informiert und wer Meldungen freigibt.

6. Meldevorlagen vorbereiten

Vorlagen sollten mindestens für Erstmeldung, 72-Stunden-Meldung, Zwischenmeldung, Fortschrittsmeldung und Abschlussmeldung vorhanden sein.

7. Meldezugänge testen

Portalzugänge, Benutzerrechte, Vertretungen und Kontaktdaten sollten regelmäßig überprüft werden.

8. Dienstleister vertraglich einbinden

Cloud-Anbieter, Managed Service Provider und andere kritische Dienstleister müssen Informationen schnell genug bereitstellen, damit das Unternehmen seine eigenen gesetzlichen Fristen einhalten kann.

9. DSGVO- und Sektorschnittstellen integrieren

Der Incident-Prozess sollte automatisch eine Prüfung weiterer Meldepflichten auslösen.

10. Kundenkommunikation vorbereiten

Verantwortlichkeiten, Freigaben und Kommunikationswege sollten bereits vor dem Vorfall definiert sein.

11. Prozess regelmäßig testen

Ein Tabletop Exercise oder eine andere Notfallsimulation zeigt, ob Entscheidungs- und Meldewege innerhalb der gesetzlichen Fristen tatsächlich funktionieren.

Welche Fehler treten in der Praxis besonders häufig auf?

Typische Schwachstellen sind:

• Die NIS2-Betroffenheit wurde nicht vorab geklärt.
• Der Zeitpunkt der Kenntniserlangung wird nicht dokumentiert.
• Es ist unklar, wer über die Erheblichkeit eines Vorfalls entscheidet.
• Niemand ist eindeutig für die externe Meldung verantwortlich.
• Unternehmen warten auf eine vollständige forensische Analyse.
• IT, Datenschutz und Recht arbeiten mit unterschiedlichen Sachverhaltsständen.
• Dienstleister liefern Informationen zu spät.
• Portalzugänge oder Vertretungsregelungen funktionieren nicht.
• Die Geschäftsleitung wird zu spät eingebunden.
• Zwischen- oder Abschlussmeldungen werden nicht nachgehalten.
• Behördenmeldung und externe Kommunikation enthalten widersprüchliche Angaben.

Der zentrale Gegenhebel ist kein weiteres Dokument, sondern ein vorbereiteter und getesteter Meldeprozess.

Meldepflicht-Checkliste: Was sollte vorbereitet sein?

Häufige Fragen zur NIS2-Meldepflicht

Muss jeder IT-Sicherheitsvorfall nach NIS2 gemeldet werden?

Nein. § 32 BSIG betrifft erhebliche Sicherheitsvorfälle. Unternehmen benötigen jedoch einen Prozess, mit dem sie mögliche erhebliche Vorfälle kurzfristig erkennen und bewerten können.

Wann beginnt die 24-Stunden-Frist?

Maßgeblich ist die Kenntniserlangung von einem erheblichen Sicherheitsvorfall. Deshalb sollte der Informations- und Entscheidungsverlauf während eines Incidents genau dokumentiert werden.

Muss die 24-Stunden-Erstmeldung bereits vollständig sein?

Nein. Sie dient der frühen Warnung. Eine weitergehende Bewertung erfolgt insbesondere mit der 72-Stunden-Meldung.

Was passiert, wenn nach 72 Stunden noch nicht alle technischen Details bekannt sind?

Das ist bei komplexen Cybervorfällen häufig der Fall. Gemeldet wird der zu diesem Zeitpunkt verfügbare und belastbare Erkenntnisstand. Der Prozess sieht weitere Aktualisierungen und gegebenenfalls Zwischenmeldungen vor.

Was passiert, wenn der Vorfall nach einem Monat noch andauert?

Dann ist anstelle der Abschlussmeldung zunächst eine Fortschrittsmeldung vorgesehen. Die endgültige Abschlussmeldung folgt nach der abschließenden Bearbeitung des Vorfalls.

Muss zusätzlich nach DSGVO gemeldet werden?

Das ist gesondert zu prüfen. Betrifft der Vorfall personenbezogene Daten und liegen die Voraussetzungen von Art. 33 DSGVO vor, kann zusätzlich eine Datenschutzmeldung erforderlich sein.

Müssen Kunden oder Nutzer informiert werden?

Nicht automatisch bei jedem erheblichen Sicherheitsvorfall. Das BSI kann eine entsprechende Unterrichtung nach § 35 Abs. 1 BSIG anordnen. Daneben können weitere gesetzliche oder vertragliche Informationspflichten bestehen.

Gilt § 32 BSIG zusätzlich zu DORA?

Für die in § 28 Abs. 6 BSIG genannten DORA-Finanzunternehmen grundsätzlich nicht. Innerhalb einer Unternehmensgruppe können jedoch andere Gesellschaften oder Dienstleister eigenständig nach dem BSIG zu prüfen sein.

Wie sollte ein Unternehmen mit der Vorbereitung beginnen?

Der erste Schritt ist eine Rollen- und Eskalationsmatrix. Danach sollten Vorfallkriterien, Meldevorlagen, Fristenüberwachung, Portalzugänge, Dienstleisterprozesse sowie Schnittstellen zu Datenschutz und anderen regulatorischen Meldewegen definiert werden. Abschließend sollte der Prozess anhand eines realistischen Vorfalls getestet werden.

Hinweis

Dieser Beitrag bietet eine allgemeine Orientierung und ersetzt keine rechtliche oder technische Einzelfallprüfung. Er stellt keine Rechtsberatung dar und begründet kein Mandatsverhältnis.

Ob und welche Meldepflichten im konkreten Fall bestehen, hängt insbesondere von der Einordnung des Unternehmens, der Art und den Auswirkungen des Sicherheitsvorfalls, sektorspezifischen Regelungen, dem Datenbezug und der konkreten Behördenzuständigkeit ab.