NIS2: Warum „compliant“ nicht gleich „resilient“ ist – und was Sie jetzt ändern müssen

NIS2: Warum „compliant“ nicht gleich „resilient“ ist – und was Sie jetzt ändern müssen

NIS2 bringt viele Organisationen in eine vertraute Komfortzone: Anforderungen lesen, Maßnahmen ableiten, Dokumente erstellen, Checklisten abhaken. Das fühlt sich nach Fortschritt an – und ein Teil davon ist auch wirklich notwendig. Trotzdem gibt es ein Problem, das in der Praxis häufig erst dann sichtbar wird, wenn es ernst wird: „Compliant“ heißt nicht automatisch „resilient“.

Compliance beantwortet primär die Frage: „Haben wir Anforderungen umgesetzt?“ Resilienz beantwortet eine andere Frage: „Können wir Störungen aushalten, schnell reagieren und den Betrieb stabil wiederherstellen – und zwar unter Stress, mit echten Abhängigkeiten und begrenzten Ressourcen?“ Zwischen beiden liegt eine Lücke, die Sie nicht mit noch mehr Papier schließen, sondern nur mit funktionierenden Abläufen.

In diesem Beitrag zeige ich Ihnen, warum diese Lücke so oft entsteht – und was Sie konkret ändern sollten. Nicht als Großprogramm, sondern als pragmatische Umstellung von „wir haben es geregelt“ hin zu „wir können es tatsächlich“.

1) Das Missverständnis: „Wenn es dokumentiert ist, ist es erledigt“

Viele NIS2-Initiativen starten mit einem vernünftigen Reflex: Erstmal Ordnung schaffen. Policies, Rollen, Risikoübersichten, Maßnahmenpläne. Das ist wichtig – aber es bleibt häufig in einer Welt, in der alles so läuft, wie man es geplant hat.

Der Betrieb ist aber anders. Er ist:

• laut (zu viele parallele Themen),
• schnell (Entscheidungen unter Zeitdruck),
• abhängig (Dienstleister, Plattformen, Lieferketten),
• und manchmal widersprüchlich (Sicherheit, Verfügbarkeit, Kosten, Time-to-Market).

Resilienz entsteht nicht durch die Existenz eines Dokuments, sondern durch Wiederholbarkeit: gleiche Situation, gleicher Ablauf, gleiche Qualität – auch wenn es unangenehm wird.

2) Woran Sie im Alltag erkennen, dass Sie „compliant“, aber nicht „resilient“ sind

Hier sind typische Signale, die ich in Organisationen immer wieder sehe. Wenn Sie davon zwei oder drei wiedererkennen, lohnt sich ein Perspektivwechsel:

• Incidents werden technisch sauber gelöst, aber die Business-Auswirkungen werden erst später „zusammenrecherchiert“.
• Es gibt ein Risikoregister, aber es verändert Entscheidungen im Alltag kaum (z. B. bei Releases, Provider-Wechsel, Priorisierung).
• Lieferanten werden bewertet, aber nicht wirklich gesteuert (kein regelmäßiger Takt, keine Eskalationsroutine, keine klare Exit-Logik).
• Es gibt Reports, aber sie führen selten zu konkreten Maßnahmen oder Priorisierungen.
• Übungen finden statt, aber die Ergebnisse verschwinden in Protokollen, ohne spürbare Verbesserung im Betrieb.

Das sind keine „Fehler“ im Sinne von „schlecht gemacht“. Es sind typische Nebenwirkungen einer Umsetzung, die zu stark auf Nachweise und zu wenig auf Betriebsfähigkeit ausgelegt ist.

3) Der Kernunterschied: Nachweislogik vs. Betriebslogik

Um NIS2 praktisch zu verstehen, hilft eine einfache Trennung:

• Nachweislogik: Was müssen wir zeigen können? (Dokumente, Policies, Verantwortlichkeiten, Maßnahmen)
• Betriebslogik: Was müssen wir können? (erkennen, entscheiden, handeln, wiederherstellen, lernen)

Viele Teams sind stark in der Nachweislogik. Die Betriebslogik kommt oft „irgendwie mit“, wird aber nicht gezielt aufgebaut. Genau hier sollten Sie ansetzen.

4) Was Sie jetzt ändern müssen – sieben Umstellungen, die wirklich wirken

Umstellung 1: Von „Sicherheitsmaßnahmen“ zu „kritischen Services“

NIS2 wird schnell zu einer Sammlung von Kontrollen. Resilienz wird aber über Services gesteuert: Welche Leistungen müssen stabil bleiben, welche Abhängigkeiten sind kritisch, welche Ausfallzeiten sind nicht akzeptabel?

Praktischer Schritt: Definieren Sie eine kurze Liste kritischer Services (lieber 10 saubere als 80 vage). Für jeden Service legen Sie fest:

• Service-Owner (eine Rolle, nicht „das Team“)
• maximal tolerierbare Ausfallzeit (realistisch)
• wichtigste Abhängigkeiten (intern/extern)
• minimaler Betrieb im Notmodus (was muss noch gehen?)

Wenn das klar ist, werden viele Entscheidungen einfacher: Priorisierung, Monitoring, Übungen, Lieferantensteuerung.

Umstellung 2: Von „Rollen definiert“ zu „Entscheidungen klar“

Eine Rollenbeschreibung hilft nur begrenzt, wenn in der Krise unklar ist, wer eine Entscheidung wirklich trifft. Resilienz hängt an wenigen kritischen Entscheidungen: Einstufung, Kommunikation, Abschaltung, Workaround, Eskalation, Wiederanlauf.

Praktischer Schritt: Erstellen Sie eine kleine Entscheidungsmatrix mit 8–12 Punkten, z. B.:

• „Major Incident ausrufen“
• „Externe Kommunikation freigeben“
• „Service in Notbetrieb setzen“
• „Rollback/Freeze anordnen“
• „Dienstleister eskalieren“

Zu jedem Punkt: Entscheider, Stellvertreter, Erreichbarkeit, maximaler Entscheidungszeitraum (z. B. 15 Minuten). Das klingt simpel – ist aber im Ernstfall Gold wert.

Umstellung 3: Von „Incident-Prozess vorhanden“ zu „Incident-Kette geschlossen“

In vielen Organisationen ist Incident Management technisch gut. Was fehlt, ist eine geschlossene Kette von der Störung bis zur Wirkung und zurück in Verbesserungen.

Praktischer Schritt: Ergänzen Sie den Incident-Prozess um vier Pflichtbausteine:

• Auswirkung: Welcher Service, welche Kundengruppe, welche Frist, welcher Schaden?
• Entscheidungspunkte: Was wurde wann entschieden, von wem – und warum?
• Kommunikation: Wer wurde informiert (intern/extern), wann und mit welcher Kernbotschaft?
• Maßnahmen: Was wird verbessert – und bis wann? (mit Owner)

So wird Incident Management vom „Feuer löschen“ zum „System stabiler machen“.

Umstellung 4: Von „Risiko bewerten“ zu „Risiko entscheidet“

Ein Risikoregister ist schnell erstellt – aber Resilienz entsteht erst, wenn Risiken reale Entscheidungen beeinflussen. Typischer Alltag: Ein Projekt will live gehen, ein Dienstleisterwechsel steht an, ein neues Feature wird priorisiert. Wenn Risiko hier nicht sichtbar wird, bleibt es Verwaltung.

Praktischer Schritt: Definieren Sie drei wiederkehrende Entscheidungspunkte, bei denen Risiko verpflichtend „mit am Tisch“ ist:

• Go-Live/Release bei kritischen Services
• Onboarding/Änderungen bei kritischen Dienstleistern
• Ausnahmen von Sicherheitsstandards (z. B. temporär)

Wichtig: Nicht „mehr Gremien“. Sondern klare Gate-Fragen und dokumentierte Entscheidungen in bestehende Abläufe integrieren.

Umstellung 5: Von „Lieferant bewertet“ zu „Lieferant geführt“

NIS2 betont die Lieferkette. Viele Organisationen machen Risikoanalysen – und hören dann auf. Resilienz braucht aber einen Steuerungstakt, der das Tagesgeschäft abbildet.

Praktischer Schritt: Für kritische Dienstleister: ein quartalsweiser Standardtermin (30–60 Minuten), der immer gleich abläuft:

• Leistung/Verfügbarkeit (kurzer Report, nicht 20 Seiten)
• Sicherheitsereignisse und relevante Änderungen
• Offene Maßnahmen (max. 10 Punkte)
• Entscheidung: akzeptieren, reduzieren, eskalieren

Wenn Sie das sauber dokumentieren, haben Sie gleichzeitig Betriebssteuerung und Nachweise – ohne Zusatzbürokratie.

Umstellung 6: Von „Wir haben geübt“ zu „Wir sind besser geworden“

Übungen werden häufig als Pflichttermin behandelt. Resilienz entsteht aber durch Lernen: Was hat nicht funktioniert, was ändern wir, was überprüfen wir beim nächsten Mal?

Praktischer Schritt: Jede Übung bekommt eine feste, kurze Ergebnislogik:

• Ziel (1 Satz)
• Was hat funktioniert (max. 5 Punkte)
• Was hat nicht funktioniert (max. 5 Punkte)
• 3 konkrete Maßnahmen (Owner + Datum)
• Re-Test-Termin (wann prüfen wir die Verbesserung?)

Damit wird Üben zu einem echten Verbesserungsprozess und nicht zu einer Formalität.

Umstellung 7: Von „Reporting“ zu „Steuerungsimpuls“

Viele Sicherheitsberichte sind entweder zu technisch oder zu „grün“. Beides ist unglücklich: Das Management versteht es nicht – oder glaubt, es gäbe keine Probleme. Beides schwächt Resilienz, weil Entscheidungen ausbleiben.

Praktischer Schritt: Machen Sie Reporting entscheidungsfähig. Pro Bericht drei Fragen – immer:

• Was hat sich seit dem letzten Bericht relevant verändert?
• Wo ist unser Risiko gestiegen oder unsere Stabilität gesunken?
• Welche Entscheidung oder Priorisierung folgt daraus?

Und ja: erlauben Sie „gelb“ und „rot“. Reife entsteht durch Transparenz, nicht durch perfekte Ampeln.

5) Ein realistischer Umsetzungsplan: 6 Wochen, die den Unterschied machen

Wenn Sie NIS2 gerade starten oder neu fokussieren wollen, hilft ein kurzer, klarer Plan. Nicht als „Projekt“, sondern als Aufbau von Routinen:

• Woche 1: Kritische Services finalisieren, Owner benennen, Ausfalltoleranzen definieren.
• Woche 2: Incident-Kette schließen (Auswirkung, Entscheidungspunkte, Kommunikation, Maßnahmen).
• Woche 3: Lieferanten-Steuerungstakt für die Top-5 Dienstleister etablieren.
• Woche 4: Entscheidungsmatrix bauen und in Bereitschaft/Eskalation verankern.
• Woche 5: Eine Tabletop-Übung (60–90 Minuten) durchführen – Fokus: Einstufung + Kommunikation + Provider-Eskalation.
• Woche 6: Reporting umbauen: weniger Zahlenfriedhof, mehr Entscheidungen und Maßnahmen.

Das Ergebnis ist nicht „alles fertig“. Aber Sie haben die entscheidenden Hebel in Betrieb – und genau das macht den Unterschied zwischen Formalerfüllung und echter Widerstandskraft.

6) Praxisnahes Beispiel: Der Unterschied zeigt sich im ersten großen Incident

Nehmen wir einen typischen Vorfall: Ein externer Plattformdienst hat eine Störung. Technisch kann Ihr Team nicht viel tun, außer koordinieren, Workarounds aktivieren, kommunizieren. In einer „compliant“ Organisation existiert ein Incident-Prozess – aber in der konkreten Situation gibt es Diskussionen:

• Ist das schon „major“ oder noch nicht?
• Wer informiert das Management – und wann?
• Müssen Kunden informiert werden oder warten wir ab?
• Wie dokumentieren wir das sauber, ohne parallel Protokolle zu pflegen?

In einer resilienten Organisation sind diese Fragen nicht „offen“, sondern bereits als Entscheidungen und Abläufe vorbereitet. Das Team kann handeln, statt zu verhandeln. Der Vorfall wird schneller stabilisiert – und die Nachweisführung entsteht nebenbei, weil sie in den Ablauf eingebaut ist.

7) Ein Merksatz, der intern hilft

Wenn Sie nur einen Satz mitnehmen, dann diesen: Resilienz ist das, was übrig bleibt, wenn der Plan nicht mehr passt. Genau deshalb müssen Sie NIS2 so umsetzen, dass Routinen unter Stress funktionieren – nicht nur in PowerPoint und Dokumenten.

Im nächsten Beitrag gehen wir tiefer in die Praxis: Wie Sie NIS2-Nachweise so strukturieren, dass Revision und Betrieb nicht gegeneinander arbeiten – sondern dieselbe Spur nutzen.