NIS2-Umsetzung in der Praxis – fünf ehrliche Lessons Learned

Die NIS2-Richtlinie ist seit Oktober 2024 in deutsches Recht umzusetzen – mit dem NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) liegt der Rahmen vor. Für viele Unternehmen bedeutet das: Anforderungen analysieren, Lücken schließen, Prozesse anpassen. Wer NIS2 in einem bereits regulierten Umfeld umsetzt, stößt dabei auf Fragen, die in den offiziellen Leitfäden selten beantwortet werden.

Die folgenden fünf Beobachtungen stammen aus der Begleitung einer NIS2-Umsetzung im regulierten Finanzumfeld. Sie erheben keinen Anspruch auf Vollständigkeit, sollen aber einen realistischen Blick auf die Herausforderungen geben, die in der Praxis am häufigsten unterschätzt werden.

1. BAIT-Compliance schützt nicht vor NIS2-Lücken

Viele Institute gehen zu Beginn davon aus, dass eine bestehende BAIT-Konformität einen Großteil der NIS2-Anforderungen bereits abdeckt. Diese Annahme ist nachvollziehbar, aber trügerisch.

BAIT reguliert IT-Risikomanagement, Auslagerungscontrolling und Notfallmanagement aus einer bankaufsichtsrechtlichen Perspektive. NIS2 setzt andere Schwerpunkte: Artikel 21 der Richtlinie schreibt unter anderem explizit Maßnahmen zur Sicherheit der Lieferkette vor – einschließlich der Bewertung von Sicherheitspraktiken bei Lieferanten und Dienstleistern. BAIT kennt zwar Anforderungen an das Auslagerungsmanagement, aber nicht in dieser Tiefe auf die Cybersicherheitspraktiken der gesamten Lieferkette ausgerichtet.

Hinzu kommen die Meldepflichten: NIS2 definiert dreistufige Meldefristen mit konkreten Inhaltsanforderungen für jede Stufe. BAIT-konforme Meldewege an die BaFin folgen anderen Logiken und Fristen. Ein Gap-Assessment, das beide Regelwerke systematisch gegenüberstellt, ist deshalb unumgänglich – und sollte früh im Projekt erfolgen, nicht als Abschlussvalidierung.

2. Die 24-Stunden-Meldefrist trifft unvorbereitete Teams hart

NIS2 sieht ein dreistufiges Meldeverfahren vor: eine Erstmeldung innerhalb von 24 Stunden nach Kenntnisnahme eines erheblichen Sicherheitsvorfalls, einen detaillierten Zwischenbericht nach 72 Stunden und einen Abschlussbericht spätestens einen Monat nach dem Vorfall. Die Erstmeldung muss dabei bereits Angaben zur Art des Vorfalls, zu betroffenen Diensten und zu ersten Einschätzungen der Ursache enthalten.

Das klingt zunächst handhabbar. In der Praxis setzt es jedoch eine Infrastruktur voraus, die in vielen Organisationen noch nicht vollständig aufgebaut ist: SIEM-Systeme, die Vorfälle mit ausreichender Präzision erkennen und klassifizieren, klare Eskalationspfade, die auch außerhalb der Bürozeiten funktionieren, sowie vorab definierte Verantwortlichkeiten für die Meldung an das BSI. Wer diese Prozesse noch nicht in Tabletop-Übungen durchgespielt hat, wird im Ernstfall unter Zeitdruck Entscheidungen treffen, für die keine belastbaren Grundlagen existieren.

Ein häufiges Problem: Die Frage, ab wann ein Vorfall „erheblich" im Sinne von NIS2 ist, ist nicht trivial. Das BSI hat Orientierungshilfen veröffentlicht, aber die Einordnung erfordert im Einzelfall Urteilsvermögen – und das muss trainiert werden, bevor es gebraucht wird.

3. Lieferkette wird systematisch unterschätzt

Die eigene technische Infrastruktur ist in vielen Organisationen gut abgesichert. Die Sicherheitspraktiken von Drittanbietern, Cloud-Providern und weiteren kritischen Dienstleistern sind es deutlich seltener – zumindest aus der Perspektive der auftraggebenden Organisation.

NIS2 Artikel 21 verpflichtet wesentliche und wichtige Einrichtungen dazu, Sicherheitsanforderungen auch gegenüber ihren direkten Lieferanten durchzusetzen. Das bedeutet konkret: Vertragsklauseln, die Mindestanforderungen an Informationssicherheit definieren, regelmäßige Nachweise (z. B. ISO 27001-Zertifizierungen, SOC-2-Berichte), und in manchen Fällen das Recht auf eigene Sicherheitsaudits beim Dienstleister.

Wer bisher kein strukturiertes Vendor Risk Management betrieben hat, steht vor einer umfangreichen Inventarisierungsaufgabe: Welche Dienstleister sind für welche kritischen Prozesse relevant? Welche davon haben direkten Zugriff auf Systeme oder Daten? Und welche vertraglichen Grundlagen existieren bereits? Dieser Aufwand wird in Projektplanungen regelmäßig unterschätzt, insbesondere dann, wenn viele Verträge historisch gewachsen und nicht zentralisiert dokumentiert sind.

4. Geschäftsführerhaftung ist kein leeres Versprechen

NIS2 enthält eine explizite Regelung zur persönlichen Haftung von Leitungsorganen. Geschäftsführerinnen und Geschäftsführer sowie Vorstandsmitglieder können für Verstöße gegen die Cybersicherheitspflichten ihrer Organisation persönlich haftbar gemacht werden. Das NIS2UmsuCG sieht zudem vor, dass Leitungsorgane Cybersicherheitsmaßnahmen aktiv genehmigen und an entsprechenden Schulungen teilnehmen müssen.

Diese Regelung hat in der Praxis eine spürbare Wirkung: Themen, die bisher in IT-Abteilungen verwaltet wurden, landen jetzt auf der Agenda von Vorstand und Geschäftsführung. Das ist strukturell sinnvoll, weil Cybersicherheit Entscheidungskompetenzen erfordert, die über IT-Budgets hinausgehen – Fragen zur Risikobereitschaft, zur Priorisierung von Investitionen und zur Geschäftsstrategie.

Für Organisationen bedeutet das auch: Die Dokumentation von Entscheidungen gewinnt an Bedeutung. Wer nachweisen muss, dass das Leitungsorgan Maßnahmen geprüft und freigegeben hat, braucht geeignete Gremienstrukturen und Beschlussvorlagen. Das ist ein Governance-Thema, das oft getrennt vom technischen NIS2-Projekt behandelt wird – und das ein Fehler ist.

5. DORA und NIS2 gleichzeitig zu managen ist kein Doppelaufwand – wenn man es richtig angeht

Für Finanzinstitute gilt DORA (Digital Operational Resilience Act) als sektorspezifisches Regelwerk, das NIS2 als lex specialis verdrängt, soweit DORA die gleichen Anforderungen abdeckt. In der Praxis bedeutet das: Viele Anforderungen aus NIS2 sind in DORA bereits enthalten – insbesondere im Bereich ICT-Risikomanagement, Incident Reporting und Third-Party Risk Management.

Eine saubere Gap-Analyse, die beide Regelwerke systematisch gegenüberstellt, ist deshalb keine Doppelarbeit, sondern eine Investition. Wer die Überschneidungen identifiziert, kann Prozesse und Nachweise so gestalten, dass sie beiden Anforderungen genügen – ohne separate Dokumentationsstränge für jedes Regelwerk. Besonders im Bereich ICT-Vorfallsmeldung lassen sich Prozesse und Vorlagen harmonisieren, da DORA und NIS2 ähnliche, aber nicht identische Fristen und Inhaltsanforderungen haben.

Die Herausforderung liegt in den Unterschieden im Detail: DORA definiert „wesentliche Vorfälle" über andere Schwellenwerte als NIS2, und die zuständigen Behörden sind unterschiedlich (BaFin vs. BSI). Diese Unterschiede müssen explizit adressiert werden, damit ein einheitlicher Prozess im Ernstfall korrekt funktioniert.

Empfehlung: Wo anfangen

Der sinnvollste erste Schritt ist eine präzise Scope-Analyse: Welche Einrichtungen der Organisation fallen unter NIS2, in welcher Kategorie (wesentlich oder wichtig), und welche Einrichtungen sind explizit ausgenommen? Diese Frage ist komplizierter als sie auf den ersten Blick wirkt, weil NIS2 nach Sektoren, Größenschwellen und Dienstleistungstypen unterscheidet. Fehler bei der Scope-Festlegung führen entweder zu unnötigem Aufwand oder zu nicht erkannten Verpflichtungen.

Auf Basis des Scopes empfiehlt sich ein strukturiertes Gap-Assessment gegen die Anforderungen aus Artikel 21 NIS2UmsuCG sowie – für Finanzinstitute – ein paralleles Mapping gegen DORA. Die Ergebnisse sollten in einem Maßnahmenplan münden, der Prioritäten, Verantwortlichkeiten und realistische Zeitrahmen enthält.

Die BSI-Orientierungshilfen sowie das ENISA-Framework zur NIS2-Implementierung sind als kostenfreie Ausgangsbasis empfehlenswert.