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?

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.

Operational Resilience klingt wie ein großes Programm. In der Praxis entscheidet sich aber sehr vieles an einer erstaunlich einfachen Frage: Wie schnell wird aus einem technischen Problem eine klare Entscheidung – und wie schnell wird aus dieser Entscheidung ein koordinierter Ablauf? Genau an dieser Stelle sind Incident-Prozesse in vielen Organisationen zu langsam. Nicht, weil Menschen nicht reagieren. Sondern weil sie im entscheidenden Moment zu viel klären müssen, was eigentlich längst geklärt sein sollte.

Wenn DORA ernst genommen wird, verschiebt sich der Blick vom „Incident als IT-Aufgabe“ hin zu „Incident als Betriebsfähigkeit“. Das ist kein kosmetischer Unterschied. Ein IT-Team kann einen Fehler beheben und trotzdem kann das Unternehmen als Ganzes langsam sein: weil Auswirkung und Priorisierung unklar bleiben, weil Kommunikation zögert, weil Dienstleister nicht sauber eingebunden werden, weil Freigaben fehlen oder weil das Thema Wiederherstellung erst dann strukturiert wird, wenn bereits wertvolle Zeit verloren ist. In Audits zeigt sich das häufig in einem typischen Muster: Prozesse sind beschrieben, Tickets existieren, aber die End-to-end-Kette ist brüchig. Und wenn die Kette brüchig ist, wird Geschwindigkeit zur Glückssache.

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.