DORA scheitert nicht an Regulierung – sondern an fehlender Evidence
DORA scheitert nicht an Regulierung

DORA ist angekommen – aber oft falsch verstanden

 

Am 16. Juli 2025 hat die Europäische Zentralbank (EZB) im Rahmen der Bankenaufsicht einen Leitfaden zur Auslagerung von Cloud-Dienstleistungen veröffentlicht und damit ihre Erwartungen an die DORA-Umsetzung weiter konkretisiert. Auffällig ist dabei weniger die Einführung neuer Regeln als der klare Fokus auf nachweisbare Wirksamkeit. Parallel dazu weist die EZB in aufsichtlichen Veröffentlichungen darauf hin, dass viele Institute trotz vorhandener Konzepte weiterhin Defizite bei Testing, Incident-Response-Fähigkeiten und der operativen Steuerung von IT-Risiken aufweisen. In Prüfungen rückt damit eine zentrale Frage in den Vordergrund: Was funktioniert im Ernstfall tatsächlich – und was kann belastbar belegt werden? DORA hat damit endgültig die Phase der konzeptionellen Vorbereitung verlassen. Entscheidend wird nun die operative Evidence-Ebene.

Genau an diesem Punkt zeigt sich, warum DORA häufig missverstanden wird. Viele Organisationen behandeln DORA weiterhin wie ein erweitertes Compliance- oder Governance-Programm. Der regulatorische Fokus liegt jedoch längst woanders: nicht auf der Existenz von Richtlinien, sondern auf ihrer tatsächlichen Wirksamkeit im Betrieb. Wer DORA verstehen will, muss daher eine grundlegende Perspektive wechseln.

DORA ist kein klassisches Compliance-Projekt.
Es geht nicht darum, neue Richtlinien zu schreiben oder bestehende Frameworks zu erweitern.
Entscheidend ist eine andere Frage: Was kann eine Organisation im Ernstfall tatsächlich belegen?

In Prüfungen zählt nicht, was geplant oder dokumentiert ist.
Es zählt, was nachweislich funktioniert.

Warum Policies Sicherheit suggerieren – aber keine Resilienz beweisen

Viele DORA-Programme starten mit Policies, Zielbildern und Governance-Strukturen.
Das schafft Ordnung – aber noch keine operative Resilienz.

Richtlinien zeigen Absicht.
Resilienz zeigt sich erst in der Umsetzung unter realen Bedingungen.

DORA bewertet nicht, ob etwas definiert wurde,
sondern ob es wirksam, steuerbar und wiederholbar ist.

Was DORA unter „Evidence“ wirklich versteht

Evidence bedeutet im DORA-Kontext nicht Dokumentation um der Dokumentation willen.

Evidence ist:

  • getestete Szenarien
  • dokumentierte Ergebnisse
  • klare Verantwortlichkeiten
  • regelmäßige Wiederholung
  • nachvollziehbare Steuerung

Evidence entsteht nicht im Audit, sondern im laufenden Betrieb.

Die gefährlichste Lücke: Zwischen Definition und Nachweis

In vielen Organisationen existieren:

  • Incident-Prozesse
  • Notfallkonzepte
  • Testpläne

Was häufig fehlt:

  • konsistente Durchführung
  • klare Bewertung der Ergebnisse
  • Management-taugliche Berichte

Diese Lücke zwischen Konzept und Nachweis ist das eigentliche DORA-Risiko.

Warum Test Governance zum DORA-Schlüssel wird

Tests sind der Punkt, an dem Theorie auf Realität trifft.
Sie machen sichtbar, ob Prozesse, Systeme und Organisation belastbar sind.

Ohne klare Test Governance bleiben Tests:

  • unkoordiniert
  • nicht vergleichbar
  • nicht steuerbar

Mit Governance werden Tests zu Evidence-Lieferanten für DORA.

Die entscheidende Management-Frage

Für Vorstände und Geschäftsleitungen reduziert sich DORA auf eine zentrale Frage:

Welche kritischen Szenarien haben wir getestet – wann – und mit welchem Ergebnis?

Wenn diese Frage nicht klar und belegbar beantwortet werden kann,
ist DORA nicht unter Kontrolle.

DORA-Readiness beginnt mit Ehrlichkeit

DORA verlangt keine Perfektion.
DORA verlangt Transparenz, Steuerbarkeit und belastbare Evidence.

Organisationen, die das früh erkennen,
vermeiden Überraschungen im Audit – und gewinnen echte Resilienz.

Wer seine DORA-Readiness realistisch einschätzen möchte, sollte nicht mit neuen Programmen starten, sondern mit einem strukturierten Reality-Check.

Quellen:
¹ Europäische Zentralbank, Guide on outsourcing cloud services to cloud service providers, 16 Jul 2025, https://www.bankingsupervision.europa.eu/press/pr/date/2025/html/ssm.pr250716~c0401b1b6b.en.html