DORA hat eine Eigenschaft, die in vielen Organisationen erst spät wirklich ankommt: Es geht nicht nur darum, dass Sie Prozesse und Kontrollen haben. Es geht darum, dass Sie unter realistischen Bedingungen zeigen können, dass Ihr Betrieb Störungen aushält – und dass Sie daraus sichtbar besser werden. Genau deshalb rückt Testing unter DORA so stark in den Vordergrund. Und genau deshalb entsteht rund um „Threat-led Penetration Testing“ (kurz TLPT) ein besonderer Druck: Viele Teams hören „Penetrationstest“ und denken sofort an Technik. In der Praxis ist TLPT aber vor allem eine Disziplin der Steuerung: realistische Szenarien, klare Ziele, eng abgestimmte Grenzen, Einbindung von Dienstleistern, belastbare Nachweise und vor allem ein sauberer Umgang mit Ergebnissen.

Wenn Unternehmen sich an TLPT „verbrennen“, liegt das selten daran, dass sie grundsätzlich zu wenig können. Meist liegt es an zwei Dingen: Entweder man startet zu groß (zu viel Scope, zu viele Systeme, zu viele Stakeholder, zu wenig Routine). Oder man startet zu technisch (Tool-Fokus), während die entscheidenden Fragen ungelöst bleiben: Welche kritischen Services testen wir wirklich? Welche Abhängigkeiten sind in der Kette? Welche Entscheidungspunkte müssen im Ernstfall funktionieren? Und wie machen wir den Test so, dass er nicht nur „spannend“ ist, sondern für Betrieb und Nachweis wirklich verwertbar?

GRC wird in vielen Organisationen immer noch wie ein Sammelbegriff behandelt: ein bisschen Risiko hier, ein paar Kontrollen dort, dazu Richtlinien, Audits und eine Handvoll Reports. Und dann – ganz am Ende – eine Excel, die alles „zusammenführt“. Das Problem daran ist nicht Excel. Das Problem ist die Erwartung, dass man Führung, Steuerung und Nachweisführung über Listen „nachrüsten“ kann, während der Betrieb längst mit eigener Logik läuft.

Wenn Sie GRC wirklich wirksam machen wollen, hilft ein anderes Bild: GRC als Betriebssystem. Nicht als Tool, nicht als Abteilung und nicht als Papierlage – sondern als die Logik, nach der Entscheidungen vorbereitet, umgesetzt und überprüfbar gemacht werden. Ein Betriebssystem ist unsichtbar, solange es funktioniert. Es macht Abläufe zuverlässig, reduziert Reibung und sorgt dafür, dass ein System unter Last stabil bleibt. Genau das ist auch die Aufgabe eines guten GRC-Ansatzes: Er muss das Unternehmen im Alltag stabiler machen – und nebenbei auditfest.

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“.