Seit dem 6. Dezember 2025 ist das NIS2-Umsetzungsgesetz (NIS2UmsuCG) in Deutschland in Kraft. Die gesetzliche Frist zur Erstregistrierung beim BSI lief am 6. März 2026 ab. Rund 29.500 Unternehmen aus 18 Sektoren stehen seitdem unter der Aufsicht des Bundesamts für Sicherheit in der Informationstechnik, gegenüber vorher etwa 4.500.
Weil bis Ende Mai erst rund 18.500 der erwarteten Unternehmen registriert waren, hat das BSI eine Nachfrist bis zum 31. Juli 2026 eingeräumt (wir haben darüber berichtet). Diese Nachfrist ist inzwischen ebenfalls abgelaufen, und die Registrierungslücke ist damit real: Wer bis heute weder registriert noch gemeldet hat, riskiert nach § 65 BSIG Bußgelder: bis zu 500.000 Euro allein für die Verletzung der Registrierungspflicht, bei Verstößen gegen die materiellen Pflichten bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes.
Viele IT-Leitungen haben die Registrierungshürde genommen. Die eigentliche Belastungsprobe kommt aber erst mit dem ersten meldepflichtigen Vorfall. Ohne durchgängige, auswertbare Protokollierung sind die engen Fristen kaum zu schaffen. Genau hier setzt ein SIEM wie das Open Source Tool Wazuh an.
Was NIS2 technisch tatsächlich verlangt
Die Richtlinie selbst schreibt keine Produkte vor, es gibt also keine “NIS2-Zertifizierung” für Software. Sie schreibt aber Ergebnisse vor. § 30 BSIG-neu definiert zehn Kernmaßnahmen, die betroffene Einrichtungen umsetzen müssen, darunter Risikoanalyse und Sicherheitskonzepte, Bewältigung von Sicherheitsvorfällen, Aufrechterhaltung des Betriebs, Lieferkettensicherheit, Schwachstellenmanagement und die Bewertung der Wirksamkeit der getroffenen Maßnahmen. Artikel 21 und 23 der NIS2-Richtlinie konkretisieren die Meldekette: Frühwarnung innerhalb von 24 Stunden, Erstbewertung innerhalb von 72 Stunden, Abschlussbericht spätestens nach einem Monat. Für die deutsche Umsetzung dieser Fristen hat das BSI ein eigenes Infopaket veröffentlicht.
Wie 
die Anforderungen abbildet
Wazuh deckt mit seinen Standardmodulen einen erheblichen Teil der technischen NIS2-Anforderungen ab, ohne dass zusätzliche Tools nötig wären. Log-Datenerfassung und -Korrelation aus Endpoints, Firewalls, Cloud-Diensten und Anwendungen bilden die Basis für den geforderten Audit-Trail. Die Dateiintegritätsüberwachung (File Integrity Monitoring) erkennt unautorisierte Änderungen an kritischen Systemen und liefert damit einen Zeitstempel für den Beginn eines Vorfalls, was eine zentrale Angabe für die 72-Stunden-Erstbewertung ist. Das Vulnerability-Detection-Modul gleicht installierte Software kontinuierlich mit bekannten CVEs ab und deckt damit die Schwachstellenmanagement-Pflicht aus § 30 ab. Security Configuration Assessment prüft Systeme gegen Härtungsbaselines wie CIS Benchmarks und liefert damit den Nachweis “angemessener technischer Maßnahmen”, den NIS2 verlangt.
Ein konkretes Beispiel: Ein Wazuh-Alert zu einem erkannten Vorfall enthält bereits die Kernangaben, die für die Meldung an das BSI benötigt werden.
{
"timestamp": "2026-08-10T03:14:22.511+0200",
"rule": {
"id": "100210",
"level": 12,
"description": "Multiple failed logins followed by successful authentication - possible brute force",
"mitre": {
"technique": ["Brute Force"],
"id": ["T1110"]
}
},
"agent": {
"id": "042",
"name": "fileserver-fra-03",
"ip": "10.20.4.17"
},
"data": {
"srcip": "185.220.101.7",
"dstuser": "svc-backup"
}
}Aus solchen Alarmen lässt sich über das Discover-Dashboard oder die API eine Timeline rekonstruieren: erster Anmeldeversuch, Eskalation, betroffenes Konto, betroffenes System. Genau diese Informationen fließen direkt in die 24-Stunden-Frühwarnung und die 72-Stunden-Erstbewertung ein, ohne dass Logs manuell aus mehreren Quellen zusammengesucht werden müssen. Die integrierten Compliance-Dashboards von Wazuh mappen Regeln zusätzlich auf Rahmenwerke wie ISO 27001, NIST 800-53 oder PCI DSS. Wer NIS2-relevante Use Cases abdeckt, deckt damit häufig auch technische Teile einer ISO-27001-Zertifizierung mit ab, insbesondere die Annex-A-Controls A.8.15 (Logging), A.8.16 (Monitoring) und A.8.8 (Schwachstellenmanagement).
Handlungsempfehlungen für die Praxis
Zunächst lohnt sich eine ehrliche Bestandsaufnahme: Welche Systeme sind meldepflichtig relevant, und liefern sie überhaupt Logs an Wazuh, oder klaffen dort blinde Flecken? Anschließend sollte die Log-Retention explizit auf die NIS2-Nachweispflicht ausgerichtet werden. Die Standard-Archivierung reicht oft nicht für die geforderten Aufbewahrungsfristen und muss bewusst konfiguriert werden. Für die Meldefristen selbst empfiehlt sich, konkrete Playbooks zu definieren, die festlegen, wer bei welchem Alarmtyp innerhalb welcher Frist welche Bewertung liefert, und diese Abläufe wo möglich mit einer SOAR-Anbindung wie Shuffle zu automatisieren, damit die 24-Stunden-Uhr nicht erst durch manuelles Sichten von Dashboards zu laufen beginnt. Schließlich sollten diese Abläufe regelmäßig geübt werden, etwa in Tabletop-Übungen mit echten Wazuh-Daten aus vergangenen Alarmen, damit im Ernstfall nicht die Meldefrist selbst zum Risiko wird.
Fazit
NIS2 verlangt keine bestimmte Software, aber sie verlangt Nachweisfähigkeit unter Zeitdruck. Genau daran scheitern viele Unternehmen, die zwar ein SIEM betreiben, dessen Daten im Ernstfall aber nicht schnell genug auswertbar sind. DigiFors unterstützt Sie bei der Implementierung und dem laufenden Betrieb von Wazuh, von der initialen Konfiguration der relevanten Datenquellen über die Definition NIS2-tauglicher Use Cases bis zur Integration in einen SOC-Betrieb, der auch nachts und am Wochenende innerhalb der 24-Stunden-Frist reaktionsfähig ist.
Von NIS2 betroffen?
Wir helfen Ihnen bei Prüfung oder Aufbau Ihres Wazuh-SetUps für die NIS2 Meldefähigkeit.
