Elena Marchetti, YuSMP Group
Elena Marchetti Head of Product (SaaS), YuSMP Group · Spezialisiert auf regulatorisch-konforme Softwarearchitektur für FinTech- und Enterprise-Kunden in der DACH-Region und den USA
Compliance-Dokumente auf einem Schreibtisch in einem modernen deutschen Bankenbüro mit digitalem Sicherheitsschild-Symbol — Sinnbild für die ersten DORA-Prüfbefunde der BaFin

Die kurze Antwort

Die BaFin hat im Rahmen des Fachaustauschs mit dem Bundesverband Öffentlicher Banken Deutschlands (VÖB) im Juni 2026 ihre ersten konkreten DORA-Prüfbefunde veröffentlicht. Sie zeigen: Drei Bereiche fallen systematisch durch — ICT-Risikomanagement, Detection-Fähigkeiten und Business Continuity Management. Die BaFin hat Follow-up-Prüfungen für 2026 und 2027 angekündigt. Gleichzeitig zeigt eine aktuelle Erhebung, dass fast jedes zweite Finanzunternehmen in Deutschland noch erhebliche Umsetzungsprobleme hat.

Für FinTech-Unternehmen und Finanzinstitute, die mit custom Software oder Nearshore-Partnern arbeiten, bedeuten diese Befunde: DORA-Compliance ist kein reines IT-Governance-Thema — sie hat direkte Auswirkungen auf Softwarearchitektur, Vertragsgestaltung und Testprozesse.

Hintergrund: DORA tritt BAIT an

Der Digital Operational Resilience Act (DORA) ist seit dem 17. Januar 2025 für über 3.600 Finanzinstitute in Deutschland verbindlich. Er regelt EU-weit einheitlich, wie Unternehmen mit ICT-Risiken umgehen müssen, und hat das nationale BAIT-Rundschreiben der BaFin für die große Mehrheit der Institute abgelöst.

Das BAIT — die Bankaufsichtlichen Anforderungen an die IT — war seit 2017 das zentrale deutsche IT-Regelwerk für Banken. Für eine kleine Übergangsgruppe, vor allem Leasing- und Factoringgesesllschaften, gilt das BAIT noch bis zum 31. Dezember 2026. Danach ist die Harmonisierung vollständig: DORA ersetzt alle nationalen Vorgänger.

DORA umfasst fünf Kernbereiche: ICT-Risikomanagement (Artikel 5–16), Vorfallsmeldung (Artikel 17–23), Resilienz-Testing inklusive bedrohungsorientierter Penetrationstests (TLPT, Artikel 24–27), Drittanbieter-Risikomanagement (Artikel 28–44) sowie den Informationsaustausch zwischen Instituten (Artikel 45). Verstöße gegen die Kernanforderungen der Artikel 9–17 können mit bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes geahndet werden.

Drei Kernprobleme aus BaFins erster Prüfpraxis

Die BaFin veröffentlichte im Juni 2026 — rund 18 Monate nach Anwendungsbeginn — ihre ersten konkreten Befunde aus der Prüfpraxis. Die Analyse zeigt drei Schwerpunkte, die bei einer Vielzahl von Instituten Defizite aufweisen. Die Befunde gehen über administrative Formalfälle hinaus: Sie betreffen operative Kernprozesse.

1. ICT-Risikomanagement: Kritische Funktionen werden nicht vollständig identifiziert

Der meistbemangelte Bereich: Kritische oder wichtige Geschäftsfunktionen werden laut BaFin nicht immer vollständig identifiziert. Die Konsequenz ist strukturell — wer nicht weiß, welche Systeme und Prozesse wirklich kritisch sind, kann keine risikoangemessenen Sicherheitsmaßnahmen ableiten.

Konkret stellt die BaFin fest: Die Ableitung von ICT-Sicherheitsmaßnahmen aus der Funktion erfolgt nicht ausreichend risikobasiert. Außerdem mangelt es häufig an der Unabhängigkeit der DORA-Funktion innerhalb der Organisation — ein strukturelles Problem, das Rollenkonflikte erzeugt und die Prüfbarkeit der Compliance erschwert.

Für Teams, die Finanzsoftware entwickeln oder betreiben, bedeutet dies: Jede Systemkomponente muss einer Kritikalitätsstufe zugeordnet sein. Das ist keine einmalige Dokumentationsaufgabe, sondern ein Prozess, der bei jeder Veränderung der Systemlandschaft aktualisiert werden muss.

2. Detection-Fähigkeiten: SIEM-Lücken und fehlende Szenarien

Der zweite Schwerpunkt betrifft die Fähigkeit, Angriffe und Anomalien rechtzeitig zu erkennen. Die BaFin stellte fest, dass ICT-Systeme, die kritische Funktionen unterstützen, häufig nicht vollständig in SIEM-Plattformen (Security Information and Event Management) integriert sind. Detection-Szenarien fehlen oder werden nicht systematisch entwickelt und getestet.

Besonders problematisch: Die Alarmbearbeitung außerhalb der Geschäftszeiten ist vielfach nicht sichergestellt. Ein Angriff, der um 2 Uhr nachts beginnt und erst am nächsten Morgen eskaliert wird, ist für DORA-Zwecke ein vermeidbarer Vorfall — mit entsprechenden Meldepflichten und möglichen Sanktionen.

Das ist eine direkte Anforderung an die Softwarearchitektur: Strukturiertes Logging, definierte Alert-Eskalationspfade und 24/7-fähige Monitoring-Infrastruktur sind keine “nice-to-have”-Features, sondern regulatorische Pflicht.

3. Business Continuity Management: Veraltete Pläne, unrealistische Tests

Im dritten Bereich — Business Continuity — findet die BaFin: Business-Impact-Analysen sind unvollständig oder fehlen ganz. Geschäftsfortführungs- und Wiederherstellungspläne sind in einer Reihe von Fällen lückenhaft und veraltet. Tests und Übungen sind selten dokumentiert und oft nicht auf realistische Szenarien ausgelegt.

DORA verlangt, dass Notfallpläne nicht nur existieren, sondern regelmäßig getestet werden — und die Testergebnisse als Grundlage für Verbesserungen dienen. Die BaFin wird in Prüfungen explizit nach dokumentierten Vorfallreaktionsübungen fragen. Wer hier keine Nachweise hat, steht schlecht da.

Was das für DACH-Finanzinstitute bedeutet

Die Befunde der BaFin sind nicht abstrakt — sie signalisieren Prüfungsschwerpunkte für 2026 und 2027. Wer in diesen drei Bereichen Lücken aufweist, muss damit rechnen, bei der nächsten Prüfung unmittelbar konfrontiert zu werden.

Aktuelle Erhebungen zeigen: Fast jedes zweite Finanzunternehmen in Deutschland hat noch erhebliche Umsetzungsprobleme. Besonders der Mittelstand — Sparkassen, Genossenschaftsbanken, kleinere Zahlungsdienstleister — kämpft mit fehlenden Fachkräften, begrenzten Budgets und Prozessen, die für die DORA-Anforderungen (zum Beispiel 4-Stunden-Erstmeldung bei schwerwiegenden Vorfällen) nicht ausgelegt sind.

Zusätzlicher Zeitdruck entsteht durch den 31. Dezember 2026: Leasing- und Factoringgesellschaften müssen bis dahin den Übergang von BAIT zu DORA vollständig abgeschlossen haben. Im Herbst 2026 wird die BaFin auch den Register of Information — die Drittanbieter-Vertragsdokumentation — eingehend prüfen; bei der ersten Übermittlung in 2025 hatte sie bereits häufige Fehler dokumentiert.

Für österreichische und Schweizer Institute gilt: Die Anforderungen sind EU-weit einheitlich. Die FMA (Österreich) und die FINMA (Schweiz, via EWR-Anpassungen) folgen denselben Priorischemen. Wer in DACH operiert, sollte die deutschen BaFin-Befunde als Vorschau auf die eigene Prüfungssituation lesen.

Was Software-Teams jetzt konkret tun sollten

Die DORA-Anforderungen haben direkte Konsequenzen für die Softwarearchitektur und die Entwicklungsprozesse. Hier sind die wichtigsten Handlungsfelder:

  • Kritikalitätsklassifikation einführen: Jede Systemkomponente muss einer der DORA-Kritikalitätsstufen zugeordnet sein. Diese Klassifikation muss versioniert und bei jeder Änderung der Systemlandschaft aktualisiert werden.
  • SIEM-Integration sicherstellen: Alle Systeme, die kritische Funktionen unterstützen, müssen strukturiertes Logging in das zentrale SIEM liefern. Alert-Eskalationspfade und On-Call-Prozesse müssen 24/7-fähig sein und dokumentiert sein.
  • Business Continuity testen und dokumentieren: Notfallpläne müssen regelmäßig getestet werden — und zwar anhand realistischer Szenarien, nicht Trockenübungen. Die Testergebnisse müssen nachvollziehbar dokumentiert werden.
  • Drittanbieterverträge prüfen: Verträge mit Softwarelieferanten, Nearshore-Entwicklungspartnern und Cloud-Anbietern müssen die DORA-Anforderungen (Zugang, Audit-Rechte, Vorfallsmeldung, Exit-Management) abdecken. Der Register of Information muss vollständig und aktuell sein.
  • SDLC in ICT-Governance einbetten: Der Softwareentwicklungsprozess (SDLC) muss Teil des ICT-Risikomanagements sein: Security Reviews, Penetrationstests und Change-Management-Prozesse müssen dokumentiert und revisionssicher sein.

Für Finanzinstitute, die mit Nearshore-Entwicklungspartnern oder über Staff Augmentation arbeiten, gilt zusätzlich: Der externe Partner muss im Register of Information geführt werden, Verträge müssen Audit-Rechte und Exit-Klauseln nach DORA Art. 28 enthalten, und die Kritikalität der übertragenen Aufgaben muss bewertet sein.

FAQ

Was ist der Unterschied zwischen BAIT und DORA?

BAIT (Bankaufsichtliche Anforderungen an die IT) war das nationale deutsche Rundschreiben der BaFin für IT-Anforderungen an Banken. DORA (Digital Operational Resilience Act) ist die EU-weite Verordnung, die seit dem 17. Januar 2025 verbindlich gilt und BAIT für die meisten Finanzinstitute abgelöst hat. Für eine kleine Übergangsgruppe — vor allem Leasing- und Factoringgesellschaften — gilt BAIT noch bis zum 31. Dezember 2026, danach ist die Harmonisierung vollständig.

Wen betrifft DORA in Deutschland?

DORA betrifft über 3.600 Finanzinstitute in Deutschland: Banken, Zahlungsdienstleister, Wertpapierfirmen, Versicherungen, Kapitalverwaltungsgesellschaften, Kreditinstitute und ihre kritischen ICT-Drittdienstleister. Kleine und mittlere Finanzunternehmen profitieren von proportionalen Anforderungen, sind aber grundsätzlich eingeschlossen.

Was passiert bei Verstößen gegen DORA?

Verstöße gegen die Kernanforderungen (Artikel 9–17) können mit bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes geahndet werden — je nachdem, welcher Betrag höher ist. Für kleinere Verstöße (fehlerhafte oder unvollständige Informationen an Behörden) drohen bis zu 7,5 Millionen Euro oder 1 Prozent des Jahresumsatzes. Die BaFin hat angekündigt, 2026 und 2027 weitere Follow-up-Prüfungen durchzuführen.

Muss Software, die Finanzinstitute einsetzen, DORA-konform sein?

Ja, indirekt. DORA verpflichtet Finanzinstitute sicherzustellen, dass alle ICT-Systeme — einschließlich extern entwickelter oder bezogener Software — in das ICT-Risikomanagement eingebunden sind. Das bedeutet: strukturiertes Logging und Monitoring, dokumentierte API-Schnittstellen, Resilienztests und vertragliche DORA-Klauseln gegenüber Softwareanbietern und Nearshore-Partnern (Register of Information).

Was ist der Register of Information unter DORA?

Der Register of Information ist eine vollständige Dokumentation aller ICT-Drittdienstleisterverträge eines Finanzinstituts. Er muss jährlich an die europäischen Aufsichtsbehörden übermittelt werden und Angaben zu Dienstleister, Vertragslaufzeit, Art der Leistung und Kritikalität enthalten. Die BaFin hat bereits bei der ersten Übermittlung in 2025 häufige Fehler festgestellt und wird dies in Prüfungen gezielt adressieren.

Quellen

  • Bundesverband Öffentlicher Banken Deutschlands (VÖB): DORA in der Praxis: Erste Prüfungserfahrungen der BaFin, Juni 2026 — voeb.de
  • ADVISORI: DORA 2026: Why 44% of Financial Companies Are Not Compliantadvisori.de
  • Baker Tilly: One Year of DORA: BaFin Takes Stock and Looks Aheadbakertilly.de
  • Deutsche Bundesbank: BAIT / DORA — Regulierung und Aufsichtbundesbank.de
  • BaFin: DORA — Digital Operational Resilience Act, Überblickbafin.de
  • TÜV Consulting: EU AI Act ab 2. August 2026 & DORA: Was Unternehmen jetzt tun müssenconsulting.tuv.com