NIS2-Angriffserkennung: Wann SIEM nach Artikel 21 wirklich Pflicht ist – und wann nicht

Kurz gesagt: Nirgends im NIS2-Text oder im deutschen Umsetzungsgesetz steht das Wort „SIEM“. Trotzdem behandeln die meisten Ratgeber Security-Information-and-Event-Management-Systeme wie eine Pflichtübung – ohne zu sagen, woher diese Pflicht eigentlich kommt. Das Ergebnis: Unternehmen kaufen entweder ein Enterprise-SIEM, das ihre Größe nicht rechtfertigt, oder verlassen sich auf ein Antivirenprogramm und hoffen, dass es reicht. Beides ist teuer – im ersten Fall in Euro, im zweiten Fall im Ernstfall.

Dieser Beitrag zieht die Linie sauber nach: von Artikel 21 der NIS-2-Richtlinie über §30 BSIG und die Durchführungsverordnung CIR 2024/2690 bis zu §31 BSIG – der einzigen Stelle im deutschen Recht, an der eine automatisierte Angriffserkennung tatsächlich namentlich vorgeschrieben ist. Und die gilt nicht für Sie, wenn Sie kein KRITIS-Betreiber sind.

Kurz gesagt: Ist SIEM nach NIS2 Pflicht?

Die ehrliche Antwort ist gestaffelt. Für die meisten „wichtigen“ und „besonders wichtigen Einrichtungen“ schreibt kein Paragraf ein SIEM-System namentlich vor. Für einen kleinen Kreis von Anbietern digitaler Infrastruktur ist eine SIEM-ähnliche Überwachungs- und Protokollierungsfunktion über die CIR 2024/2690 direkt bindend. Für KRITIS-Betreiber und Energieanlagenbetreiber ist eine kontinuierliche, automatisierte Angriffserkennung über §31 BSIG tatsächlich Pflicht.

Die Rechtsgrundlage: Was Artikel 21 und §30 BSIG wörtlich verlangen

Artikel 21 Absatz 2 der NIS-2-Richtlinie listet zehn Risikomanagementmaßnahmen auf. Buchstabe (b) lautet schlicht „Bewältigung von Sicherheitsvorfällen“ – ohne ein einziges Wort zu Erkennungstechnologie [1]. Der deutsche Gesetzgeber hat diesen Punkt fast wortgleich in §30 Abs. 2 Nr. 2 BSIG übernommen: „Bewältigung von Sicherheitsvorfällen“ [2]. Auch die offizielle BSI-Übersicht der zehn Maßnahmen aus §30 Abs. 2 verwendet an keiner Stelle die Begriffe „Angriffserkennung“, „Überwachung“, „Protokollierung“ oder „SIEM“ [3].

Das ist kein Zufall, sondern Prinzip: NIS2 und BSIG formulieren technologieneutral. §30 Abs. 1 BSIG verlangt „geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen“ und macht die Verhältnismäßigkeit ausdrücklich vom „Ausmaß der Risikoexposition, der Größe der Einrichtung, den Umsetzungskosten und der Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen“ abhängig [2]. Ein Zehn-Personen-Betrieb mit überschaubarer IT-Landschaft muss Sicherheitsvorfälle bewältigen können – aber niemand schreibt ihm dafür ein SIEM vor, das für einen Konzern mit Dutzenden Systemen gebaut ist.

Praktisch bedeutet das: Die Bewertung, ob Ihre Maßnahme „angemessen“ ist, findet nicht am Tag des Einkaufs statt, sondern im Ernstfall oder im Audit. Der Nachweis, dass ein Konzept auf dem Papier existiert, reicht dabei zunehmend weniger – Prüfer und Aufsichtsbehörden erwarten zunehmend, dass Sie zeigen können, dass die Erkennung im laufenden Betrieb tatsächlich funktioniert, etwa durch regelmäßig ausgewertete Logs, dokumentierte Alarme und nachvollziehbare Reaktionszeiten, nicht nur durch eine Richtlinie in der Schublade. Genau hier liegt der praktische Unterschied zwischen einer formal vorhandenen und einer wirksamen „Bewältigung von Sicherheitsvorfällen“.

Die eigentliche Technikvorgabe: CIR 2024/2690, Abschnitt 3.2

Wer wissen will, was „Bewältigung von Sicherheitsvorfällen“ technisch bedeutet, findet die Antwort nicht im BSIG, sondern in der Durchführungsverordnung (EU) 2024/2690. Deren Anhang widmet Abschnitt 3 komplett dem Incident Handling – unterteilt in Punkt 3.1 (Konzept) und Punkt 3.2 (Überwachung und Protokollierung) [4]. Einen vollständigen Überblick über alle technischen Anforderungen der Verordnung finden Sie im Leitfaden zur NIS2-Durchführungsverordnung.

Punkt 3.2.1 verlangt, dass betroffene Einrichtungen „Verfahren festlegen und Werkzeuge einsetzen, um Aktivitäten in ihren Netz- und Informationssystemen zu überwachen und zu protokollieren, um Ereignisse zu erkennen“ [4]. Punkt 3.2.3 listet, was diese Protokolle mindestens erfassen sollen: Authentifizierungsereignisse, privilegierte Zugriffe, Systemressourcen, physische Zugänge und Umgebungsereignisse. Punkt 3.2.4 verlangt festgelegte Alarmschwellenwerte – bei Überschreitung wird, soweit angemessen, automatisch ein Alarm ausgelöst, und die Einrichtung muss sicherstellen, dass darauf zeitnah eine „qualifizierte und angemessene Reaktion“ erfolgt [4].

Das ist, Wort für Wort, die Funktionsbeschreibung eines SIEM-Systems – nur ohne den Markennamen. Wichtig für die Einordnung: CIR 2024/2690 bindet formal nur eine bestimmte Gruppe von Anbietern digitaler Infrastruktur (DNS-Diensteanbieter, TLD-Registrierungsstellen, Cloud-Computing-Anbieter, Rechenzentren, Content-Delivery-Netzwerke, verwaltete Dienstanbieter, Anbieter von Online-Marktplätzen, Online-Suchmaschinen, sozialen Netzwerken und Vertrauensdiensten). Für alle anderen wichtigen und besonders wichtigen Einrichtungen ist Abschnitt 3.2 kein direktes Gesetz – aber der mit Abstand konkreteste verfügbare Maßstab dafür, was Aufsichtsbehörden unter „angemessener Bewältigung von Sicherheitsvorfällen“ verstehen, wenn sie prüfen. Wer sich daran orientiert, argumentiert im Audit mit der Formulierung, die die Verordnung selbst verwendet – nicht mit einer Interpretation Dritter.

Wo die echte SIEM-Pflicht beginnt: §31 BSIG und Systeme zur Angriffserkennung

Es gibt eine echte, namentlich benannte Pflicht zur automatisierten Angriffserkennung im deutschen Recht – sie steht nur nicht in §30, sondern in §31 BSIG, und sie gilt nur für Betreiber kritischer Anlagen. §31 Abs. 2 BSIG verpflichtet KRITIS-Betreiber, für die Systeme, Komponenten und Prozesse, die für die Funktionsfähigkeit der jeweiligen kritischen Anlage maßgeblich sind, Systeme zur Angriffserkennung einzusetzen [5]. Diese müssen laut BSI „geeignete Parameter und Merkmale aus dem laufenden Betrieb kontinuierlich und automatisch erfassen und auswerten“, fortwährend Bedrohungen identifizieren und geeignete Beseitigungsmaßnahmen vorsehen [6].

Die BSI-eigene FAQ-Seite zu diesem Thema zitiert noch die ältere Rechtsgrundlage aus dem IT-Sicherheitsgesetz 2.0, §8a Abs. 1a BSIG. Seit Inkrafttreten des NIS2UmsuCG am 6. Dezember 2025 ist die Pflicht in §31 Abs. 2 BSIG neu verortet, inhaltlich aber im Kern unverändert: Sie gilt für Betreiber kritischer Anlagen und, parallel dazu, für Energieanlagenbetreiber nach dem Energiewirtschaftsgesetz [5][6]. Für eine „einfache“ wichtige oder besonders wichtige Einrichtung ohne KRITIS-Einstufung besteht diese konkrete Pflicht nicht – auch wenn mehrere vielgelesene deutsche Fachartikel zu diesem Thema genau diese Unterscheidung nicht sauber treffen und den Eindruck erwecken, die Pflicht gelte pauschal für „NIS2-Unternehmen“.

Der Unterschied ist mehr als juristische Feinarbeit. §31 BSIG verlangt kontinuierliche, automatisierte Erkennung mit eingebauter Reaktionsfähigkeit – das ist ein Niveau, das ein mittelständischer Betrieb ohne KRITIS-Einstufung nicht vorhalten muss, um §30 BSIG zu erfüllen. Wer diese Stufen verwechselt, kauft entweder deutlich zu viel Werkzeug ein oder unterschätzt, was ein tatsächlicher KRITIS-Betrieb im eigenen Konzern leisten muss.

Entscheidungsbaum: Welche Erkennungsebene brauchen Sie wirklich?

Aus den drei vorangegangenen Abschnitten ergibt sich ein praktischer Entscheidungsrahmen. Er ersetzt keine Rechtsberatung, aber er zeigt, an welcher Stelle im Werkzeug-Spektrum Ihr Unternehmen realistisch steht.

Der praktische Rat für die große Mehrheit der Leser dieses Beitrags – wichtige oder besonders wichtige Einrichtungen ohne KRITIS-Einstufung: Beginnen Sie nicht bei der Software, sondern bei der Risikobewertung nach §30 Abs. 2 Nr. 1 BSIG. Sie bestimmt, welche Systeme überhaupt protokolliert werden müssen, bevor Sie ein Werkzeug dafür kaufen. Ein SIEM ohne priorisierte Log-Quellen erzeugt vor allem eines: mehr Alarme, die niemand auswertet.

Warum Erkennungsfähigkeit trotzdem zählt, auch ohne SIEM-Pflicht

Selbst wenn keine Vorschrift Ihnen ein SIEM namentlich vorschreibt, bleibt die Erkennungsfähigkeit der Engpass in der gesamten NIS2-Meldekette. Artikel 23 der NIS2-Richtlinie setzt die 24-Stunden-Frühwarnung ab dem Zeitpunkt in Gang, an dem die Einrichtung von einem Sicherheitsvorfall „Kenntnis erlangt“ – nicht ab dem Zeitpunkt, an dem er bestätigt ist. Ohne Protokolle, die einen Vorfall überhaupt sichtbar machen, beginnt diese Uhr für Sie faktisch nie, bis der Schaden längst eingetreten ist.

Mandiants M-Trends-2026-Report, der über 500.000 Stunden Incident-Response-Einsätze auswertet, zeigt, wie groß dieser Unterschied in der Praxis ist: Organisationen, die einen Angriff selbst intern entdeckten, brauchten dafür im Median rund neun Tage – wer auf eine externe Meldung angewiesen war, etwa durch Strafverfolgungsbehörden oder betroffene Kunden, wartete im Median 25 Tage, mehr als das 2,5-Fache [7]. Über den gesamten Datensatz lag die weltweite mittlere Verweildauer eines Angreifers im Netzwerk 2025 bei 14 Tagen [7]. Jeder Tag zusätzlicher Verweildauer ist ein Tag mehr, in dem ein Angreifer sich lateral bewegen oder Daten exfiltrieren kann, bevor Sie überhaupt wissen, dass die Meldeuhr läuft.

Das verschärft sich durch die Schwelle, ab der ein Vorfall überhaupt meldepflichtig wird. Artikel 23 Abs. 3 der NIS2-Richtlinie macht einen Vorfall „erheblich“, wenn er entweder eine schwerwiegende Betriebsstörung oder einen finanziellen Verlust verursacht hat oder verursachen kann, oder wenn er andere natürliche oder juristische Personen durch erheblichen materiellen oder immateriellen Schaden betroffen hat oder betreffen kann [8] – ein Kriterium reicht aus. Ohne Protokolldaten lässt sich diese Einschätzung kaum belastbar treffen: Wer nicht weiß, welche Systeme betroffen waren und wie lange, kann weder glaubhaft „nicht erheblich“ noch fristgerecht „erheblich“ melden. Erkennungsfähigkeit ist damit keine separate Übung neben der Meldepflicht, sondern deren Voraussetzung.

Rollen und Verantwortlichkeiten

Angriffserkennung ist selten eine reine IT-Entscheidung. Vier Rollen tragen unterschiedliche Verantwortung:

Bußgelder und Konsequenzen bei fehlender Erkennungsfähigkeit

Fehlt die Fähigkeit, Sicherheitsvorfälle zu erkennen, verletzt das nicht nur eine abstrakte Pflicht – es untergräbt die Fähigkeit, die 24-Stunden-Meldefrist nach Artikel 23 einzuhalten, und genau dort setzen die schärfsten Sanktionen an.

Wichtig zur Einordnung: Ein fehlendes SIEM allein ist kein eigener Bußgeldtatbestand – sanktioniert wird die mangelnde „Bewältigung von Sicherheitsvorfällen“ als Ganzes, wenn sie den Verhältnismäßigkeitsmaßstab aus §30 Abs. 1 BSIG unterschreitet. Ein dokumentiertes, aber einfaches Log-Management kann diesen Maßstab für eine kleine Einrichtung durchaus erfüllen; ein Konzept ganz ohne Protokollierung in der Regel nicht.

Häufige Fragen

Muss ich als kleines Unternehmen ein SIEM kaufen, um NIS2-konform zu sein?
Nicht zwangsläufig. §30 Abs. 1 BSIG verlangt Maßnahmen, die im Verhältnis zu Größe, Risikoexposition und Umsetzungskosten stehen [2]. Für kleinere wichtige Einrichtungen kann eine dokumentierte, zentrale Log-Sammlung der wichtigsten Systeme – kombiniert mit einem klaren Eskalationsprozess – ausreichen, solange sie tatsächlich ausgewertet wird.

Was ist der Unterschied zwischen §30 und §31 BSIG bei der Angriffserkennung?
§30 BSIG gilt für alle wichtigen und besonders wichtigen Einrichtungen und verlangt allgemein die „Bewältigung von Sicherheitsvorfällen“, ohne ein Werkzeug zu benennen. §31 BSIG gilt zusätzlich, aber ausschließlich für Betreiber kritischer Anlagen und Energieanlagenbetreiber und schreibt konkret automatisierte Systeme zur Angriffserkennung vor [2][5].

Bindet die CIR 2024/2690 mein Unternehmen direkt, wenn ich kein Cloud- oder DNS-Anbieter bin?
Formal nicht. Die Durchführungsverordnung bindet nur die im Anhang genannten Anbieter digitaler Infrastruktur. Für alle anderen Einrichtungen dient sie als praktischer Maßstab, den Aufsichtsbehörden bei der Bewertung heranziehen können [4].

Ab wann beginnt die 24-Stunden-Meldefrist, wenn ich einen Angriff erst spät bemerke?
Die Frist beginnt mit der „Kenntniserlangung“ – also dem Zeitpunkt begründeten Verdachts, nicht dem der Bestätigung. Je später Ihre Erkennungsfähigkeit einen Vorfall sichtbar macht, desto später beginnt formal Ihre Frist – aber desto größer ist in der Praxis meist bereits der Schaden.

Wo finde ich heraus, welche Systeme ich zuerst protokollieren sollte?
Das ist Aufgabe der Risikoanalyse nach §30 Abs. 2 Nr. 1 BSIG, nicht der Angriffserkennung selbst – sie priorisiert, welche Systeme das höchste Risiko tragen und deshalb zuerst überwacht werden sollten.

Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechts- oder Fachberatung dar. Anforderungen können je nach Rechtsraum und Unternehmenstyp variieren. Für eine auf Ihre Situation zugeschnittene Einschätzung konsultieren Sie einen qualifizierten Rechtsanwalt oder Compliance-Spezialisten.

Quellen

• [1] Artikel 21 NIS-2-Richtlinie (nis-2-directive.com)
• [2] § 30 BSIG – Risikomanagementmaßnahmen (lxgesetze.de)
• [3] #nis2know: NIS-2 Risikomanagementmaßnahmen (bsi.bund.de)
• [4] Durchführungsverordnung (EU) 2024/2690, Anhang Abschnitt 3 (eur-lex.europa.eu)
• [5] § 31 BSIG – Besondere Anforderungen kritischer Anlagen (lxgesetze.de)
• [6] FAQ Systeme zur Angriffserkennung (bsi.bund.de)
• [7] Mandiant M-Trends 2026 Report – Zusammenfassung (helpnetsecurity.com)
• [8] Artikel 23 NIS-2-Richtlinie – Meldepflichten (nis-2-directive.com)