Cybersicherheit & Compliance —  Praxiseinblick

NIS 2 in der Umsetzung: Die vier zentralen Anforderungen

Im ersten Teil ging es um die Grundlagen: Was NIS 2 ist, wer betroffen ist und welche Konsequenzen die Geschäftsleitung persönlich treffen. Wer an dieser Stelle steht, hat die Betroffenheit geklärt und sich beim BSI registriert – und damit die formalen Pflichten erfüllt.

Jetzt beginnt die eigentliche Arbeit. NIS 2 verlangt nicht nur, dass man auf der Liste steht. Verlangt werden konkrete Maßnahmen in vier Bereichen: ein lebendes Risikomanagement, ein funktionierender Meldeprozess für Sicherheitsvorfälle, getestete Notfallpläne und ein belastbarer Umgang mit der eigenen Lieferkette. Wer hier liefert, ist nicht nur compliant, sondern tatsächlich sicherer. Das ist der Punkt, an dem Compliance und operative Sicherheit zusammenfallen – wenn man es richtig macht.

1. Risikomanagement

In der Praxiserleben wir häufig dasselbe Bild: Risikoanalysen existieren, sind aber Jahre alt, undokumentiert oder wurden nie in konkrete Maßnahmen übersetzt. Wer eine Risikoanalyse von 2022 in der Schublade liegen hat, hat kein Risikomanagement – er hat ein Dokument. NIS 2 fordert das genaue Gegenteil: einen lebenden Prozess, der regelmäßig aktualisiert wird, nachvollziehbar ist und klare Verantwortlichkeiten kennt.

Lebend heißt: Wenn sich die IT-Landschaft ändert, ein neues System eingeführt oder ein Cloud-Dienst hinzugefügt wird, muss die Risikobewertung mitziehen. Nachvollziehbar heißt: Es muss schriftlich erkennbar sein, welche Risiken identifiziert wurden, wie sie bewertet sind und welche Maßnahmen daraus folgen. Und mit klarer Verantwortung heißt: Eine namentlich benannte Person trägt die Zuständigkeit – nicht die IT.

Was konkret stehen muss:

• Kontinuierliche Bewertung von Cyberrisiken – nicht als einmaliges Projekt, sondern als Daueraufgabe mit definiertem Turnus.
• Technische Mindeststandards: Verschlüsselung, granulare Zugriffskontrollen, Multi-Faktor-Authentifizierung. Was vor fünf Jahren noch optional war, ist heute Pflichtprogramm.
• Schwachstellenmanagement mit definierten Patch-Zyklen, Eskalationswegen und klaren Zuständigkeiten – nicht wir patchen wenn jemand Zeit hat.
• Dokumentation, die im Prüfungsfall gegenüber dem BSI standhält – nicht für die Schublade, sondern für den Audit.

Der typische Fehler an dieser Stelle ist, das Risikomanagement bei der IT abzulegen und es dort sterben zu lassen. NIS 2 verlangt explizit die Verzahnung mit der Geschäftsführung – und damit eine Berichtsstruktur, die Risiken nach oben sichtbar macht.

2. Incident Response und Meldepflichten

Das Gesetzschreibt einen dreistufigen Meldeprozess vor: 24 Stunden für die Frühwarnung, 72 Stunden für den Erstbericht, ein Monat bis zum Abschlussbericht. Wer diese Fristen liest und noch keinen funktionierenden Meldeprozess hat, versteht das Problem sofort: 24 Stunden sind keine Zeit, in der man einen Prozess aufbauen kann. Unter dem Druck eines laufenden Angriffs funktionieren nur Abläufe, die vorher geübt wurden.

Das eigentliche Risiko ist nicht die Frist als solche, sondern die Kombination aus Zeitdruck, unklarer Faktenlage und juristischer Brisanz. Wer in den ersten Stunden falsche Informationen meldet, riskiert Folgeprobleme. Wer zu spätmeldet, riskiert Bußgelder. Die einzige Versicherung dagegen ist ein vorabdefinierter, geübter Prozess.

Was vor dem ersten Vorfall stehen muss:

• Klare Eskalationsketten: Wer informiert wen, in welcher Reihenfolge, mit welchen Informationen? Inklusive Vertretungsregelungen für Urlaub und Krankheit.
• Meldewege ans BSI – inklusive technischer Zugänge, hinterlegter Kontakte und Vorlagen für die drei Meldestufen.
• Vordefinierte Kommunikationsvorlagen für interne und externe Krisenkommunikation – Mitarbeitende, Kunden, Presse, gegebenenfalls Aufsichtsbehörden.
• Regelmäßige Tabletop-Übungen, damit der Plan nicht im Ernstfall zum ersten Mal gelesen wird. Einmal jährlich ist Minimum.

Ein oft übersehener Punkt: Der Abschlussbericht nach einem Monat ist genauso verpflichtend wie die Frühwarnung. Viele Unternehmen melden den Erstvorfall, lassen den Abschluss aber schleifen, weil der Druck nachlässt. Das ist nachweisbar und sanktionierbar.

3. Business Continuity und IT-Betrieb

Resilienz ist kein neues Konzept. Aber viele Kontinuitätspläne sind auf dem Stand von vor drei Jahren, wurden nie unter realistischen Bedingungen getestet oder bilden die heutige IT-Landschaft schlicht nicht mehr ab. Wer auf Cloud-Dienste, Software-as-a-Service und hybride Architekturen umgestellt hat, kann nicht mit einem Notfallplan arbeiten, der noch vom eigenen Rechenzentrum ausgeht.

NIS 2 macht daraus eine prüfbare Pflicht. Es reicht nicht zu behaupten, man habe einen Notfallplan – man muss zeigen, dass er aktuell ist, getestet wurde und im Ernstfall funktioniert. Eine PDF im Archiv, an die sich keiner erinnert, erfüllt diese Anforderung nicht.

Was prüfungsfest sein muss:

• Aktuelle, getestete Business-Continuity-Pläne – als gelebte Prozesse mit benannten Verantwortlichen, nicht als Dokumentenleichen.
• Disaster-Recovery-Verfahren mit definierten Wiederanlaufzeiten (RTO) und akzeptiertem Datenverlust (RPO) je nach Kritikalität des Systems.
• Redundanzen für kritische Systeme und Kommunikationswege – auch dann, wenn der primäre Kanal ausfällt, muss die Lagesteuerbar bleiben.
• Jährliche Übungen, die Schwachstellen sichtbar machen, bevor ein Angriff es tut – idealerweise inklusive externer Beobachtung.

Die häufigste Lücke an dieser Stelle: Die IT hat Pläne, das Business hat Pläne, aber beide kennen die jeweils anderen nicht. Im Ernstfall stellt sich dann heraus, dass die Wiederanlaufzeit der IT nicht zur Erwartung der Fachbereiche passt – und niemand hatte das vorher zusammengeführt.

4. Sicherheit in der Lieferkette

Dieser Punkt wird am häufigsten unterschätzt. Die eigene Infrastruktur ist gesichert – aber was ist mit dem Cloud-Anbieter, dem Softwareentwickler, dem IT-Dienstleister, dem externen Helpdesk? NIS 2 macht unmissverständlich klar: Verantwortung endet nicht an der eigenen Unternehmensgrenze. Wer Drittparteien einbindet, haftet für deren Sicherheitsniveau mit.

Die Konsequenz ist unbequem, weil sie aktiven Aufwand erzeugt. Verträge, die seit Jahren ohne Sicherheitsklauseln laufen, müssen nachverhandelt werden. Lieferanten, die nie auf Sicherheit hin geprüft wurden, müssen Auskunft geben. Und das gilt nicht nur für die großen Hyperscaler, sondern auch für den kleinen Dienstleister, der das Personalsystem betreut.

Worauf es ankommt:

• Sicherheitsanforderungen müssen in Lieferantenverträgen verankert sein – konkret, prüfbar und mit Konsequenzen bei Verstoß, nicht als Absichtserklärung.
• Regelmäßige Überprüfung und Bewertung von Drittparteien: Audits, Zertifikate, strukturierte Fragebögen. Risikobasiert priorisiert, nicht flächendeckend.
• Transparenz über eingesetzte Softwarekomponenten – Stichwort SBOM (Software Bill of Materials). Wer nicht weiß, was in seiner Software steckt, kann Schwachstellen nicht bewerten.
•  Vertragliche Meldepflicht bei Sicherheitsvorfällen beim Dienstleister – mit Fristen, die zur eigenen 24h-Pflicht passen.

Die strategische Erkenntnis dahinter: Die Lieferkette ist heute der bevorzugte Angriffsweg. Wer in jüngster Vergangenheit die großen Vorfälle verfolgt hat, weiß, dass die betroffenen Unternehmen selten direkt angegriffen wurden – sie hingen an einem kompromittierten Dienstleister.

Der beste Zeitpunkt ist jetzt. Morgen kann es schon zu spät sein. Wer jetzt strukturiert vorgeht, wehrt Angriffe ab, bevor sie Schaden anrichten –und stellt gleichzeitig die geforderte Compliance her. Beides gehört zusammen. Wenn der Angriff erst da ist, bleibt kein Spielraum mehr. Dann reagiert man unter Druck – und das ist selten die Grundlage für gute Entscheidungen.

Stand: Mai 2026  — Dieser Artikel gibt praxisbasierte Einblicke und ersetzt keine individuelle Rechts- oder Sicherheitsberatung.

‍