Die Meldepflicht ist ein Erkennungsproblem
Liest man die Meldevorschriften von NIS2, klingen sie nach einer Dokumentationsaufgabe: drei Meldungen, jeweils ein paar definierte Felder, an ein Behördenportal. Genau diese Deutung führt in die Irre. Die Pflicht lautet nicht „schreiben Sie einen Bericht“. Sie lautet: „bemerken Sie einen erheblichen Sicherheitsvorfall und geben Sie innerhalb von 24 Stunden nach Kenntniserlangung eine Erstmeldung ab“. Das entscheidende Wort ist Kenntnis. Die 24-Stunden-Uhr beginnt nicht, wenn Sie die Analyse abgeschlossen haben; sie beginnt in dem Moment, in dem der Vorfall für Sie erkennbar ist. Wenn Ihr Logging und Monitoring eine ernste Kompromittierung erst nach drei Tagen sichtbar machen, sind Sie bereits drei Tage in einer 24-Stunden-Frist, bevor überhaupt jemand ein Wort tippt.
Die ehrliche Frage lautet also nicht „schaffen wir das Formular rechtzeitig?“, sondern „erkennen wir einen erheblichen Vorfall rechtzeitig?“. Für die meisten Mittelständler, die NIS2 neu in den Anwendungsbereich zieht — Hersteller, Energieversorger, Entsorger, Lebensmittelbetriebe, digitale Anbieter, die sich nie als regulierte Infrastruktur verstanden haben —, lautet die Antwort heute: nein. Sie haben Firewalls, Virenschutz und Backups. Sie haben keine Erkennung: keine zentrale Log-Sammlung, keine auf ihr „erheblich“ abgestimmte Alarmierung und niemanden, dessen Aufgabe das Hinschauen ist. Die Meldepflicht macht diese Lücke lediglich rechtlich sichtbar.
Sind Sie betroffen? Niemand schickt einen Brief
NIS2 — formal die Richtlinie (EU) 2022/2555 — hat das alte NIS-Regime von einer kurzen Liste benannter Betreiber auf ganze Sektoren ausgeweitet, sortiert nach Größe. Entscheidend: Es gibt kein Register, in das Sie eingetragen werden, und keine Benachrichtigung, dass Sie erfasst sind. Die Regelung arbeitet mit Selbstidentifikation: Sie sind selbst dafür verantwortlich, Ihre Betroffenheit festzustellen, sich bei der zuständigen Behörde zu registrieren und die Pflichten zu erfüllen — ob Sie jemand dazu auffordert oder nicht. „Uns hat niemand kontaktiert“ ist keine Verteidigung.
Besonders wichtige und wichtige Einrichtungen
Der Anwendungsbereich hängt an zwei Dingen: Ihrem Sektor und Ihrer Größe. Die Richtlinie unterscheidet besonders wichtige und wichtige Einrichtungen. Sie unterscheiden sich vor allem in der Aufsicht (besonders wichtige Einrichtungen werden proaktiv beaufsichtigt, wichtige erst reaktiv, wenn etwas passiert ist) — die Meldepflichten sind praktisch dieselben. Als grobe Orientierung: Große Unternehmen (etwa ab 250 Beschäftigten oder über 50 Mio. € Umsatz und 43 Mio. € Bilanzsumme) in den Sektoren mit hoher Kritikalität sind besonders wichtig; mittlere Unternehmen (etwa ab 50 Beschäftigten oder über 10 Mio. € bei Umsatz und Bilanzsumme) fallen als wichtig darunter, ebenso große Unternehmen in den „sonstigen kritischen“ Sektoren. Einige Typen — DNS-Anbieter, TLD-Registrare, qualifizierte Vertrauensdiensteanbieter, bestimmte TK-Anbieter und als kritisch eingestufte Betreiber — sind unabhängig von der Größe erfasst.
Schätzen Sie das nicht über den Daumen. Die Sektoranhänge und die Größenarithmetik haben Randfälle — Konzernstrukturen, Teiltätigkeiten, Beschäftigtenzahl gegen Umsatz —, die über die Einstufung entscheiden, und ein Fehler schneidet in beide Richtungen: unnötige Kosten bei Über-, unkalkulierte Haftung bei Untererfassung. Dieser Text stammt von einem Engineer, nicht von einem Anwalt; die Einstufung selbst ist eine juristische Bewertung, und genau hier verdienen ein qualifizierter Berater und die Handreichungen der Behörde ihr Honorar.
Die Pflicht zur Selbstidentifikation
Weil die Betroffenheit selbst festzustellen ist, ist das erste Ergebnis gar nicht technisch: eine belastbare, schriftliche Scoping-Entscheidung. Welche Einheit, welche Sektoren, welche Größenklasse — und die Begründung, datiert und aufbewahrt. Fragt eine Aufsicht später, warum Sie sich registriert oder nicht registriert haben, ist dieses Dokument Ihre Antwort. Es ist heute günstig zu erstellen und nach einem Vorfall teuer zu rekonstruieren.
Die Meldekaskade nach Artikel 23
Artikel 23 der Richtlinie schreibt eine gestufte Kaskade vor, keine einzelne Meldung. Jede Stufe hat ihre eigene Frist und ihren eigenen Pflichtinhalt, und die späteren Stufen aktualisieren die früheren, sobald Ihr Bild klarer wird.
Was jede Stufe tragen muss, im Klartext:
- Erstmeldung — binnen 24 Stunden nach Kenntnis. Ein kurzes erstes Signal, keine Analyse. Sie kennzeichnet, ob der Vorfall vermutlich auf rechtswidriges oder böswilliges Handeln zurückgeht und ob er grenzüberschreitende Auswirkungen haben könnte. Mehr braucht sie im Wesentlichen nicht — was genau der Grund ist, warum der Engpass das Bemerken ist, nicht das Schreiben.
- Folgemeldung — binnen 72 Stunden. Aktualisiert die Erstmeldung und ergänzt eine erste Bewertung: Schweregrad und Auswirkungen sowie, soweit verfügbar, Kompromittierungsindikatoren (IoCs). Hier legen Sie sich auf ein erstes belastbares Bild fest.
- Abschlussmeldung — binnen eines Monats. Eine ausführliche Beschreibung des Vorfalls samt Schweregrad und Auswirkungen, die Art der Bedrohung bzw. die wahrscheinliche Ursache, die ergriffenen und laufenden Gegenmaßnahmen sowie etwaige grenzüberschreitende Folgen. Dauert der Vorfall zum Monatsende noch an, melden Sie dann den Fortschritt und reichen die Abschlussmeldung binnen eines Monats nach seiner Bewältigung nach.
Auslöser ist ein „erheblicher“ Vorfall, und die Richtlinie definiert ihn: einer, der schwerwiegende Betriebsstörungen oder finanzielle Verluste bei Ihnen verursacht hat oder verursachen kann, oder erhebliche materielle oder immaterielle Schäden bei anderen. Die zuständige Behörde kann zudem jederzeit eine Zwischenmeldung anfordern. Wenn Ihnen die 72-Stunden-Frist aus der DSGVO bekannt vorkommt: Das ist derselbe Reflex, angewandt auf die Betriebssicherheit — und es lohnt sich, das zusammen mit der 72-Stunden-Regel in der Praxis zu lesen, denn ein einziges Ereignis kann beide Pflichten auslösen.
Deutschland: Das Gesetz ist in Kraft
Lange lautete die ehrliche deutsche Antwort: „Die Richtlinie gibt es, das nationale Gesetz noch nicht.“ Das hat sich geändert. Die EU-Umsetzungsfrist war der 17. Oktober 2024, den Deutschland um mehr als ein Jahr verpasst hat — doch das NIS-2-Umsetzungsgesetz (NIS2UmsuCG) wurde am 13. November 2025 vom Bundestag beschlossen und trat am 6. Dezember 2025 in Kraft. Die Pflichten sind damit geltendes deutsches Recht, umgesetzt über das BSI-Gesetz, und keine ferne Aussicht mehr, die man aussitzen könnte.
Zuständige Behörde ist das BSI (Bundesamt für Sicherheit in der Informationstechnik). Es betreibt die Registrierung und das Meldeportal, und die Umsetzung vergrößert den Kreis der erfassten Organisationen drastisch — von einigen tausend KRITIS-Betreibern auf eine Zahl, die der Gesetzgeber mit rund 29.000 bis 30.000 Einrichtungen beziffert hat. Wenn Sie ein mittelständischer Hersteller oder Zulieferer sind, der nie mit dem BSI zu tun hatte, ist das die Verschiebung: Sie müssen sich nun selbst registrieren und meldefähig sein. Da die genauen Registrierungsmodalitäten und Fristen sich noch bewegen können, prüfen Sie den aktuellen Stand an den veröffentlichten Handreichungen des BSI selbst — und nicht an einem Blog, auch nicht an diesem.
Was „24-Stunden-fähig“ wirklich verlangt
Streift man die juristische Hülle ab, ist das Ziel konkret: An jedem beliebigen Tag können Sie einen erheblichen Vorfall bemerken und binnen 24 Stunden melden. Diese Fähigkeit hat vier Teile, und nur einer davon ist ein Dokument.
Erkennung ist der Engpass
Der schwere, teure Teil ist, den Vorfall überhaupt sichtbar zu machen. Das heißt: Logs tatsächlich zentral gesammelt aus den Systemen, die zählen, lange genug aufbewahrt, um nützlich zu sein, und — der Schritt, den die meisten überspringen — eine Alarmierung, die so abgestimmt ist, dass ein wirklich erhebliches Ereignis über dem täglichen Rauschen aufscheint. Ein Log, das niemand abfragt, ist keine Erkennung; es ist Speicher. Das ist Detection Engineering, und es überlappt stark mit dem Absichern der Systeme an sich — weshalb dieselben Disziplinen wie beim Absichern von LLM- und Software-Anwendungen hier greifen: Kennen Sie Ihre Assets, beobachten Sie die Grenzen, und rechnen Sie damit, rekonstruieren zu müssen, was passiert ist.
Erkennung verstärkt sich zudem mit gutem Logging-Design. Wenn Ihre Systeme — auch die KI-Systeme — standardmäßig strukturierte, abfragbare Audit-Logs ausgeben, wird aus „rekonstruieren, was passiert ist“ ein Nachmittag statt einer Ausgrabung. Es ist dasselbe Argument, das ich für das Log-Schema nach Artikel 12 des EU AI Act gemacht habe: Legen Sie fest, wie ein brauchbarer Ereignisdatensatz aussieht, bevor der Vorfall eintritt, nicht während. Erkennungsregeln zu schreiben ist eine eigene Disziplin — unser eigener Multi-Agenten-KQL-Generator für Microsoft Sentinel existiert genau deshalb, weil es langsame Expertenarbeit ist, aus „wir wollen X erwischen“ eine validierte Detection-Query zu machen, die sich mit jedem korrekt ausgelösten Alarm auszahlt.
Die anderen drei Teile sind leichter, und ihre Leichtigkeit sollte Sie nicht dazu verleiten, sie für die ganze Aufgabe zu halten:
- Ein Incident-Response-Runbook. Eine kurze, geübte Prozedur: Wer entscheidet, dass ein Ereignis ein „erheblicher Vorfall“ ist, wie die Uhr gestartet und dokumentiert wird, wer meldet und wie die 72-Stunden- und die Monatsfrist nachgehalten werden. Festgelegt an einem ruhigen Nachmittag, nicht um 2 Uhr nachts.
- Eine benannte verantwortliche Person. Ein zuständiger Owner für Erkennung und Meldung, mit Vertretung. „Die ganze IT“ heißt niemand, und die 24-Stunden-Uhr pausiert nicht für Urlaub oder Kündigungsfristen.
- Vorgefertigte Meldevorlagen. Die Felder für Erst- und Folgemeldung vorab bis auf ein Gerüst ausgefüllt, sodass Sie unter Druck ein Formular ausfüllen und keines verfassen. Das ist der Teil, der wirklich nur Papierkram ist — machen Sie ihn einmal, im Voraus.
Was ich nicht täte: am ersten Tag eine große SIEM-Plattform und einen Managed-Detection-Vertrag kaufen, nur weil eine Compliance-Frist aufgetaucht ist. Für einen Mittelständler ist das oft ein Weg, viel Geld in Werkzeuge zu stecken und die Vorfälle, auf die es ankommt, trotzdem nicht zu erkennen — weil die Alarme nicht abgestimmt sind und niemand sie verantwortet. Beginnen Sie bei den Vorfallstypen, die für Ihren Betrieb tatsächlich „erheblich“ wären, instrumentieren Sie dafür, und wachsen Sie. Das richtig zu dimensionieren — statt es zu maximieren — ist der Punkt.
Wo Tippel ins Spiel kommt
NIS2 ist für Sie nicht in erster Linie ein Rechtsproblem, das man mit einem Ordner voller Richtlinien löst; es ist eine Erkennungs- und Reaktionsfähigkeit, die Sie entweder haben oder nicht. Tippel baut diese Fähigkeit als Engineering: herausarbeiten, wie ein „erheblicher Vorfall“ für Ihre konkreten Systeme aussieht, die richtigen Logs an einen Ort bringen, Erkennung schreiben, die echte Ereignisse sichtbar macht, ohne Sie im Rauschen zu ertränken, und Ihnen ein Runbook und Vorlagen hinterlassen, die auch eine Nicht-Spezialistin führen kann. On-Premise dort, wo die Daten das Haus nicht verlassen dürfen.
Wenn Ihnen gerade klar geworden ist, dass Sie betroffen sind, und Sie auf eine 24-Stunden-Uhr blicken, die Sie derzeit nicht halten könnten, ist ein zugeschnittener KI-Readiness-Check ein sinnvoller Weg, die echte Lücke günstig zu finden — oder Sie nehmen einfach Kontakt auf und schildern Ihr Setup. Die rechtliche Einstufung gehört zum Anwalt; das Erkennungsproblem gehört zum Engineer.