DORA für Zahlungsinstitute und E-Geld-Institute 2026
Was der Digital Operational Resilience Act 2026 von Zahlungs- und E-Geld-Instituten verlangt: Anwendungsbereich und vereinfachte Regeln für kleine Institute, IKT-Risiken, Meldung von Vorfällen, Tests, Informationsregister, IKT-Verträge und was Sie Ihren Core-Banking-Anbieter fragen sollten.
DORA in einem Absatz
Der Digital Operational Resilience Act, Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025. Als Verordnung gilt er in jedem Mitgliedstaat unmittelbar, ohne Umsetzung in nationales Recht. Für ein Zahlungs- oder E-Geld-Institut umfasst er fünf Bereiche: IKT-Risikomanagement, Meldung IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, Management des IKT-Drittparteienrisikos und den Austausch von Informationen über Cyberbedrohungen.
Die Detailregeln stehen in technischen Standards, die die Kommission auf Vorschlag der drei Europäischen Aufsichtsbehörden (EBA, ESMA und EIOPA) erlassen hat. Ein Zahlungsinstitut oder EMI hat am häufigsten mit diesen zu tun: dem RTS zum IKT-Risikomanagementrahmen (Delegierte Verordnung (EU) 2024/1774), dem RTS zur Leitlinie für vertragliche Vereinbarungen über IKT-Dienstleistungen (2024/1773), dem ITS zum Informationsregister (Durchführungsverordnung (EU) 2024/2956) und dem RTS zur Meldung von Vorfällen (Delegierte Verordnung (EU) 2025/301).
DORA ist EU-Recht. Ein von der FCA zugelassenes britisches Unternehmen fällt nicht darunter und folgt stattdessen den eigenen Regeln der FCA zur operationellen Resilienz. Eine britische Gruppe mit einer Tochtergesellschaft in der EU muss DORA in dieser Tochter allerdings anwenden.
Sie bauen ein Geschäft auf dieser Lizenz auf?
Sehen Sie, was die Plattform dafür abdeckt: die IT-Fragen der Aufsicht, Zahlungswege, Anbieter und den technischen Teil Ihres Antrags.
- Core Banking für litauische EMIs
- Digital Banking für luxemburgische E-Geld-Institute
- Digital Banking für portugiesische E-Geld-Institute
Wer betroffen ist und wer erleichterte Regeln bekommt
Artikel 2 Absatz 1 nennt Zahlungsinstitute und E-Geld-Institute einschließlich der ausgenommenen Institute nach PSD2 und E-Geld-Richtlinie. Kontoinformationsdienstleister werden gesondert aufgeführt. Wer klein ist, fällt also nicht aus DORA heraus. Die Größe bestimmt nur, wie viel davon gilt.
| Art des Instituts | IKT-Risikomanagementrahmen | Tests | Drittparteienrisiko |
|---|---|---|---|
| Zugelassenes Zahlungsinstitut oder EMI | Vollständiger Rahmen nach den Artikeln 5 bis 15. | Ein Testprogramm mit jährlichen Tests der Systeme, die kritische oder wichtige Funktionen unterstützen. | Strategie für das IKT-Drittparteienrisiko, Informationsregister, Verträge nach Artikel 30, Ausstiegspläne. |
| Ausgenommenes (kleines) Zahlungsinstitut nach Art. 32 PSD2 oder kleines EMI nach Art. 9 E-Geld-Richtlinie | Vereinfachter IKT-Risikomanagementrahmen nach Artikel 16, näher ausgeführt in Titel III des RTS 2024/1774. | Regelmäßige Tests der Notfallpläne und Kontrollen nach Artikel 16. | Keine formelle Strategie für das Drittparteienrisiko, Informationsregister und Vertragsregeln gelten aber weiterhin. |
| Kleinstunternehmen (weniger als 10 Beschäftigte und Jahresumsatz oder Bilanzsumme bis EUR 2 Millionen) | Vollständiger Rahmen, verhältnismäßig angewendet, mit mehreren spezifischen Erleichterungen. | Risikobasierter Testplan, keine Pflicht zu unabhängigen Testern. | Dieselben Kernpflichten. Prüfrechte können an einen vom Anbieter bestellten Dritten delegiert werden. |
Ein Punkt wird oft falsch verstanden. Der vereinfachte Rahmen nach Artikel 16 gilt für ausgenommene Institute, also die kleinen Zahlungsinstitute und kleinen EMIs, die über die nationalen Ausnahmen registriert sind. Ein voll zugelassenes EMI mit fünf Beschäftigten ist ein Kleinstunternehmen, kein Artikel-16-Unternehmen, und behält den vollständigen Rahmen mit Verhältnismäßigkeit.
IKT-Risikomanagement: was der Rahmen enthalten muss
Das Leitungsorgan trägt die Verantwortung für IKT-Risiken und genehmigt den Rahmen. In der Praxis sucht die Aufsicht nach diesen Dokumenten und nach Belegen, dass sie tatsächlich genutzt werden:
- IKT-Risikomanagementrahmen und Strategie für die digitale operationale Resilienz, mindestens jährlich und nach schwerwiegenden Vorfällen überprüft.
- Inventar der Vermögenswerte. Systeme, Daten, Netzwerkressourcen und die Geschäftsfunktionen, die sie unterstützen, wobei kritische oder wichtige Funktionen gekennzeichnet sind.
- Sicherheitsrichtlinien. Zugriffskontrolle, Verschlüsselung und Schlüsselverwaltung, Änderungsmanagement, Patching, Protokollierung, Netzwerksicherheit.
- Erkennung und Reaktion. Wie Auffälligkeiten erkannt werden, wer alarmiert wird, wie ein Vorfall klassifiziert wird.
- Business-Continuity- und IKT-Wiederherstellungspläne mit Backups, Wiederherstellung und Wiederherstellungszielen, nach Zeitplan getestet.
- Schulungen. Sicherheitsbewusstsein für Mitarbeitende und Schulungen zur digitalen Resilienz für die Geschäftsleitung.
Wenn Sie auf der Plattform eines Anbieters arbeiten, stammt ein großer Teil der Nachweise zu Inventar, Sicherheitskontrollen und Wiederherstellung von diesem Anbieter. Die Verantwortung wandert aber nicht mit: Nach Artikel 28 Absatz 1 bleibt das Finanzunternehmen jederzeit voll für die Einhaltung verantwortlich.
Meldung schwerwiegender Vorfälle: die Fristen
Ein IKT-bezogener Vorfall wird meldepflichtig, wenn er die Kriterien für einen schwerwiegenden Vorfall aus dem RTS zur Klassifizierung erfüllt: betroffene Kunden, Dauer, Datenverluste, betroffene kritische Dienste, wirtschaftliche Auswirkungen und geografische Ausbreitung. Für Zahlungsunternehmen hat dies das Meldeverfahren für schwerwiegende Vorfälle nach PSD2 abgelöst: Die EBA hat ihre PSD2-Leitlinien zur Meldung von Vorfällen zum 17. Januar 2025 aufgehoben.
| Meldung | Frist nach Delegierter Verordnung (EU) 2025/301 |
|---|---|
| Erstmeldung | Innerhalb von 4 Stunden nach Einstufung des Vorfalls als schwerwiegend und spätestens 24 Stunden, nachdem Sie davon Kenntnis erlangt haben. |
| Zwischenbericht | Innerhalb von 72 Stunden nach der Erstmeldung, auch wenn sich nichts geändert hat, und erneut bei jeder wesentlichen Änderung des Status. |
| Abschlussbericht | Spätestens einen Monat nach dem letzten Zwischenbericht, sobald die Ursachenanalyse abgeschlossen ist. |
Artikel 19 enthält zwei weitere Pflichten. Wirkt sich ein schwerwiegender Vorfall auf die finanziellen Interessen der Kunden aus, müssen Sie diese unverzüglich informieren und mitteilen, was Sie dagegen unternehmen. Außerdem dürfen Sie die Meldung an einen Dienstleister auslagern, bleiben aber voll dafür verantwortlich. Für ein Institut auf der Plattform eines Anbieters heißt das: Ihr Vertrag muss den Anbieter verpflichten, Sie so schnell über Vorfälle zu informieren, dass Sie die Fristen von 4 und 24 Stunden einhalten können.
Resilienztests
Jedes Zahlungsinstitut und EMI, das kein Kleinstunternehmen ist, braucht ein Programm für das Testen der digitalen operationalen Resilienz (Artikel 24). Artikel 25 nennt die Werkzeuge: Schwachstellenscans, Bewertungen der Netzwerksicherheit, Überprüfungen des Quellcodes, wo möglich, szenariobasierte Tests, Leistungs- und End-to-End-Tests sowie Penetrationstests. Systeme, die kritische oder wichtige Funktionen unterstützen, müssen mindestens einmal jährlich getestet werden, und zwar von Testern, die unabhängig von den Entwicklern dieser Systeme sind.
Bedrohungsorientierte Penetrationstests (TLPT) nach Artikel 26 sind etwas anderes. Sie sind nur für Unternehmen Pflicht, die die zuständigen Behörden bestimmen, etwa alle drei Jahre, und Artikel-16-Unternehmen sowie Kleinstunternehmen sind ausgenommen. Die meisten Zahlungs- und E-Geld-Institute werden nicht ausgewählt. Wenn doch, muss der Test die Produktivsysteme im laufenden Betrieb abdecken, auch die Ihrer IKT-Dienstleister. Deshalb enthalten Verträge nach Artikel 30 eine Pflicht zur Mitwirkung.
Das Informationsregister
Nach Artikel 28 Absatz 3 muss jedes Finanzunternehmen, auch die kleinen, ein Informationsregister über alle vertraglichen Vereinbarungen zu IKT-Dienstleistungen führen und dabei diejenigen kennzeichnen, die kritische oder wichtige Funktionen unterstützen. Das Format legt die Durchführungsverordnung (EU) 2024/2956 fest: eine Reihe verknüpfter Tabellen zum Unternehmen, zu jedem Vertrag, zu jedem Anbieter und seinen Unterauftragnehmern, zu den unterstützten Funktionen und zur Bewertung jeder Dienstleistung.
Stichtag
Ab 2026 bildet das Register die Verträge ab, die am 31. Dezember des Vorjahres bestanden.
Ihre Frist
Legt Ihre nationale Aufsichtsbehörde fest, früher als die Frist der ESAs. Die luxemburgische CSSF etwa hat die Register für 2026 zwischen dem 11. Februar und dem 31. März eingesammelt.
Frist der ESAs
Die nationalen Behörden leiten die Register jedes Jahr bis zum 31. März an die ESAs weiter.
Das Register ist nicht nur eine jährliche Abgabe. Ihre Aufsichtsbehörde kann es jederzeit anfordern, und Sie müssen sie rechtzeitig über jeden geplanten Vertrag über IKT-Dienstleistungen informieren, die eine kritische oder wichtige Funktion unterstützen. Die ESAs haben anhand der Register außerdem die Anbieter ausgewählt, die sie heute direkt beaufsichtigen. Quellen: ESAs zum Zeitplan für das Register, Einreichungsfenster der CSSF 2026.
Verträge mit IKT-Dienstleistern und Ausstiegsstrategien
Artikel 30 Absatz 2 legt das Minimum für jeden IKT-Vertrag fest: eine vollständige Beschreibung der Leistungen und ob Unterauftragsvergabe zulässig ist, die Orte, an denen Leistungen erbracht und Daten gespeichert werden, Datenschutz, Zugang zu den Daten und ihre Rückgabe bei Insolvenz oder Vertragsende, Dienstleistungsgüte, Unterstützung bei IKT-Vorfällen ohne Zusatzkosten oder zu einem vorab vereinbarten Preis, Zusammenarbeit mit Ihren Aufsichtsbehörden, Kündigungsrechte und die Teilnahme an Ihren Sicherheitsschulungen.
Für Leistungen, die kritische oder wichtige Funktionen unterstützen, kommen nach Artikel 30 Absatz 3 hinzu: genaue Service Levels mit quantitativen Zielen, Melde- und Berichtspflichten, die eigenen Notfallpläne und Sicherheitsmaßnahmen des Anbieters, die Teilnahme an TLPT, uneingeschränkte Zugangs-, Inspektions- und Prüfrechte für Sie und Ihre Aufsicht sowie eine Ausstiegsstrategie mit verpflichtender Übergangsfrist.
Die Ausstiegsstrategie selbst ist Ihr Dokument, nicht das des Anbieters. Nach Artikel 28 Absatz 8 müssen Sie einen Anbieter verlassen können, ohne den Geschäftsbetrieb zu stören, gegen Vorschriften zu verstoßen oder Kunden zu schaden. Sie brauchen einen dokumentierten und getesteten Ausstiegsplan und müssen wissen, wie Daten und Leistungen zu einem anderen Anbieter oder ins eigene Haus übergehen würden. Für eine Core-Banking-Plattform heißt das: vereinbarte Exportformate für Kundendatensätze, Salden und Transaktionshistorie sowie eine Übergangsfrist, die lang genug für eine Migration ist.
Kritische IKT-Drittdienstleister
Am 18. November 2025 haben die ESAs die erste Liste kritischer IKT-Drittdienstleister (CTPPs) nach Artikel 31 veröffentlicht. Laut Morgan Lewis umfasst sie 19 Anbieter, überwiegend große Cloud-, Rechenzentrums-, Netzwerk- und Unternehmenssoftware-Firmen. Jeder davon hat nun eine federführende Überwachungsbehörde unter den ESAs mit direkten Befugnissen zur Prüfung vor Ort.
Diese Überwachung ersetzt Ihre eigene Arbeit nicht. Läuft Ihre Plattform bei einem Hyperscaler, der als CTPP eingestuft ist, bewerten Sie trotzdem das Risiko, halten die Vertragsbedingungen ein und führen den Cloud-Anbieter in Ihrem Register als Unterauftragnehmer. Die meisten Core-Banking-Anbieter sind nicht eingestuft, und die Pflichten nach den Artikeln 28 bis 30 gelten für sie über Ihren Vertrag in vollem Umfang.
Was Sie Ihren Core-Banking-Anbieter fragen sollten
Eine Core-Banking-Plattform unterstützt fast jede kritische Funktion eines Zahlungsinstituts oder EMI: Konten, Zahlungen, Kundendaten. Holen Sie vor der Unterschrift oder vor Ihrem nächsten Registerzyklus klare Antworten auf diese Fragen ein.
| Frage | Warum es unter DORA wichtig ist |
|---|---|
| Wo wird die Plattform gehostet, wo werden die Daten gespeichert und wer sind die Unterauftragnehmer? | Orte und Unterauftragsvergabe müssen im Vertrag (Art. 30 Abs. 2) und in Ihrem Register stehen. |
| Wie schnell informieren Sie uns über einen Vorfall, und über welchen Kanal? | Sie haben 4 Stunden ab Einstufung und 24 Stunden ab Kenntnis, um die Erstmeldung abzugeben. |
| Welche Service Levels gelten, in Zahlen? | Artikel 30 Absatz 3 verlangt quantitative Ziele, die Sie überwachen können. |
| Können wir, unser Prüfer und unsere Aufsicht Sie prüfen? | Uneingeschränkte Zugangs-, Inspektions- und Prüfrechte sind bei kritischen Leistungen Pflicht. |
| Welche Wiederherstellungsziele testen Sie, und können wir die Ergebnisse sehen? | Ihre Notfallpläne hängen von den Backups und der Wiederherstellung des Anbieters ab. |
| In welchem Format erhalten wir unsere Daten zurück, und wie lang ist die Übergangsfrist? | Ausstiegsstrategien und Datenrückgabe verlangen die Artikel 28 Absatz 8 und 30. |
| Nehmen Sie an unseren Resilienztests teil? | Tests, und TLPT, falls Sie ausgewählt werden, umfassen auch ausgelagerte Systeme. |
Wie DORA mit Ihrem Lizenzantrag zusammenhängt
Zusammen mit DORA kam eine Änderungsrichtlinie, die Richtlinie (EU) 2022/2556. Sie hat Teile von Artikel 5 Absatz 1 PSD2 neu gefasst, der regelt, was ein Antrag enthalten muss. Der Abschnitt zur Unternehmensführung muss jetzt beschreiben, wie Sie IKT-Dienstleistungen im Sinne von DORA nutzen, das Verfahren für Vorfälle muss die Meldepflichten nach DORA abbilden, und die Sicherheitsmaßnahmen müssen ein hohes Maß an digitaler operationaler Resilienz nach dem IKT-Risikokapitel von DORA belegen. Die E-Geld-Richtlinie wendet diese Zulassungsregeln der PSD2 auch auf EMIs an. Ein Antragsteller wird am Tag seiner Zulassung zum Finanzunternehmen im Sinne von DORA, deshalb muss der Antrag einen Rahmen beschreiben, der vom ersten Tag an funktioniert.
- Erfassen Sie Ihre Funktionen. Legen Sie fest, welche Funktionen kritisch oder wichtig sind und welche IKT-Dienstleistungen sie unterstützen.
- Entwerfen Sie das Register früh. Ihre Kernplattform, die Cloud, Ihr KYC-Anbieter, Ihr Kartenprozessor und Ihr Bankpartner gehören alle hinein.
- Verhandeln Sie die Klauseln nach Artikel 30 vor der Unterschrift. Verträge nach der Zulassung zu ändern dauert länger und schwächt den Antrag.
- Schreiben Sie das Verfahren für Vorfälle auf Basis realer Zeiten. Nehmen Sie die Meldezusage des Anbieters auf.
- Bereiten Sie den Ausstiegsplan vor. Zeigen Sie der Aufsicht, wie Sie jeden kritischen Anbieter verlassen würden.
Crassula ist ein Technologieanbieter, kein reguliertes Unternehmen, und unterstützt bei den meisten Kunden kritische Funktionen. Für den Antrag liefern wir eine Beschreibung der Architektur der Plattform, des Hostings, der Sicherheitskontrollen (rollenbasierter Zugriff, Zwei-Faktor-Authentifizierung, Audit-Trail) und unseres Incident-Prozesses, die Sie in Ihre eigenen Abschnitte zu IKT und Auslagerung übernehmen. Backoffice und Reporting-Endpunkte der Plattform liefern Ihnen Datenexporte, aber die Klassifizierung von Vorfällen, die Meldungen und die Führung des Registers bleiben Ihre Aufgaben. Mehr zur Lizenz selbst finden Sie in unserem Leitfaden für Zahlungsinstitute und im Leitfaden zur EMI-Lizenz, oder fordern Sie eine Demo an.
FAQ
Ja. Artikel 2 bezieht Zahlungsinstitute und EMIs ein, die nach PSD2 und E-Geld-Richtlinie ausgenommen sind. Sie wenden statt der Artikel 5 bis 15 den vereinfachten IKT-Risikomanagementrahmen nach Artikel 16 an, führen aber trotzdem ein Informationsregister und befolgen die Regeln zur Meldung von Vorfällen und zu IKT-Verträgen.
Es ist eine strukturierte Aufstellung aller Ihrer Verträge über IKT-Dienstleistungen, in der Vorlage nach Durchführungsverordnung (EU) 2024/2956. Ab 2026 ist der Stichtag der 31. Dezember des Vorjahres, und die nationalen Behörden leiten die Register bis zum 31. März an die ESAs weiter. Ihre eigene Frist legt Ihre nationale Aufsichtsbehörde fest, und sie liegt früher.
Die Erstmeldung ist innerhalb von 4 Stunden nach Einstufung des Vorfalls als schwerwiegend fällig, spätestens aber 24 Stunden nach Kenntnis. Ein Zwischenbericht folgt innerhalb von 72 Stunden, ein Abschlussbericht innerhalb eines Monats nach dem letzten Zwischenbericht.
Nur wenn ihre zuständige Behörde sie dafür bestimmt. Kleine ausgenommene Institute und Kleinstunternehmen sind vollständig ausgenommen. Alle anderen Zahlungsinstitute und EMIs brauchen trotzdem ein Testprogramm mit mindestens jährlichen Tests der Systeme, die kritische oder wichtige Funktionen unterstützen.
Wahrscheinlich nicht. Die Liste der ESAs vom November 2025 nennt überwiegend große Cloud- und Technologieunternehmen. Für Sie ändert das nichts: Ein Anbieter, der Ihre kritischen Funktionen betreibt, braucht trotzdem einen Vertrag mit den Klauseln nach Artikel 30 Absatz 3, eine Ausstiegsstrategie und einen Eintrag in Ihrem Register.
Nein. DORA ist EU-Recht. Ein britisches EMI oder Zahlungsinstitut folgt den Regeln der FCA zur operationellen Resilienz. Wenn Sie über eine Tochtergesellschaft auch eine EU-Lizenz halten, fällt diese Tochter unter DORA.
Sie informieren Ihre Aufsichtsbehörde rechtzeitig über den neuen Vertrag für eine kritische Funktion, aktualisieren das Register und folgen Ihrem Ausstiegsplan für den bisherigen Anbieter. Genau deshalb verlangt DORA Ausstiegspläne und Regeln zur Datenrückgabe, bevor Sie sie brauchen.
Nein. Crassula stellt die Technologie und die Dokumentation für Ihre Abschnitte zu IKT und Auslagerung bereit, dazu Datenexporte aus der Plattform. Klassifizierung von Vorfällen, Meldungen an Ihre Aufsichtsbehörde und das Informationsregister bleiben bei Ihrem Unternehmen.
Weitere Leitfäden
Erstellen Sie eine digitale Bank in nur wenigen Tagen
Demo anfordern