NIS-2-Vorfall melden: So funktioniert die Meldekette

Freitag, 16:40 Uhr. Mehrere Systeme sind ausgefallen. Auf zwei Servern liegen verdächtige Dateien. Noch weiß niemand, ob Daten abgeflossen sind, wie viele Kunden betroffen sind oder ob sich der Angreifer noch im Netz befindet.

Die Technik beginnt mit der Analyse. Die Geschäftsführung fragt nach den Auswirkungen. Der Datenschutzbeauftragte möchte wissen, ob personenbezogene Daten betroffen sind. Und irgendwo fällt der Satz:

„Wir melden erst, wenn wir genau wissen, was passiert ist.“

Das klingt ordentlich. Für eine NIS-2-Meldepflicht kann es aber genau der falsche Ansatz sein. Die gesetzliche Meldekette ist ausdrücklich mehrstufig gebaut, weil in den ersten Stunden eben noch nicht alles bekannt ist. Wer auf den perfekten Abschlussbericht wartet, bevor er die erste Meldung absetzt, hat die Logik des Verfahrens auf den Kopf gestellt.

Die kurze Antwort

Besonders wichtige und wichtige Einrichtungen müssen einen erheblichen Sicherheitsvorfall nach § 32 des BSI-Gesetzes mehrstufig an die gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe melden:

• unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung, eine frühe Erstmeldung;
• unverzüglich, spätestens innerhalb von 72 Stunden nach Kenntniserlangung, eine ausführlichere Meldung mit erster Bewertung;
• auf Ersuchen des BSI eine Zwischenmeldung mit relevanten Statusaktualisierungen;
• spätestens einen Monat nach der 72-Stunden-Meldung eine Abschlussmeldung;
• dauert der Vorfall dann noch an, zunächst eine Fortschrittsmeldung und nach der abschließenden Bearbeitung die Abschlussmeldung.

Diese Meldekette läuft parallel zur technischen und organisatorischen Vorfallbehandlung. Unser Beitrag Sicherheitsvorfall erkannt: Was ist jetzt konkret zu tun? behandelt Eindämmung, Beweissicherung, Wiederherstellung und Koordination. Dieser Artikel konzentriert sich bewusst auf eine andere Frage: Wer muss wann was an wen melden und wie organisiert man das, obwohl die Faktenlage noch unvollständig ist?

Schritt 0: Fallen Sie überhaupt unter die Pflicht?

Die gesetzliche Meldepflicht nach § 32 BSIG trifft nicht automatisch jedes Unternehmen mit einem IT-Vorfall. Sie richtet sich an besonders wichtige Einrichtungen und wichtige Einrichtungen im Sinne des BSI-Gesetzes.

Ob Ihr Unternehmen dazugehört, hängt unter anderem von Tätigkeit, Sektor, Unternehmensgröße, möglichen Sonderregeln und der konkreten Einrichtungsart ab. Unser Überblick Was ist NIS-2? erklärt die Grundstruktur. Wie man aus Anforderungen ein Umsetzungsprogramm macht, steht im Leitfaden NIS-2-konform werden.

Die Prüfung der Betroffenheit gehört vor den ersten Vorfall. Wer erst während eines laufenden Angriffs diskutiert, ob das Unternehmen vielleicht eine wichtige Einrichtung sein könnte, verbraucht die knappste Ressource der Meldekette: Zeit.

Halten Sie deshalb vorab fest:

• welche Rechtseinheit unter das BSIG fällt,
• welche Dienste und Standorte dazugehören,
• wer die Einordnung verantwortet,
• über welchen Zugang gemeldet wird,
• und welche weiteren Meldepflichten parallel in Betracht kommen.

Das BSI stellt für Registrierung und Vorfallmeldungen das BSI-Portal bereit. Betreiber kritischer Anlagen und Bundesbehörden können laut BSI übergangsweise vorrangig etablierte Meldewege nutzen. Der Meldeweg sollte eingerichtet und der Zugriff getestet sein, bevor am Freitag um 16:40 Uhr jemand nach dem Passwort sucht.

Wann ist ein Sicherheitsvorfall „erheblich“?

Nicht jede verdächtige E-Mail löst die gesetzliche Meldekette aus. Entscheidend ist der erhebliche Sicherheitsvorfall.

§ 2 Nummer 11 BSIG bezeichnet damit einen Sicherheitsvorfall, der

• schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die betroffene 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.

Das kleine Wort „kann“ ist wichtig. Sie müssen nicht warten, bis der volle Schaden zweifelsfrei eingetreten ist. Wenn ein Vorfall nach den bekannten Umständen schwerwiegende Folgen verursachen kann, gehört die Erheblichkeitsprüfung sofort auf den Tisch.

Für bestimmte digitale Anbieter konkretisiert die Durchführungsverordnung (EU) 2024/2690 die Fälle, in denen ein Vorfall als erheblich gilt. Unser Artikel Wann ist ein Sicherheitsvorfall nach EU 2024/2690 erheblich? geht auf diese Schwellen und Fallgruppen ein.

Für die praktische Entscheidung sollten Sie mindestens prüfen:

• Welche Dienste sind gestört oder könnten ausfallen?
• Wie viele Kunden, Benutzer oder andere Personen sind betroffen?
• Wie lange dauert die Beeinträchtigung voraussichtlich?
• Sind Daten, Systeme oder Zugänge kompromittiert?
• Drohen erhebliche finanzielle Verluste?
• Können andere Personen oder Unternehmen erheblich geschädigt werden?
• Gibt es grenzüberschreitende Auswirkungen?
• Deuten Erkenntnisse auf eine böswillige oder rechtswidrige Handlung hin?

Dokumentieren Sie die Entscheidung auch dann, wenn Sie zunächst nicht melden. Neue Erkenntnisse können die Bewertung ändern. Aus einem begrenzten Ausfall kann eine Stunde später ein Vorfall mit deutlich größerer Reichweite werden.

Der Startpunkt ist Kenntniserlangung – nicht die fertige Ursachenanalyse

Die Fristen knüpfen an die Kenntniserlangung vom erheblichen Sicherheitsvorfall an. Praktisch brauchen Sie deshalb einen sauberen Zeitstrahl:

• Wann ging der erste Alarm ein?
• Wann erkannte das Incident-Team einen Sicherheitsvorfall?
• Wann lagen Tatsachen vor, aus denen sich seine mögliche Erheblichkeit ergab?
• Wer traf auf welcher Grundlage die Bewertung?
• Wann wurden Geschäftsleitung und Meldeverantwortlicher informiert?

Es wäre riskant, den Fristbeginn durch interne Weiterleitungsschleifen künstlich nach hinten zu schieben. „Die Technik wusste es am Freitag, aber Compliance hat die E-Mail erst Montag gelesen“ ist keine besonders überzeugende Prozessbeschreibung.

Legen Sie eine interne Eskalationsschwelle fest, die früher greift als die endgültige juristische Bewertung. Das Incident-Team muss einen möglicherweise erheblichen Vorfall sofort an den Meldeverantwortlichen geben können. Lieber wird die Erheblichkeit zügig geprüft, als dass ein kritischer Sachverhalt bis zum nächsten Regeltermin im Ticketsystem liegt.

Innerhalb von 24 Stunden: die frühe Erstmeldung

Die frühe Erstmeldung ist kein vollständiger forensischer Bericht. Nach § 32 Absatz 1 Nummer 1 BSIG soll sie angeben, ob der Verdacht besteht, dass der erhebliche Sicherheitsvorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist oder grenzüberschreitende Auswirkungen haben könnte.

Praktisch sollte das Unternehmen die zu diesem Zeitpunkt verfügbaren und gesicherten Informationen geordnet liefern. Dazu gehören insbesondere:

• betroffene Einrichtung und Ansprechpartner,
• Zeitpunkt der Kenntniserlangung,
• betroffener Dienst,
• aktueller Status,
• erkennbare Auswirkungen,
• Verdacht auf böswillige oder rechtswidrige Handlungen,
• mögliche grenzüberschreitende Auswirkungen,
• sowie ein klarer Hinweis, welche Angaben noch vorläufig oder unbekannt sind.

Der letzte Punkt ist keine Peinlichkeit. Er ist der Sinn einer frühen Meldung. Schreiben Sie nicht aus Nervosität Vermutungen als Tatsachen auf. Trennen Sie sauber:

• bekannt und bestätigt,
• plausibler Verdacht,
• noch in Prüfung,
• derzeit unbekannt.

So wird die Meldung belastbar, ohne eine Gewissheit vorzutäuschen, die nach wenigen Stunden regelmäßig niemand haben kann.

Innerhalb von 72 Stunden: die Meldung mit erster Bewertung

Die 72-Stunden-Meldung bestätigt oder aktualisiert die frühe Erstmeldung. Hinzu kommen eine erste Bewertung des erheblichen Sicherheitsvorfalls, sein Schweregrad, seine Auswirkungen und gegebenenfalls Kompromittierungsindikatoren.

Bis dahin sollte das Team die Lage deutlich besser strukturiert haben:

• Was ist tatsächlich betroffen?
• Welche Dienste waren oder sind beeinträchtigt?
• Wie groß sind Reichweite und Dauer?
• Welche Daten oder Konten könnten kompromittiert sein?
• Welche Maßnahmen wurden bereits getroffen?
• Welche Auswirkungen sind eingetreten oder weiterhin möglich?
• Welche technischen Indikatoren können für die Bewertung oder Abwehr relevant sein?

Auch nach 72 Stunden darf etwas unbekannt sein. Aktualisieren Sie die Meldung nach bestem Kenntnisstand. Erfinden Sie keine abschließende Ursache, nur weil im Formular ein Feld danach aussieht.

Verlässliche Zeitangaben hängen an gutem Logging und Monitoring und an korrekt synchronisierten Systemuhren. Unser Artikel zur Uhrensynchronisation zeigt ziemlich anschaulich, was schiefgeht, wenn verschiedene Protokolle nicht dieselbe Zeit meinen.

Zwischenmeldung, Fortschrittsmeldung und Abschlussmeldung

Das BSI kann eine Zwischenmeldung mit relevanten Statusaktualisierungen verlangen. Dafür sollte niemand den bisherigen Ablauf aus Chat-Nachrichten, einzelnen Tickets und Erinnerung zusammensuchen müssen. Führen Sie von Beginn an ein zentrales Vorfallprotokoll.

Spätestens einen Monat nach der 72-Stunden-Meldung verlangt § 32 BSIG grundsätzlich eine Abschlussmeldung mit:

• ausführlicher Beschreibung des Vorfalls einschließlich Schweregrad und Auswirkungen,
• Art der Bedrohung beziehungsweise wahrscheinlicher Ursache,
• getroffenen und noch laufenden Abhilfemaßnahmen,
• sowie gegebenenfalls grenzüberschreitenden Auswirkungen.

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

Hier zahlt sich eine vernünftige Nachbereitung aus. A.5.27 der ISO 27001 fordert, aus Sicherheitsvorfällen zu lernen. Im Beitrag Server läuft wieder – alles fertig? erklären wir, wie Ursachen, Schwächen und Verbesserungsmaßnahmen aus dem Vorfall herausgearbeitet werden. Diese Arbeit liefert zugleich wesentliche Inhalte für eine belastbare Abschlussmeldung.

Die Meldekette muss parallel zur Vorfallbehandlung laufen

Der technische Einsatzleiter soll Systeme eindämmen und wiederherstellen. Er sollte nicht gleichzeitig das Gesetz lesen, das Meldeportal bedienen, Kundeninformationen abstimmen und der Geschäftsführung jede halbe Stunde dieselbe Lage erklären.

Für einen ernsten Vorfall sind mindestens diese Rollen sinnvoll:

• Incident Lead: steuert technische und organisatorische Bearbeitung;
• Meldeverantwortlicher: prüft Fristen, Empfänger, Inhalte und Abgabe;
• Protokollführer: pflegt Zeitstrahl, Entscheidungen und offene Punkte;
• Geschäftsleitung: trifft wesentliche Risiko- und Kommunikationsentscheidungen;
• Datenschutz und Recht: prüfen parallele Pflichten und rechtliche Fragen;
• Kommunikation: bereitet Informationen für Kunden, Partner und gegebenenfalls Öffentlichkeit vor;
• Fach- und Serviceverantwortliche: bewerten Auswirkungen auf Dienste und Kunden.

In kleinen Unternehmen können mehrere Rollen bei derselben Person liegen. Die Aufgaben verschwinden dadurch nicht. Wichtig ist, dass technische Hilfe und gesetzliche Meldung parallel laufen und Informationen kontrolliert zwischen beiden Spuren fließen.

Ein gemeinsames Lagebild statt fünf Wahrheiten

Ein zentrales Vorfallprotokoll sollte mindestens enthalten:

• Zeitstempel und Quelle jeder wesentlichen Erkenntnis,
• bestätigte Tatsachen und offene Hypothesen,
• betroffene Systeme, Dienste und Parteien,
• Bewertung der Erheblichkeit,
• Entscheidungen mit Verantwortlichem,
• getroffene Eindämmungs- und Abhilfemaßnahmen,
• abgegebene Meldungen und deren Inhalt,
• externe Kommunikation,
• sowie Fristen und nächste Aktualisierungstermine.

Damit arbeiten Technik, Geschäftsleitung, Datenschutz und Kommunikation auf derselben Grundlage. Ohne dieses Lagebild produziert ein Unternehmen schnell verschiedene Versionen desselben Vorfalls: im BSI-Portal steht etwas anderes als in der Kundenmail, und der Datenschutzbeauftragte rechnet mit einer dritten Zeitlinie.

NIS-2, Datenschutz und andere Meldungen sind nicht dasselbe

Ein erheblicher Sicherheitsvorfall nach BSIG kann zugleich eine Verletzung des Schutzes personenbezogener Daten sein. Dann kann zusätzlich die Meldepflicht nach Artikel 33 DSGVO greifen. Auch dort spielt eine 72-Stunden-Frist eine Rolle. Trotzdem sind Schwelle, Inhalt, Empfänger und Zweck nicht identisch.

Daneben können sektorale Pflichten, vertragliche Informationspflichten, Versicherungsbedingungen, Vorgaben von Kunden oder eine Strafanzeige relevant sein. Bauen Sie deshalb keine einzelne Schaltfläche mit der Beschriftung „Behörde informieren“. Nutzen Sie eine Melde- und Kommunikationsmatrix:

§ 35 BSIG enthält außerdem Unterrichtungspflichten gegenüber Empfängern von Diensten. Das BSI kann bei einem erheblichen Sicherheitsvorfall eine unverzügliche Unterrichtung anordnen. Für bestimmte Sektoren bestehen zudem Pflichten, potenziell betroffene Empfänger über erhebliche Cyberbedrohungen und mögliche Abhilfemaßnahmen zu informieren, wenn deren Interessen überwiegen.

Was bei Vorfällen eines Lieferanten passiert

Ein Cloud-Anbieter, Rechenzentrum oder anderer Dienstleister kann den technischen Vorfall haben. Ihr Unternehmen kann trotzdem eigene Melde- und Informationspflichten treffen, wenn der Vorfall Ihre Dienste erheblich beeinträchtigt.

Deshalb sollte das Lieferantenmanagement nicht nur eine hübsche Sicherheitsanlage zum Vertrag produzieren. Es muss sicherstellen, dass Sie rechtzeitig die Informationen erhalten, die Sie für die eigene Bewertung und Meldung brauchen:

• Zeitpunkt und Art des Vorfalls,
• betroffene Leistungen und Regionen,
• bekannte Auswirkungen,
• mögliche Datenkompromittierung,
• ergriffene Maßnahmen,
• regelmäßige Statusaktualisierungen,
• und einen erreichbaren Ansprechpartner für den Ernstfall.

„Unser Dienstleister untersucht noch“ kann sachlich richtig sein. Es stoppt aber nicht automatisch Ihre eigene Uhr.

Testen Sie nicht nur die Technik, sondern auch die Meldung

Ein Tabletop-Test sollte mehr prüfen als Eindämmung und Wiederanlauf. Bauen Sie bewusst eine unvollständige Faktenlage ein:

• Freitagabend fällt ein kritischer Dienst aus.
• Der Dienstleister liefert nur bruchstückhafte Informationen.
• Es ist unklar, ob Daten abgeflossen sind.
• Ein Kunde fragt öffentlich nach der Ursache.
• Nach 20 Stunden taucht ein neuer Hinweis auf eine größere Reichweite auf.

Prüfen Sie dann:

• Wer bewertet die Erheblichkeit?
• Wer setzt den Zeitpunkt der Kenntniserlangung fest und dokumentiert ihn?
• Wer besitzt den Portalzugang?
• Wer erstellt und genehmigt die 24-Stunden-Meldung?
• Wie werden unbekannte Angaben gekennzeichnet?
• Wer verfolgt die 72-Stunden- und Monatsfrist?
• Wie werden BSI-, Datenschutz-, Kunden- und Versicherermeldung abgestimmt?

Solche Übungen verbinden Meldeprozess und Business Continuity Management. Sie finden nicht nur technische Lücken, sondern auch fehlende Telefonnummern, unklare Freigaben und das berühmte Portalpasswort, das ausschließlich der Kollege im Urlaub kennt.

Typische Fehler

Der erste Fehler ist das Warten auf vollständige Gewissheit. Die Meldekette ist mehrstufig, damit früh mit vorläufigen Informationen gemeldet und später aktualisiert werden kann.

Der zweite Fehler ist eine späte interne Eskalation. Wenn das Security-Team die mögliche Erheblichkeit erkennt, muss der Meldeprozess beginnen – nicht erst nach dem nächsten Jour fixe.

Der dritte Fehler ist, NIS-2 und DSGVO wegen der 72 Stunden in einen Topf zu werfen. Es handelt sich um unterschiedliche Pflichten.

Der vierte Fehler ist ein fehlendes zentrales Lagebild. Dann widersprechen sich technische Analyse, Managementinformation und externe Meldungen.

Der fünfte Fehler ist die Annahme, ein Dienstleister werde schon alles melden. Jede betroffene Einrichtung muss ihre eigene Stellung und Pflicht prüfen.

Und der sechste Fehler ist, nur eine Telefonnummer in den Notfallplan zu schreiben. Eine Meldekette braucht Bewertung, Rollen, Zugänge, Vorlagen, Freigaben und Fristenverfolgung.

Dieser Artikel ordnet die gesetzlichen Vorgaben praktisch ein, ist aber keine Rechtsberatung für Ihren Einzelfall. Gesetze, Verordnungen und behördliche Verfahren können sich ändern – und die zuständigen Stellen rufen uns leider nicht jedes Mal vorher an. Prüfen Sie deshalb bei einem konkreten Vorfall den aktuellen Rechtsstand und holen Sie bei Bedarf Rechtsberatung hinzu.

Interesse geweckt?

Sie möchten die NIS-2-Meldekette so vorbereiten, dass im Ernstfall nicht gleichzeitig Portalzugänge, Zuständigkeiten und Gesetzestexte gesucht werden? Sprechen Sie mit uns. Wir helfen Ihnen, Meldeprozess, Incident Management und Übungen praxistauglich zusammenzubringen.