NIS2 Vorfallmeldung
Letzte Aktualisierung: 24. März 2026
Die NIS2-Richtlinie verpflichtet betroffene Unternehmen zur dreistufigen Vorfallmeldung an das BSI: Erstmeldung innerhalb 24 Stunden, Folgemeldung binnen 72 Stunden und Abschlussbericht nach maximal einem Monat. Für die Praxis heißt das: Sie dürfen mit der Meldung nicht warten, bis Forensik, Geschäftsleitung und externe Dienstleister jedes Detail bestätigt haben. Die Frist läuft ab Kenntnis eines erheblichen Sicherheitsvorfalls, nicht erst ab dem fertigen Abschlussbericht. Je nach Einordnung drohen bei Pflichtverstößen Bußgelder bis 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes.
Die kürzeste Handlungsanweisung lautet daher: Meldefähigkeit in den ersten Stunden organisieren, Signifikanz früh bewerten, das BSI rechtzeitig informieren und jede spätere Erkenntnis gestuft nachliefern. Wenn Sie den Vorfallkontext breiter einordnen möchten, lesen Sie ergänzend unseren Leitfaden zum Krisenmanagement bei Cyberangriffen, den Vergleich CRA vs. NIS2 und die Einordnung zur Geschäftsführer-Haftung bei Cyberangriffen.
Wann muss ein NIS2-Vorfall gemeldet werden?
Ein NIS2-Vorfall muss gemeldet werden, sobald Ihre Organisation Kenntnis von einem erheblichen Sicherheitsvorfall hat und Sie hinreichend belastbar einschätzen können, dass die Schwelle überschritten sein könnte. „Kenntnis“ bedeutet praktisch nicht absolute Beweissicherheit, sondern einen ausreichend fundierten Verdacht auf einen signifikanten Vorfall. Genau deshalb ist die 24-Stunden-Meldung bewusst knapp gehalten: Geschwindigkeit geht vor Vollständigkeit.
Die Richtlinie arbeitet mit drei Stufen:
| Meldestufe | Frist | Ziel | Was mindestens hinein gehört |
|---|---|---|---|
| Erstmeldung | binnen 24 Stunden | Frühe Lageinformation für Behörde oder CSIRT | Hinweis auf erheblichen Vorfall, Verdacht auf rechtswidrige oder böswillige Ursache, möglicher grenzüberschreitender Effekt, grobe Betroffenheit |
| Folgemeldung | binnen 72 Stunden | Erste belastbare Bewertung | aktualisierte Lage, Schweregrad, Auswirkungsanalyse, erste technische Erkenntnisse, eingeleitete Gegenmaßnahmen |
| Abschlussbericht | spätestens nach 1 Monat | Vollständige Dokumentation | bestätigte Ursache, tatsächliche Auswirkungen, endgültige Maßnahmen, Lessons Learned, Nachweise der Untersuchung |
Entscheidend ist der Fristbeginn. Maßgeblich ist nicht der Moment, in dem alle Systeme wiederhergestellt sind, sondern der Zeitpunkt, an dem Sie von einem erheblichen Vorfall erfahren. In der Praxis startet die Uhr häufig, wenn Ihr SOC, Ihr IT-Dienstleister, ein Managed Security Service Provider oder die interne IT eine belastbare Eskalation an die zuständige Incident- oder Compliance-Funktion auslöst.
Ebenso wichtig ist der Grundsatz „im Zweifel eher melden“. Artikel 23 NIS2 will schnelle behördliche Lagebilder ermöglichen. Die bloße Meldung soll die meldende Einrichtung nicht automatisch einer erhöhten Haftung aussetzen. Wer dagegen erst tagelang abwartet, weil noch einzelne Logs fehlen oder die genaue Angriffsroute unklar ist, verfehlt den Zweck der Norm regelmäßig.
Was ist ein erheblicher Sicherheitsvorfall nach NIS2?
Ein erheblicher Sicherheitsvorfall nach NIS2 liegt vor, wenn Ihre Dienste wesentlich gestört werden, Ihr Unternehmen erhebliche finanzielle Verluste erleidet oder Dritte beträchtliche materielle oder immaterielle Schäden erleiden können. Die zentrale Frage ist deshalb nicht, ob ein Angriff „medienwirksam“ ist, sondern ob die Dienstleistung, die Verfügbarkeit, die Integrität oder die betroffenen Dritten in relevantem Maß beeinträchtigt sind.
Für die praktische Einordnung helfen drei Prüfblöcke:
- Betriebswirkung: Sind zentrale Dienste ausgefallen, erheblich verlangsamt oder nur eingeschränkt nutzbar?
- Schadenswirkung: Entstehen erhebliche finanzielle Schäden oder operative Folgekosten?
- Drittwirkung: Sind Kunden, Patienten, Lieferkettenpartner, Kommunen oder andere externe Stellen spürbar betroffen?
Typische meldepflichtige Konstellationen sind:
- Ransomware mit relevanter Beeinträchtigung der Dienstverfügbarkeit,
- erfolgreicher unbefugter Zugriff auf kritische Systeme,
- länger andauernder Ausfall zentraler Plattformen,
- kompromittierte Verwaltungs- oder Produktionssysteme mit Betriebsfolgen,
- Lieferkettenvorfälle, die Ihre eigenen Dienste erheblich beeinträchtigen.
Für bestimmte digitale Dienste und Vertrauensdienste konkretisieren EU-Durchführungsregeln die Signifikanz zusätzlich. Dort spielen unter anderem finanzielle Schwellen, erfolgreiche unbefugte Zugriffe oder wiederkehrende Vorfälle mit gleicher Ursache eine besondere Rolle. Für andere Einrichtungen bleibt die Bewertung stärker an der konkreten Dienstwirkung orientiert. Deshalb ist es gefährlich, sich nur auf starre Euro-Beträge zu verlassen.
Diese Orientierung hilft im Alltag:
| Frage | Wenn „Ja“, steigt die Meldewahrscheinlichkeit deutlich |
|---|---|
| Sind zentrale Dienste spürbar beeinträchtigt? | Vorfall spricht für NIS2-Relevanz |
| Ist die Dauer nicht nur kurzzeitig oder trivial? | Vorfall spricht für Signifikanz |
| Gibt es wirtschaftliche Schäden, Notbetrieb oder Lieferausfälle? | Vorfall spricht für Signifikanz |
| Sind Kunden oder andere Dritte konkret betroffen? | Vorfall spricht für Meldepflicht |
| Besteht ein Risiko in mehreren EU-Staaten? | Frühe Kennzeichnung in der Erstmeldung erforderlich |
Die größte Fehlannahme in Unternehmen lautet: „Solange wir noch prüfen, ob der Vorfall wirklich erheblich ist, läuft keine Frist.“ Genau das ist zu kurz gedacht. Wenn starke Indikatoren auf einen erheblichen Sicherheitsvorfall hindeuten, müssen Sie in die Meldebahn gehen und Unsicherheiten transparent benennen. Eine vorläufige Bewertung ist zulässig; gar keine Bewertung ist das größere Risiko.
An wen wird ein NIS2-Vorfall in Deutschland gemeldet?
In Deutschland wird der NIS2-Vorfall grundsätzlich an das BSI gemeldet. Nach den Informationen des BSI gilt seit Inkrafttreten des NIS-2-Umsetzungsgesetzes am 6. Dezember 2025, dass Registrierung und Vorfallmeldung über das BSI-Portal unter portal.bsi.bund.de erfolgen. Unternehmen und Behörden, die unter die gesetzlichen Voraussetzungen fallen, sollen sich dort registrieren und künftige Sicherheitsvorfälle über diesen Kanal melden.
Für die operative Praxis sind zwei Punkte wichtig:
- Das BSI ist zugleich nationale zentrale Anlaufstelle und nationales CSIRT.
- KRITIS-Betreiber und Bundesbehörden dürfen übergangsweise etablierte Prozesse über MIP2 weiter nutzen; laut BSI mindestens bis 31. Juli 2026, voraussichtlich sogar bis 31. Dezember 2026.
Wer bereits im BSI-Portal registriert ist, sollte danach konsequent denselben Kanal für Vorfälle und Schwachstellenmeldungen verwenden. Eine Doppelmeldung in BSI-Portal und MIP2 ist nach der BSI-Information nicht erforderlich.
Praktisch bedeutet „Meldeweg“ aber mehr als nur das technische Portal. Ihr Unternehmen braucht intern einen belastbaren Weg von der ersten technischen Eskalation zur externen Behördenmeldung. Typisch ist diese Kette:
- Detection durch IT, SOC oder externen Dienstleister.
- Sofortige interne Qualifizierung als möglicher erheblicher Vorfall.
- Entscheidung durch Incident Lead, Security Lead oder Krisenstab.
- Fristgerechte Meldung an das BSI.
- Parallele Prüfung weiterer Meldewege, etwa DSGVO, Versicherer, Vertragskunden oder sektorspezifische Aufsicht.
Wenn Ihr Vorfall potenziell grenzüberschreitende Auswirkungen in mehreren EU-Mitgliedstaaten hat, muss diese Information schon in die frühe Meldung hinein. Die Koordination innerhalb der EU läuft dann über die zuständigen Behörden- und CSIRT-Strukturen; Sie melden aber zunächst weiter an Ihren nationalen Kanal.
Was muss die Erstmeldung innerhalb von 24 Stunden enthalten?
Die Erstmeldung muss kein forensischer Roman sein, sondern eine belastbare Frühwarnung. Genau deshalb sollten Sie die 24-Stunden-Meldung als Management- und Behörden-Alarm verstehen: schnell, knapp, ehrlich und dokumentiert. Warten Sie nicht auf perfekte Logketten, wenn bereits klar ist, dass ein erheblicher Sicherheitsvorfall vorliegen könnte.
In die Erstmeldung gehören typischerweise diese Mindestinformationen:
| Pflichtinhalt der Erstmeldung | Praktische Leitfrage |
|---|---|
| Zeitpunkt der Kenntnis | Wann hat Ihre Organisation den erheblichen Vorfall erkannt? |
| Kurze Vorfallbeschreibung | Was ist passiert oder wird derzeit vermutet? |
| Betroffene Dienste | Welche Services, Plattformen oder Prozesse sind beeinträchtigt? |
| Verdacht auf böswillige oder rechtswidrige Ursache | Spricht etwas für Angriff, Missbrauch oder kriminelle Handlung? |
| Mögliche grenzüberschreitende Wirkung | Könnten Dienste, Nutzer oder Standorte in mehreren EU-Staaten betroffen sein? |
| Erreichbare Kontaktperson | Wer kann fachlich und organisatorisch Rückfragen beantworten? |
Eine praxistaugliche Struktur für die ersten 24 Stunden sieht so aus:
- Vorfall-ID und Zeitachse: interner Incident-Code, Entdeckungszeit, Zeitpunkt der Eskalation.
- Kurzklassifikation: etwa Ransomware, unbefugter Zugriff, DDoS, Lieferkettenvorfall oder noch unklar.
- Dienstbetroffenheit: Welche geschäftskritischen Leistungen sind eingeschränkt?
- Erste Risikobewertung: Verdacht auf Angriff, potenzielle Drittbetroffenheit, EU-Auslandsbezug.
- Sofortmaßnahmen: Isolation, Abschaltung, Passwort-Reset, Segmentierung, Incident-Response-Dienstleister eingebunden.
- Kontakt: Verantwortliche Person mit Telefon und E-Mail.
Die häufigste Fehleinschätzung ist, dass eine Erstmeldung erst dann sinnvoll sei, wenn Root Cause, IoCs und Schadenshöhe bereits validiert sind. Das ist falsch. Die 24-Stunden-Meldung ist gerade für Situationen gedacht, in denen Sie noch nicht alles wissen. Unbekannte Punkte dürfen ausdrücklich als vorläufig gekennzeichnet werden.
Ein zweiter häufiger Fehler ist das Weglassen der grenzüberschreitenden Perspektive. Wenn Ihre Plattform Kunden in mehreren Mitgliedstaaten bedient, ein zentraler Cloud-Dienst mehrere Landesgesellschaften betrifft oder ein Lieferkettenvorfall grenzüberschreitend wirken kann, gehört dieser Hinweis in die Erstmeldung. Sie müssen nicht jedes betroffene Land abschließend beweisen; ein belastbarer Verdacht genügt.
Was gehört in die 72-Stunden-Folgemeldung?
Die Folgemeldung nach 72 Stunden muss die Behörde in die Lage versetzen, Ihren Vorfall besser einzuordnen. Jetzt reicht ein reiner Alarmhinweis nicht mehr. Erwartet wird eine erste belastbare Einschätzung zu Schweregrad, Auswirkungen und Gegenmaßnahmen.
Spätestens nach 72 Stunden sollten Sie daher folgende Punkte sauber dokumentiert haben:
- aktualisierte Beschreibung des Vorfalls,
- betroffene Systeme, Dienste und Geschäftsprozesse,
- vorläufige Schweregradbewertung,
- erste Auswirkungen auf Kunden, Nutzer oder andere Dritte,
- Indikatoren für böswillige oder rechtswidrige Handlungen,
- bisherige und laufende Eindämmungsmaßnahmen,
- bekannte oder vermutete Ursachen,
- Stand externer Kommunikation und weiterer Meldungen.
Die 72-Stunden-Meldung ist typischerweise der Punkt, an dem sich Technik, Recht, Kommunikation und Management sauber verzahnen müssen. Die IT kennt die Loglage, externe Forensik kennt erste Indikatoren, Legal prüft DSGVO und Vertragspflichten, die Geschäftsleitung will die Betriebswirkung verstehen. Wenn diese Informationen in getrennten Silos liegen, reißen Fristen.
Praktisch sollten Sie die Folgemeldung deshalb nicht erst am Ende der 72 Stunden beginnen, sondern parallel zur Erstmeldung vorbereiten. Ein gutes Vorgehen ist:
- Direkt nach der Erstmeldung einen festen Update-Termin für T+48 oder T+60 Stunden ansetzen.
- Bis dahin technische Mindestdaten einsammeln: betroffene Assets, Zugangspfade, Verfügbarkeitsstatus, IoCs, Schadenshypothesen.
- Geschäftsseitige Auswirkungen quantifizieren: Nutzerzahl, Ausfalldauer, Umsatz- oder Produktionsschaden, Notbetrieb.
- Parallele Meldepflichten sauber abgleichen.
- Die Folgemeldung juristisch und fachlich finalisieren.
Unternehmen verlieren hier oft Zeit, weil sie interne Freigaben falsch organisieren. Eine 72-Stunden-Folgemeldung ist kein Image-Statement für den Aufsichtsrat, sondern eine regulatorische Pflichtmitteilung. Freigabeschleifen mit fünf Hierarchieebenen sind dafür regelmäßig zu langsam.
Was muss im Abschlussbericht nach spätestens einem Monat stehen?
Der Abschlussbericht muss den Vorfall nachvollziehbar abschließen: Ursache, Verlauf, tatsächliche Auswirkungen und Abhilfemaßnahmen müssen jetzt so dokumentiert sein, dass Aufsicht, Revision und internes Management ein konsistentes Bild erhalten. Wenn der Vorfall nach einem Monat noch andauert, ist stattdessen zunächst ein Fortschrittsbericht fällig; der finale Bericht folgt dann binnen eines Monats nach Bewältigung des Vorfalls.
Ein belastbarer Abschlussbericht enthält mindestens:
| Bestandteil | Inhalt |
|---|---|
| Vollständige Chronologie | Erkennung, Eskalation, Reaktion, Stabilisierung, Wiederherstellung |
| Bestätigte Ursache | Angriffsweg, Schwachstelle, Fehlkonfiguration, menschlicher Fehler oder Drittursache |
| Endgültige Auswirkung | reale Ausfallzeit, reale Nutzerbetroffenheit, tatsächlicher finanzieller Schaden |
| Forensische Erkenntnisse | IoCs, betroffene Systeme, Datenlage, Bewegungen des Angreifers |
| Umgesetzte Maßnahmen | technische, organisatorische und kommunikative Schritte |
| Präventionsmaßnahmen | Härtung, Monitoring, Schulung, Lieferantensteuerung, Governance-Korrekturen |
| Lessons Learned | Welche strukturellen Lücken wurden sichtbar und wie werden sie geschlossen? |
Gerade der letzte Punkt wird häufig unterschätzt. Ein Abschlussbericht ist nicht nur Rückschau, sondern Grundlage für Aufsichtsgespräche, Budgetentscheidungen und mögliche Haftungsfragen. Wer zwar die Systeme wieder hochfährt, aber keine governancebezogenen Ursachen dokumentiert, lässt einen wesentlichen Teil der Pflicht unerfüllt.
Typische Governance-Fragen im Abschlussbericht sind:
- Warum wurde der Vorfall nicht früher erkannt?
- Warum funktionierte Segmentierung, Backup oder Zugriffsschutz nicht ausreichend?
- Waren Rollen und Eskalationspfade klar?
- Waren Dienstleister vertraglich und operativ eingebunden?
- Haben Geschäftsleitung und relevante Verantwortliche rechtzeitig entschieden?
Gerade im Zusammenspiel mit Organpflichten lohnt sich hier der Blick auf unseren Beitrag zur Geschäftsführer-Haftung bei Cyberangriffen. Die technische Aufarbeitung allein reicht selten aus; entscheidend ist, ob das Unternehmen seine Cyber-Governance belastbar organisiert hatte.
NIS2 Meldepflicht, DSGVO und DORA sauber abgrenzen
NIS2 ersetzt nicht automatisch andere Meldepflichten. Ein einziger Vorfall kann gleichzeitig NIS2-, DSGVO-, DORA-, vertrags- oder versicherungsrechtliche Meldungen auslösen. Wer nur an „die eine Behörde“ denkt, verliert im Ernstfall wertvolle Zeit.
Die wichtigste Abgrenzung lautet:
| Regelwerk | Wann relevant? | Wohin wird gemeldet? | Zentrale Frist |
|---|---|---|---|
| NIS2 | erheblicher Sicherheitsvorfall mit Dienst- oder Betriebswirkung | nationale Behörde oder CSIRT, in Deutschland typischerweise BSI | 24h / 72h / 1 Monat |
| DSGVO | Verletzung des Schutzes personenbezogener Daten | zuständige Datenschutzaufsicht | regelmäßig 72 Stunden |
| DORA | große ICT-Vorfälle bei Finanzunternehmen | Finanzaufsicht nach DORA-Regime | eigenes, sektorales Meldeschema |
Ein klassisches Beispiel: Ransomware verschlüsselt Produktions- oder Versorgungssteuerung, ohne dass bereits klar personenbezogene Daten exfiltriert wurden. Dann kann NIS2 sofort einschlägig sein, obwohl die DSGVO-Meldung noch geprüft wird oder möglicherweise gar nicht ausgelöst wird. Umgekehrt kann ein Datenschutzvorfall mit begrenzter Betriebswirkung vor allem DSGVO-relevant sein.
Für Finanzunternehmen ist zusätzlich DORA entscheidend. Dort gelten eigene Meldewege und Aufsichtslogiken. Wenn Sie den sektoralen Unterschied vertiefen möchten, lesen Sie ergänzend unseren Beitrag zur DORA Schulung.
Die häufigsten Fehler bei der NIS2 Vorfallmeldung
Die häufigsten Fehler bei der NIS2 Vorfallmeldung entstehen nicht aus bösem Willen, sondern aus schlechter Vorbereitung. Unternehmen scheitern selten an der Frage, ob sie „prinzipiell“ meldebereit wären, sondern an konkreten Übergaben in den ersten Stunden.
Diese Fehler sehen wir besonders oft:
1. Zu spät eskaliert
Zu späte Eskalation ist der gefährlichste Fehler. Wenn erst auf vollständige Forensik, CFO-Freigabe oder externe Presseline gewartet wird, läuft die 24-Stunden-Frist faktisch leer. NIS2 verlangt jedoch gerade die frühe Lageinformation.
2. Signifikanz zu eng ausgelegt
Zu enge Signifikanzmaßstäbe führen dazu, dass reale Dienstbeeinträchtigungen intern als „noch kein echter Vorfall“ abgetan werden. Wer erst bei vollständigem Totalausfall meldet, interpretiert die Norm meist zu restriktiv.
3. Meldung nur technisch gedacht
Eine rein technische Meldung ohne Dienst-, Kunden- oder Drittwirkung greift zu kurz. NIS2 fragt nicht nur nach Logdaten, sondern nach der tatsächlichen Auswirkung auf die Leistungserbringung.
4. Parallele Pflichten nicht koordiniert
DSGVO, Vertragspflichten, Versicherer, Aufsichtsgremien und NIS2 laufen oft parallel. Wenn jede Funktion ihren eigenen Statusbericht produziert, entstehen Widersprüche. Benötigt wird ein gemeinsamer Incident-Factsheet mit einer einzigen belastbaren Zeitachse.
5. Abschlussbericht ohne Lessons Learned
Ein Abschlussbericht, der nur technische Maßnahmen aufzählt, verfehlt den Governance-Teil des Vorfalls. Aufsicht und Management wollen wissen, welche strukturellen Lücken sichtbar wurden und wie sie geschlossen werden.
Praktische Vorlage: So organisieren Sie die ersten 72 Stunden
Die ersten 72 Stunden nach einem erheblichen Sicherheitsvorfall entscheiden über Meldefähigkeit, Beweissicherung und Führungsfähigkeit. Deshalb sollte jede NIS2-relevante Organisation einen Standardablauf haben, der ohne Grundsatzdiskussion startet.
Ein pragmatisches Muster sieht so aus:
In den ersten 4 Stunden
- Incident Lead benennen,
- Vorfall-ID anlegen,
- Systemsicherung und Beweissicherung starten,
- betroffene Dienste und Standorte erfassen,
- erste Einschätzung zur Signifikanz treffen,
- Meldefrist im Ticket sichtbar setzen.
Bis spätestens 24 Stunden
- Erstmeldung an das BSI vorbereiten und absenden,
- externe Forensik oder Dienstleister einbinden,
- Geschäftsleitung und relevante Fachverantwortliche informieren,
- mögliche DSGVO- und Vertragsmeldungen parallel prüfen,
- Kommunikationssperren und Freigabeprozess festlegen.
Bis spätestens 72 Stunden
- Folgemeldung mit aktualisierter Lage absenden,
- betroffene Services, Nutzer und Schäden konkretisieren,
- technische Indikatoren und Hypothesen dokumentieren,
- Maßnahmenplan für Wiederherstellung und Prävention strukturieren.
Bis spätestens 1 Monat
- Abschluss- oder Fortschrittsbericht erstellen,
- Ursachenanalyse vervollständigen,
- Lessons Learned beschließen,
- Nachweis- und Auditunterlagen konsolidieren,
- Governance-Verbesserungen terminieren.
Wer diesen Ablauf nicht erst im Ernstfall entwerfen will, sollte ihn in Krisenhandbuch, Incident-Playbook und Rollenprofilen vorab festhalten. Genau dort schließt sich die Brücke zum breiteren Krisenmanagement bei Cyberangriffen: NIS2-Meldepflicht ist kein Einzelprozess der IT, sondern Teil belastbarer Unternehmenssteuerung.
FAQ zur NIS2 Vorfallmeldung
Wann muss ein NIS2-Vorfall gemeldet werden?
Ein erheblicher Sicherheitsvorfall muss ohne unangemessene Verzögerung gemeldet werden: mit Erstmeldung binnen 24 Stunden, Folgemeldung binnen 72 Stunden und Abschlussbericht spätestens nach einem Monat. Die Frist startet ab Kenntnis des erheblichen Vorfalls, nicht erst nach abgeschlossener Forensik.
Was ist ein erheblicher Sicherheitsvorfall nach NIS2?
Erheblich ist ein Vorfall, wenn er die Erbringung Ihrer Dienste wesentlich beeinträchtigt, erhebliche finanzielle Schäden verursacht oder andere Personen oder Organisationen spürbar schädigt. Für bestimmte digitale Dienste konkretisieren EU-Durchführungsregeln diese Schwelle weiter.
An wen wird ein NIS2-Vorfall gemeldet?
In Deutschland erfolgt die Meldung grundsätzlich an das BSI. Seit dem 6. Dezember 2025 stellt das BSI dafür das BSI-Portal bereit; KRITIS-Betreiber und Bundesbehörden können übergangsweise MIP2 weiter nutzen.
Welche Informationen muss die Erstmeldung enthalten?
Die Erstmeldung sollte den Zeitpunkt der Kenntnis, die Art des Vorfalls, betroffene Dienste, den Verdacht auf böswillige oder rechtswidrige Ursachen, mögliche grenzüberschreitende Auswirkungen und eine erreichbare Kontaktperson enthalten. Detailtiefe kann später nachgeliefert werden.
Was passiert bei verspäteter Meldung?
Verspätete Meldungen verschärfen das Aufsichts- und Sanktionsrisiko. Für wesentliche Einrichtungen sieht NIS2 Bußgeldrahmen bis 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes vor; für wichtige Einrichtungen bis 7 Mio. EUR oder 1,4 %.
Muss zusätzlich eine DSGVO-Meldung erfolgen?
Ja, wenn zugleich personenbezogene Daten betroffen sind und die Voraussetzungen einer meldepflichtigen Datenschutzverletzung vorliegen. NIS2 und DSGVO verfolgen unterschiedliche Schutzgüter und können parallel auslösen.
Fazit: NIS2 Vorfallmeldung ist ein 24-Stunden-Thema, kein Monatsprojekt
Die richtige Antwort auf die Frage „Was, wann und wie melden?“ lautet unter NIS2 überraschend klar: früh, gestuft und dokumentiert. Wer erhebliche Vorfälle erst nach interner Perfektion melden will, läuft in Fristprobleme. Wer dagegen innerhalb von 24 Stunden eine saubere Frühwarnung, binnen 72 Stunden eine belastbare Lageaktualisierung und innerhalb eines Monats einen vollständigen Bericht liefern kann, erfüllt nicht nur eine Rechtsnorm, sondern verbessert seine tatsächliche Krisenfähigkeit.
Wenn Sie Rollen, Nachweise und Governance rund um regulatorische Pflichten strukturiert aufbauen wollen, ist unsere EU AI Act Schulung ein sinnvoller nächster Schritt. Sie hilft Teams, Verantwortlichkeiten, Dokumentation und Entscheidungswege sauber zu organisieren, was auch für NIS2-nahe Incident- und Compliance-Prozesse praktisch relevant ist.