Die meisten Organisationen machen denselben Fehler, wenn mehrere Regelwerke gleichzeitig relevant werden: Sie bauen drei Programme. DORA bekommt ein Projekt, NIS2 bekommt ein Projekt, der EU AI Act bekommt ein Projekt. Jedes Projekt erstellt Anforderungen, Maßnahmenlisten, Richtlinien, Reportings. Und jedes Projekt hat gute Gründe, weil jede Anforderung „irgendwie“ stimmt. Das Ergebnis ist trotzdem oft enttäuschend: viel Arbeit, viel Dokumentation, aber die Betriebsfähigkeit wird nicht proportional besser. Noch schlimmer: Teams beginnen zu „optimieren“, indem sie das jeweils nächste Audit bedienen, statt das System als Ganzes stabiler zu machen.

Die Abkürzungen sind unterschiedlich, aber die Realität dahinter ist erstaunlich ähnlich. Alle drei Rahmenwerke wollen im Kern, dass Sie Entscheidungen nicht dem Zufall überlassen. Sie wollen Verantwortlichkeiten, die im Alltag funktionieren. Sie wollen, dass Störungen beherrscht werden können. Sie wollen, dass kritische Abhängigkeiten gesteuert werden. Und sie wollen, dass Sie das belegen können – nicht durch schöne Texte, sondern durch eine nachvollziehbare Spur.

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.

GRC-Automation klingt nach einer naheliegenden Lösung: Anforderungen wachsen, Nachweise steigen, Audits werden häufiger – also automatisieren wir eben. Workflows, Tickets, Freigaben, automatische Erinnerungen, Dashboards. Viele Organisationen starten genau so. Und viele stellen nach ein paar Monaten fest, dass zwar „mehr System“ da ist, aber nicht unbedingt mehr Steuerung. Manchmal sogar weniger. Das liegt nicht daran, dass Automation grundsätzlich schlecht wäre. Es liegt daran, dass Workflows nur dann helfen, wenn sie eine saubere Betriebslogik unterstützen. Wenn sie dagegen unklare Prozesse, diffuse Verantwortlichkeiten oder schlechte Evidenzlogik einfach nur digitalisieren, entsteht Tool-Chaos: mehr Klicks, mehr Status, mehr Listen – und trotzdem Unsicherheit, wenn es wirklich zählt.

Der Unterschied zwischen „hilfreicher Automation“ und „Tool-Chaos“ ist selten eine Toolfrage. Er ist eine Designfrage. Automatisierung ist wie Beton: Sie macht das, was schon da ist, stabiler – in gut wie in schlecht. Wenn Ihr GRC-Betrieb klare Decision Points hat, klare Owners, klare Nachweisartefakte und einen sinnvollen Takt, dann kann Automation diese Logik verstärken. Wenn Ihr Betrieb aber auf Zuruf funktioniert, wenn Entscheidungen informell getroffen werden oder wenn Evidenz nachträglich zusammengesucht wird, dann verstärkt Automation genau diese Schwächen. Dann wird aus „Wir automatisieren“ schnell „Wir pflegen ein System, das niemandem hilft“.

Ein KI-Register klingt zunächst wie ein Verwaltungsartefakt: eine Liste, ein Tool, ein paar Felder, fertig. Genau so werden viele Register auch gebaut – und genau deshalb funktionieren sie später weder im Audit noch im Betrieb. Denn ein Register, das nur „Daten sammelt“, wird schnell veraltet, erzeugt Diskussionen und wird umgangen. Ein Register, das dagegen Audit und Betrieb bedient, ist etwas anderes: Es ist die zentrale Steuerungsspur für Verantwortlichkeiten, Klassifizierung, Änderungen und Nachweise. Und es ist vor allem so gestaltet, dass es im Alltag genutzt wird, nicht nur im Prüfungsfall.

Der EU AI Act macht diese Doppelrolle wichtig, weil sich die Nachweiserwartung nicht auf „wir haben uns Gedanken gemacht“ beschränkt. Es geht um nachvollziehbare Entscheidungen: warum eine Anwendung so eingestuft wurde, welche Anforderungen daraus folgen, wie sie umgesetzt werden, wie Änderungen erkannt werden und wie man im Ereignisfall reagieren kann. Wenn Ihr Register diese Kette nicht abbildet, müssen Sie sie in PowerPoints, E-Mails und Einzeldokumenten nachbauen – und genau das ist der Moment, in dem das Thema kippt: zu viel Aufwand, zu wenig Klarheit.

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.