Zum Inhalt springen
MeldeKette24MeldeKette24
Meldepflicht

NIS2: Wann ist ein Vorfall wirklich meldepflichtig? Die 8 Erheblichkeitskriterien

Nicht jeder Sicherheitsvorfall löst die NIS2-Meldepflicht aus. Die EU-DVO 2024/2690 definiert 8 Kriterien — mit Praxisbeispielen und Checkliste.

10. Januar 20263 Min. Lesezeit

Die entscheidende Frage: Erheblich oder nicht?

Vor jeder BSI-Meldung steht die Triage: Ist dieser Vorfall überhaupt meldepflichtig? Wer zu schnell „nein" antwortet, riskiert ein Bußgeld. Wer alles meldet, verliert Zeit für die eigentliche Incident Response.

Die EU-Durchführungsverordnung 2024/2690 (vom 17. Oktober 2024) liefert die verbindliche Antwort. Sie konkretisiert, wann ein Sicherheitsvorfall als erheblich im Sinne von §32 BSIG gilt.

Die 8 Erheblichkeitskriterien der EU-DVO 2024/2690

Ein Vorfall ist erheblich, wenn mindestens eines der folgenden Kriterien erfüllt ist:

1. Anzahl betroffener Nutzer

Betrifft der Ausfall oder die Störung eine signifikante Anzahl von Nutzern Ihres Dienstes? Die Verordnung nennt keine absolute Zahl — maßgeblich ist die Verhältnismäßigkeit zur Gesamtnutzerbasis.

Praxis: Ein Ausfall, der alle Kunden eines Logistikunternehmens für mehrere Stunden betrifft, ist erheblich. Ein internes IT-Problem, das nur zwei Mitarbeiter betrifft, wahrscheinlich nicht.

2. Dauer des Ausfalls

Wie lange dauert die Störung an? Das Kriterium ist zeitgebunden: Kurzfristige Störungen unter einer Stunde sind weniger erheblich als mehrstündige oder mehrtägige Ausfälle.

Faustformel: Ab zwei Stunden Ausfall eines kritischen Dienstes wird die Erheblichkeit wahrscheinlich.

3. Geographische Ausdehnung

Ist nur ein einzelner Standort betroffen, oder erstreckt sich die Störung über mehrere Bundesländer oder EU-Mitgliedstaaten? Grenzüberschreitende Auswirkungen erhöhen die Erheblichkeit automatisch.

4. Finanzieller Schaden

Ist ein erheblicher wirtschaftlicher Schaden entstanden oder absehbar? Dabei zählt sowohl der direkte Schaden (Umsatzausfall, Wiederherstellungskosten) als auch der potenzielle Schaden, der noch eintreten kann.

5. Auswirkungen auf andere NIS2-Einrichtungen

Hat der Vorfall Kaskadeneffekte auf andere NIS2-pflichtige Einrichtungen oder kritische Infrastrukturen? Lieferketten-Angriffe (z. B. über Software-Dienstleister) sind ein typisches Beispiel.

6. Auswirkungen auf die öffentliche Sicherheit

Beeinträchtigt der Vorfall die öffentliche Sicherheit, Gesundheitsversorgung oder Versorgung der Bevölkerung? Dieses Kriterium gilt vor allem für KRITIS-nahe Einrichtungen.

7. Art der betroffenen Daten

Sind besonders schützenswerte Daten betroffen — Gesundheitsdaten, personenbezogene Daten im großen Maßstab, Berufsgeheimnisse? Die Art der Daten kann die Erheblichkeit auch dann begründen, wenn andere Kriterien nicht erfüllt sind.

8. Reputationsschaden

Kann der Vorfall zu einem erheblichen Reputationsschaden führen? Dieses Kriterium ist weich formuliert, aber relevant — insbesondere wenn eine Veröffentlichung des Vorfalls durch Dritte droht.

Praxisbeispiele

Meldepflichtig

  • Ransomware-Angriff auf die Produktions-IT eines Maschinenbauers mit 12-stündigem Produktionsausfall
  • DDoS-Angriff auf das Online-Bestellsystem eines Lebensmittelgroßhändlers für über 6 Stunden
  • Datenabfluss von Kundendatensätzen bei einem Transport-Dienstleister
  • Kompromittierung eines IT-Dienstleisters, der mehrere NIS2-pflichtige Kunden betreut

Wahrscheinlich nicht meldepflichtig

  • Phishing-Mail, die vom Spam-Filter abgefangen wurde — kein Schaden entstanden
  • Kurzfristiger Server-Ausfall (unter 1 Stunde) ohne Datenverlust und ohne Kundenauswirkungen
  • Versuchter Angriff, der vollständig abgewehrt wurde ohne Systemkompromittierung
  • Interne Passwort-Zurücksetzung aufgrund von Verdacht ohne konkreten Schadensnachweis

Die BSI-Empfehlung: Im Zweifel melden

Das BSI empfiehlt explizit: Bei Unsicherheit lieber die Frühwarnung (24h) absetzen und in der Vorfallsmeldung (72h) präzisieren. Falschmeldungen werden milder behandelt als Nicht-Meldungen.

Die Frühwarnung ist niedrigschwellig — sie erfordert keine vollständige Analyse. Eine Faustregel: Wenn Ihr IT-Sicherheitsteam intern einen P1-Vorfall ausruft, ist die Meldung ans BSI fast immer angebracht.

Schnell prüfen mit MeldeKette24

MeldeKette24 führt Ihr Team im Ernstfall durch eine strukturierte Triage: Welche Kriterien sind erfüllt? Ist der Vorfall erheblich? Was ist der nächste Schritt? — Alles in einem geführten Workflow, der die BSI-Fristen im Blick behält.

Hinweis: Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für Ihre konkrete Situation empfehlen wir einen auf IT-Recht spezialisierten Anwalt.

MeldeKette24 — NIS2-Meldeprozess für KMU

Jetzt Meldeprozess strukturieren — kostenlos in der Beta

Zur Beta-Anmeldung

Verwandte Artikel