

Wenn man sich mit dem Digital Operational Resilience Act – kurz DORA – beschäftigt, stellt sich schnell die Frage, wen diese EU‐Verordnung eigentlich betrifft. Auf den ersten Blick scheint die Antwort einfach: „Die Finanzbranche.“ Doch wer genauer hinschaut, erkennt, dass DORA nicht nur Banken und Versicherungen ins Visier nimmt, sondern einen weitaus größeren Kreis von Unternehmen – und dass manche Akteure überrascht sein könnten, wie direkt sie unter die neuen Vorgaben fallen. Die EU hat den Anwendungsbereich bewusst breit gefasst, um nicht nur die großen, offensichtlichen Player zu erfassen, sondern das gesamte digitale Ökosystem, das den europäischen Finanzmarkt stützt. Die Logik dahinter ist simpel und schlüssig: Digitale Resilienz funktioniert nur dann, wenn nicht nur die sichtbarsten Akteure abgesichert sind, sondern auch alle kritischen Verbindungen dazwischen.
DORA ist konzipiert als Querschnittsregelwerk über den Finanzsektor hinweg. Statt einzelne Institutionstypen isoliert zu betrachten, verknüpft die Verordnung die betriebliche Widerstandsfähigkeit von Finanzunternehmen mit der ihrer IKT‐Lieferkette (Informations- und Kommunikationstechnologie). Das bedeutet: Ein Institut, das seine Kernprozesse verlässlich betreibt, ist nur dann wirklich resilient, wenn auch die technischen Dienstleister, auf die es sich stützt, robust, transparent und gut gesteuert sind. Genau deshalb erfasst DORA sowohl die „klassischen“ Finanzunternehmen als auch – direkt oder indirekt – die Drittparteien, die deren digitale Grundversorgung sicherstellen, etwa Cloud-, Rechenzentrums-, Software-, Sicherheits- oder Kommunikationsanbieter.
Zur unstrittigen Kernzielgruppe zählen die großen Säulen der Finanzwirtschaft. Das sind insbesondere:
Damit adressiert DORA die Knotenpunkte des europäischen Finanzmarktes: Orte, an denen Abwicklung, Verwahrung, Handel und Zahlungsverkehr zusammenlaufen – also genau dort, wo Ausfälle oder Angriffe schnell systemische Auswirkungen entfalten.
Die Reichweite geht bewusst darüber hinaus. DORA umfasst auch vielfältige Finanzmarktakteure, die in der Öffentlichkeit weniger sichtbar sind, aber für das Funktionieren des Systems essenziell. Dazu gehören unter anderem:
Die Verordnung verzahnt so das gesamte Spektrum von Anlage, Handel, Abwicklung, Verwahrung, Berichtswesen und Zahlungsverkehr – ein Netz, das nur so stark ist wie seine schwächste (digitale) Verbindung.
Besonders bemerkenswert ist die Aufnahme von Krypto-Dienstleistern in den DORA-Kosmos – also etwa Handelsplätze für Krypto-Assets, Verwahrer (Wallet-Anbieter/Custodians) und weitere Erbringer von Diensten rund um digitale Vermögenswerte, soweit sie unter die einschlägigen EU-Regime fallen. Das Signal ist unmissverständlich: Die EU betrachtet die operative Resilienz auch in jungen, dynamischen Segmenten nicht als freiwillige Zugabe, sondern als Voraussetzung für Marktreife. Wer Krypto-Assets für EU-Kunden anbietet, wird künftig die gleiche Sprache der Resilienz sprechen müssen wie klassische Institute – in Prozessen, Tests, Meldungen, Verträgen und im Umgang mit Drittanbietern.
Zahlungsdienste und E-Geld-Emission sind die „Blutbahnen“ der Realwirtschaft. Unterbrechungen treffen Verbraucher und Firmen direkt – an der Kasse, im Online-Shop, in der Lohn- und Gehaltszahlung. Deshalb unterliegen auch Zahlungsinstitute und E-Geld-Institute den DORA-Pflichten. Die proportionalen Anforderungen können je nach Größe und Risikoprofil variieren, die Grundidee aber bleibt: belastbare IKT-Risikosteuerung, geübte Incident-Prozesse, getestete Wiederanlauf-Szenarien, wirksame Kontrolle der Dienstleister.
Auch Versicherer und Rückversicherer sind vollumfänglich adressiert – Branchen mit hoher Datenintensität (Underwriting, Schaden, Aktuariat) und vielfältigen Auslagerungen (z. B. Bestandsführungssysteme, Schadenplattformen, Cloud-Analytics). Je nach nationaler Ausgestaltung können auch Pensions-/Vorsorgeeinrichtungen erfasst sein. Entscheidend ist stets der Bezug zu den sektorspezifischen EU-Rechtsakten, auf die DORA verweist: Deren Definitionen entscheiden darüber, ob ein Unternehmen als Finanzunternehmen im Sinne von DORA gilt.
Für Handelsplätze, CCPs und CSDs gilt: Deren IKT-Stabilität ist gleichbedeutend mit Marktstabilität. DORA fordert hier entsprechend reife Testlandschaften (inklusive adversarischer Tests), eng getaktete Meldeprozesse, belastbare Business-Continuity- und Disaster-Recovery-Fähigkeiten sowie eine lückenlose Steuerung von IKT-Drittparteien. Der Maßstab ist hoch, die Begründung eindeutig: Ein Ausfall kann binnen Minuten marktweit spürbar werden.
Fondsgesellschaften, Vermögensverwalter und Datenbereitsteller stehen oft weniger im Rampenlicht, sind aber für Transparenz, Abrechnung und Governance unverzichtbar. DORA adressiert diese Rolle, indem es Anforderungen an IKT-Risikomanagement, Vorfallsteuerung, Testen, Drittparteienkontrolle und Informationsaustausch auf sie anwendet. Wer z. B. Transaktionsdaten aggregiert oder veröffentlicht, muss sicherstellen, dass diese Dienste auch unter Störungen verlässlich arbeiten – sonst bröckelt Marktintegrität.
Ein Alleinstellungsmerkmal von DORA ist der explizite Fokus auf IKT-Drittparteien. Zwei Ebenen sind dabei zu unterscheiden:
Kurz: IKT-Anbieter müssen sich darauf einstellen, dass DORA-Anforderungen zum De-facto-Standard in ihren Kundenbeziehungen werden – vom technischen Nachweis bis zur auditfesten Prozess- und Vertragsgestaltung.
DORA gilt unmittelbar in der EU. Drittlandsanbieter, die Dienstleistungen für EU-Finanzunternehmen erbringen, sind dennoch betroffen – spätestens durch die Vertragsanforderungen ihrer EU-Kunden. Wenn sie als kritisch eingestuft werden, können sogar aufsichtliche Pflichten direkt an sie adressiert werden. Das schafft einen extraterritorialen Wirkungsbereich: Wer den EU-Finanzmarkt bedienen will, muss EU-Resilienzkriterien erfüllen – unabhängig vom eigenen Sitz.
DORA verankert das Prinzip der Proportionalität. Umfang und Tiefe der Maßnahmen richten sich nach Größe, Komplexität, Risikoprofil und Bedeutung für das Finanzsystem. Kleine und mittlere Unternehmen werden also nicht über denselben Kamm geschoren wie Großinstitute. Aber: Herausfallen ist in der Praxis selten. Ein kleines Fintech mit Zahlungsdienstlizenz muss genauso ein tragfähiges IKT-Risikomanagement etablieren, Vorfälle klassifizieren und melden, die Drittparteiensteuerung dokumentieren und Resilienztests betreiben – nur eben in angemessenem Zuschnitt.
Auch Unternehmen, die nicht als Finanzunternehmen gelten, können faktisch DORA-Pflichten spüren, wenn sie für regulierte Kunden arbeiten. Beispiele:
Hier werden DORA-Anforderungen über Verträge, Kontrollrechte, Meldewege, Nachweise und Testteilnahmen zur Realität. Wer sich frühzeitig darauf einstellt, wird als „DORA-ready“ bevorzugter Partner – wer zögert, riskiert Ausschlüsse aus sensiblen Projekten.
In der Umsetzung tauchen häufig Abgrenzungsfragen auf, z. B.:
Wen DORA erfasst, der muss konkret liefern: ein IKT-Risikomanagement, das lebt; Incident-Prozesse mit klaren Fristen und Rollen; Resilienztests vom Schwachstellen-Scan bis zum adversarischen Test; Drittparteiensteuerung mit harten Mindestklauseln, Audit- und Exit-Rechten; und die Bereitschaft, Informationen zu Bedrohungen strukturiert auszutauschen. Diese Pflichten sind nicht „nice to have“, sondern aufsichtsrechtlich durchsetzbar – mit Prüfungen, Anordnungen und spürbaren Sanktionen. Genau dadurch wird die Frage „Bin ich betroffen?“ mehr als akademisch: Sie entscheidet darüber, ob ein Unternehmen seine Geschäftsbeziehungen im regulierten Umfeld halten und ausbauen kann.
Je öfter Sie „ja“ sagen, desto wahrscheinlicher ist eine direkte oder indirekte Betroffenheit – und desto dringlicher ist ein geordneter DORA-Fahrplan.
Damit wird DORA nicht zur Bedrohung, sondern zur Chance: Wer früh „DORA-ready“ ist, wird zum verlässlichen Partner – für Institute, für Aufsichten und für Kunden.
Unterm Strich lässt sich sagen: Die Reichweite von DORA ist bewusst breit angelegt, um systemische Risiken einzudämmen. Betroffen sind nicht nur die großen Banken oder Versicherungen, die in der öffentlichen Wahrnehmung den Finanzsektor prägen, sondern auch eine Vielzahl kleinerer Marktteilnehmer und technologischer Dienstleister. Wer heute noch glaubt, nicht in den Anwendungsbereich zu fallen, sollte die in DORA referenzierten Kategorien genau prüfen – und ebenso die eigenen Abhängigkeiten. Denn spätestens wenn ein regulierter Kunde Anforderungen an seine Lieferanten stellt, wird DORA für viele Unternehmen Realität – ob sie wollen oder nicht.
Für Unternehmen, die direkt unter DORA fallen, bedeutet das eine klare Pflicht zur Umsetzung der Vorgaben. Für indirekt Betroffene ist es eine strategische Weichenstellung: Proaktiv vorbereiten und als „DORA-tauglicher“ Anbieter punkten – oder mittelfristig Aufträge verlieren, weil die Compliance-Schwelle nicht erreicht wird. Die Frage ist nicht, ob man sich mit DORA auseinandersetzen muss, sondern wie schnell man damit beginnt – und wie konsequent man die eigene Rolle im finanziellen Digital-Ökosystem denkt. Genau darin liegt die eigentliche Stärke von DORA: Es macht sichtbar, dass digitale Resilienz keine Inselbegabung ist, sondern ein Gemeinschaftsprojekt entlang der gesamten Wertschöpfungskette.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 41
Spannend finde ich die praktische Seite: wie sich die Anforderung in einen belastbaren Arbeitsablauf übersetzen lässt. Reicht dafür zunächst ein kleiner Pilot oder braucht es sofort einen breiteren Ansatz?
Für mich wäre ein begrenzter Anwendungsfall der beste Einstieg. Dann sieht man relativ schnell, ob die Information tatsächlich zu einer anderen Priorität oder Entscheidung führt.
Den Pilotgedanken finde ich gut. Ergänzen würde ich eine klare Schwelle: Ab wann führt das Ergebnis zu einer Entscheidung und wann bleibt es nur eine Beobachtung?
Genau diese Verbindung ist entscheidend: klein beginnen, aber Wirkung und Entscheidungsfolge vorher festlegen. So bleibt der Aufwand vertretbar und das Ergebnis trotzdem belastbar.
Das überzeugt mich. Ein konkreter Fall mit klarer Zuständigkeit und Nachprüfung dürfte mehr zeigen als ein umfangreiches Modell ohne praktische Rückkopplung.
Eine Frage zur Umsetzung: Wie würdest du die im Beitrag angesprochenen Anforderungen in überschaubare erste Schritte übersetzen?
Ich würde mit klaren Verantwortlichkeiten und einem begrenzten Anwendungsfall beginnen. So lässt sich prüfen, ob die Vorgehensweise im Alltag tatsächlich hilft.
Ein weiterer Punkt: Wie prüft man, ob ein Dienstleister wirklich zur eigenen Widerstandsfähigkeit beiträgt?
Mein Vorschlag wäre: Ich würde nicht nur auf Zusagen schauen, sondern auf Abhängigkeiten und überprüfbare Abläufe. Der eigene Umgang mit einem Ausfall gehört für mich ebenfalls dazu.
Beim Prinzip bin ich dabei. Bei der Umsetzung könnte aber gerade die Übergabe zwischen zwei Zuständigen schwierig werden.
Dazu eine Rückfrage: Wer hält die Nachweise aktuell, nachdem das Projekt offiziell abgeschlossen ist?
Ich würde es so einordnen: Diese Aufgabe würde ich in den Betrieb überführen und an vorhandene Änderungsprozesse anbinden. Ein eigener Projektordner allein wäre dafür zu wenig.
Mir wäre die laufende Pflege wichtiger als die perfekte erste Fassung. Wie könnte man das mit überschaubarem Aufwand organisieren? Meine Ausgangsfrage bleibt: Wer hält die Nachweise aktuell, nachdem das Projekt offiziell abgeschlossen ist?
Eine überprüfbare Zuständigkeit wäre für mich die Basis. Dazu gehört auch, wer die notwendige Information liefert und wer handelt, wenn sie fehlt. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Wie verhindert man, dass das DORA-Projekt viele Dokumente produziert, aber den Betrieb kaum verändert?
Daran würde ich anknüpfen. Ich würde die Nachweise an konkrete Abläufe koppeln: Wer handelt, welche Information wird benötigt, und woran erkennt man, dass der Ablauf funktioniert?
Hier würde ich widersprechen: Ein zusätzlicher Prozess kann auch neue Reibung schaffen. Welche vorhandene Aufgabe könnte man damit zusammenführen?
Ein vorhandener Nachweis wäre für mich zunächst nur ein Hinweis. Seine Aussagekraft hängt davon ab, ob er wirklich den betrachteten Ablauf und Zeitraum abdeckt. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Welche minimale Lösung wäre für Abstimmung von Vertragsanforderungen und Betriebsrealität vertretbar, wenn ein kleines Team mehrere Rollen gleichzeitig übernimmt?
Ich würde die Rollen dennoch getrennt dokumentieren und für die kritische Entscheidung einen zweiten Blick vorsehen. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Abstimmung von Vertragsanforderungen und Betriebsrealität sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie würdet ihr Konzentrationsrisiken bei IT-Dienstleistern konkret prüfen, wenn die verfügbaren Nachweise lückenhaft sind?
Mein Vorschlag wäre, die Lücke offen dokumentieren und einen überprüfbaren nächsten Schritt vereinbaren, statt Vollständigkeit zu unterstellen. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Konzentrationsrisiken bei IT-Dienstleistern sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wo würdest du beginnen, wenn Personal und Zeit für die Umsetzung knapp sind? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Das ist ein wichtiger Punkt. Für mich wäre zuerst wichtig, kritische Leistungen und Abhängigkeiten zu verstehen. Daraus ließe sich begründen, welche Lücken zuerst bearbeitet werden.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Wie verhindert ihr bei Konzentrationsrisiken bei IT-Dienstleistern, dass eine vorläufige Lösung ohne erneute Prüfung dauerhaft bestehen bleibt?
Ich würde einen festen Wiedervorlagetermin und eine klare Entscheidung über Fortführung oder Abschluss vorsehen. Wichtig ist, dass die Ausnahme nicht allein deshalb bestehen bleibt, weil niemand mehr nachfragt. Mit Blick auf Konzentrationsrisiken bei IT-Dienstleistern würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Wie lässt sich bei Konzentrationsrisiken bei IT-Dienstleistern vermeiden, dass offene Punkte zwischen mehreren Zuständigkeiten liegen bleiben?
Ich würde den offenen Punkt mit einem Verantwortlichen, einem Termin und einem überprüfbaren Ergebnis verbinden. Bei mehreren Beteiligten sollte außerdem klar sein, wer eine Entscheidung herbeiführt. Für Konzentrationsrisiken bei IT-Dienstleistern würde ich den ersten Prüfschritt bewusst klein halten.
Woran erkennt man, dass eine Übung die Widerstandsfähigkeit prüft und nicht nur den Ablauf vorführt?
Das ist ein wichtiger Punkt. Ich würde das Ziel und die beobachtbaren Ergebnisse vorher festlegen. Eine erfolgreich abgehaltene Übung ist für mich noch kein Nachweis für einen funktionierenden Wiederanlauf.
Beim Prinzip bin ich dabei. Bei der Umsetzung könnte aber gerade die Übergabe zwischen zwei Zuständigen schwierig werden. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Eine überprüfbare Zuständigkeit wäre für mich die Basis. Dazu gehört auch, wer die notwendige Information liefert und wer handelt, wenn sie fehlt. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig. Mein Maßstab wäre die nachvollziehbare Wirkung.
Wie lässt sich vermeiden, dass Meldeprozesse erst mitten im Vorfall geklärt werden?
Mein Vorschlag wäre: Ich würde Rollen, Entscheidungspunkte und Informationswege vorab üben. Dabei wäre auch zu prüfen, ob die erforderlichen Informationen rechtzeitig verfügbar sind.
Ich würde das nicht allein anhand einer Beschreibung beurteilen. Was wäre ein überzeugender praktischer Nachweis? Meine Ausgangsfrage bleibt: Wie lässt sich vermeiden, dass Meldeprozesse erst mitten im Vorfall geklärt werden?
Bei fehlenden Informationen würde ich die Unsicherheit sichtbar machen und eine vorläufige Entscheidung mit klarer Wiedervorlage treffen. Einfach so zu tun, als wäre alles bekannt, wäre die schlechtere Grundlage. Auf die Ausgangsfrage bezogen: Ich würde Rollen, Entscheidungspunkte und Informationswege vorab üben. Dabei wäre auch zu prüfen, ob die erforderlichen Informationen rechtzeitig verfügbar sind.
Genau an der Übergabe sehe ich ebenfalls die Schwierigkeit. Ohne die nötige Information kann auch eine klar benannte Person wenig entscheiden. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern?
Ich würde kritische IKT-Abhängigkeiten zunächst an einem kritischen, aber überschaubaren Fall testen. Dann lassen sich Aufwand und Nutzen vernünftig vergleichen.