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 Antwort steht in §2 Nr. 11 BSIG: Erheblich ist ein Sicherheitsvorfall, der schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die 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. Die EU-Durchführungsverordnung 2024/2690 konkretisiert das nur für bestimmte digitale Anbieter, etwa Cloud-Computing-Dienstleister, Rechenzentrumsbetreiber und Anbieter verwalteter Dienste. Für die meisten anderen Einrichtungen gibt es keine verbindliche Kriterienliste.
8 Prüffragen zur Erheblichkeit
Die folgenden Fragen sind keine gesetzliche Liste, helfen aber, §2 Nr. 11 BSIG auf den eigenen Vorfall anzuwenden:
1. Anzahl betroffener Nutzer
Betrifft der Ausfall oder die Störung eine signifikante Anzahl von Nutzern Ihres Dienstes? Eine feste Zahl nennt das BSIG nicht — aussagekräftig ist der Anteil an der 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.
3. Geographische Ausdehnung
Ist nur ein einzelner Standort betroffen, oder erstreckt sich die Störung über mehrere Bundesländer oder EU-Mitgliedstaaten? Mögliche grenzüberschreitende Auswirkungen sind schon in der Frühwarnung anzugeben (§32 Abs. 1 Satz 1 Nr. 1 BSIG).
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.