Seit Januar 2025 fragt niemand mehr nach Ihrem Konzept
Die DORA-Verordnung gilt seit dem 17. Januar 2025. Keine Übergangsfrist, kein nationales Gesetz, das noch irgendwo im Verfahren hängt. Verordnung (EU) 2022/2554, Artikel 64: gilt unmittelbar in jedem Mitgliedstaat.
Interessant ist, was seitdem passiert ist.
Die ersten Monate drehten sich um Papier. Rahmenwerke, Richtlinien, Verantwortlichkeitsmatrizen. Inzwischen fragen Aufseher nach Belegen: nach Meldeprotokollen mit Zeitstempel, nach Testberichten, nach dem Informationsregister als Datei.
Nicht nach der Beschreibung des Prozesses. Nach dem, was der Prozess produziert hat.
Genau da wird DORA von einem Compliance-Thema zu einem Architekturthema. Denn fast jede Pflicht in dieser Verordnung endet in einer Frage an Ihre Systeme: Können sie das liefern, schnell genug, nachweisbar?
Fallen Sie unter DORA? Die Antwort hängt an einem Wort
Artikel 2 adressiert Finanzunternehmen. Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, Versicherer, Kryptowerte-Dienstleister und ein gutes Dutzend weiterer Kategorien.
Wenn Sie Software bauen, stehen Sie nicht auf dieser Liste. Sie stehen woanders.
Artikel 3 Nummer 19 definiert den IKT-Drittdienstleister denkbar knapp: ein Unternehmen, das IKT-Dienstleistungen bereitstellt. Die eigentliche Schwelle steckt in Nummer 21. IKT-Dienstleistungen sind digitale Dienste und Datendienste, die über IKT-Systeme dauerhaft bereitgestellt werden.
Dauerhaft. An diesem Wort entscheidet sich alles.
Ein abgeschlossenes Projekt, übergeben und aus der Hand gegeben, ist keine dauerhafte Dienstleistung. Sobald Sie betreiben, hosten, überwachen oder laufend warten, sind Sie drin. Und die meisten Rahmenverträge im Finanzumfeld enthalten genau diesen Betriebsanteil.
Das ist keine juristische Feinheit. Es entscheidet, ob Ihr Firmenname im Informationsregister Ihres Kunden auftaucht und damit irgendwann auf dem Schreibtisch einer Aufsichtsbehörde.
Eine Entwarnung gibt es trotzdem. Artikel 28 Absatz 1 Buchstabe b verankert Verhältnismäßigkeit ausdrücklich: Art, Umfang, Komplexität und Bedeutung der IKT-Abhängigkeit zählen, ebenso die Kritikalität der gestützten Funktion. Ein Terminbuchungs-Widget auf der Website einer Sparkasse wird nicht behandelt wie das Kernbankensystem.
Auch auf der Kundenseite ist die Skala nicht flach. Artikel 16 sieht für kleine und nicht verflochtene Wertpapierfirmen, ausgenommene Zahlungs- und E-Geld-Institute sowie kleine Einrichtungen der betrieblichen Altersversorgung einen vereinfachten IKT-Risikomanagementrahmen vor. Die Artikel 5 bis 15 gelten für sie nicht.
Fragen Sie im Erstgespräch also nicht nur, ob Ihr Gegenüber unter DORA fällt. Fragen Sie, unter welchen Teil.
Und rechnen Sie damit, dass der Kreis größer wird. In Deutschland erklärt § 1a Absatz 2a KWG die DORA-Vorgaben auch für Institute anwendbar, die nach Artikel 2 gar nicht in den Geltungsbereich fallen: Sie werden behandelt, als wären sie CRR-Kreditinstitute. Statt der Artikel 5 bis 15 gilt für sie der vereinfachte Rahmen nach Artikel 16, bedrohungsgeleitete Penetrationstests entfallen, und für Kleinstunternehmen greifen die Artikel 28 bis 30 nicht.
Nach § 65a Absatz 3 KWG gilt das ab dem 1. Januar 2027. Für Sie als Dienstleister heißt das: ab 2027 kommen Verträge mit DORA-Klauseln auch von Häusern, die heute noch nicht danach fragen.
Vier Stunden. Nicht vier Arbeitstage.
Artikel 19 verpflichtet Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle der zuständigen Behörde zu melden. Die konkreten Fristen stehen nicht in DORA selbst, sondern in Artikel 5 der Delegierten Verordnung (EU) 2025/301:
Erstmeldung. So früh wie möglich, in jedem Fall innerhalb von vier Stunden nach Einstufung des Vorfalls als schwerwiegend, und spätestens 24 Stunden nach dem Zeitpunkt der Kenntnisnahme.
Zwischenmeldung. Spätestens 72 Stunden nach Übermittlung der Erstmeldung. Auch dann, wenn sich Status und Handhabung nicht geändert haben.
Abschlussmeldung. Spätestens einen Monat nach der Zwischenmeldung oder nach deren letzter Aktualisierung.
Lesen Sie die erste Frist noch einmal. Die vier Stunden laufen ab der Einstufung, nicht ab dem Ausfall. Das klingt nach Entlastung und ist das Gegenteil.
Denn die Einstufung ist selbst eine technische Frage. Wie viele Kunden waren betroffen? Über welchen Zeitraum? Waren personenbezogene Daten im Spiel? Ist eine kritische oder wichtige Funktion ausgefallen, also eine, deren Störung die Geschäftsfortführung oder die Zulassungsbedingungen des Instituts berührt?
Wenn Ihre Systeme diese Fragen nicht in Minuten beantworten, verbrennen Sie die 24-Stunden-Obergrenze mit Nachforschung und die vier Stunden mit Formulieren.
Was daraus für die Architektur folgt: Sie brauchen Telemetrie, die betroffene Mandanten und Transaktionen auszählt statt nur Fehlerraten zu zeigen. Sie brauchen eine Zuordnung von technischen Komponenten zu Geschäftsfunktionen, gepflegt und nicht in jemandes Kopf. Und Sie brauchen einen Bereitschaftsdienst, der die Einstufung auslösen darf, ohne auf ein Gremium zu warten.
Ein Detail, das gern untergeht: Fällt eine Frist auf ein Wochenende oder einen Feiertag, darf die Meldung bis 12 Uhr des folgenden Arbeitstags erfolgen. Bei Erst- und Zwischenmeldung gilt diese Erleichterung aber nicht für Kreditinstitute, zentrale Gegenparteien, Betreiber von Handelsplätzen und alle Finanzunternehmen, die nach Artikel 3 der NIS2-Richtlinie als wesentliche oder wichtige Einrichtungen gelten.
Wer wirklich systemrelevant ist, meldet am Sonntagmorgen.
Resilienz testen heißt nicht: einmal im Jahr ein Pentest
Artikel 24 verlangt ein Programm für das Testen der digitalen operationalen Resilienz, als fester Bestandteil des IKT-Risikomanagementrahmens. Artikel 25 zählt auf, was hineingehört: Schwachstellenbewertungen und Scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Lückenanalysen, Quellcodeprüfungen soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests, Penetrationstests.
Das ist keine Compliance-Liste. Das ist eine Testpyramide mit anderem Vokabular.
Artikel 26 legt nach: bedrohungsorientierte Penetrationstests, im Regelwerk TLPT genannt, mindestens alle drei Jahre. Das trifft aber nicht jeden.
Die zuständigen Behörden bestimmen nach Absatz 8, welche Institute TLPT durchführen müssen, und stützen sich dabei auf die Wirkung auf den Finanzsektor, auf Finanzstabilitätsbedenken und auf das IKT-Risikoprofil des Hauses. Kleinstunternehmen und die kleinen Institute nach Artikel 16 Absatz 1 sind ohnehin ausgenommen.
Fragen Sie Ihren Kunden also, ob er bestimmt wurde. Die Antwort verändert Ihren Aufwand erheblich.
Wurde er bestimmt, wird es konkret: Der Test läuft an Live-Produktionssystemen, die kritische oder wichtige Funktionen tragen.
An Live-Produktionssystemen.
Das ist der Halbsatz, den Ihr Betriebsteam lesen sollte, bevor jemand den Vertrag unterschreibt. Ein TLPT gegen eine Staging-Umgebung erfüllt die Anforderung nicht. Und interne Tester reichen nicht dauerhaft: Jeder dritte Test verlangt einen externen Tester, bedeutende Kreditinstitute dürfen ausschließlich externe einsetzen.
Und wenn Ihre Dienstleistung zum Testumfang gehört, sind Sie nicht Zuschauer. Artikel 30 Absatz 3 Buchstabe d verpflichtet Sie vertraglich, sich an diesen Tests zu beteiligen und uneingeschränkt mitzuwirken.
Das Informationsregister macht Ihre Lieferkette sichtbar
Nach Artikel 28 Absatz 3 führt jedes Finanzunternehmen ein Informationsregister über sämtliche Verträge zur Nutzung von IKT-Dienstleistungen. Sauber getrennt danach, ob eine kritische oder wichtige Funktion dahinterhängt oder nicht.
Mindestens einmal jährlich geht ein Bericht an die zuständige Behörde. Auf Verlangen das vollständige Register. Und geplante Verträge für kritische oder wichtige Funktionen sind vorab anzuzeigen, ebenso der Fall, dass eine Funktion nachträglich kritisch geworden ist.
Aus diesen Registern entsteht die europäische Landkarte der Abhängigkeiten. Am 18. November 2025 haben die Europäischen Aufsichtsbehörden auf dieser Grundlage erstmals die Liste der nach Artikel 31 eingestuften kritischen IKT-Drittdienstleister veröffentlicht. 19 Unternehmen, die nach Beschreibung der Behörden Dienste “von Kerninfrastruktur bis zu Geschäfts- und Datendiensten” liefern: Cloud-Plattformen, Rechenzentren, Netzbetreiber, große IT-Dienstleister, Datenanbieter.
Artikel 31 Absatz 9 verlangt eine jährliche Aktualisierung. Die Liste ist kein Endstand.
Für diese Anbieter greift dann direkte europäische Überwachung. Artikel 35 Absatz 8 erlaubt der federführenden Überwachungsbehörde Zwangsgelder von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes des Vorjahres, wenn ein eingestufter Anbieter Auskunfts-, Untersuchungs- oder Berichtsanordnungen nicht nachkommt. Verhängt wird täglich, höchstens sechs Monate lang, bis das Unternehmen einlenkt.
Das ist kein allgemeines DORA-Bußgeld, sondern ein Beugemittel gegen genau diese 19 Unternehmen.
Werden Sie auf dieser Liste landen? Vermutlich nie.
Sie landen im Register. Und das genügt, um Fragen zu bekommen, die ein gewöhnlicher Softwarevertrag nicht beantwortet. Wie Sie solche Anfragen systematisch beantworten statt jedes Mal neu, haben wir im Beitrag zum Drittanbieter-Risiko beschrieben.
Die Klauseln, die Sie unterschreiben werden
Artikel 30 Absatz 2 gilt für jeden IKT-Vertrag. Absatz 3 kommt hinzu, sobald eine kritische oder wichtige Funktion betroffen ist. Das sind die Punkte, an denen Verhandlungen im Finanzumfeld tatsächlich hängen bleiben:
- Standorte benennen: Regionen und Länder, in denen die Leistung erbracht und in denen Daten verarbeitet und gespeichert werden, plus Vorabinformation bei jeder Änderung.
- Dienstgüte mit Zahlen. Absatz 3 Buchstabe a verlangt präzise quantitative und qualitative Leistungsziele. “Bestmögliche Verfügbarkeit” reicht nicht.
- Zugangs-, Inspektions- und Auditrechte, uneingeschränkt, für das Finanzunternehmen, für einen beauftragten Dritten und für die zuständige Behörde. Vor Ort eingeschlossen.
- Mitwirkung am TLPT.
- Meldung aller Entwicklungen, die Ihre Fähigkeit zur vereinbarten Leistungserbringung wesentlich beeinträchtigen könnten.
- Eine Ausstiegsstrategie mit verbindlichem Übergangszeitraum, in dem Sie weiterliefern, während Ihr Kunde migriert oder auf eine interne Lösung wechselt.
- Unterstützung bei IKT-Vorfällen, ohne Zusatzkosten oder zu vorab festgelegten Kosten.
Punkt 6 tut am meisten weh. Eine Exit-Klausel zwingt Sie, Ihre eigene Ablösbarkeit zu planen: Datenformate, Exportwege, Dokumentation, die jemand anders lesen kann, ohne Sie anzurufen.
Der Klassiker: Ein Team verhandelt monatelang über Haftungsgrenzen und übersieht, dass die Exit-Klausel einen Zustand verlangt, den das Produkt technisch gar nicht hergibt.
Ihre Unterauftragnehmer werden zum Vertragsgegenstand
Die Delegierte Verordnung (EU) 2025/532 vom 24. März 2025, veröffentlicht im Amtsblatt am 2. Juli 2025, präzisiert die Untervergabe von IKT-Dienstleistungen, die kritische oder wichtige Funktionen stützen.
Artikel 4 verlangt, dass der Vertrag festlegt, welche Leistungen überhaupt untervergeben werden dürfen und unter welchen Bedingungen. Sie bleiben für die Leistung Ihrer Unterauftragnehmer verantwortlich und müssen sie überwachen.
Artikel 5 ist der, der Ihren Betriebsalltag verändert. Sie müssen Ihren Kunden rechtzeitig über beabsichtigte wesentliche Änderungen Ihrer Unterauftragsvereinbarungen informieren, mit einer angemessenen Mitteilungsfrist, in der er zustimmen oder ablehnen kann.
Übersetzt: Der Wechsel des Monitoring- oder Log-Anbieters ist kein Infrastruktur-Ticket mehr. Er ist ein Vorgang mit Vorlauf und Vetorecht.
Praktische Konsequenz, unbequem und simpel: Die Liste Ihrer eigenen Subdienstleister muss gepflegt sein, bevor der Kunde danach fragt. Wer sie erst beim Onboarding zusammensucht, verliert Wochen.
DORA verdrängt NIS2. Für Ihren Kunden. Nicht für Sie.
Artikel 1 Absatz 2 erklärt DORA für Finanzunternehmen, die nach nationalem Recht als wesentliche oder wichtige Einrichtungen gelten, zum sektorspezifischen Rechtsakt im Sinne von Artikel 4 der NIS2-Richtlinie. Erwägungsgrund 16 formuliert es direkt: DORA ist Lex specialis zu NIS2.
Für Ihren Kunden ist das eine Erleichterung. Eine Bank meldet an die Finanzaufsicht, nicht zusätzlich nach dem NIS2-Regime.
Für Sie ändert das nichts.
Die Verdrängung greift für das Finanzunternehmen, nicht für seine Zulieferer. Artikel 4 Absatz 1 der NIS2-Richtlinie nimmt ausdrücklich nur “solche Einrichtungen” aus und stellt im zweiten Satz klar, dass NIS2 für alle nicht erfassten Einrichtungen weitergilt. DORA rechnet selbst damit: Artikel 35 Absatz 2 Buchstabe b verpflichtet die Überwachungsbehörde, sich mit den NIS2-Behörden abzustimmen, um Doppelungen bei kritischen IKT-Drittdienstleistern zu vermeiden.
Wenn Sie als IT-Dienstleister in den Anwendungsbereich des deutschen NIS2-Umsetzungsgesetzes fallen, bleibt das so, völlig unabhängig davon, dass Ihr Kunde unter DORA steht. Zwei Regelwerke treffen dasselbe Team.
Und sie ticken unterschiedlich schnell. Wer seine Meldekette auf die NIS2-Fristen von 24 und 72 Stunden ausgelegt hat, hat eine Architektur gebaut, die die Vier-Stunden-Uhr von DORA nicht einhält. Die Erstmeldung ist der Engpass, nicht der Abschlussbericht.
Das ist reparierbar, aber nicht nebenbei. Die technischen Bausteine, die beide Regime tragen (Ereignisklassifizierung, Betroffenheitsanalyse, belastbare Zeitstempel), beschreiben wir im technischen NIS2-Leitfaden. Unter DORA ist es dieselbe Maschine mit einer schärferen Uhr.
Und wenn Sie es nicht tun?
DORA überlässt die Sanktionierung von Finanzunternehmen dem nationalen Recht. Artikel 50 verlangt von den Mitgliedstaaten wirksame, verhältnismäßige und abschreckende verwaltungsrechtliche Sanktionen, ohne selbst einen Bußgeldrahmen in Euro vorzugeben. In Deutschland benennt § 6 Absatz 1g KWG die Aufsichtsbehörden nach § 1 Absatz 5 KWG als zuständige Behörden im Sinne von Artikel 46.
Das ist die BaFin, bei den direkt beaufsichtigten bedeutenden Kreditinstituten die EZB. Die operativen Aufgaben rund um TLPT nimmt die Deutsche Bundesbank wahr.
Nur trifft Sie als Dienstleister ohnehin nicht die Aufsicht, sondern der Vertrag.
Artikel 28 Absatz 1 Buchstabe a stellt klar, dass das Finanzunternehmen jederzeit in vollem Umfang für die Einhaltung verantwortlich bleibt. Es kann diese Verantwortung nicht auslagern. Also reicht es sie weiter, in Klauseln, Prüfrechten und Kündigungsgründen.
Womit Sie anfangen
Wer in den nächsten zwölf Monaten mit einem Finanzunternehmen ins Geschäft kommen will, sollte vier Dinge vorzeigen können.
Erstens eine Zuordnung Ihrer Systeme zu den Geschäftsfunktionen Ihrer Kunden, damit “kritisch oder wichtig” nicht bei jedem Vorfall neu ausdiskutiert wird. Zweitens eine Vorfallkette, die in Minuten eine belastbare Ersteinschätzung liefert statt in einem halben Tag.
Drittens eine aktuelle Subdienstleisterliste samt Standorten und verarbeiteten Datenarten. Viertens einen Exit-Plan, der ohne Sie funktioniert.
Nichts davon ist exotisch. Es ist solides Betriebshandwerk, das DORA nur endlich einfordert.
Sie liefern Software an ein Finanzunternehmen und sollen plötzlich DORA-Klauseln unterschreiben? Sprechen wir darüber, bevor Sie unterschreiben.
