DORA Compliance für Fintechs: Timeline, Kosten und die sechs teuersten Fallstricke

Marcus, Solution Architect

Seit dem 17. Januar 2025 ist DORA verbindlich. Keine Übergangsfrist, keine Schonfrist, kein "wir prüfen das noch". Die Europäischen Aufsichtsbehörden erwarten vollständige Compliance, und die BaFin hat klargestellt, dass sie die Verordnung aktiv durchsetzen wird. Wer jetzt noch diskutiert, ob DORA für sein Fintech relevant ist, hat die Frage falsch gestellt.

Die richtige Frage lautet: Welche der fünf DORA-Kernbereiche bereiten Ihrem Unternehmen das größte Risiko, und wie priorisieren Sie die nächsten zwölf Monate?

Dieser Artikel gibt keine diplomatischen Antworten. Er gibt Ihnen eine ehrliche Einschätzung der Kosten, eine realistische Timeline und eine klare Benennung der Fallstricke, in die erfahrungsgemäß die meisten mittelgroßen Fintechs tappen. Die DORA Compliance Beratung, die Ihr Haus braucht, beginnt nicht mit einem Präsentationsdeck über die fünf Säulen der Verordnung. Sie beginnt damit, ehrlich zu benennen, wo Sie heute stehen und was eine vollständige Implementierung wirklich kostet.

DORA ist kein Upgrade von BAIT

Viele CISOs, besonders in Häusern, die bereits unter dem KAIT/BAIT-Regime der BaFin gearbeitet haben, machen denselben Fehler: Sie behandeln DORA als eine Art Versionsupgrade ihrer bestehenden IT-Governance. Das ist falsch, und dieser Irrtum ist teuer.

BAIT und KAIT definieren Mindestanforderungen an die Informationssicherheit von Banken und Versicherungen in Deutschland. DORA definiert einen EU-weit einheitlichen Rahmen für die digitale operationelle Resilienz. Die Verordnung gliedert sich in fünf Kernbereiche: ICT-Risikomanagement, Meldung von IKT-bezogenen Vorfällen, Digital Operational Resilience Testing, Management von Drittparteirisiken aus IKT und den Informationsaustausch über Cyberbedrohungen.^[1]

Der Unterschied zwischen BAIT und DORA ist nicht graduell, er ist kategorial. BAIT fragt: "Haben Sie eine dokumentierte IT-Sicherheitsrichtlinie?" DORA fragt: "Können Sie beweisen, dass Ihre gesamte IKT-Lieferkette unter einem realistischen Störungsszenario operationell resilient bleibt, und wenn nicht, warum haben Sie das Restrisiko akzeptiert und wer auf Vorstandsebene hat diese Akzeptanz dokumentiert?"

DORA verankert die Letztverantwortung für das ICT-Risikomanagement explizit auf der Ebene des Leitungsorgans.^[1] Das ist kein Detailpunkt in Artikel 5. Das ist die fundamentale Governance-Anforderung, an der viele DORA-Projekte scheitern, weil niemand sie wirklich ernst nimmt, bis ein Auditor nachfragt.

Das gilt für alle Finanzunternehmen im Anwendungsbereich der Verordnung: Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, Anbieter von Krypto-Asset-Dienstleistungen (CASPs), Versicherungsunternehmen und eine Reihe weiterer regulierter Einheiten. Für Fintechs bedeutet das in der Praxis: Fast jedes Unternehmen mit einer BaFin-Lizenz oder einer Passporting-Erlaubnis aus einem anderen EU-Staat fällt unter DORA. Eine "wir sind zu klein"-Argumentation existiert in der Verordnung nicht, lediglich eine Verhältnismäßigkeitsklausel für nicht bedeutende Institute, die den vereinfachten ICT-Risikomanagementrahmen nach Artikel 16 ermöglicht.

Was die Timeline wirklich bedeutet

Die offizielle Timeline liest sich technisch einfach: DORA wurde am 27. Dezember 2022 im Amtsblatt der EU veröffentlicht, trat am 16. Januar 2023 in Kraft und ist seit dem 17. Januar 2025 anwendbar.^[1] Dazu kamen Regulatory Technical Standards (RTS) und Implementing Technical Standards (ITS) der Europäischen Aufsichtsbehörden, die in mehreren Wellen bis Ende 2024 verabschiedet wurden.^[3]

Was diese Timeline in der Praxis bedeutet, ist eine andere Geschichte.

Die RTS zum ICT-Risikomanagementrahmen wurden erst im Januar 2024 finalisiert. Die RTS zu Threat-Led Penetration Testing (TLPT) folgten im März 2024. Das bedeutet, dass Fintechs für einen erheblichen Teil der konkreten Implementierungsarbeit weniger als zwölf Monate hatten, obwohl DORA formal zwei Jahre Vorlaufzeit bot.^[3]

Hinzu kommt ein strukturelles Problem: Die Anforderungen an das Informationsregister der Drittdienstleister waren in der ursprünglichen DORA-Verordnung weniger präzise spezifiziert als in den späteren Durchführungsverordnungen. Wer 2023 damit begonnen hat, ein solches Register aufzubauen, musste es 2024 oft von Grund auf neu strukturieren, weil die ESAs im Rahmen der ITS sehr detaillierte Templates vorgegeben haben, die von früheren Eigenentwicklungen erheblich abwichen.

Der dritte Aspekt, der in vielen Timelines fehlt: DORA enthält keine "Once and Done"-Compliance. Die Verordnung fordert ein dauerhaftes operationelles Regime mit jährlichen Resilienztests, regelmäßiger Überprüfung des ICT-Risikomanagementrahmen und laufendem Monitoring der Drittdienstleister. Wer DORA als abgeschlossenes Projekt betrachtet, hat die Verordnung nicht verstanden.

Was konkret seit Januar 2025 gilt:

Das vollständige ICT-Risikomanagementrahmenwerk gemäß Artikel 5 bis 16 muss implementiert und dokumentiert sein.^[1] Die Meldepflichten bei schwerwiegenden IKT-Vorfällen sind aktiv: Die Erstmeldung muss innerhalb von vier Stunden nach Feststellung eines schwerwiegenden Vorfalls erfolgen, die Zwischenmeldung folgt spätestens 72 Stunden später, die Abschlussmeldung nach einem Monat.^[1] Das Informationsregister aller IKT-Drittdienstleister muss vollständig und aktuell sein. Vertragliche Anforderungen nach Artikel 30 DORA müssen in alle relevanten IKT-Dienstleistungsverträge implementiert sein. Ein jährliches Programm von Resilienztests muss durchgeführt und dokumentiert werden.

Für systemrelevante Institute kommen die erhöhten Anforderungen an Threat-Led Penetration Testing hinzu, das alle drei Jahre durchgeführt werden muss.

DORA und NIS2: Abgrenzung

Ein Punkt, der in vielen Häusern für Verwirrung sorgt, ist das Verhältnis zwischen DORA und der NIS2-Richtlinie. Die kurze Antwort: Für Finanzunternehmen, die unter DORA fallen, gilt DORA als lex specialis, NIS2 tritt in diesen Fällen zurück.^[1]

Das klingt einfacher als es ist. Fintechs, die gleichzeitig regulierte Finanzdienstleistungen erbringen und kritische Infrastruktur im Sinne von NIS2 betreiben, müssen die Abgrenzung sorgfältig vornehmen. Ein Zahlungsdienstleister, der eigene Telekommunikationsinfrastruktur für sein Produkt betreibt, kann sich nicht pauschal auf DORA berufen.

Die praktische Empfehlung: Lassen Sie die regulatorische Zuordnung für jede Ihrer Betriebseinheiten explizit dokumentieren. DORA oder NIS2 ist keine akademische Frage, die Anforderungsunterschiede betreffen konkrete Punkte wie Meldewege, Definitionen schwerwiegender Vorfälle und die zuständigen Behörden.

Was beide Verordnungen gemeinsam haben: Sie verschieben die Compliance-Logik von "Was können wir dokumentieren?" zu "Können wir beweisen, dass unsere Sicherheitsmaßnahmen tatsächlich funktionieren?"^[2] Das ist ein fundamentaler kultureller Wandel für Organisationen, die bisher in Richtlinien und Prozessdokumenten dachten, ohne deren operative Wirksamkeit zu prüfen.

Die realen Kosten

Jede Kostenschätzung für DORA-Compliance, die mit einer einzigen runden Zahl antwortet, ist unseriös. Die Kosten hängen von zu vielen Variablen ab: Ausgangsniveau der IT-Governance, Komplexität der IKT-Lieferkette, Anzahl kritischer Drittdienstleister, Reife des bestehenden Incident-Management-Prozesses und verfügbares internes Personal.

Was ich nach mehreren DORA-Implementierungen sagen kann: Für ein mittelgroßes Fintech mit 50 bis 250 Mitarbeitern, das ernsthaft compliant werden will und nicht nur auf dem Papier, liegt der reale Aufwand zwischen 250.000 und 800.000 Euro im ersten Jahr. Das schließt externe Beratung, Tooling und internen Aufwand ein.

Diese Zahl schockiert viele Geschäftsführungen. Sie ist trotzdem realistisch. Wer 100.000 Euro budgetiert und glaubt, damit vollständig compliant zu werden, kauft sich eine Gap-Analyse und ein hübsches Präsentationsdeck. Er kauft sich keine Compliance.

Die Kostenblöcke im Einzelnen:

ICT-Risikomanagement-Framework: 40.000 bis 120.000 Euro für Entwicklung und Implementierung. Das umfasst die Erstellung eines vollständigen Rahmenwerks inklusive Asset-Inventar, Risikobewertung, Business Impact Analysis und Dokumentation. Wer bereits ein ISMS nach ISO 27001 betreibt, liegt am unteren Ende dieser Spanne. Wer von null beginnt, am oberen.

Drittparteirisikomanagement: 60.000 bis 200.000 Euro. Das ist für die meisten Fintechs der teuerste Einzelposten der gesamten DORA-Implementierung. Cloud-native Fintechs haben regelmäßig zwischen 15 und 40 IKT-Drittdienstleister, darunter kritische Provider wie AWS, GCP oder Azure sowie spezialisierte Zahlungsdienstleister, KYC-Anbieter und Fraud-Detection-Systeme. Jeder dieser Provider muss bewertet, vertraglich nach DORA-Anforderungen ausgestaltet und in das Informationsregister aufgenommen werden.

Incident Management und Reporting-Infrastruktur: 30.000 bis 80.000 Euro. Aufbau oder Überarbeitung von Prozessen zur Erkennung, Klassifizierung und Meldung schwerwiegender IKT-Vorfälle. Die 4-Stunden-Frist für die Erstmeldung ist kein reiner Papierprozess. Sie erfordert funktionierende technische Alarmsysteme, klar definierte Eskalationswege und Personal, das diese Wege auch unter Druck nutzen kann.

Resilienztestprogramm: 50.000 bis 150.000 Euro jährlich. Grundlegende Tests wie Vulnerability Assessments und Penetrationstests plus die formale Governance und Dokumentation dieser Tests auf Vorstandsebene.

GRC-Tooling: 20.000 bis 80.000 Euro jährlich. GRC-Plattformen, SIEM-Systeme, Drittparteirisiko-Management-Tools. Viele Fintechs versuchen hier zu sparen und kaufen sich Tabellenchaos, das im nächsten Audit als unzureichend eingestuft wird.

Interner Personalaufwand: Dieser Posten fehlt in fast jeder Kostenschätzung, die externe Berater vorlegen. Realistisch sind 0,5 bis 2,0 Vollzeitäquivalente im ersten Jahr, die für DORA-Aktivitäten gebunden sind und nicht für Produktentwicklung zur Verfügung stehen. Das ist der unsichtbarste, aber oft schmerzhafteste Kostenpunkt, weil er in keiner Projektrechnung erscheint.

Ein weiterer Punkt, der systematisch unterschätzt wird: DORA-Compliance muss dauerhaft finanziert werden. Nach dem ersten Implementierungsjahr sind laufende Kosten von 80.000 bis 180.000 Euro jährlich für Testing, Register-Pflege, Drittparteiüberwachung und regulatorisches Reporting realistisch.

Die sechs teuersten Fallstricke

Fallstrick 1: Das ICT-Asset-Inventar als Nachgedanke behandeln

Das ICT-Asset-Inventar stellt in der Praxis regelmäßig den kritischsten Engpass der gesamten DORA-Implementierung dar. Die Verordnung verlangt, dass Finanzunternehmen alle ihre IKT-Assets sowie deren Konfigurationen und Abhängigkeiten identifizieren und dokumentieren.^[1] Das klingt trivial. Es ist es nicht.

Sam Newman beschreibt in "Building Microservices", wie in verteilten Architekturen das Wissen über Systemabhängigkeiten sich über viele Teams und Repositories verteilt und nie vollständig in einem einzigen System konsolidiert ist.^[5] Genau dieses Phänomen trifft Fintechs besonders hart: Eine moderne Fintech-Architektur besteht aus Dutzenden von Microservices, serverless Funktionen, verwalteten Datenbankdiensten, externen APIs und Drittbibliotheken. Einzeln betrachtet ist keines dieser Elemente undokumentiert. Zusammengenommen und für Compliance-Zwecke nutzbar aufbereitet sind sie es fast immer.

Die Empfehlung ist eindeutig: Beginnen Sie mit dem Asset-Inventar, bevor Sie irgendeinen anderen DORA-Workstream starten. Es ist die Voraussetzung für alles andere, für die Risikoanalyse, für die Drittparteiidentifikation und für die Business Impact Analysis. Wer ohne dieses Fundament mit dem Drittparteirisikomanagement beginnt, baut auf Sand.

Fallstrick 2: Drittparteirisikomanagement auf Vertragsarbeit reduzieren

DORA enthält in Artikel 28 bis 44 detaillierte Anforderungen an das Management von IKT-Drittdienstleistern.^[1] Die häufigste Reaktion in der Praxis: Eine Rechtsabteilung überarbeitet die MSAs und SLAs mit den wichtigsten Providern, und das Thema gilt als erledigt.

Das ist gefährlich kurz gedacht. DORA verlangt nicht nur korrekte Verträge. Es verlangt ein kontinuierliches Überwachungsregime, regelmäßige Risikobewertungen, Exit-Strategien für kritische Dienstleister und die Fähigkeit, auf IKT-Vorfälle bei Drittdienstleistern operationell reagieren zu können.

Ein Vertrag mit AWS, der alle DORA-Klauseln enthält, aber ohne ein Notfallkonzept für den Fall eines regionalen AWS-Ausfalls hinterlegt ist, ist DORA-compliant auf dem Papier und operationell wertlos.

Die Frage, die jeder CISO seinen Teams stellen muss: "Wenn unser kritischster IKT-Drittdienstleister morgen für 48 Stunden ausfällt, was passiert dann genau, wer macht was und in welcher Reihenfolge?" Wenn die ehrliche Antwort "wir schauen dann" lautet, ist das Drittparteirisikomanagement nicht compliant, ungeachtet der Vertragsqualität.

Fallstrick 3: Die Meldepflichten unterschätzen

Die DORA-Meldepflichten für schwerwiegende IKT-Vorfälle werden in ihrer operationellen Komplexität stark unterschätzt. Die Erstmeldung muss innerhalb von vier Stunden nach Feststellung eines schwerwiegenden Vorfalls erfolgen, und in dieser Erstmeldung muss das Finanzunternehmen bereits den Vorfalltyp, die betroffenen Dienste und eine erste Einschätzung der Auswirkungen liefern.^[1] Die Zwischenmeldung folgt spätestens 72 Stunden später, die Abschlussmeldung nach einem Monat.

Das klingt nach bürokratischer Dokumentationsarbeit. Es ist in Wirklichkeit ein Stresstest für die gesamte Incident-Response-Organisation. Wer jemals einen echten Security-Incident managen musste, weiß: In den ersten vier Stunden herrscht Chaos. Teams koordinieren sich, Fakten sind unklar, Verantwortlichkeiten sind im besten Fall halb-definiert.

Konkret: Ihre Incident-Response-Playbooks müssen die DORA-Meldeklassifizierung als integralen Bestandteil des Workflows enthalten, nicht als Anhang. Dieser Workflow muss geübt werden, mindestens jährlich in einer Tabletop-Übung, die explizit das DORA-Meldeprozedere einschließt. Wer seinen ersten DORA-konformen Meldeprozess im Ernstfall übt, wird die 4-Stunden-Frist verfehlen.

Fallstrick 4: Resilienztests als Compliance-Checkbox behandeln

DORA verlangt ein Programm von Resilienztests, das von grundlegenden Vulnerability Assessments bis zu Threat-Led Penetration Tests reicht. Die Versuchung ist groß, einen jährlichen Penetrationstest zu bestellen, den Bericht in einen Ordner zu legen und das Thema als erledigt zu betrachten.

DORA verlangt etwas Grundlegenderes: Die Testergebnisse müssen in den ICT-Risikomanagementrahmen integriert werden, identifizierte Schwachstellen müssen nach einem definierten Prozess mit klar zugewiesenen Eigentümern und Fristen behoben werden, und die Governance dieser Tests muss auf Vorstandsebene verankert sein.

Martin Fowler beschreibt in "Patterns of Enterprise Application Architecture", wie technische Schulden sich in Systemen akkumulieren, wenn kein systematischer Abbau organisatorisch erzwungen wird.^[6] Dasselbe gilt für Sicherheitslücken. Ein Penetrationstest, dessen Findings in keinem Tracking-System mit Eigentümer und Frist landen, ist nicht nur nutzlos. Er ist aktiv schädlich, weil er eine falsche Sicherheit erzeugt und beim nächsten Audit als Beleg dafür herhalten muss, dass bekannte Schwachstellen ignoriert wurden.

Fallstrick 5: DORA als IT-Projekt statt als Governance-Thema behandeln

Das ist der kulturelle Fallstrick, und er ist in mittelgroßen Fintechs besonders verbreitet. DORA landet beim CISO oder CTO, der daraus ein Projektteam mit einem Backlog macht. Das Ergebnis: DORA-Compliance als Feature-Branch, der irgendwann in den Hauptzweig der Organisation gemergt werden soll.

Das funktioniert nicht, und zwar aus einem strukturellen Grund, den die Verordnung explizit adressiert: Die Letztverantwortung für das ICT-Risikomanagement liegt beim Leitungsorgan des Finanzunternehmens.^[1] Das bedeutet Vorstand oder Geschäftsführung, nicht CTO, nicht CISO.

Die praktischen Konsequenzen: Die Governance-Struktur muss sicherstellen, dass der Vorstand regelmäßig über den Stand des ICT-Risikomanagements informiert wird, dass Entscheidungen über Risikoakzeptanz auf Vorstandsebene getroffen und dokumentiert werden und dass die DORA-relevanten Richtlinien von der Geschäftsführung verabschiedet sind. Wer DORA als reines IT-Projekt behandelt ohne diese Governance-Anker zu setzen, wird beim ersten aufsichtlichen Gespräch erhebliche Erklärungsnöte haben.

Fallstrick 6: Das Informationsregister der Drittdienstleister als statisches Dokument behandeln

Das Informationsregister ist eine der technisch unscheinbarsten, aber operationell aufwändigsten DORA-Anforderungen. Es erfordert eine vollständige, aktuelle Dokumentation aller IKT-Drittdienstleister inklusive der Vertragsdetails, der unterstützten Funktionen, der geografischen Standorte der Datenspeicherung und -verarbeitung sowie einer Einschätzung der Kritikalität.^[3]

Die ESAs haben präzise Templates für dieses Register vorgegeben, mit über 50 Datenfeldern pro Dienstleister. Ein mittelgroßes Fintech mit 25 IKT-Drittdienstleistern, das dieses Register korrekt befüllt, bindet damit initial mehrere Personenmonate.

Der Fehler, den ich immer wieder beobachte: Das Register wird als Einmalprojekt behandelt und nach dem initialen Befüllen nicht mehr gepflegt. DORA verlangt, dass dieses Register bei wesentlichen Änderungen aktualisiert wird und mindestens jährlich vollständig überprüft wird. Ein veraltetes Register ist kein Register, es ist ein Compliance-Risiko, das bei einer Prüfung unmittelbar auffällt.^[2]

Ein pragmatischer Implementierungsplan

Für ein Fintech, das seine DORA-Compliance strukturiert angehen will, empfehle ich folgende Priorisierung. Diese Reihenfolge ist nicht akademisch, sie folgt den tatsächlichen Abhängigkeiten, die in der Praxis Projekte blockieren.

Phase 1 (Monate 1 bis 3): Fundament

Das ICT-Asset-Inventar steht als Erstes. Kein anderer Workstream kann ohne diese Grundlage sinnvoll voranschreiten. Parallel dazu: Gap-Analyse gegen den DORA-Anforderungskatalog und die finalen RTS, Identifikation kritischer IKT-Drittdienstleister, Einrichtung der DORA-Governance-Struktur mit expliziter Vorstandsverankerung und Benennung eines verantwortlichen Programmleiters mit direktem Zugang zur Geschäftsführung.

Realistisches Budget für Phase 1: 60.000 bis 150.000 Euro.

Phase 2 (Monate 4 bis 8): Kern-Compliance

Entwicklung und Implementierung des ICT-Risikomanagementrahmenwerks, Überarbeitung der Verträge mit kritischen Drittdienstleistern nach Artikel 30 DORA, Aufbau des Informationsregisters nach ESA-Template, Implementierung der Incident-Management-Prozesse inklusive DORA-Klassifizierung und Meldewege zur BaFin.

Realistisches Budget für Phase 2: 120.000 bis 350.000 Euro.

Phase 3 (Monate 9 bis 12): Testing und Operationalisierung

Durchführung des ersten vollständigen Resilienztestprogramms, Tabletop-Übungen für Incident Response mit explizitem DORA-Meldeprozedere, Überprüfung und Finalisierung der Dokumentation, erste interne Audit-Readiness-Prüfung.

Realistisches Budget für Phase 3: 70.000 bis 200.000 Euro.

Dauerhafter Betrieb ab Monat 13: 80.000 bis 180.000 Euro jährlich für laufendes Testing, Register-Pflege, Drittparteiüberwachung und regulatorisches Reporting.

Diese Phasen können je nach Ausgangsreifegrad beschleunigt oder verlangsamt werden. Was sich nicht beschleunigen lässt, ist die organisatorische Verankerung. Die Governance-Strukturen, die DORA fordert, brauchen Zeit, um sich in den operativen Betrieb einzufügen.

Was eine gute DORA Compliance Beratung wirklich leistet

Der Markt für DORA-Beratungsleistungen ist seit 2023 stark gewachsen. Jede größere Unternehmensberatung und viele spezialisierte Anbieter offerieren DORA-Pakete. Die Qualitätsunterschiede sind erheblich.

Was eine seriöse DORA Compliance Beratung auszeichnet, lässt sich an drei Kriterien festmachen:

Technische Tiefe bei der Drittparteirisikobewertung: Ein Berater, der Drittparteirisikomanagement auf Vertragsoptimierung reduziert ohne die technischen Abhängigkeiten und Architekturen zu verstehen, liefert halbe Arbeit. Die Bewertung kritischer IKT-Drittdienstleister erfordert ein Verständnis der technischen Integration, nicht nur der rechtlichen Grundlagen. Wer nicht versteht, wie eine Multi-Cloud-Architektur mit ihren Abhängigkeiten aufgebaut ist, kann kein sinnvolles Drittparteirisikoprofil erstellen.

Operationelle Orientierung statt Dokumentationsoptimierung: DORA-Compliance entsteht nicht durch perfekte Richtlinien und Policies, sondern durch funktionierende Prozesse. Ein Berater, der primär Dokumente produziert ohne die operationelle Umsetzung zu begleiten, löst das falsche Problem. Die entscheidende Frage ist nicht, ob das Incident-Response-Handbuch die DORA-Anforderungen formal abdeckt, sondern ob die Organisation in einem echten Incident tatsächlich so handelt.

Verständnis der aufsichtlichen Prüfungslogik: Die BaFin und die ESAs prüfen DORA nicht mit einem statischen Checklisten-Ansatz. Sie prüfen, ob die internen Prozesse und die Governance-Struktur tatsächlich geeignet sind, die Ziele der Verordnung zu erreichen.^[2] Ein Berater, der nur den Buchstaben der Verordnung kennt aber nicht die Prüfungsphilosophie der deutschen Aufsicht, bereitet seinen Mandanten auf ein Compliance-Bild vor, das beim ersten aufsichtlichen Gespräch auseinanderfällt.

DORA und die technische Architektur

Ein Aspekt, der in vielen DORA-Implementierungen zu kurz kommt: Die Verordnung hat unmittelbare Implikationen für technische Architekturentscheidungen.

Das gilt besonders für die Anforderungen an Business Continuity und Recovery. DORA fordert, dass Finanzunternehmen Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs) für kritische Funktionen definieren und diese durch tatsächliche Tests validieren.^[1] Das ist keine Dokumentationsübung, das ist ein Architektur-Constraint.

Ein System, das für kritische Zahlungsfunktionen ein RTO von zwei Stunden deklariert, aber auf einer Single-Region-Deployment-Architektur ohne automatisiertes Failover läuft, ist nicht DORA-compliant. Die Architektur muss die deklarierten RTOs und RPOs technisch unterstützen können. Wer beides nicht in Einklang bringt, schreibt bewusst Compliance-Dokumente, die bei einem realen Incident nicht einzuhalten sind.

Vaughn Vernon, dessen Arbeiten zur Domain-Driven Design-Praxis das strategische Design verteilter Systeme fundamental beeinflusst haben, zeigt, dass die sorgfältige Abgrenzung von Bounded Contexts nicht nur ein semantisches Werkzeug ist, sondern direkte Auswirkungen auf die Fehlerausbreitung in verteilten Architekturen hat. Dieser Ansatz ist für DORA-Implementierungen direkt relevant: Eine Fintech-Architektur, in der ein Ausfall eines einzelnen Zahlungsservices das gesamte System in Mitleidenschaft zieht, hat ein strukturelles Problem, das durch keine Governance-Dokumentation gelöst werden kann.

Die Empfehlung ist klar: Bringen Sie technische Architekten in die DORA-Implementierung ein, nicht als Beobachter, sondern als aktive Mitgestalter. Die RTO/RPO-Definitionen müssen mit den tatsächlichen Architektur-Capabilities abgeglichen werden. Wenn die Architektur die definierten Ziele nicht erfüllen kann, muss entweder die Architektur angepasst oder die Ziele realistisch korrigiert werden. Eines von beidem, aber nicht beides offenlassen.

Fazit: Compliance als dauerhafter operativer Zustand

DORA ist keine Einmalinvestition und kein Projekt mit Endtermin. Es ist ein dauerhaftes operationelles Regime, das kontinuierliche Aufmerksamkeit, Ressourcen und Governance erfordert. Fintechs, die das als reine Kostenlast betrachten, werden frustriert sein. Fintechs, die es als Reifegrad ihrer operationellen IT-Organisation verstehen, werden feststellen, dass viele DORA-Anforderungen zu einem tatsächlich resilienteren Betrieb führen, unabhängig von aufsichtlichen Anforderungen.

Was den Unterschied zwischen "compliant auf dem Papier" und "wirklich compliant" ausmacht, lässt sich in einem Satz zusammenfassen: Wirkliche DORA-Compliance bedeutet, dass Ihre Organisation einen schwerwiegenden IKT-Vorfall erkennen, klassifizieren, an die Aufsicht melden und operationell bewältigen kann, ohne dass irgendjemand dabei ein Handbuch aufschlagen muss.

Das ist das eigentliche Ziel der Verordnung. Die Dokumentation ist der Beweis, nicht das Ziel selbst.

Wenn Sie wissen wollen, wo Ihr Haus konkret steht, beginnen Sie mit einer strukturierten Gap-Analyse gegen die finalisierten RTS und ITS, nicht gegen die ursprüngliche DORA-Verordnung von 2022, sondern gegen den Stand, den die ESAs in ihren finalen Standards von 2024 definiert haben.^[3] Dieser Unterschied allein sorgt in jedem zweiten Projekt für Überraschungen.

---

Quellen

[1] Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die digitale operationale Resilienz im Finanzsektor und zur Änderung der Verordnungen (EG) Nr. 1060/2009, (EU) Nr. 648/2012, (EU) Nr. 600/2014, (EU) Nr. 909/2014 und (EU) 2016/1011. Amtsblatt der EU, L 333, 27. Dezember 2022. https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32022R2554

[2] BaFin, "DORA: Digital Operational Resilience Act, Wichtige Informationen für beaufsichtigte Unternehmen", Merkblatt, aktualisiert 2025. https://www.bafin.de/DE/Aufsicht/DigitaleFinanzdienstleistungen/DORA/dora_node.html

[3] European Supervisory Authorities (EBA, EIOPA, ESMA), "Final Report: Draft Regulatory Technical Standards on ICT risk management framework and on simplified ICT risk management framework under Articles 15 and 16 DORA", JC 2023 86, Januar 2024. https://www.eba.europa.eu/regulation-and-policy/operational-resilience/digital-operational-resilience-act-dora-policy-products

[4] ENISA, "Technical Guidance on the Digital Operational Resilience Act (DORA) for Financial Entities", Europäische Agentur für Netz- und Informationssicherheit, 2024. https://www.enisa.europa.eu/topics/digital-operational-resilience

[5] Sam Newman, "Building Microservices: Designing Fine-Grained Systems", 2. Auflage, O'Reilly Media, 2021, ISBN 978-1492034025.

[6] Martin Fowler, "Patterns of Enterprise Application Architecture", Addison-Wesley Professional, 2002, ISBN 978-0321127426.