DORA für Banken: Was die EU-Verordnung regelt und wie sie funktioniert

Teil 1 von 7 unserer DORA-Serie für Banken. Dieser Einstieg ordnet die Verordnung ein und zeigt, warum digitale operationale Resilienz als Führungsaufgabe organisiert werden muss. Für den Übergang von der Einordnung zur praktischen Auslagerungssteuerung verweist Teil 2 auf den DORA-Exit-Plan.

Autor: acceleraid Redaktion

DORA ist ein Betriebsmodell für digitale Resilienz

DORA ist keine zusätzliche Checkliste für die Informationssicherheit. Die Verordnung (EU) 2022/2554 verbindet Governance, Technik, Meldewesen und die Steuerung externer IKT-Dienstleistungen zu einem gemeinsamen Rahmen für die digitale operationale Resilienz im Finanzsektor. Ihre praktische Frage lautet deshalb nicht nur: „Sind unsere Systeme geschützt?“ Sondern auch: Kann das Institut Störungen erkennen, Entscheidungen nachvollziehbar treffen, weiterarbeiten und seine Dienstleister wirksam steuern? Die Verordnung wurde am 14. Dezember 2022 unterzeichnet, trat am 16. Januar 2023 in Kraft und gilt seit dem 17. Januar 2025. (EUR-Lex, Verordnung (EU) 2022/2554)

Für Bankvorstände und verantwortliche Bereiche ist das entscheidend, weil DORA Verantwortlichkeit nicht an die IT delegiert. Das Risikomanagement für Informations- und Kommunikationstechnik (IKT) muss mit Geschäftsprozessen, Datenflüssen, Notfallverfahren und Lieferantenbeziehungen zusammenpassen. Eine gute Umsetzung beginnt daher mit einem belastbaren Zielbild: Welche Leistungen sind für Kunden und Marktinfrastruktur wesentlich, welche Systeme und Daten tragen sie, und wer entscheidet im Störfall?

Für wen und ab wann der Rahmen gilt

Der Anwendungsbereich ist breit. Artikel 2 zählt 21 Kategorien von Finanzunternehmen auf, darunter Kredit- und Zahlungsinstitute, Handelsplätze, Versicherer, Ratingagenturen, Krypto-Dienstleister und kritische IKT-Drittdienstleister. DORA ist unmittelbar geltendes EU-Recht; die Ausgestaltung sollte jedoch proportional zur Größe, zum Risikoprofil sowie zu Art, Umfang und Komplexität der Dienstleistungen erfolgen. (EUR-Lex, Artikel 2 sowie Artikel 3 und 4)

In Deutschland hat sich zugleich der nationale Regelwerkskontext verschoben. BaFin hob KAIT, VAIT und ZAIT mit Ablauf des 16. Januar 2025 auf; für Institute mit IKT-Risikomanagement nach DORA gelten die BAIT-Ausnahmen seit dem 17. Januar 2025. Die vollständige Aufhebung der BAIT ist zum Ablauf des 31. Dezember 2026 vorgesehen; ab 1. Januar 2027 erfasst der neu gefasste § 1a Absatz 2 KWG weitere Institute. (BaFin, Mitteilung zur DORA-Umsetzung)

Das ist kein Anlass, bestehende Kontrollen pauschal zu verwerfen. Es ist ein Anlass, sie auf die DORA-Logik abzubilden: Risiko, Verantwortlichkeit, Nachweis und Wiederherstellbarkeit müssen über den gesamten digitalen Leistungsfluss konsistent sein.

Die fünf Säulen als Steuerungslandkarte

Die Struktur der Verordnung lässt sich in fünf zusammenhängende Arbeitsfelder übersetzen. Erstens verlangt sie ein IKT-Risikomanagement. Zweitens regelt sie die Behandlung und Meldung IKT-bezogener Vorfälle. Drittens fordert sie Tests der digitalen operationalen Resilienz, einschließlich Threat-Led Penetration Testing (TLPT). Viertens adressiert sie das Management von IKT-Drittparteienrisiken einschließlich der Aufsicht über kritische Anbieter. Fünftens eröffnet sie einen Rahmen für den Austausch von Informationen über Cyberbedrohungen. (EUR-Lex, Aufbau der DORA-Verordnung)

Die Säulen sind kein Organisationsdiagramm. Sie beschreiben Abhängigkeiten: Ein Incident-Prozess funktioniert nur, wenn Eigentümer von Daten und Services bekannt sind. Ein Resilienztest ist nur aussagekräftig, wenn seine Ergebnisse in Risikoentscheidungen einfließen. Und eine Exit-Strategie für einen Provider bleibt Papier, wenn Vertragsrechte, Datenformate und interne Fähigkeiten nicht dazu passen.

Meldefristen brauchen einen geübten Entscheidungsprozess

Bei schwerwiegenden IKT-Vorfällen verdichtet DORA die Zeit. Die Erstmeldung ist innerhalb von vier Stunden nach der Klassifizierung abzugeben und spätestens 24 Stunden nach Kenntnisnahme des Vorfalls. Eine Zwischenmeldung folgt spätestens 72 Stunden nach der Erstmeldung; der Abschlussbericht ist innerhalb eines Monats fällig. Für Kreditinstitute gilt die in der RTS enthaltene Wochenend- und Feiertagserleichterung nicht. (EUR-Lex, Delegierte Verordnung (EU) 2025/301)

Diese Fristen sind kein Reporting-Thema am Ende einer Störung. Sie verlangen ein vorbereitetes Zusammenspiel aus Erkennung, Klassifizierung, Eskalation, fachlicher Bewertung und Freigabe. Ein praktikables Vorgehen definiert deshalb vorab einen Vorfallsverantwortlichen, eine belastbare Vertretung, Kontaktwege zu Compliance und Kommunikation sowie die Beweise, die zur Klassifizierung verfügbar sein müssen. Die Frage „Wer formuliert die Meldung?“ kommt erst danach.

In Deutschland ist BaFin die zuständige Behörde. Das unterstreicht, dass vollständige, konsistente und zeitgerechte Informationen nicht nur operative, sondern aufsichtliche Relevanz haben.

Testen heißt mehr als kontrollieren

DORA verlangt nicht nur Prävention, sondern überprüfbare Belastbarkeit. Für ausgewählte Finanzunternehmen schreibt Artikel 26 TLPT mindestens alle drei Jahre und ausdrücklich an Live-Produktionssystemen vor. Welche Tests im Einzelfall angemessen sind, folgt aus Risiko und Proportionalität; entscheidend ist, ob das Institut aus den Ergebnissen konkrete Verbesserungen ableitet. (EUR-Lex, Artikel 26 DORA)

Das betrifft auch externe Abhängigkeiten. Wenn ein Cloud-, Software- oder Datenanbieter ausfällt, muss sichtbar werden, welche Funktion betroffen ist, welche Daten bewegt werden müssen und welche Alternative tatsächlich verfügbar ist. Teil 2 dieser Serie vertieft, warum ein Exit-Plan nicht nur dokumentiert, sondern getestet werden muss. Teil 7 liefert dafür die Einstufungslogik für kritische oder wichtige Funktionen.

Drittparteienrisiko beginnt vor dem Vertrag

DORA verschiebt den Blick von der Einkaufsentscheidung zur laufenden Steuerung. Bei IKT-Dienstleistungen für kritische oder wichtige Funktionen verlangt Artikel 28 Ausstiegsstrategien, alternative Lösungen und Übergangspläne. Artikel 30 ergänzt vertragliche Anforderungen, unter anderem zu Leistungs- und Datenverarbeitungsstandorten, zur Rückgabe von Daten in einem leicht zugänglichen Format und zu Kündigungsrechten. (EUR-Lex, Artikel 28 und 30 DORA)

Das ist besonders relevant, wenn Kunden-, Transaktions- oder Modellinformationen über mehrere technische Ebenen fließen. Das Informationsregister aus Teil 5 der Serie wird damit mehr als eine Meldeliste: Es macht Abhängigkeiten, Verträge und Datenflüsse prüfbar. Einen praxisnahen Zugang dazu beschreibt der Beitrag zum DORA-Informationsregister als Datenqualitätsproblem.

Bei kritischen IKT-Drittdienstleistern sieht DORA zudem ein tägliches Zwangsgeld von bis zu einem Prozent des durchschnittlichen weltweiten Tagesumsatzes des Vorjahres vor, begrenzt auf höchstens sechs Monate und mit 30 Kalendertagen Vorlauf. Für Finanzunternehmen bleiben die Folgen eines schwachen Dienstleistermanagements jedoch vor allem operativ: fehlende Handlungsfähigkeit, schlechte Nachweisbarkeit und eine Wiederherstellung unter Zeitdruck. (EUR-Lex, Artikel 35 DORA)

Ein pragmatischer Startpunkt für Banken

Ein wirksames DORA-Programm lässt sich als wiederkehrender Steuerungskreislauf aufsetzen. Erstens werden Services, Daten und Verantwortliche kartiert. Zweitens werden Risikoszenarien und Meldewege an realen Geschäftsprozessen getestet. Drittens werden Verträge, Subunternehmerketten und Exit-Optionen gegen diese Szenarien geprüft. Viertens fließen die Ergebnisse in Prioritäten, Budgets und die Arbeit des Managements zurück.

Der internationale Vergleich sollte dabei nicht mit Gleichsetzung verwechselt werden. DORA ist eine EU-Verordnung; eine Bankengruppe mit Aktivitäten in der Schweiz oder im Vereinigten Königreich braucht zusätzlich eine eigenständige Prüfung der jeweils lokalen aufsichtsrechtlichen Anforderungen.

Kurzvergleich: Schweiz und Vereinigtes Königreich

Das FINMA-Rundschreiben 2023/1 nennt bei den regelmäßig zu testenden schweren, plausiblen Szenarien ausdrücklich einen längeren Ausfall durch die Insolvenz eines wichtigen Dienstleisters als Beispiel für einen Stressed Exit. Für Gruppen mit Schweizer Präsenz ist dies ein klarer Hinweis, Exit-Szenarien nicht nur vertraglich, sondern betrieblich zu denken. (FINMA-Rundschreiben 2023/1)

Im Vereinigten Königreich adressiert das Critical-Third-Parties-Regime in der Policy Statement PS16/24 die operationale Resilienz kritischer Drittparteien im Finanzsektor. Die Regime sind nicht gleichzusetzen; für international tätige Banken ist die gemeinsame Lehre jedoch praktisch: Abhängigkeiten, Lieferketten und der geordnete Übergang nach einer Beendigung müssen vor dem Ernstfall sichtbar sein. (Bank of England, PS16/24)

Als Steuerungsprinzip bleibt jedoch übertragbar, was DORA konkret macht: digitale Abhängigkeiten transparent machen, Verantwortlichkeit festlegen und Wiederherstellung nicht erst im Ernstfall erfinden.

Die Stärke von DORA liegt damit nicht in einer einzelnen Kontrolle. Sie liegt in der Verbindung von Risiko, Test, Vertrag und Entscheidungsfähigkeit. Wer diese Verbindung herstellt, gewinnt nicht nur eine bessere Aufsichtsfähigkeit, sondern auch ein belastbareres digitales Betriebsmodell.

Die DORA-Serie im Überblick

• Teil 1: DORA für Banken: Was die EU-Verordnung regelt und wie sie funktioniert (dieser Beitrag)

• Teil 2: Der Exit-Plan nach DORA: Was er enthalten muss und warum er getestet werden muss

• Teil 3: Cloud-Abhängigkeit europäischer Banken: Wie man von AWS, Microsoft und Google notfalls loskommt

• Teil 4: Exit-Option für Customer-Engagement-Workloads: CDP, Personalisierung und Kampagnen DORA-konform absichern

• Teil 5: Das DORA-Informationsregister: Warum es in Wahrheit ein Datenqualitätsproblem ist

• Teil 6: KI-Anbieter als neues Konzentrationsrisiko: Was DORA für Modell-Abhängigkeiten bedeutet

• Teil 7: Kritisch oder wichtig? Risiko-Level von Core Banking bis CRM, Data Lake und CDP

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.