· Sascha Enke
NIS-2: Welche Pflichten Security Monitoring und Backup abdecken und welche nicht
Seit dem 6. Dezember 2025 gilt in Deutschland das neue BSI-Gesetz, mit dem die europäische NIS-2-Richtlinie umgesetzt wurde. Viele Unternehmen, die bisher nichts mit IT-Sicherheitsrecht zu tun hatten, sind jetzt „wichtige“ oder „besonders wichtige Einrichtungen“. Die erste Frage, die uns dazu erreicht, lautet meist: Reicht es, ein Security Monitoring einzuführen und die Sicherung zu prüfen? Die kurze Antwort: Damit deckt man einen wichtigen Teil ab, aber nicht alles. Hier beschreiben wir, welcher Teil das ist.
Vorweg: Wir sind ein IT-Dienstleister, keine Kanzlei und kein Prüfdienstleister. Ob Ihr Unternehmen unter das Gesetz fällt, klären Sie mit der Betroffenheitsprüfung des BSI oder mit Ihrer Rechtsberatung. Als grobe Orientierung gilt: Betroffen sind in den Sektoren der Anlagen 1 und 2 des Gesetzes in der Regel Unternehmen ab 50 Beschäftigten oder mit mehr als 10 Millionen Euro Jahresumsatz und Bilanzsumme.
Was das Gesetz verlangt
Der Kern steht in § 30 BSIG. Betroffene Einrichtungen müssen „geeignete, verhältnismäßige und wirksame“ technische und organisatorische Maßnahmen ergreifen und deren Einhaltung dokumentieren. Absatz 2 nennt zehn Bereiche, die mindestens abgedeckt sein müssen, von der Risikoanalyse über Backup und Notfallwiederherstellung bis zur Multi-Faktor-Authentifizierung.
Dazu kommen zwei weitere Pflichten, die direkt mit der Technik zu tun haben:
- Meldepflicht (§ 32 BSIG): Ein erheblicher Sicherheitsvorfall muss innerhalb von 24 Stunden nach Kenntnis an das BSI gemeldet werden, eine ausführlichere Meldung folgt nach 72 Stunden, ein Abschlussbericht nach einem Monat.
- Verantwortung der Geschäftsleitung (§ 38 BSIG): Die Geschäftsleitung muss die Maßnahmen umsetzen, ihre Umsetzung überwachen und sich regelmäßig schulen lassen. Bei schuldhafter Pflichtverletzung haftet sie.
Die zehn Maßnahmen und was die Technik beiträgt
Die folgende Tabelle ordnet jede der zehn Maßnahmen aus § 30 Abs. 2 ein. „Monitoring“ meint hier ein Werkzeug wie Wazuh, das Ereignisse, Schwachstellen und Konfiguration der Server zentral auswertet. „Backup“ meint eine Sicherung, deren Wiederherstellung regelmäßig getestet wird.
| Nr. | Maßnahme laut § 30 Abs. 2 | Beitrag von Monitoring und Backup | Was zusätzlich nötig ist |
|---|---|---|---|
| 1 | Risikoanalyse und Sicherheitskonzepte | Inventar der Systeme und Software als Grundlage | die Analyse selbst und die Bewertung der Risiken |
| 2 | Bewältigung von Sicherheitsvorfällen | Erkennen, Zeitstempel, Verlauf eines Vorfalls | ein Ablauf: wer entscheidet, wer meldet, wer informiert |
| 3 | Aufrechterhaltung des Betriebs, Backup, Notfallwiederherstellung, Krisenmanagement | Sicherung, Kopie außer Haus, gemessene Wiederherstellungszeit | Notfallplan und Krisenorganisation |
| 4 | Sicherheit der Lieferkette | Nachweise, die ein Dienstleister liefern kann | Auswahl und Steuerung der Dienstleister, Verträge |
| 5 | Sicherheit bei Erwerb, Entwicklung und Wartung, Umgang mit Schwachstellen | Schwachstellenliste je System, Härtungsprüfung | Entscheidung, was wann behoben wird |
| 6 | Bewertung der Wirksamkeit | Messwerte über die Zeit: offene Schwachstellen, Restore-Tests | regelmäßige Auswertung durch die Leitung |
| 7 | Schulung und Sensibilisierung | keiner | Schulungen für Mitarbeitende und Geschäftsleitung |
| 8 | Kryptographie | Prüfung von Konfigurationen, etwa veraltete Verfahren | Konzept, welche Daten wie verschlüsselt werden |
| 9 | Personalsicherheit, Zugriffskontrolle, Verwaltung der Systeme | Hinweise auf neue Administratorkonten und Anmeldungen | Berechtigungskonzept, Ein- und Austrittsprozess |
| 10 | Multi-Faktor-Authentifizierung, gesicherte Kommunikation | Prüfung, ob Dienste MFA erzwingen, soweit technisch auslesbar | Einführung von MFA, Notfallkommunikation |
Auf einen Blick: Bei den Nummern 3 und 5 tragen Monitoring und Backup den Großteil. Bei 1, 2, 6, 8, 9 und 10 liefern sie Daten und Nachweise, ersetzen aber nicht die Entscheidung oder das Konzept. Bei 4 und 7 helfen sie kaum.
Backup: die Pflicht, die sich am besten belegen lässt
Nummer 3 nennt Backup-Management und Notfallwiederherstellung ausdrücklich. Hier lässt sich mit Technik am meisten nachweisen, wenn drei Dinge stimmen:
- Die Sicherung läuft und wird überwacht. Ein fehlgeschlagener Lauf fällt am nächsten Morgen auf, nicht erst im Notfall.
- Eine Kopie liegt außer Haus und ist vor Löschung geschützt. Ein Angreifer mit Administratorrechten darf nicht beides löschen können, das Original und die Sicherung.
- Die Wiederherstellung wird getestet. Ein erfolgreicher Sicherungslauf beweist nur, dass Daten geschrieben wurden. Ob man daraus in vertretbarer Zeit ein laufendes System bekommt, zeigt erst der Test.
Für den Nachweis genügt keine Aussage wie „das Backup läuft“. Hilfreich sind ein Protokoll der letzten Sicherungen, das Datum und die gemessene Dauer des letzten Wiederherstellungstests und festgelegte Werte für den tolerierbaren Datenverlust und die Ausfallzeit. Wie man diese Werte festlegt, beschreiben wir im Beitrag RPO und RTO realistisch festlegen.
Monitoring: Schwachstellen, Härtung und die 24-Stunden-Frist
Bei Nummer 5, dem Umgang mit Schwachstellen, ist ein Werkzeug wie Wazuh nah an dem, was das Gesetz meint. Es zeigt je Server, welche installierte Software bekannte Schwachstellen hat und wo die Konfiguration von einer Härtungsrichtlinie abweicht. Was die einzelnen Prüfungen leisten und wo ihre Grenzen liegen, steht im Beitrag Was die drei Wazuh-Prüfungen leisten.
Für die Meldepflicht ist ein anderer Punkt entscheidend. Die 24 Stunden laufen ab Kenntnis des Vorfalls. Ohne zentrale Auswertung der Logs erfährt man von einem Vorfall oft spät und kann danach kaum rekonstruieren, wann er begonnen hat und welche Systeme betroffen sind. Ein Monitoring verkürzt nicht die Frist, aber es liefert die Zeitstempel und den Verlauf, die in die Meldung gehören.
Wichtig ist auch, was ein Monitoring nicht ist. Es ist ein Werkzeug, keine Sicherheitsleitstelle. Jemand muss die Meldungen lesen, einordnen und entscheiden, ob ein Vorfall erheblich und damit meldepflichtig ist. Wer das tut und wie er erreichbar ist, gehört in den Ablauf zu Nummer 2.
Was keine Technik abnimmt
Ein Teil der Pflichten lässt sich mit keinem Werkzeug erfüllen:
- Die Risikoanalyse. Welche Systeme sind für das Geschäft kritisch, was kostet ein Tag Ausfall? Das kann nur das Unternehmen selbst bewerten.
- Die Schulungen. Mitarbeitende und Geschäftsleitung müssen geschult werden; die Geschäftsleitung ist dazu nach § 38 BSIG persönlich verpflichtet.
- Die Lieferkette. Welche Dienstleister Zugriff auf die IT haben und wie man sie steuert, steht in Verträgen und Prüfungen, nicht in Logdateien.
- Die Entscheidung. Ob eine Schwachstelle sofort behoben wird oder bis zum nächsten Wartungsfenster wartet, ob ein Vorfall gemeldet wird: Das entscheidet ein Mensch, und diese Entscheidung muss dokumentiert sein.
Wenn Sie selbst Dienstleister sind
Nummer 4, die Sicherheit der Lieferkette, wirkt auch in die andere Richtung. Wer als IT-Dienstleister für betroffene Einrichtungen arbeitet, wird nach Nachweisen gefragt, auch wenn er selbst nicht unter das Gesetz fällt. Für uns gilt das genauso: Kunden, die unter NIS-2 fallen, fragen, wie wir ihre Systeme sichern, überwachen und wer bei uns Zugriff hat.
Hier zahlt sich aus, wenn die Infrastruktur als Code beschrieben ist. Welche Systeme es gibt, wie sie konfiguriert sind und wer wann was geändert hat, steht dann im Git und muss nicht für jeden Fragebogen neu zusammengesucht werden. Ähnlich ist es bei TISAX, wo Auditoren ebenfalls fragen, wie ein Unternehmen seinen IT-Dienstleister steuert. Welche Nachweise sich dort automatisieren lassen, beschreibt der Beitrag TISAX-Nachweise automatisieren.
Wo anfangen?
Für ein Unternehmen, das gerade erst festgestellt hat, dass es betroffen ist, empfehlen wir diese Reihenfolge:
- Betroffenheit klären und, falls zutreffend, beim BSI registrieren.
- Inventar erstellen: Welche Systeme gibt es, welche sind kritisch?
- Sicherung prüfen: Gibt es eine geschützte Kopie außer Haus, und wann wurde die Wiederherstellung zuletzt getestet?
- Meldeweg festlegen: Wer erkennt einen Vorfall, wer entscheidet über die Meldung, wer meldet?
- Monitoring einführen, damit Schwachstellen und Vorfälle sichtbar werden.
- Den Rest planen: Schulungen, Berechtigungskonzept, MFA, Dienstleistersteuerung.
Die Schritte 2, 3 und 5 sind die, bei denen Technik am schnellsten Wirkung zeigt. Der Rest braucht Zeit und Entscheidungen, aber er baut auf einem sauberen Inventar und einer geprüften Sicherung auf.
Wie wir Wazuh aufbauen und betreiben, steht unter Wazuh Security Monitoring. Wie wir Sicherungen einrichten und Wiederherstellungen testen, beschreibt die Seite Backup & Wiederherstellung.

Geschrieben von Sascha Enke, Gründer & Geschäftsführer von Enke-iTS – über 20 Jahre Erfahrung in Infrastruktur-Architektur und Virtualisierung. Mehr über uns
