Wenn die IT nicht ausfallen darf: DORA und die digitale operationale Resilienz des Finanzsektors

Der Aufhänger: Ein Freitagnachmittag, an dem die Zahlungen stehen bleiben

Stell dir vor, es ist Freitag, kurz vor 16 Uhr. Eine mittelgroße europäische Bank rollt ein Routine-Update ihres Kernbankensystems aus – nichts Aufregendes, so etwas passiert jede Woche. Doch dieses Mal reagiert das Cloud-Speichersystem des externen Anbieters, auf dem die Transaktionsdatenbank liegt, mit einem stillen Konfigurationsfehler. Innerhalb von Minuten hängen Überweisungen fest, Kartenzahlungen werden abgelehnt, das Online-Banking zeigt weiße Seiten. Der Anbieter sitzt nicht im Haus der Bank; er sitzt in einem Rechenzentrum, dessen Betreiber Kunden in ganz Europa hat. Die Bank kann nichts anderes tun, als ein Ticket zu öffnen und zu warten.

Vor 2025 wäre das ein internes Drama gewesen, das man nach dem Wochenende in einem Post-Mortem aufarbeitet. Seit dem 17. Januar 2025 ist es eine regulatorische Verpflichtungskaskade. Die Bank muss den Vorfall klassifizieren, ihn gegebenenfalls als „schwerwiegend" einstufen und dann eine strikte Uhr respektieren: eine erste Meldung an die zuständige Aufsichtsbehörde binnen weniger Stunden, ein Zwischenbericht binnen 72 Stunden, ein Abschlussbericht binnen eines Monats. Sie muss belegen können, dass sie den Cloud-Vertrag mit Ausstiegsklauseln, Auditrechten und Sicherheitsanforderungen ausgestattet hatte. Und wenn der Cloud-Anbieter groß genug ist, unterliegt er inzwischen selbst der direkten Aufsicht durch eine europäische Behörde – unabhängig davon, dass er formal gar kein Finanzunternehmen ist.

Das ist die Welt, die der Digital Operational Resilience Act – kurz DORA, offiziell Verordnung (EU) 2022/2554 – geschaffen hat. DORA ist der Versuch der EU, eine unbequeme Wahrheit in Gesetzesform zu gießen: Ein modernes Finanzsystem ist im Kern ein IT-System. Ob eine Bank solvent ist, nützt niemandem etwas, wenn ihre Rechenzentren stillstehen, ihre Dienstleister ausfallen oder ein Angreifer ihre Systeme lahmlegt. Finanzstabilität ist untrennbar mit operationaler Resilienz verbunden – mit der Fähigkeit, IKT-Störungen zu widerstehen, sie zu absorbieren und sich von ihnen zu erholen.

Für jemanden wie Sven – Senior AI Engineer mit einem Bein in der Cloud-Architektur und einem in der IT-Sicherheit – ist DORA aus zwei Richtungen relevant. Als Ingenieur, der Systeme für oder mit Finanzunternehmen baut, definiert DORA, welche Nachweise, Verträge und Tests ein Produkt braucht, bevor es in Produktion gehen darf. Und als Dienstleister ist man mit DORA plötzlich Teil einer Lieferkette, deren regulatorisches Gewicht ganz oben – bei den systemrelevanten Cloud-Providern – so schwer geworden ist, dass eine eigene, direkte EU-Aufsicht dafür geschaffen wurde. Dieser Artikel nimmt dich auf die ganze Strecke mit: von der Grundidee über die fünf Säulen, das Prinzip der Verhältnismäßigkeit und die Aufsicht kritischer Drittdienstleister bis zu Zeitplan, Sanktionen und dem, was 2025/26 tatsächlich passiert ist.

Teil 1: Warum DORA? Von der Kapitaldecke zur Betriebsfähigkeit

Die alte Logik: Geld gegen Risiko

Jahrzehntelang drehte sich die Finanzregulierung fast ausschließlich um finanzielle Risiken. Der Basler Rahmen (Basel II/III), die europäischen Umsetzungen und die Aufsichtspraxis fragten im Kern: Hat eine Bank genug Kapital, um Verluste aus Krediten, Marktschwankungen oder Zahlungsausfällen aufzufangen? Das operationelle Risiko – also das Risiko von Verlusten durch fehlerhafte interne Prozesse, Menschen, Systeme oder externe Ereignisse – existierte in dieser Welt zwar, wurde aber überwiegend so behandelt, wie man Finanzrisiken behandelt: Man unterlegte es mit Kapital. Ein IT-Ausfall war ein potenzieller Verlustposten, gegen den man Eigenkapital vorhielt.

Diese Logik hat eine blinde Stelle. Kapital hilft, wenn Geld verloren geht. Es hilft nicht, wenn das Problem darin besteht, dass die Systeme schlicht nicht mehr laufen. Eine perfekt kapitalisierte Bank, deren Handelsplattform seit vier Stunden offline ist, deren Kunden nicht auf ihr Geld zugreifen können und deren Meldewesen ausgefallen ist, hat kein Kapitalproblem – sie hat ein Betriebsfähigkeitsproblem. Und in einer Welt, in der Zahlungen in Millisekunden erfolgen, in der Handel algorithmisch abläuft und in der ein einziger Cloud-Anbieter Hunderte Finanzunternehmen gleichzeitig bedienen kann, ist dieses Betriebsfähigkeitsproblem zum systemischen Risiko geworden.

Der Flickenteppich davor

Vor DORA war die europäische Regulierung digitaler Resilienz ein Flickenteppich. Es gab Leitlinien der Europäischen Bankenaufsichtsbehörde (EBA) zum Auslagerungsmanagement und zur IKT-Sicherheit, sektorspezifische Vorgaben für Versicherer, nationale Aufsichtsanforderungen wie die deutschen BAIT/VAIT und eine Fülle überlappender, teils widersprüchlicher Anforderungen. Ein grenzüberschreitend tätiges Finanzunternehmen musste in jedem Mitgliedstaat leicht andere Regeln beachten. Das war teuer, uneinheitlich und ließ genau die Lücke offen, die das größte Risiko barg: die Drittdienstleister. Wer eine kritische Funktion an einen Cloud-Anbieter auslagerte, verschob damit ein Risiko, das die einzelne Aufsichtsbehörde kaum noch greifen konnte, weil der Anbieter außerhalb ihres Zuständigkeitsbereichs lag.

Die Rechtsnatur: eine Verordnung, kein Kompromiss

DORA wurde am 14. Dezember 2022 verabschiedet und trat am 16. Januar 2023 in Kraft. Entscheidend ist ihre Rechtsform: DORA ist eine Verordnung, keine Richtlinie. Eine EU-Verordnung gilt unmittelbar und einheitlich in allen Mitgliedstaaten, ohne dass sie erst in nationales Recht umgesetzt werden müsste. Das unterscheidet DORA fundamental von der NIS2-Richtlinie, deren konkrete Ausgestaltung von Land zu Land variiert und deren Umsetzung sich in vielen Staaten verzögert hat. Bei DORA gilt im Kern überall derselbe Text. Nach einer zweijährigen Vorbereitungsphase ist DORA seit dem 17. Januar 2025 anwendbar – ohne die gestaffelten Übergangsfristen, die der EU AI Act kennt. Vom Stichtag an galt der volle Pflichtenkatalog.

Der Grundgedanke: Resilienz statt Perfektion

Die zentrale gedankliche Wende von DORA lautet: Man kann Ausfälle nicht verhindern, also muss man lernen, sie zu überstehen. DORA verlangt nicht, dass Systeme niemals ausfallen – das wäre naiv. Es verlangt, dass ein Finanzunternehmen jederzeit weiß, welche IKT-Risiken es trägt, dass es Störungen schnell erkennt und meldet, dass es regelmäßig testet, ob seine Abwehr wirklich hält, dass es die Risiken seiner Dienstleister im Griff hat und dass es aus den Vorfällen der anderen lernt. Aus dieser Wende folgen die fünf Säulen, die den Kern der Verordnung bilden.

Teil 2: Der Anwendungsbereich – wer betroffen ist

Bevor wir zu den Säulen kommen, lohnt der Blick darauf, für wen DORA überhaupt gilt – denn der Anwendungsbereich ist bewusst weit gefasst. DORA erfasst rund zwanzig Kategorien von Finanzunternehmen: Kreditinstitute (Banken), Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Handelsplätze, zentrale Gegenparteien, Zentralverwahrer, Verwaltungsgesellschaften, Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler, Anbieter von Krypto-Dienstleistungen, Ratingagenturen, Crowdfunding-Dienstleister und weitere. Vom Großkonzern bis zum kleinen Zahlungsinstitut fällt praktisch der gesamte regulierte Finanzsektor darunter.

Zugleich – und das ist die eigentliche Neuerung – erfasst DORA die IKT-Drittdienstleister dieser Unternehmen. Cloud-Anbieter, Rechenzentrumsbetreiber, Softwarehäuser, Anbieter von Datenanalyse- und Sicherheitsdiensten: Sobald sie kritische IKT-Dienste für Finanzunternehmen erbringen, werden ihre Verträge, ihre Sicherheitszusagen und ihre Ausfallsicherheit zum regulatorischen Gegenstand. Die größten und systemrelevantesten unter ihnen werden sogar direkt einer europäischen Aufsicht unterstellt (dazu mehr in Teil 5). Und der Anwendungsbereich reicht über die EU-Grenzen hinaus: Ein Anbieter mit Sitz außerhalb der EU, der kritische Dienste für ein EU-Finanzunternehmen erbringt, kann ebenfalls in den Sog der Regulierung geraten.

Teil 3: Die fünf Säulen im Detail

Man kann sich DORA als ein Gebäude auf fünf Säulen vorstellen. Jede Säule adressiert einen anderen Aspekt der operationalen Resilienz; zusammen tragen sie das Dach der Betriebsfähigkeit.

Säule 1: IKT-Risikomanagement – die Verantwortung wandert nach oben

Die erste Säule verlangt einen umfassenden, dokumentierten Rahmen für das IKT-Risikomanagement: Das Finanzunternehmen muss seine informations- und kommunikationstechnischen Assets identifizieren, schützen, Störungen erkennen, auf sie reagieren und sich von ihnen erholen. Diese fünf Verben – identifizieren, schützen, erkennen, reagieren, erholen – sind kein Zufall; sie entsprechen dem Aufbau etablierter Sicherheitsrahmen wie dem NIST Cybersecurity Framework, sodass ein Unternehmen, das bereits nach solchen Standards arbeitet, hier auf Vertrautes trifft.

Die vielleicht wichtigste und schärfste Neuerung dieser Säule betrifft nicht die Technik, sondern die Verantwortung. DORA weist die letztendliche Verantwortung für das IKT-Risikomanagement ausdrücklich dem Leitungsorgan zu – dem Vorstand, der Geschäftsführung. Cyber-Resilienz ist damit ausdrücklich Chefsache und keine Angelegenheit, die man an die IT-Abteilung delegieren und dann vergessen darf. Das Management muss den Rahmen genehmigen, ihn überwachen und – das ist der wunde Punkt – über hinreichende eigene Kenntnisse verfügen, um IKT-Risiken überhaupt beurteilen zu können. Ich bin der Meinung, dass diese Verlagerung der Verantwortung nach oben die kulturell wirksamste Bestimmung der gesamten Verordnung ist, weil sie IKT-Sicherheit aus der Nische holt und zur Vorstandsfrage macht.

Säule 2: Vorfallmeldung – die Uhr tickt

Die zweite Säule harmonisiert, wie IKT-bezogene Vorfälle erfasst, klassifiziert und gemeldet werden. Der erste Schritt ist immer die Klassifizierung: Ist ein Vorfall „schwerwiegend"? Dafür definieren technische Standards Kriterien wie die Zahl betroffener Kunden, die Dauer und die geografische Ausbreitung der Störung, den Datenverlust und die wirtschaftlichen Auswirkungen. Erst wenn ein Vorfall diese Schwellen überschreitet, greift die Meldepflicht in voller Härte – und dann beginnt eine strikte Uhr mit drei Stufen:

• Erstmeldung: binnen vier Stunden nach der Klassifizierung als schwerwiegend, spätestens jedoch 24 Stunden nach Bekanntwerden des Vorfalls. Die Klassifizierung selbst muss ohne unangemessene Verzögerung erfolgen – man kann die Uhr also nicht dadurch anhalten, dass man einen Vorfall bewusst nicht einstuft.
• Zwischenbericht: binnen 72 Stunden nach der Erstmeldung, mit aktualisierten Details – auch dann, wenn sich am Status nichts geändert hat.
• Abschlussbericht: binnen eines Monats nach dem Zwischenbericht, mit Ursachenanalyse (Root-Cause), Behebungsmaßnahmen und einer Bewertung der Auswirkungen.

Die Meldungen laufen über harmonisierte Vorlagen, die in technischen Standards (RTS 2025/301 und ITS 2024/2956) festgelegt sind, sodass ein Vorfall in Frankfurt genauso strukturiert gemeldet wird wie einer in Dublin oder Mailand. Die verspätete oder unterlassene Meldung ist ein sanktionsfähiger Verstoß. Für die Ingenieurspraxis bedeutet diese Säule vor allem eines: Die technische Fähigkeit, einen Vorfall schnell zu erkennen, seinen Umfang zu bestimmen und sauber zu dokumentieren, ist keine Kür mehr, sondern die Voraussetzung, um eine gesetzliche Frist überhaupt einhalten zu können. Wer erst nach drei Tagen weiß, wie viele Kunden betroffen waren, hat die 4-Stunden-Frist längst gerissen.

Säule 3: Resilienztests – von der Schwachstellenprüfung zum Red Team

Die dritte Säule verlangt, dass ein Finanzunternehmen seine digitale Resilienz nicht bloß behauptet, sondern regelmäßig prüft. Auf der Basisebene bedeutet das ein jährliches Programm aus Schwachstellenanalysen, Sicherheitsbewertungen, Netzwerksicherheitsprüfungen und ähnlichen Maßnahmen für alle betroffenen Unternehmen.

Für die bedeutendsten Institute geht DORA jedoch deutlich weiter und verlangt Threat-Led Penetration Testing (TLPT) – bedrohungsgeleitete Penetrationstests, mindestens alle drei Jahre. TLPT ist kein gewöhnlicher Pentest. Es ist ein strukturierter, nachrichtendienstlich informierter Red-Team-Angriff, der prüft, ob die Erkennungs- und Reaktionsfähigkeiten eines Instituts unter realistischen Angriffsbedingungen tatsächlich funktionieren. Die entscheidenden Merkmale: Der Test basiert auf echter, von einem externen Threat-Intelligence-Anbieter erstellter Bedrohungsaufklärung; er läuft gegen Live-Produktionssysteme und kritische Funktionen, nicht gegen eine Testumgebung; und er kann sogar kritische Drittdienstleister in seinen Umfang einbeziehen.

TLPT ist keine Erfindung aus dem Nichts. Es baut auf dem TIBER-EU-Rahmen (Threat Intelligence-Based Ethical Red Teaming) auf, den die Europäische Zentralbank entwickelt hat, und gießt diesen faktisch für die designierten Institute in verbindliches Recht. Der Unterschied zu einem klassischen Pentest ist auch der Umfang: Während ein Pentest meist einen abgegrenzten Teil eines Systems prüft, zielt TLPT auf die gesamte Verteidigungskette der Organisation – Menschen, Prozesse und Technik gleichermaßen. Für Sicherheitsingenieure ist das die Säule, die den Beruf am unmittelbarsten prägt, weil sie „Sicherheit" von einer Behauptung in einen wiederkehrenden, messbaren Beweis verwandelt.

Säule 4: Drittparteienrisiko – das Herzstück von DORA

Wenn DORA eine Säule hat, die es von allem Vorherigen abhebt, dann ist es die vierte. Sie adressiert genau die Lücke, die der alte Flickenteppich offen ließ: das Risiko, das entsteht, wenn ein Finanzunternehmen kritische IKT-Funktionen an Dritte auslagert. Die Kernpflichten sind konkret und einschneidend.

Erstens muss jedes Finanzunternehmen ein Informationsregister führen – eine vollständige, strukturierte Übersicht über alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern. Dieses Register ist den zuständigen Behörden jährlich (in der Praxis bis zum 31. März) vorzulegen. Es zwingt die Unternehmen, überhaupt erst einmal zu wissen, von wem sie abhängen – eine Frage, die vor DORA erstaunlich viele nicht sauber beantworten konnten.

Zweitens schreibt DORA Mindestinhalte für Verträge mit IKT-Drittdienstleistern vor. Verträge über kritische oder wichtige Funktionen müssen unter anderem klare Leistungsbeschreibungen, Datenschutz- und Sicherheitsanforderungen, Auditrechte (das Finanzunternehmen und die Aufsicht dürfen prüfen), Regelungen zur Unterauftragsvergabe und – besonders wichtig – Ausstiegsstrategien enthalten. Ein Finanzunternehmen muss belegen können, dass es einen Anbieter im Ernstfall geordnet verlassen und die Funktion migrieren oder ersetzen kann, ohne dass der Betrieb zusammenbricht. Damit greift DORA das Problem des Lock-in direkt an: Eine kritische Abhängigkeit ohne Fluchtweg ist unter DORA schlicht nicht mehr zulässig.

Drittens muss das Unternehmen die Konzentrationsrisiken im Blick behalten. Wenn ein einziger Cloud-Anbieter mehrere kritische Funktionen trägt, oder wenn die halbe Branche denselben Anbieter nutzt, entsteht ein systemisches Klumpenrisiko, das DORA sichtbar machen und begrenzen will.

Säule 5: Informationsaustausch – die freiwillige Säule

Die fünfte Säule ist die leichteste. Sie ermutigt Finanzunternehmen, innerhalb vertrauenswürdiger Gemeinschaften Bedrohungsinformationen auszutauschen – Angriffsindikatoren, Taktiken, Techniken und Verfahren von Angreifern. Der Gedanke ist einfach: Cyberangriffe treffen selten nur ein Ziel; was gestern eine Bank getroffen hat, trifft morgen die nächste. Wenn die Institute ihre Erkenntnisse teilen, steigt die Resilienz der ganzen Branche. Anders als die übrigen vier Säulen ist der Informationsaustausch freiwillig – DORA schafft den rechtlichen Rahmen und die Erlaubnis, verpflichtet aber niemanden zur Teilnahme.

Teil 4: Das Prinzip der Verhältnismäßigkeit

An dieser Stelle stellt sich eine berechtigte Frage: Soll ein kleines Zahlungsinstitut mit fünfzehn Mitarbeitern wirklich denselben Apparat auffahren wie eine global systemrelevante Großbank? DORA beantwortet das mit dem Grundsatz der Verhältnismäßigkeit (Proportionalität). Die Pflichten sollen im Verhältnis zur Größe, zum Risikoprofil und zur Komplexität eines Unternehmens stehen.

Konkret sieht DORA für kleine und nicht vernetzte Unternehmen einen vereinfachten IKT-Risikomanagement-Rahmen vor. Und das anspruchsvollste Instrument, das bedrohungsgeleitete Penetrationstesten (TLPT), gilt ohnehin nur für die Institute, die von den Behörden anhand ihrer Bedeutung ausdrücklich dafür bestimmt werden – nicht für jeden. Die Verhältnismäßigkeit ist damit kein Schlupfloch, sondern eine bewusste Justierung: Die Härte der Regulierung soll dort am größten sein, wo der potenzielle Schaden für das Finanzsystem am größten ist. Trotzdem bleibt für kleinere Häuser ein spürbarer Kern an Pflichten bestehen – die Grundidee, dass IKT-Risiko Chefsache ist und dass man seine Dienstleister kennen muss, gilt für alle.

Teil 5: Die Aufsicht kritischer IKT-Drittdienstleister – DORAs schärfstes Schwert

Hier wird DORA regulatorisch wirklich neuartig. Bisher konnte eine Finanzaufsicht immer nur das beaufsichtigte Finanzunternehmen selbst greifen, nicht dessen Zulieferer. Wenn tausend Banken denselben Cloud-Anbieter nutzen und dieser Anbieter ein Problem hat, ist das ein systemisches Risiko – aber der Anbieter selbst war für die Finanzaufsicht bislang unsichtbar. DORA schließt diese Lücke, indem es die bedeutendsten Anbieter direkt einer europäischen Aufsicht unterstellt.

Die Designation: Wer wird „kritisch"?

Die drei Europäischen Aufsichtsbehörden (die ESAs: EBA für das Bankwesen, ESMA für die Kapitalmärkte, EIOPA für Versicherungen) bewerten IKT-Drittdienstleister und benennen die systemrelevanten als kritische IKT-Drittdienstleister (Critical ICT Third-Party Providers, CTPPs). Artikel 31(2) DORA nennt vier Kriterien, die dabei zusammenwirken: die systemische Bedeutung der von dem Anbieter abhängigen Finanzunternehmen, der Grad der Ersetzbarkeit des Anbieters, seine grenzüberschreitende Tätigkeit und der Grad seiner Verflechtung mit dem Finanzsektor. Ein Anbieter muss alle relevanten Kriterien erfüllen, nicht nur eines.

Im November 2025 veröffentlichten die ESAs die erste Liste designierter CTPPs: 19 Anbieter wurden benannt und unterliegen seither der direkten EU-Aufsicht. Darunter sind die großen Namen, die man erwartet – die führenden Cloud-Hyperscaler und einige spezialisierte IT- und Datendienstleister. Bemerkenswert an der ersten Runde ist die Cloud-Konzentration: Ein erheblicher Teil der 19 CTPPs sind generische Cloud-Infrastruktur-Anbieter, und die Aufsicht hat darauf hingewiesen, dass ein großer Teil der EU-Finanzunternehmen kritische Funktionen bei mehreren der großen Cloud-Provider betreibt. Genau dieses Klumpenrisiko war einer der Hauptgründe, warum DORA überhaupt eine Drittparteienaufsicht schuf.

Der Lead Overseer und seine Befugnisse

Für jeden CTPP wird eine der drei ESAs als federführende Aufsicht (Lead Overseer) bestimmt – grob nach Sektorschwerpunkt: die EBA für bankennahe Anbieter, die ESMA für den Kapitalmarkt- und Nachhandelsbereich, die EIOPA für versicherungsspezifische Anbieter. Der Lead Overseer prüft, ob der CTPP über angemessene Risikomanagement- und Governance-Strukturen verfügt, um die Resilienz seiner Dienste zu gewährleisten. Er kann Informationen anfordern, Untersuchungen und Vor-Ort-Prüfungen durchführen und verbindliche Empfehlungen aussprechen.

Und hier liegt das schärfste Schwert: Befolgt ein CTPP diese Empfehlungen nicht, kann der Lead Overseer Zwangsgelder verhängen – bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes des Anbieters, für jeden Tag der Nichtbefolgung, über einen Zeitraum von bis zu sechs Monaten. Für einen der weltgrößten Cloud-Anbieter ist das eine Zahl mit erheblichem Abschreckungspotenzial. Zum ersten Mal kann eine europäische Behörde einem globalen Technologiekonzern also direkt und mit finanzieller Wucht Vorgaben zur Betriebssicherheit machen – nicht über den Umweg des Finanzkunden, sondern unmittelbar.

Für 2026 – das Jahr, in dem dieser Artikel entsteht – ist die Phase der ersten umfassenden Prüfungen angelaufen; für mehrere Anbieter werden im Laufe des Jahres die ersten verbindlichen Empfehlungen erwartet. DORA ist damit vom Regelwerk in die gelebte Aufsichtspraxis übergegangen.

Teil 6: Zeitplan und Sanktionen

Der Zeitstrahl

Die Sanktionen

DORA überlässt die Durchsetzung gegenüber den Finanzunternehmen weitgehend den nationalen zuständigen Behörden (in Deutschland der BaFin), die wirksame, verhältnismäßige und abschreckende Sanktionen verhängen. Die Größenordnungen sind erheblich: Für Verstöße können Finanzunternehmen mit Geldbußen belegt werden, die sich in schweren Fällen an einem Prozentsatz des weltweiten Jahres- oder Tagesumsatzes orientieren; für einzelne Verantwortliche und kleinere Einheiten kommen feste Höchstbeträge im Millionenbereich in Betracht. Für die CTPPs greifen die bereits genannten Zwangsgelder von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes.

Wichtiger als die reine Zahl ist die Systematik: DORA sanktioniert nicht nur den erfolgreichen Angriff oder den spektakulären Ausfall, sondern bereits das Fehlen der geforderten Strukturen – ein nicht geführtes Register, ein Vertrag ohne Ausstiegsklausel, eine verpasste Meldefrist, ein ausgebliebener Test. Man kann DORA-Bußgelder also kassieren, ohne dass je ein einziger Kunde einen Ausfall bemerkt hätte. Das ist gewollt: Die Verordnung will Resilienz erzwingen, bevor der Ernstfall eintritt, nicht erst danach abrechnen.

Teil 7: DORA im Kontext – Nachbarn im Regelungsgeflecht

DORA steht nicht allein. Es ist Teil einer ganzen Welle europäischer Digitalregulierung, und seine Verwandtschaftsverhältnisse helfen, es einzuordnen.

Der nächste Nachbar ist die NIS2-Richtlinie, die die Cybersicherheit für „wesentliche" und „wichtige" Einrichtungen über viele Sektoren hinweg regelt – von Energie über Gesundheit bis zur digitalen Infrastruktur. Hier gilt der Grundsatz lex specialis derogat legi generali: DORA ist das speziellere Gesetz für den Finanzsektor und geht NIS2 in seinem Anwendungsbereich vor. Ein Finanzunternehmen erfüllt seine sektorspezifischen Resilienzpflichten über DORA, nicht über NIS2. Wer die Logik von NIS2 verstanden hat, erkennt in DORA denselben Grundgedanken – Meldepflichten, Risikomanagement, Verantwortung der Leitung – nur eben in einer für den Finanzsektor zugeschnittenen, unmittelbar geltenden und ungewöhnlich detaillierten Form.

Interessant ist auch die inhaltliche Nähe zur Post-Quanten-Kryptographie: DORAs Forderung nach kontinuierlichem IKT-Risikomanagement erfasst auch das langfristige Risiko, dass heutige Verschlüsselung durch künftige Quantencomputer gebrochen wird – ein Risiko, das man unter dem Stichwort „Harvest now, decrypt later" kennt. Und die Vorfall- und Bedrohungslogik von DORA lässt sich unmittelbar auf mikroarchitektonische Angriffsklassen wie Spectre und Meltdown beziehen, bei denen eine scheinbar harmlose Hardware-Optimierung zur systemischen Schwachstelle wurde. Nicht zuletzt berührt DORAs Anspruch an ununterbrochene Betriebsfähigkeit dieselben verteilten Systeme, deren Konsens- und Zeitmechanismen an anderer Stelle im Vault behandelt werden.

Querverweise im Vault

• NIS2 und was sie für mittelständische IT-Beratungsunternehmen in Deutschland wirklich bedeutet – der nächste Verwandte im Regelungsgeflecht; DORA als lex specialis des Finanzsektors.
• Die Pyramide des Risikos: Wie der EU AI Act künstliche Intelligenz bändigt – und warum das die ganze Welt betrifft – ein weiteres risikobasiertes EU-Digitalgesetz, dieselbe Regulierungsphilosophie.
• Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer – ein Langfristrisiko, das DORAs IKT-Risikomanagement mit abdecken muss.
• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – wie aus einer Optimierung eine systemische Schwachstelle wird.
• Wie Maschinen sich einig werden: Verteilter Konsens von FLP über Paxos zu Raft – die technische Grundlage der Ausfallsicherheit, die DORA regulatorisch verlangt.
• Uhren, die ihre eigene Unsicherheit kennen: Google Spanner, TrueTime und die Beherrschung der Zeit in der Cloud – Cloud-Infrastruktur und Konsistenz, das technische Fundament unter der Drittparteien-Säule.

Erkenntnis zum Mitnehmen

Wenn du aus diesem Artikel eine einzige Sache mitnimmst, dann diese: DORA verschiebt die Frage von „Ist das System sicher?" zu „Kannst du beweisen, dass du einen Ausfall überstehst – und weißt du, von wem du dabei abhängst?" Resilienz ist keine Eigenschaft, die man einmal herstellt, sondern eine, die man fortlaufend nachweist – durch dokumentierte Risikomanagement-Strukturen, durch schnelle und ehrliche Vorfallmeldungen, durch echte Tests gegen echte Produktionssysteme und durch eine Lieferkette, aus der man im Ernstfall geordnet aussteigen kann.

Für die tägliche Ingenieurspraxis heißt das ganz konkret: Behandle Beobachtbarkeit (Observability), Vorfalldokumentation und Ausstiegsfähigkeit nicht als lästige Compliance-Anhängsel, sondern als erstklassige Designanforderungen. Ein System, das nicht schnell sagen kann, wie viele Nutzer eine Störung betrifft, kann keine 4-Stunden-Frist einhalten. Eine Architektur, die einen einzigen Anbieter ohne Fluchtweg umklammert, ist unter DORA nicht mehr baubar. Und ein Team, dessen Führung IKT-Risiko an „die IT" delegiert, hat die kulturelle Kernbotschaft der Verordnung verfehlt. DORA ist, richtig gelesen, weniger eine Bürokratie- als eine Ingenieurdisziplin: Es zwingt dazu, Resilienz von Anfang an einzubauen, statt sie hinterher zu behaupten.

Reflexionsfrage

DORA macht die Ausstiegsfähigkeit aus einer kritischen Abhängigkeit zur Pflicht – ein Finanzunternehmen muss einen Cloud-Anbieter im Ernstfall geordnet verlassen können. Denke an ein System, an dem du gerade arbeitest oder das du kennst: Wenn dein wichtigster externer Dienstleister morgen ausfiele oder du ihn aus regulatorischen Gründen verlassen müsstest – wie lange würde die Migration dauern, und weißt du das überhaupt genau genug, um es einer Aufsichtsbehörde zu belegen?

Quellen

• Application of the Digital Operational Resilience Act (DORA): Key considerations – DLA Piper
• Five Pillars Explained: Digital Operational Resilience Act (DORA) – Bizzdesign
• The European Supervisory Authorities designate critical ICT third-party providers under DORA – European Banking Authority
• Designation of critical ICT third-party providers under DORA: What does it mean for regulated firms? – DLA Piper
• DORA Incident Reporting: 4h/72h/1M Timelines & Templates – regulation-dora.eu
• DORA Threat-Led Penetration Testing (TLPT): Articles 26–27 Requirements – financialregulations.eu
• DORA act penalties, regulation, and compliance framework – Avenga

← All articles