NIS2 Sicherheitsvorfall melden: 24-Stunden-Frist, Inhalt und Stolperfallen

Wer NIS2-reguliert ist und keine eingespielte Melderoutine hat, wird im Ernstfall eines tun: zu spät melden. Das ist keine Spekulation – es ist das Muster, das sich in den ersten Aufsichtskontakten abzeichnet, die das BSI seit Frühjahr 2026 aufnimmt. § 32 BSIG gibt nur den Rahmen vor, die Praxis entscheidet sich an den ersten 24 Stunden. Wer da improvisiert, landet in genau der Schadensbilanz, die das BSI vermeiden will.

Der Beitrag setzt den Überblick zur NIS2-Registrierung voraus und führt operativ in die Vorfallmeldung. Er richtet sich an IT-Sicherheitsverantwortliche, CISOs und an die Geschäftsleitung, die im Ernstfall unterschreiben wird. Stand: 18. August 2026.

Warum die 24-Stunden-Frist existiert

Eine 24-Stunden-Frist klingt für viele Compliance-Verantwortliche übertrieben. Wer in einer normalen Branche operiert, denkt spontan an Wochenend-Ransomware als Worst Case – und der braucht seine Zeit, bis überhaupt klar ist, was passiert ist. Trotzdem steht die Frist im Gesetz, und das ist kein Zufall.

Sie soll das BSI in die Lage versetzen, andere Unternehmen zu warnen, bevor die gleiche Schwachstelle bei ihnen ankommt. Genau das hat im Frühjahr 2026 mehrfach funktioniert – etwa im Zuge der „Operation Endgame“ gegen Schadsoftware-Familien, an der sich das BSI zusammen mit BKA und internationalen Partnern beteiligt hat. Frühwarnungen binnen Stunden haben verhindert, dass die gleichen Angriffe in anderen Unternehmen liefen. Wer später meldet, verlängert ein Zeitfenster, in dem andere angegriffen werden können. Genau deshalb steht die Frist da, wo sie steht.

Was NIS2 als „erheblich“ versteht

Nicht jeder Vorfall ist meldepflichtig. § 32 Abs. 1 BSIG verlangt die Meldung nur, wenn der Vorfall erheblich ist. Das Gesetz definiert den Begriff nicht abschließend, gibt aber mit § 2 Abs. 5 BSIG und der NIS2-Richtlinie Anhaltspunkte: schwerwiegende Betriebsstörung der Dienste – schon möglich, nicht erst eingetreten. Finanzielle Verluste für die Einrichtung oder andere. Betroffene Personen. Das ist die Spanne.

In der Mandatspraxis hat sich eine Faustregel bewährt, die ich jedem mitgebe, der mich vor der Meldung fragt: lieber einmal zu viel melden als einmal zu wenig. Eine zurückgewiesene Meldung („nicht erheblich“) hat keine Folgen; eine unterlassene Meldung, die das BSI später als erheblich einstuft, dagegen sehr wohl. Die Schwelle liegt deutlich unterhalb des Schadens, der in die Presse kommt – schon ein erfolgversprechender Angriffsversuch auf ein produktives System reicht oft.

Wer meldet – und wer nicht

Meldepflichtig sind besonders wichtige und wichtige Einrichtungen, also genau die Gruppe, die bereits nach § 33 BSIG registriert ist. Wer als Zulieferer, Dienstleister oder Schwesterunternehmen nicht selbst registriert ist, muss keine eigene Meldung ans BSI schicken – sehr wohl aber seinen Auftraggeber so rechtzeitig informieren, dass dieser noch melden kann. Wer in der Lieferkette eines NIS2-Betroffenen steht, sollte den Vertrag auf eine Klausel zur Vorab-Information prüfen. Wer das nicht tut, erfährt vom Vorfall, wenn die Aufsicht schon fragt.

In der Praxis meldet nicht jeder IT-Verantwortliche im Konzern direkt ans BSI, sondern die dafür benannte zentrale Stelle. Klingt banal, war aber bei den ersten Audits, die ich begleitet habe, regelmäßig der Punkt, an dem es hakte. Die Erstmeldung lief ins Leere, weil niemand wusste, wer den Knopf drückt. In Konzernen mit mehreren Standorten oder Töchtern sollte die Verantwortlichkeit pro Standort, pro Geschäftsbereich und pro Schicht klar geregelt sein – und zwar schriftlich, nicht in einer Sharepoint-Seite, die im Notfall nicht zugänglich ist.

Die drei Fristen im Detail

§ 32 BSIG sieht drei gestaffelte Meldungen vor, dazu kommen auf Verlangen des BSI weitere Zwischenmeldungen. Wer die Stufen kennt, kann intern klare Zeitfenster definieren – und genau das ist der Punkt, an dem die meisten Vorbereitungen scheitern oder gelingen.

Erstmeldung binnen 24 Stunden nach Kenntnis. Knapp gehalten: was ist passiert, wann, welche Systeme sind betroffen, welche Auswirkungen sind absehbar? Keine Ursachenanalyse, nur die Tatsache, dass etwas vorliegt. Wer hier mehr schreibt als nötig, verzettelt sich.

Vorfallmeldung binnen 72 Stunden. Vertiefung mit einer ersten Einschätzung zu Schwere, Auswirkung und vermuteter Ursache, dazu die ergriffenen Sofortmaßnahmen. Lückenhaftigkeit ist erlaubt – das BSI weiß, dass Ermittlungen Zeit brauchen, und nimmt lieber eine ehrliche Lücke als eine ausgeschmückte Vermutung.

Abschlussmeldung spätestens einen Monat nach der Vorfallmeldung. Vollständige Chronologie, belegte Ursache, betroffene Daten und Systeme, Bewertung der Folgen, ergriffene und geplante Folgemaßnahmen. Wer innerhalb des Monats noch ermittelt, kann eine Fristverlängerung beantragen – das BSI ist hier pragmatisch, erwartet aber eine plausible Begründung und einen realistischen neuen Termin, nicht „drei Monate mehr“.

Dazu kommen Zwischenmeldungen, die das BSI jederzeit anfordern kann – etwa wenn sich der Sachstand deutlich ändert. Wer auf so eine Anfrage nicht binnen Stunden antworten kann, hat die operative Bereitschaft nicht im Griff.

Was in die Erstmeldung gehört

Schlank gehalten, absichtlich. Das BSI will in den ersten 24 Stunden keine Ursachenanalyse, sondern eine schnelle Einordnung: Einzelfall oder sektoral? Daraus ergibt sich, was die Behörde parallel unternimmt – und damit, ob andere Unternehmen gewarnt werden müssen. Wer zu viel erzählt, lenkt vom Wesentlichen ab.

Was in der Erstmeldung tatsächlich erwartet wird: Name der Einrichtung, die im BSI-Portal hinterlegten Kontaktdaten, Zeitpunkt der Kenntniserlangung, knappe Beschreibung des Vorfalls, betroffene Systeme und Dienste, vorläufige Einschätzung der Auswirkungen, soweit bekannt. Wer zu diesem Zeitpunkt noch keine abschließende Aussage zur Ursache treffen kann, sagt das offen. Das BSI akzeptiert ausdrücklich vorläufige Meldungen – was viele nicht wissen, weil sie aus der PR-Welt kommen, in der „wir melden, wenn wir etwas zu sagen haben“ als Tugend gilt.

Ein Punkt, der in der Praxis regelmäßig vergessen wird: auch eine Verdachtslage kann meldepflichtig sein. Wer ein typisches Angriffsmuster erkennt, ohne den Erfolg sicher belegen zu können, sollte die Meldung nicht aufschieben, bis die forensische Bestätigung vorliegt. Die Frist beginnt mit der Kenntnisnahme – und die ist bereits bei einem begründeten Verdacht gegeben.

Was in die Vorfallmeldung nach 72 Stunden gehört

Innerhalb von 72 Stunden muss die Meldung substanzieller werden. Das BSI erwartet eine erste Ursachenhypothese, eine Bewertung der Schwere (gering / mittel / hoch / kritisch), eine erste Einschätzung der grenzüberschreitenden Wirkung und die ergriffenen Sofortmaßnahmen. Wer hier Lücken lässt, muss erklären, warum – und das fällt schwer, wenn die Ursachenforschung eigentlich gerade erst angelaufen ist.

Inhaltlich hat sich eine Struktur bewährt, die sich an etablierten CERT-Standards orientiert: Was? (kurz beschrieben), Wann? (Zeitlinie mit den erkannten Ereignissen), Wie? (vermuteter Angriffsvektor), Wen? (betroffene Systeme und Daten), Wirkung? (auf Dienste, Daten, Personen), Maßnahmen? (Eindämmung, Wiederherstellung). Sechs Felder, die praktisch jede Rückfrage des BSI abdecken. Wer die ausfüllt, hat eine belastbare Meldung.

Was viele unterschätzen: das BSI will in dieser Phase eine aktive Rückmeldung, kein passives Warten auf Ermittlungsergebnisse. Wer am Tag drei noch keine Bewertung der Schwere hat, muss erklären, warum nicht. Wer keine Sofortmaßnahmen ergriffen hat, wird gefragt, warum nicht. Stille ist die schlechteste Antwort, die man geben kann.

Die Abschlussmeldung nach spätestens einem Monat

Die Abschlussmeldung ist die Chance, einen Vorfall sauber zu dokumentieren. Was hier landet, wird später im internen Audit, in der Geschäftsleitungssitzung und möglicherweise vor Gericht vorgelegt. Vollständige Chronologie, belegte Ursache, Übersicht der betroffenen Daten und Systeme, Bewertung der Folgen – finanziell, operativ, reputational – und die ergriffenen und geplanten Folgemaßnahmen. Wer hier oberflächlich arbeitet, baut eine Akte, die bei der nächsten Prüfung gegen das Unternehmen verwendet wird.

Für die Geschäftsleitung besonders wichtig: in der Abschlussmeldung steht auch, was zur Vermeidung in Zukunft getan wird. Genau daran zeigt sich, ob das Unternehmen aus dem Vorfall lernt – oder ob beim nächsten Mal das gleiche Szenario wieder läuft. Aufsichtsbehörden lesen diesen Teil genauer als den Rest. Wer hier „nein, wir ändern nichts“ schreibt, hat die Prüfung danach schon verloren.

Wenn der Monat nicht reicht – forensische Untersuchungen dauern länger, externe Gutachten brauchen Zeit –, kann die Frist verlängert werden. Das BSI ist hier pragmatisch, wenn die Begründung plausibel ist und der neue Termin realistisch. Wer ohne Vorankündigung am Tag 31 noch nicht liefern kann, fällt negativ auf, obwohl die Verlängerung an sich kein Problem wäre.

Krisenkommunikation: was das BSI wirklich will

Wer mit der Meldung ans BSI beginnt, sollte die Erwartungshaltung der Behörde kennen. Das BSI will nicht die Pressearbeit des Unternehmens übernehmen und will auch nicht in jedes interne Krisenmeeting eingebunden werden. Es will valide Informationen, einen klaren Ansprechpartner und eine Rückmeldung, wenn sich der Sachstand ändert. Mehr nicht. Wer diese Erwartung erfüllt, wird vom BSI als professioneller Partner behandelt. Wer sie nicht erfüllt, fängt an, sich ungeplant Aufsichtsdruck einzuhandeln.

In der Praxis beobachtet man, dass die Unternehmen, die am besten durch ein NIS2-Vorfallsverfahren kommen, einen einzigen Punkt internalisiert haben: sie melden lieber zu früh als zu spät und lieber zu viel als zu wenig. Das ist das genaue Gegenteil der PR-Logik, in der „wir kommunizieren, wenn wir etwas zu sagen haben“ als Tugend gilt. Im Aufsichtskontext ist Schweigen verdächtig – Reden ist professionell. Wer das internalisiert, hat schon die halbe Miete.

Datenschutz-Schnittstelle: parallel zu Art. 33 DSGVO

Sobald bei einem Sicherheitsvorfall personenbezogene Daten betroffen sind, läuft parallel die DSGVO-Meldung nach Art. 33 an die zuständige Aufsichtsbehörde – in Deutschland je nach Sitz des Unternehmens an die jeweilige Landesdatenschutzbehörde. Die DSGVO-Frist beträgt ebenfalls 72 Stunden, beginnt aber mit der Kenntnis der Verletzung, nicht der Meldung ans BSI. Inhaltlich deckt sie einen Teil der NIS2-Angaben ab – aber nur einen Teil.

Wer beide Meldungen aus einer Hand macht, spart sich Doppelerfassung. Praktisch heißt das: ein gemeinsamer Vorfallbericht, aus dem zwei spezifische Meldungen abgeleitet werden. Datenschutzbeauftragter und NIS2-Meldestelle müssen früh im Verfahren miteinander sprechen, nicht erst am Tag drei. In Unternehmen, die das versäumt haben, entstehen regelmäßig zwei parallele Berichte mit widersprüchlichen Zahlen – und beide Meldungen verlieren an Glaubwürdigkeit.

Löschfristen sind ein zweiter Schnittpunkt. Wer nach Art. 33 DSGVO meldet, muss gleichzeitig die Meldepflicht nach § 32 BSIG im Auge behalten, die eine Dokumentation über drei Jahre verlangt. Beide Dokumentationen sollten im gleichen System liegen, mit unterschiedlichen Zugriffsrechten.

Und dann ist da noch Art. 34 DSGVO – die Meldung an betroffene Personen. Die greift nur bei hohem Risiko für deren Rechte und Freiheiten; die NIS2-Meldung löst sie nicht aus. Wer beide Regelwerke in der Vorfallbewertung verschmilzt, läuft Gefahr, entweder zu viel oder zu wenig gegenüber den Betroffenen zu kommunizieren. Beides ist teuer – das eine als Vertrauensverlust, das andere als Bußgeld.

Was passiert, wenn Sie nicht oder zu spät melden

§ 65 BSIG ist deutlich. Wer eine Meldung nach § 32 Abs. 1 Satz 1 BSIG nicht, nicht richtig, nicht vollständig oder nicht rechtzeitig abgibt, handelt ordnungswidrig. Bei besonders wichtigen Einrichtungen reicht der Bußgeldrahmen bis 10 Millionen Euro oder 2 Prozent des Konzernumsatzes, bei wichtigen Einrichtungen bis 7 Millionen oder 1,4 Prozent. Das BSI hat für Herbst 2026 eine erste Welle von Aufsichtsverfahren angekündigt, in denen vor allem die Meldung im Fokus stehen soll – wer hier auffällt, ist schneller auf der Tagesordnung der Behörde, als ihm lieb ist.

Das Bußgeld ist allerdings selten der größte Schaden. Eine öffentlich bekannt gewordene verzögerte Meldung wirkt in der Geschäftswelt wie ein Vertrauensverlust. Kunden fragen nach, Auftraggeber prüfen Verträge, Wettbewerber positionieren sich. Wer also aus Sorge vor Imageschaden die Meldung verzögert, handelt fast immer kontraproduktiv – das BSI bewertet pünktliche Meldungen deutlich milder als verschleppte. Wer das einmal verstanden hat, lässt die Meldung laufen.

Ein Beispiel aus der Aufsichtspraxis, anonymisiert, Stand Sommer 2026: Ein mittelständischer Energieversorger registriert einen Ransomware-Angriff am späten Freitagabend. Die IT informiert die Geschäftsleitung am Samstagmorgen; die Meldung ans BSI geht am Montag um 14 Uhr ein, 60 Stunden nach Kenntnis. Die anschließende Aufsichtsprüfung beanstandet nicht den Vorfall selbst, sondern ausschließlich die verzögerte Meldung. Das Bußgeld fällt moderat aus, der Reputationsschaden bleibt gering. Hätte das Unternehmen einen Tag länger gewartet, wäre das Bußgeld mehrfach höher ausgefallen. Genau dieser Druck erzeugt den Lerneffekt, den die Aufsicht beabsichtigt.

Die häufigsten Stolperfallen

Was ich in den ersten Audits und Mandaten immer wieder sehe, sind fünf Stolperfallen, die in fast jedem Unternehmen auftauchen – und die alle mit derselben Grundsünde zu tun haben: zu wenig geübt.

Die Kenntnis verzögert sich. Das BSI rechnet ab dem Moment, in dem eine Person im Unternehmen erkennt, dass ein Vorfall vorliegt. Wer am Montag erfährt, dass in der Nacht von Freitag auf Samstag etwas auffällig war, meldet ab Montag – nicht ab Samstag. Aber wer erst am Mittwoch davon erfährt, weil eine Mitarbeiterin in einem anderen Team das Ereignis für „nicht so schlimm“ gehalten hat, fängt am Mittwoch an. Genau diese Verzögerung ist der häufigste Grund, warum die 24-Stunden-Frist gerissen wird. Wer ein funktionierendes Ticket-System hat, in dem IT-Vorfälle konsequent erfasst werden, schneidet hier deutlich besser ab.

Die Bewertung fehlt. „Ist das erheblich?“ – das ist die Frage, die viele am längsten aufhält. Wer keine Bewertungskriterien dokumentiert hat, ringt im Ernstfall tagelang um eine Antwort; wer eine Matrix aufgesetzt hat, die nach Auswirkungen auf Dienste, Daten und Personen sortiert, trifft die Entscheidung binnen einer Stunde. Der Unterschied zwischen den beiden Fällen ist die Vorbereitung – nicht die Intelligenz.

Die falschen Leute melden. Die Erstmeldung an das BSI sollte durch die Person gehen, die offiziell registriert ist und entsprechende Zugänge hat. Wer stattdessen über die IT-Abteilung einen beliebigen Mitarbeiter schickt, läuft Gefahr, dass die Meldung im BSI-Portal nicht zugeordnet werden kann. Klingt nach Selbstverständlichkeit, ist aber einer der häufigsten Gründe für „die Meldung ist angeblich raus, das BSI hat aber nichts“.

Die Sprache ist zu vage. „Wir hatten einen Sicherheitsvorfall“ hilft dem BSI nicht. Die Behörde braucht konkrete Angaben: welche Systeme, welche Datenmengen, welche Zeiträume. Wer eine leere Hülle meldet, muss am nächsten Tag nachlegen – und fängt damit praktisch bei null an. In der ersten Meldung zählt jedes Detail, auch wenn es banal klingt.

Die Vertretung greift nicht. Wer am Wochenende erkennt, dass ein Vorfall vorliegt, aber die zuständige Person erst am Montag im Dienst ist, verliert unter Umständen einen halben Tag. Eine 24/7-Erreichbarkeit für die NIS2-Meldestelle ist deshalb keine Übertreibung, sondern operative Notwendigkeit. Das muss nicht die Geschäftsführung sein – ein eingespielter Bereitschaftsdienst der IT reicht, wenn er die Stellvertretung kennt und das BSI-Portal bedienen kann.

Wie Sie den Ablauf im Unternehmen verankern

Wer einmal eine NIS2-Meldung erfolgreich durchgespielt hat, weiß: das Verfahren entsteht nicht in der Notfall-Sitzung, sondern in der Vorbereitung. Vier Bausteine gehören vorab aufgesetzt, dokumentiert und regelmäßig geübt – sonst kennen sie im Ernstfall die Hälfte der Beteiligten nicht mehr.

Das Meldeformular ist das eine. Ein vorgefertigtes Template, das alle Pflichtangaben der Erstmeldung abfragt und mit dem BSI-Portal kompatibel ist. Wer das Formular erst im Ernstfall entwirft, verliert Zeit, die er nicht hat. Das Formular sollte auch Felder enthalten, die im Moment der Erstmeldung noch unbekannt sind – damit klar ist, was später nachgeliefert wird und was nicht.

Das Bereitschaftshandbuch ist das andere. Wer ist wann erreichbar, wie ist die Vertretung geregelt, wie wird eskaliert, wer spricht mit dem BSI? Steht das nicht schriftlich – mit Telefonnummern, nicht auf einer Sharepoint-Seite, die im Notfall nicht zugänglich ist –, hat man im Ernstfall kein Handbuch, sondern eine Erwartungshaltung. Die reicht nicht.

Die Übung ist das dritte. Eine simulierte NIS2-Meldung einmal pro Quartal, keine vollständige Krisenübung, sondern ein Tabellen-Test: ein fiktiver Vorfall wird in das Meldeformular eingetragen, die internen Eskalationszeiten werden durchgespielt, das BSI-Portal wird getestet. Wer solche Tests regelmäßig macht, verkürzt die Reaktionszeit im Ernstfall deutlich – und wer nach der Übung feststellt, dass die Vertretung fehlt oder die Kontaktliste veraltet ist, hat immerhin vor dem Ernstfall davon erfahren.

Und viertens die Eskalationsmatrix: welche Schweregrade werden automatisch welchen Empfängern zugeordnet, welche Geschäftsleitungsebene wird wann eingebunden? Wer das vorher festlegt, vermeidet Diskussionen über Zuständigkeiten während der ersten 24 Stunden – und genau dort, wo die Diskussionen am teuersten werden.

Einordnung: NIS2-Meldung als Teil der Compliance-Architektur

Die Vorfallsmeldung nach § 32 BSIG steht nicht allein. Sie ist Teil eines größeren Pflichtenkatalogs, der mit der Registrierung beim BSI beginnt, über die Risikomanagement-Maßnahmen nach § 30 BSIG läuft und in der persönlichen Verantwortung der Geschäftsleitung nach § 38 BSIG mündet. Wer nur die Vorfallsmeldung isoliert betrachtet, übersieht, dass das BSI bei späteren Audits nicht die einzelne Meldung prüft, sondern die Architektur dahinter.

Wer parallel unter der KI-Verordnung als Anbieter eines kritischen KI-Systems auftritt, sollte beachten, dass die dortigen Transparenzpflichten nicht automatisch durch die NIS2-Meldung erfüllt werden – auch wenn es auf den ersten Blick so aussieht. Und wer nach CRA als Hersteller verpflichtet ist, hat mit dem Cyber Resilience Act eine eigene Meldesystematik an die Marktüberwachungsbehörden. Beide schließen sich nicht aus, müssen aber bewusst parallel betrieben werden, sonst überschneiden sich die Pflichten unklar. Auch die KI-Haftungsrichtlinie verlangt bei Personenschäden eine zivilrechtliche Beweislastumkehr.

Was bleibt: ein Unternehmen, das seine NIS2-Meldung sauber aufgesetzt hat, kann sie in den meisten anderen Compliance-Kontexten wiederverwenden – als Template für interne Eskalationen, als Dokumentationsbasis für Vertragspartner, als Vorlage für Krisenkommunikation. Wer die Meldung nicht nur als Pflichtübung begreift, sondern als operativen Standard, gewinnt mehrfach – und hat am Ende nicht nur eine NIS2-konforme Meldung, sondern einen Krisenstandard, der auch ohne Aufsichtsdruck trägt.

Fazit

Die NIS2-Vorfalls­meldung ist die Königsdisziplin der operativen NIS2-Compliance. Wer hier vorbereitet ist, gewinnt im Ernstfall Stunden – und damit Ruhe. Wer hier improvisiert, zahlt das doppelt und dreifach.

Vier Bausteine entscheiden: ein dokumentiertes Meldeformular, ein eingespielter Bereitschaftsdienst, eine klare Eskalationsmatrix und regelmäßige Übungen. Wer die vier im August 2026 nicht hat, kann sie mit einer Projektwoche aufsetzen. Wer sie hat, kann die NIS2-Vorfalls­meldung als das behandeln, was sie sein sollte: eine belastbare Routine, die im Ernstfall funktioniert.

Wer die Meldung als Pflicht begreift, die man irgendwie erledigt, wird im Ernstfall genau die Stunden verlieren, die er nicht hat. Wer sie als operativen Prozess versteht, der ständig trainiert und gepflegt wird, gewinnt diese Stunden zurück – und mit ihnen die Ruhe, im Ernstfall die richtige Entscheidung zu treffen, statt in der falschen Reihenfolge die falschen Leute zu informieren.