DORA schützt die Lieferkette, heißt es. Die falsche IBAN sieht es nicht.

Der Rat der EU verkündete es am 28. November 2022 wörtlich: Der Digital Operational Resilience Act werde sicherstellen, dass der europäische Finanzsektor „resilient through a severe operational disruption“ bleibt, jede schwere operative Störung also übersteht (consilium.europa.eu consilium.europa.eu ↗). Seit dem 17. Januar 2025 gilt DORA. Ein Anbieter-Vertreter wurde deutlicher: Richard Lindsay von Orange Cyberdefense sagte der Fachpresse, die Verordnung werde „die digitale Widerstandsfähigkeit im gesamten Ökosystem der EU erheblich verbessern“ (crn.de¹). Gesamtes Ökosystem, jede schwere Störung: Nach diesem Anspruch sollte eine Rechnung, die zwischen einem Finanzunternehmen und seinem Steuerberater hin- und hergeht, zu den am besten abgesicherten Dokumenten Europas zählen.

Ein typischer Vendor-Email-Compromise-Ablauf zeigt, warum das nicht zutrifft. Das Postfach des Steuerberaters ist echt, niemand hat es gehackt im Sinne eines sichtbaren Einbruchs, sondern schlicht übernommen. Die Rechnung, die daraus kommt, ist echt, mit echtem Briefkopf und echten alten Beträgen. Die elektronische Signatur darunter ist gültig, ausgestellt von einer bekannten Plattform. Kein System fällt aus, kein Incident wird gemeldet, kein Alarm schlägt an. Nur die IBAN im Dokument ist eine andere als in der letzten Rechnung, und das Geld verlässt das Konto in Richtung eines Angreifers. Sicherheitsanbieter fassen dieses Muster unter dem Begriff Vendor Email Compromise. Mimecast beschreibt ihn so: „built around real business relationships“. Der Angriff nutzt eine bereits bestehende, echte Geschäftsbeziehung, keine erfundene (mimecast.com²). Er braucht keine Schwachstelle in einem System, nur eine Lücke im Vertrauen zwischen zwei Firmen, die einander schon kennen. Das FBI Internet Crime Complaint Center bezifferte die weltweit gemeldeten Verluste aus dieser Betrugsfamilie zwischen Oktober 2013 und Dezember 2023 auf 55,5 Milliarden US-Dollar, verteilt auf 305.033 Fälle (ic3.gov³).

Panorays, ein auf Drittparteirisiko spezialisierter Sicherheitsanbieter, bewirbt DORA so: Die Verordnung verlange „stringentes Third-Party-Risk-Management“ und verhindere dadurch „kaskadierende Ausfälle, die Märkte und Finanzstabilität stören könnten“ (panorays.com⁴). Auch dieser Satz kreist um dasselbe Wort: Ausfall. Im geschilderten Fall fällt nichts aus. Die Systeme laufen, die Signatur hält jeder Prüfung stand, der Absender ist der richtige. DORAs gesamter Erfolgsmaßstab, Systeme bleiben oben und Vorfälle werden erkannt und gemeldet, ist in diesem Betrug vollständig erfüllt, während das Geld trotzdem beim Angreifer landet.

Wer die Verordnung selbst liest, findet den Grund für diese Lücke im ersten Satz. Erwägungsgrund 1 der Verordnung (EU) 2022/2554 nennt als Anlass, dass zunehmende Digitalisierung und Vernetzung die Gesellschaft „anfälliger für Cyberbedrohungen oder IKT-Störungen“ mache (eur-lex.europa.eu⁵). Artikel 1 zählt den Regelungsgegenstand auf: IKT-Risikomanagement, Meldung von Vorfällen, Resilienz-Testing, Überwachung des IKT-Drittparteirisikos. Rechnungsauthentizität, Zahlungsbetrug oder die Echtheit einer Bankverbindung stehen in keiner der vier Kategorien.

Wie eng der Anwendungsbereich zusätzlich gefasst ist, zeigt Artikel 2. Die Vorschrift listet 21 Kategorien Unternehmen auf; 20 davon fasst Artikel 2 Absatz 2 ausdrücklich zum Sammelbegriff „Finanzunternehmen“ zusammen, von Kreditinstituten über Zahlungsdienstleister bis zu Krypto-Anbietern. Die 21. Kategorie, der IKT-Drittdienstleister selbst, ist von diesem Sammelbegriff per Definition ausgenommen. Ein Steuerberater steht in keiner der Kategorien. Auch als IKT-Drittdienstleister nach Artikel 28 bis 30 fällt er nur dann in den Anwendungsbereich, wenn er eine „IKT-Dienstleistung“ im Sinn von Artikel 3 Nummer 21 erbringt, also digitale und Datendienste über IKT-Systeme auf fortlaufender Basis. Klassische Steuerberatung, Buchführung, Rechnungsstellung, Beratung zur Steuerlast, ist das nicht. Selbst Wirtschaftsprüfer, die dem Berufsbild näher stehen als jede andere Gruppe, wurden im Trilog eigens aus dem Anwendungsbereich herausverhandelt; der Deutsche Steuerberaterverband begrüßte das ausdrücklich (datev-magazin.de⁶). Wenn schon die nähere Berufsgruppe draußen bleibt, bleibt der gewöhnliche Steuerberater erst recht draußen.

Nun die Autofiktion, so großzügig konstruiert, wie es die Verordnung überhaupt zulässt: Ein Finanzunternehmen beauftragt den Steuerberater, und die Leistung hat einen digitalen Anteil, etwa ein Mandanten-Cloud-Portal. Dann müsste die Kanzlei laut Artikel 28 Absatz 3 ins interne „Register of Information“ des Finanzunternehmens aufgenommen werden, ein Verwaltungsakt beim Auftraggeber, nicht bei der Kanzlei selbst. Erst bei einer „kritischen oder wichtigen Funktion“ nach Artikel 3 Nummer 22, deren Ausfall die Geschäftskontinuität wesentlich beeinträchtigen würde, griffen die schärferen Pflichten aus Artikel 30 Absatz 3: Auditrechte, Exit-Strategie, Business-Continuity-Klauseln. Für gewöhnliche Steuerberatungsleistungen ist das praktisch nie einschlägig. Direkte Aufsicht über den Anbieter selbst gibt es nach Artikel 31 erst ab der Einstufung als „kritischer IKT-Drittdienstleister“, und diese Schwelle verlangt systemische Wirkung bei Ausfall und Marktkonzentration. Am 18. November 2025, zehn Monate nach Geltungsbeginn, benannten die europäischen Aufsichtsbehörden die ersten 19 Anbieter dieser Kategorie, ausnahmslos globale Cloud-, Telekom- und IT-Konzerne: AWS, Microsoft, Google Cloud, SAP, Accenture, IBM, Deutsche Telekom, Oracle, Orange, Capgemini, Bloomberg, Tata Consultancy Services, Kyndryl, NTT Data, Equinix, Colt Technology, FIS, InterXion und LSEG Data and Risk (eba.europa.eu⁷, eiopa.europa.eu⁸). Eine lokale Kanzlei erreicht diese Schwelle nicht.

19 Konzerne stehen damit unter der schärfsten Form der DORA-Aufsicht. Kein einziger Steuerberater darunter, und das gilt selbst dann, wenn er als registrierte IKT-Drittpartei eines Finanzunternehmens auftritt. Denn selbst in dieser konstruierten Rolle verlangt Artikel 30 Absatz 2 Vertragsklauseln zu Leistungsbeschreibung, Unterauftragsvergabe, Serviceorten, Datenrückgabe, Service Levels und Kooperationspflichten bei Vorfällen. Auch die technischen Regulierungsstandards zum IKT-Risikomanagement, die Delegierte Verordnung (EU) 2024/1774, regeln Netzwerksicherheit, Verschlüsselung und Zugriffsmanagement der IKT-Dienstleistung selbst (eur-lex.europa.eu⁹). Kein Satz darin verlangt eine Verifikation von Zahlungsdaten, einen Rückruf bei geänderter Bankverbindung oder eine E-Mail-Authentifizierung wie DMARC.

Zwischen diesem schmalen Anwendungsbereich und der Umsetzung liegt eine zweite Lücke, die das große Versprechen weiter schrumpfen lässt. Die technischen Durchführungsstandards zum Informationsregister kamen selbst verspätet; die Einreichfrist wurde von April auf den 30. April 2025 verschoben, weil die Standards nicht rechtzeitig fertig waren (it-finanzmagazin.de¹⁰). Eine Gnadenfrist für die betroffenen Institute gab es trotzdem nicht, der Stichtag 17. Januar 2025 blieb hart. Eine Analyse von KPMG hielt fest, dass zu diesem Zeitpunkt keine der befragten Banken die Vorgaben vollständig erfüllt hatte und viele Häuser die Melde- und Dokumentationspflichten kurzfristig über Excel-Tabellen lösten (klardenker.kpmg.de klardenker.kpmg.de ↗). Ein Praktiker-Roundtable des IT-Finanzmagazins beschreibt zusätzlich eine Nebenwirkung, die dem Versprechen widerspricht: kleine IT-Dienstleister könnten den nun geforderten Vertragsaufwand „nicht mehr kostendeckend erbringen und stellen Services ein“, während Hyperscaler wie AWS trotz DORA kaum kooperativer würden, „man bekommt von AWS lediglich standardisierte Protokolle, man kann sich in einem Portal etwas abrufen, man kann Fragen an eine Mailbox schicken. Das wars“ (it-finanzmagazin.de it-finanzmagazin.de ↗). Wenn kleine Anbieter aus dem Markt gedrängt werden, während die großen sich kaum bewegen, wirkt das dem Konzentrationsrisiko entgegen, das DORA laut Vertragswerk gerade eindämmen soll. Zum Sanktionsrahmen selbst gilt: Ein öffentlich dokumentiertes größeres DORA-Bußgeld ist bis Sommer 2026 nach Fachpublikationen nicht bekannt. Ob und wann sich das ändert, ist offen; die ersten Aufsichtsprüfungen der Register liefen erst 2025 und 2026 an.

Wie die Verordnung selbst mit Sprache umgeht, zeigt eine Rede des BaFin-Exekutivdirektors Nikolas Speer im Dezember 2025 zum ersten Jahr DORA (bafin.de bafin.de ↗): über 600 gemeldete schwerwiegende IKT-Vorfälle seit Januar 2025, dazu die Warnung, man frage sich „nicht, ob es zu größeren Schäden kommt, sondern eher wann“. An anderer Stelle derselben Rede, im Abschnitt über Vernetzung und Informationsaustausch, dient eine Störung der Sicherheitssysteme von PayPal als Beispiel: Sie habe deutschen Banken „milliardenschwere betrügerische und unautorisierte Lastschriften“ beschert. Zwischen beiden Passagen verschwimmt eine Trennung, die die Verordnung sonst zieht: Der PayPal-Fall ist selbst ein Systemausfall und damit DORAs Regelungsgegenstand, doch die Rede nutzt ihn als Beleg für eine allgemeine Schadenswarnung, die im selben Atemzug auch Betrug einschließt, der wie im Fall des Steuerberaters ganz ohne Systemausfall läuft. Selbst die eigene Aufsichtsbehörde hält die beiden Fälle in dieser Rede nicht auseinander.

An dieser Stelle kommt regelmäßig der Einwand, ein Unternehmen pflege seine Lieferanten ohnehin über ein Lieferantenmanagement-Portal oder ein zentrales Onboarding, DORA verstärke das nur. Der Einwand verwechselt zwei verschiedene Prüfungen. Ein Portal verifiziert einmalig, beim Onboarding, dass hinter einem Lieferanten ein reales Unternehmen mit gültigem Vertrag steht. Genau das ist die Angriffsfläche, die Vendor Email Compromise per Definition nutzt: eine bereits geprüfte, echte Beziehung, keine neu erfundene (mimecast.com mimecast.com ↗). Die gefälschte Rechnung besteht die Onboarding-Prüfung deshalb mühelos, weil Kanzlei und Vertrag echt sind, nur die einzelne Nachricht nicht. Ob die konkrete E-Mail von heute wirklich aus diesem Postfach stammt, prüft kein Portal und keine Vertragsklausel, sondern zwei ganz andere Mechanismen: die DMARC-Konfiguration auf der Domain des Absenders und, beim Empfänger, eine eigene Verifikationsroutine für jede Zahlungsänderung. Der kleine Steuerberater selbst kann außerdem nichts an seiner DORA-Einordnung ändern: Er wird nicht zum IKT-Drittanbieter, weil das Finanzunternehmen ein besseres Portal einführt, und selbst als registrierte Drittpartei träfen ihn, wie oben gezeigt, Klauseln zu Systemverfügbarkeit, nicht zu Rechnungsprüfung. Die eigene Vollerhebung von 33.041 eigenständigen Steuerberater-Kanzlei-Domains aus dem amtlichen Verzeichnis zeigt, wie wenig an dieser Stelle mechanisch abgesichert ist: 73,5 Prozent ohne wirksamen Absenderschutz, 51,4 Prozent ganz ohne den dafür zuständigen DNS-Eintrag namens DMARC. Kein Portal, keine Vertragsklausel aus Artikel 30 rührt an dieser Zahl.

Bleiben die naiven Fragen, gestellt in der Reihenfolge, in der der Fall sie aufwirft. Hätte DORA die getauschte IBAN erkannt? Nein, die Verordnung verlangt kein Verfahren, das eine Bankverbindung in einer Rechnung gegen die zuletzt bekannte prüft; das Zahlungsdokument selbst ist nicht ihr Regelungsgegenstand. Hätte DORA die gültige, aber missbräuchlich genutzte Signatur aufgedeckt? Ebenfalls nein: Die Vertragsklauseln aus Artikel 30 verlangen Angaben zu Verfügbarkeit, Authentizität und Integrität der IKT-Dienstleistung, gemeint ist damit die Dienstleistung selbst (Serverbetrieb, Datenzugriff), nicht die Echtheit eines einzelnen signierten Dokuments, das über eine reguläre, funktionierende Signaturplattform läuft. Hätte DORA das übernommene Postfach gemeldet? Hier bleibt ehrlich eine offene Frage: Eine unbefugte Kontoübernahme wäre nach der Definition in Artikel 3 Nummer 8 grundsätzlich ein „IKT-bezogener Vorfall“. Nur träfe diese Meldepflicht, wenn überhaupt, das Finanzunternehmen für Vorfälle in seinen eigenen Systemen, nicht die Kanzlei, deren Postfach übernommen wurde und die selbst nicht unter DORA fällt; ob ein reiner Zahlungsbetrug über ein fremdes, funktionierendes Postfach beim zahlenden Finanzunternehmen überhaupt als meldepflichtiger eigener IKT-Vorfall zählt, ist im Verordnungstext nicht eindeutig entschieden und wird hier bewusst offengelassen, statt es zu behaupten.

Was in diesem Fall geholfen hätte, kommt aus keiner Verordnung, sondern aus dem Ablauf selbst. Eine Bankverbindung wechselt nicht durch eine E-Mail, so vollständig signiert und so termingebunden sie auch klingt; bestätigt wird ausschließlich über eine Telefonnummer, die schon vor der Nachricht bekannt war, aus der eigenen Kartei, nicht aus der neuen Mail. Genau das rät auch das FBI Internet Crime Complaint Center: Änderungen an Kontodaten über einen zweiten, unabhängigen Kanal bestätigen, nie über die Nachricht, die die Änderung meldet (ic3.gov ic3.gov ↗). Im Zahllauf entscheidet über eine geänderte IBAN nie eine einzelne Person, sondern zwei, unabhängig voneinander, nach demselben Ablauf, jedes Mal. Und wer als Kanzlei oder Zulieferer verhindern will, für einen fremden Betrug missbraucht zu werden, trägt einen eigenen, wirksamen DMARC-Eintrag mit der Einstellung `p=reject` ein und macht ihn zur vertraglichen Bedingung gegenüber seinen eigenen Dienstleistern, unabhängig davon, ob DORA für ihn gilt.

Die Regel bleibt darum die gleiche, ob eine Verordnung zusieht oder nicht: Eine Zahlungsanweisung folgt nie allein einer Mail, sondern immer auch einem zweiten, unabhängigen Blick auf eine schon vorher bekannte Nummer.

Grundlage sind der Verordnungstext VO (EU) 2022/2554 samt Erwägungsgründen und die Delegierte Verordnung (EU) 2024/1774 (eur-lex.europa.eu), die Pressemitteilungen von consilium.europa.eu und eba.europa.eu/eiopa.europa.eu zur Benennung der ersten 19 kritischen IKT-Drittanbieter am 18. November 2025, die Rede des BaFin-Exekutivdirektors Nikolas Speer vom 4. Dezember 2025 (bafin.de) sowie Berichte von it-finanzmagazin.de (zur Fristverschiebung des Informationsregisters und zum Praktiker-Roundtable) und klardenker.kpmg.de zur Umsetzungspraxis. Branchenzitate stammen von crn.de und panorays.com, die Einordnung des Anwendungsbereichs zusätzlich von datev-magazin.de. Die Einordnung und die Verlustzahlen zu Vendor Email Compromise/Business Email Compromise stammen von mimecast.com und dem FBI Internet Crime Complaint Center (ic3.gov). Der DMARC-Befund beruht auf einer eigenen Vollerhebung aller 33.041 eigenständigen Steuerberater-Kanzlei-Domains aus dem amtlichen Verzeichnis, Juli 2026, ausgewertet wurden ausschließlich öffentlich abrufbare DNS-Antworten. Der Sanktionsstand (kein dokumentiertes größeres DORA-Bußgeld bis Sommer 2026) beruht auf Fachpublikationen und bleibt offen für Korrektur, sobald eine Aufsichtsbehörde ein Verfahren veröffentlicht. Eine Reichweiten-Analyse, kein Rechtsurteil.