NIS2 Monitoring: Welche Anforderungen IT- und Plattform-Teams an Logging, Erkennung und Meldung erfüllen müssen

NIS2 Monitoring ist für IT- und Plattform-Teams einer der praktischsten Teile der neuen Cybersicherheitsregulierung: Wer einen erheblichen Sicherheitsvorfall nicht erkennt, nicht rekonstruieren und nicht schnell bewerten kann, schafft auch die Meldefristen nicht. Die NIS2-Anforderungen schreiben kein bestimmtes Werkzeug vor. Sie verlangen aber Risikomanagementmaßnahmen zur Bewältigung von Sicherheitsvorfällen und zur Aufrechterhaltung des Betriebs – und sie setzen feste Fristen, die ab Kenntniserlangung laufen.

Dieser Beitrag erklärt, wer betroffen ist, welche Maßnahmen aus Art. 21 der Richtlinie (EU) 2022/2555 und § 30 BSIG Monitoring, Logging und Incident Handling betreffen, wie die NIS2-Meldepflicht nach Art. 23 und § 32 BSIG funktioniert und wie der Stand der deutschen Umsetzung im Oktober 2026 ist. Am Ende finden Sie eine Checkliste, die jede Anforderung konkreten Observability-Fähigkeiten und typischen Audit-Nachweisen zuordnet.

Wer ist von NIS2 betroffen?

Die Richtlinie unterscheidet wesentliche und wichtige Einrichtungen; das deutsche BSI-Gesetz spricht von besonders wichtigen und wichtigen Einrichtungen. Beide Gruppen müssen dieselben Kategorien von Risikomanagementmaßnahmen umsetzen und erhebliche Sicherheitsvorfälle melden. Unterschiede gibt es vor allem bei der Aufsicht und bei den Bußgeldobergrenzen.

Ob ein Unternehmen erfasst ist, entscheidet sich an zwei Fragen:

• Sektor: Anhang I der Richtlinie (in Deutschland Anlage 1 zum BSIG) umfasst Sektoren mit hoher Kritikalität, etwa Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur (zum Beispiel Cloud-Anbieter, Rechenzentrumsdienste, DNS und Content Delivery Networks), Verwaltung von IKT-Diensten im B2B-Bereich (Managed Services und Managed Security Services) sowie Weltraum. Anhang II beziehungsweise Anlage 2 nennt weitere Sektoren wie Post- und Kurierdienste, Abfallbewirtschaftung, Chemie, Lebensmittel, verarbeitendes Gewerbe (unter anderem Medizinprodukte, Elektronik, Maschinen und Fahrzeuge), Anbieter digitaler Dienste und Forschung.
• Größe: Nach § 28 BSIG ist eine Einrichtung in einem gelisteten Sektor in der Regel eine wichtige Einrichtung, wenn sie mindestens 50 Mitarbeitende beschäftigt oder einen Jahresumsatz und eine Jahresbilanzsumme von jeweils über 10 Millionen Euro aufweist. Besonders wichtig ist eine Einrichtung aus Anlage 1 ab 250 Mitarbeitenden oder bei über 50 Millionen Euro Umsatz und zugleich über 43 Millionen Euro Bilanzsumme. Die Schwellen folgen der KMU-Empfehlung 2003/361/EG der Kommission.

Einige Einrichtungen sind unabhängig von der Größe erfasst, etwa qualifizierte Vertrauensdiensteanbieter, Top-Level-Domain-Registries und DNS-Diensteanbieter. Betreiber kritischer Anlagen gelten stets als besonders wichtige Einrichtungen. Und auch wer selbst nicht reguliert ist, aber eine Plattform für betroffene Kunden betreibt, sollte mit vertraglichen NIS2-Anforderungen rechnen, denn die Sicherheit der Lieferkette gehört selbst zu den Pflichtmaßnahmen.

Art. 21 und § 30 BSIG: Maßnahmen mit Bezug zu Monitoring und Logging

Art. 21 Abs. 2 der Richtlinie und § 30 Abs. 2 BSIG nennen zehn Mindestmaßnahmen, die auf einem gefahrenübergreifenden Ansatz beruhen müssen. Vier davon betreffen Observability-Teams unmittelbar:

• Bewältigung von Sicherheitsvorfällen: Sie brauchen einen definierten Prozess, um Vorfälle zu erkennen, zu analysieren, einzudämmen und zu beheben. Ohne Monitoring und Logging gibt es keine Erkennung – hier wird Telemetrie zum Compliance-Thema.
• Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement: Sie müssen wissen, ob Ihre Dienste verfügbar sind, wie schnell Sie wiederherstellen und ob Ihre Wiederherstellungsverfahren tatsächlich funktionieren.
• Konzepte und Verfahren zur Bewertung der Wirksamkeit: Kennzahlen wie Erkennungszeit, Reaktionszeit und wiederkehrende Ursachen eignen sich gut als Nachweis, dass Maßnahmen wirken.
• Personalsicherheit, Zugriffskontrolle und Management von Anlagen: Ein aktuelles Inventar der Dienste und ihrer Abhängigkeiten sowie Zugriffsprotokolle für sensible Systeme helfen bei Erkennung und Untersuchung.

Die Maßnahmen sollen den Stand der Technik einhalten, und § 30 Abs. 1 BSIG verlangt ausdrücklich, dass die Einrichtungen die Einhaltung dokumentieren. Für bestimmte Anbieter digitaler Infrastruktur und digitaler Dienste – darunter Cloud-Anbieter, Rechenzentrumsdienste, Managed Service Provider und Managed Security Service Provider – konkretisiert die Durchführungsverordnung (EU) 2024/2690 der Kommission die Anforderungen. Ihr Anhang enthält einen eigenen Abschnitt zu Überwachung und Protokollierung: Verfahren und Werkzeuge zur Überwachung und Protokollierung der Aktivitäten in Netz- und Informationssystemen, Automatisierung, wo möglich, sowie Aufbewahrung, Dokumentation, Prüfung und Schutz der Protokolle. Gehören Sie zu diesen Anbietern, lesen Sie diesen Anhang zusätzlich zum BSIG.

NIS2-Meldepflicht: 24 Stunden, 72 Stunden, ein Monat

Gemeldet werden müssen erhebliche Sicherheitsvorfälle, also Vorfälle, die schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht haben oder verursachen können oder andere Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigen. In Deutschland gehen die Meldungen nach § 32 BSIG an eine gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK):

Stufe	Frist	Inhalt	Was Ihre Telemetrie liefern muss
Frühe Erstmeldung	Unverzüglich, spätestens 24 Stunden nach Kenntniserlangung	Ob der Verdacht auf rechtswidrige oder böswillige Handlungen besteht und ob grenzüberschreitende Auswirkungen möglich sind	Belastbaren Erkennungszeitpunkt, betroffene Dienste und Regionen, erste Hinweise auf die Ursache
Meldung	Unverzüglich, spätestens 72 Stunden nach Kenntniserlangung	Bestätigung oder Aktualisierung der Erstmeldung, erste Bewertung inkl. Schweregrad und Auswirkungen, ggf. Kompromittierungsindikatoren	Impact-Kennzahlen (Fehlerraten, betroffene Nutzer, Dauer), Schweregrad, relevante Logs und Traces
Zwischenmeldung	Auf Ersuchen des BSI	Relevante Statusaktualisierungen	Aktuelle Zeitleiste und Stand der Abhilfe
Abschlussmeldung	Spätestens einen Monat nach der 72-Stunden-Meldung	Ausführliche Beschreibung inkl. Schweregrad und Auswirkungen, Art der Bedrohung oder Ursache, getroffene und laufende Abhilfemaßnahmen, ggf. grenzüberschreitende Auswirkungen	Ursachenanalyse mit Belegen, vollständige Zeitleiste, Maßnahmen

Dauert der Vorfall zum Zeitpunkt der Abschlussmeldung noch an, ist stattdessen eine Fortschrittsmeldung fällig und die Abschlussmeldung folgt nach Abschluss der Bearbeitung. Zwei Folgen sind für die Praxis wichtig: Die Frist beginnt mit der Kenntniserlangung, nicht mit dem Ende Ihrer Analyse, und sie läuft auch am Wochenende. Außerdem decken sich die Inhalte fast vollständig mit guter Incident-Praxis: Zeitleiste, Schweregrad, Impact-Daten und ein schriftliches Postmortem. Teams, die bereits so arbeiten, brauchen meist nur einen zusätzlichen Schritt zur regulatorischen Einstufung.

Haftung der Geschäftsleitung

Art. 20 der Richtlinie verpflichtet die Leitungsorgane, die Risikomanagementmaßnahmen zu billigen, ihre Umsetzung zu überwachen, und macht sie für Verstöße verantwortlich. In Deutschland regelt das § 38 BSIG: Geschäftsleitungen müssen die Maßnahmen nach § 30 umsetzen und deren Umsetzung überwachen. Verletzen sie diese Pflichten, haften sie ihrer Einrichtung für schuldhaft verursachte Schäden nach den für die jeweilige Rechtsform geltenden gesellschaftsrechtlichen Regeln. Zudem müssen sie regelmäßig an Schulungen teilnehmen.

Die Bußgeldobergrenzen liegen nach Art. 34 der Richtlinie bei mindestens 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche und mindestens 7 Millionen Euro oder 1,4 % für wichtige Einrichtungen, jeweils der höhere Betrag. Für Plattform-Teams bedeutet das: Monitoring, Logging und Meldeprozesse sind keine rein technischen Entscheidungen mehr. Die Geschäftsleitung wird Nachweise verlangen, dass die Maßnahmen existieren und wirken – es lohnt sich, diese Nachweise von Anfang an im Observability-Setup mitzudenken.

Stand der Umsetzung in Deutschland (Oktober 2026)

Deutschland hat NIS2 verspätet umgesetzt; die Frist der Richtlinie endete am 17. Oktober 2024. Nach Angaben des BSI hat der Bundestag das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) am 13. November 2025 beschlossen, der Bundesrat am 21. November 2025 zugestimmt; das Gesetz wurde am 5. Dezember 2025 im Bundesgesetzblatt verkündet und ist am 6. Dezember 2025 in Kraft getreten. Es ist ein Artikelgesetz, dessen Kern ein vollständig neu gefasstes BSI-Gesetz ist. Für technische Teams sind vor allem diese Vorschriften relevant:

• § 28 BSIG: Einordnung als besonders wichtige oder wichtige Einrichtung, inklusive der genannten Schwellenwerte.
• § 30 BSIG: Risikomanagementmaßnahmen und Dokumentationspflicht.
• § 32 BSIG: dreistufige Meldepflicht an die gemeinsame Meldestelle von BSI und BBK.
• § 33 BSIG: Registrierung beim BSI spätestens drei Monate, nachdem eine Einrichtung erstmals als betroffen gilt.

Laut BSI sieht das Gesetz keine allgemeine Übergangsfrist vor; die Pflichten gelten also seit Inkrafttreten. Die Registrierung läuft über das BSI-Portal und setzt ein Organisationskonto über „Mein Unternehmenskonto“ voraus. Auf der BSI-Seite „NIS-2 in Zahlen“ werden zum Stand 30. September 2026 mehr als 20.000 registrierte Einrichtungen ausgewiesen, bei einer früheren BSI-Schätzung von rund 29.500 betroffenen Einrichtungen. Berichte über eine faktische Kulanz bei verspäteten Registrierungen ändern nichts an der gesetzlichen Frist; verlassen Sie sich nicht darauf, sondern prüfen Sie die aktuellen Hinweise des BSI, falls Sie noch nicht registriert sind. Sektorspezifische Regelungen, etwa für Energie oder Telekommunikation, und weitere Rechtsverordnungen können Details ergänzen – klären Sie die Anforderungen für Ihren Sektor mit der zuständigen Behörde.

Checkliste: NIS2-Anforderungen und Observability

Die folgende Tabelle ist ein Ausgangspunkt für Ihren Compliance-Tracker. Sie ist nicht abschließend, und die Spalte „Nachweise“ beschreibt, was Prüfer typischerweise sehen wollen, keinen rechtlichen Maßstab.

Anforderung	Was umsetzen	Nachweise für Audits
Bewältigung von Sicherheitsvorfällen (§ 30 Abs. 2 Nr. 2 BSIG)	Zentrale Logs, Metriken und Traces für alle relevanten Dienste; Alarmierung auf Symptome und sicherheitsrelevante Ereignisse; Rufbereitschaft mit Eskalation	Alarmregeln mit Verantwortlichen, Bereitschaftsplan, Beispiel-Incidents mit Erkennungs- und Reaktionszeitpunkten
Erkennungsfähigkeit	Anomalieerkennung auf Fehlerraten, Latenz, fehlgeschlagene Anmeldungen und ungewöhnlichen Traffic; synthetische Checks für kritische Nutzerpfade	Abdeckungsliste je Dienst, Verlauf der MTTD
Integrität und Aufbewahrung von Logs	Strukturiertes Logging mit einheitlichen Feldern (Zeitstempel in UTC, Dienst, Trace-ID, Nutzer- oder Client-ID, soweit zulässig); zugriffsgeschützter Speicher; definierte Datenaufbewahrung je Log-Klasse	Logging-Standard, Aufbewahrungskonzept, Zugriffsprotokolle des Log-Speichers selbst
Personenbezogene Daten in Telemetrie	Maskierung oder Pseudonymisierung vor der Speicherung, damit Logs lange genug aufbewahrt werden können, ohne die DSGVO zu verletzen	Maskierungsregeln, Verarbeitungsverzeichnis, Angaben zur Datenresidenz
Frühe Erstmeldung (24 h)	Incident-Tool mit Feld „regulatorisch erheblich“, vorbereitete Vorlage und benannte Verantwortliche für die Meldung	Vorlage, Runbook, Nachweise abgegebener Meldungen
Meldung (72 h)	Impact-Dashboards je Vorfall (Dienste, Nutzer, Regionen, Dauer); Schweregradmatrix, abgestimmt auf die Kriterien eines erheblichen Vorfalls	Schweregradmatrix, exportierte Impact-Daten je Vorfall
Abschlussmeldung (1 Monat)	Ursachenanalyse mit verknüpften Belegen; Postmortem-Prozess mit nachverfolgten Maßnahmen	Postmortems, Status der Maßnahmen, Links auf die Telemetrie
Aufrechterhaltung des Betriebs (§ 30 Abs. 2 Nr. 3 BSIG)	Verfügbarkeits-SLOs, Überwachung der Backup-Jobs, regelmäßige Wiederherstellungstests, Hochverfügbarkeit für kritische Dienste	SLO-Berichte, Ergebnisse der Restore-Tests, Protokolle von Notfallübungen
Management von Anlagen	Servicekatalog und Abhängigkeitskarte aus der Telemetrie, mit Verantwortlichen je Dienst	Exportiertes Dienste-Inventar mit Verantwortlichen und Abhängigkeiten
Wirksamkeitsbewertung (§ 30 Abs. 2 Nr. 6 BSIG)	Quartalsweise Auswertung: Erkennungszeit, Zeit bis zur Eindämmung, wiederkehrende Ursachen, Alarmrauschen	Protokolle der Reviews, Kennzahlenberichte an die Geschäftsleitung

Vorlage zum Kopieren: interner Datensatz für die Erstmeldung

In den ersten 24 Stunden geht oft Zeit verloren, weil niemand weiß, was in die Erstmeldung gehört. Halten Sie einen kurzen internen Datensatz wie diesen in Ihrem Incident-Tool bereit und füllen Sie ihn aus, sobald ein Vorfall erheblich sein könnte:

NIS2 frühe Erstmeldung - interner Datensatz
Incident-ID:             INC-____
Zeitpunkt Kenntnis:      JJJJ-MM-TT hh:mm UTC (wer, wie erkannt)
Betroffene Dienste:      ____
Betroffene Regionen / EU-Mitgliedstaaten: ____
Verdacht auf rechtswidrige/böswillige Ursache: ja / nein / unklar (Grundlage: ____)
Mögliche grenzüberschreitende Auswirkungen: ja / nein / unklar
Aktueller Impact (Beispielwerte): Fehlerrate __ %, betroffene Nutzer ca. __, Dauer __ Min.
Schweregrad (intern):    SEV1 / SEV2 / SEV3
Erheblich nach NIS2/BSIG: ja / nein / in Prüfung
Verantwortlich für Meldung: ____   Frist 24 h: ____   Frist 72 h: ____
Belege:                  Dashboards, Log-Abfragen, Traces

Typische Lücken in der Praxis

An der NIS2-Meldepflicht scheitern Organisationen selten an fehlenden Werkzeugen, sondern an Lücken zwischen Werkzeug und Prozess:

1. Kein belastbarer Zeitpunkt der Kenntniserlangung. Laufen Alarme nur in einen Chat-Kanal ohne Bestätigung, lässt sich nicht belegen, wann die Frist begann. Nutzen Sie einen Incident-Datensatz mit expliziten Zeitstempeln.
2. Logs, die sich nicht korrelieren lassen. Ohne gemeinsame Trace-IDs und einheitliche Zeitstempel dauert die Zeitleiste für die 72-Stunden-Meldung Tage statt Stunden.
3. Aufbewahrung nach Kosten statt nach Bedarf. Verfallen sicherheitsrelevante Logs nach sieben Tagen, ist eine Ursachenanalyse für die Abschlussmeldung womöglich nicht mehr möglich. Trennen Sie Audit- und Security-Logs von ausführlichen Debug-Logs und legen Sie die Aufbewahrung je Klasse fest.
4. Schweregrad ohne Impact-Daten. „SEV1“ allein sagt einer Behörde nicht, wie viele Nutzer oder welche Dienste betroffen waren. Verknüpfen Sie den Schweregrad mit messbaren Auswirkungen.
5. Postmortems ohne Nachverfolgung. Die Abschlussmeldung fragt nach getroffenen und laufenden Abhilfemaßnahmen. Nicht nachverfolgte Maßnahmen lassen sich schwer berichten.

Wenn Sie die Grundlagen noch aufbauen, erklärt unser Beitrag Was ist Observability?, wie Logs, Metriken und Traces für solche Untersuchungen zusammenwirken.

Wie Obseria unterstützt

Obseria macht eine Organisation nicht NIS2-konform; Compliance hängt immer von Ihren Prozessen und Ihrer eigenen Bewertung ab. Obseria liefert aber die technische Grundlage für viele der genannten Maßnahmen: OpenTelemetry-native Erfassung von Logs, Metriken, Traces und Events, eine Pipeline, die personenbezogene Daten vor der Speicherung filtert und maskiert, und Incident-Workflows, die Zeitstempel, Schweregrad und Belege an einem Ort halten. Informationen zu Hosting, Datenresidenz und unseren Sicherheitspraktiken finden Sie auf der Seite Sicherheit und Vertrauen.

• Erkennung und Zeitleisten: Anomalieerkennung, SLO-Burn-Rate-Alarme und synthetisches Monitoring speisen das Incident Management mit automatischen Zeitleisten.
• Aufbewahrung und Datenschutz: Obseria Pipeline maskiert personenbezogene Daten und leitet Daten je Klasse weiter; Obseria Lake speichert Logs, Metriken, Traces und Events mit konfigurierbarer Aufbewahrung und Datenresidenz in der EU.
• Ursache mit Belegen: Obseria Intelligence schlägt kausale Ursachen samt zugehöriger Telemetrie vor und verkürzt so die Arbeit an Postmortems und Abschlussmeldungen.

Wie Zeitleiste und Belege für Ihre eigenen Vorfälle aussehen würden, sehen Sie am schnellsten mit einem kostenlosen Test mit Ihrer Telemetrie.