Resilienz ist im Alltag oft sichtbar, lange bevor sie dokumentiert ist. Teams reagieren auf Störungen, stabilisieren Systeme, klären Ursachen, steuern Dienstleister, passen Abläufe an. Operativ passiert viel. Und trotzdem kommt in Revisionen oder Prüfungen sehr häufig dieselbe Rückfrage: „Können Sie mir das bitte nachvollziehbar zeigen?“ Nicht, weil niemand glaubt, dass gearbeitet wurde. Sondern weil die Spur fehlt, die Entscheidung, Umsetzung und Ergebnis als Paket zusammenhält.

Genau hier liegt der Kern von Resilienz-Evidenz. Belege sind selten „nicht vorhanden“. Sie sind nur verteilt: Tickets, Chatverläufe, E-Mails, Logs, Monitoring-Dashboards, Meeting-Notizen, Provider-Statusmeldungen, Change-Freigaben, Testprotokolle, Maßnahmenlisten. Im Alltag reicht das oft, weil die Beteiligten den Kontext kennen. Revision darf Kontext nicht erraten. Revision muss aus Dokumenten und Artefakten nachvollziehen können, was passiert ist, warum es passiert ist, wer entschieden hat und was daraus folgte. Und sie muss das ohne Expedition durch fünf Systeme können.

NIS2 bringt viele Organisationen dazu, Sicherheitsmaßnahmen zu „listen“: man schaut auf Kataloge, orientiert sich an Standards, erstellt Maßnahmenpläne. Das ist grundsätzlich sinnvoll. Die unangenehme Wahrheit ist aber: Nicht jede Maßnahme, die auf dem Papier gut aussieht, trägt im Ernstfall wirklich. Und umgekehrt sind es oft ein paar Basics, die darüber entscheiden, ob ein Vorfall kontrollierbar bleibt – oder ob er sich in Chaos, Stillstand und Nacharbeit übersetzt.

Wenn man über „Basics“ spricht, klingt das schnell nach Allgemeinplätzen. In der Praxis ist es deutlich konkreter. „Basics, die tragen“ sind Maßnahmen, die in kritischen Momenten zwei Dinge gleichzeitig ermöglichen: schnelle Entscheidungen und stabile Abläufe. Genau das erwartet NIS2 im Kern: nicht Perfektion, sondern Betriebsfähigkeit.

KRITIS, NIS2, DORA – drei Kürzel, die in vielen Unternehmen gerade gleichzeitig aufschlagen. Und fast immer passiert dabei dasselbe: Es wird erst mal gesammelt. Anforderungen, Pflichten, Leitfäden, Listen, Zuständigkeiten. Dann entstehen Workstreams. Dann entstehen Überschneidungen. Und irgendwann stellt jemand die richtige Frage: „Moment – was davon betrifft uns wirklich, und wie vermeiden wir Doppelarbeit?“

Dieser Beitrag ist eine Landkarte. Nicht im Sinne eines juristischen Kommentars, sondern als Orientierung für Praktiker: Welche Themen liegen wo, was ist ähnlich, was ist wirklich anders – und welche Entscheidungen sollten Sie früh treffen, damit Sie nicht ein Jahr lang parallel aneinander vorbeiarbeiten. Ich vermeide bewusst Nebelbegriffe. Stattdessen arbeite ich mit einem einfachen Prinzip: Pflichten sind nur dann hilfreich, wenn sie sich in einen betrieblichen Ablauf übersetzen lassen.

DORA klingt auf dem Papier oft klar: Risiken rund um digitale Dienstleistungen beherrschbar machen, Ausfälle reduzieren, Nachweise liefern. In der Umsetzung zeigt sich aber ein Muster, das ich in Projekten immer wieder sehe: Im Alltag wirkt vieles „irgendwie geregelt“ – bis ein Audit oder eine Prüfung fragt: Wo ist das belastbar belegt? Dann tauchen Lücken auf, die vorher niemand auf dem Radar hatte.

Dieser Beitrag ist bewusst praktisch gehalten. Er beschreibt zehn typische Stolperfallen, die meist erst dann schmerzhaft werden, wenn jemand von außen den Finger in die Wunde legt – Revision, Prüfer, Aufsicht, Kunden oder ein großer Dienstleister im Vertragsgespräch. Zu jeder Stolperfalle finden Sie: ein kurzes Erkennungszeichen, warum das passiert, und was Sie konkret tun können, ohne das Unternehmen mit zusätzlichen Programmen zu überfrachten.

GRC – Governance, Risk & Compliance – galt jahrelang als vernünftiger Dreiklang, in der Praxis aber oft als Dreifaltigkeit der Silos. Governance schrieb Richtlinien, Risk malte Heatmaps, Compliance pflegte Ordner – jede Disziplin korrekt im eigenen Kosmos, selten im Gleichklang. Das Ergebnis: viele Aktivitäten, wenig Wirkung. Heute, mit überlappenden Aufsichten (DORA, NIS2, AI Act, CRA, CSRD), komplexen Lieferketten und softwaregetriebener Wertschöpfung, bricht dieses Modell sichtbar. Was fehlt, ist kein weiterer Standard, sondern eine Arbeitsweise, die GRC zu einem System macht: aus einem Guss geplant, aus Daten gespeist, im Betrieb verankert, mit Nachweisen, die aus dem Tun entstehen – nicht aus dem Nachzeichnen. Dieser Beitrag zeigt, wie die Integration gelingt: organisatorisch, technisch, kulturell. Und warum „integriert“ nicht bedeutet, alles zu zentralisieren, sondern Schnittstellen so zu gestalten, dass Arbeit fließt.

1) Warum die alte GRC-Logik scheitert – und zwar zuverlässig

Silos sind bequem. Jedes Team setzt seine Tools, seine Taxonomie, seine KPIs. Doch drei strukturelle Brüche machen das alte Modell unhaltbar: