DORA-Verordnung: Anwendungsbereich, Pflichten und Folgen für IT-Dienstleister
Was ist die DORA-Verordnung?
Die DORA-Verordnung verpflichtet Finanzunternehmen, ihre IT-Risiken systematisch zu steuern, und bezieht ihre Dienstleister ausdrücklich mit ein.
DORA steht für Digital Operational Resilience Act und bezeichnet die Verordnung (EU) 2022/2554. Sie schafft einen einheitlichen Rechtsrahmen für die digitale operationale Widerstandsfähigkeit im europäischen Finanzsektor. Geregelt werden das Management von IKT-Risiken, die Meldung von Vorfällen, das Testen der Widerstandsfähigkeit und die Steuerung ausgelagerter Leistungen.
Die Verordnung trat am 16. Januar 2023 in Kraft und gilt nach einer zweijährigen Übergangsfrist seit dem 17. Januar 2025. Zuständige Aufsichtsbehörde in Deutschland ist die BaFin, die den Rahmen in ihrer Übersicht zu DORA darstellt. Als Verordnung gilt DORA unmittelbar, sie musste also nicht erst in nationales Recht überführt werden.
Die vier Säulen im Überblick
Die Anforderungen gliedern sich in vier Bereiche, die zusammen einen geschlossenen Regelkreis bilden.
- IKT-Risikomanagement mit dokumentiertem Rahmenwerk und Verantwortung der Leitung
- Behandlung und Meldung IKT-bezogener Vorfälle innerhalb festgelegter Fristen
- Regelmäßige Tests der digitalen operationalen Resilienz
- Management des Risikos durch IKT-Drittdienstleister einschließlich Vertragsanforderungen
Abgrenzung zu NIS-2
Beide Regelwerke zielen auf Widerstandsfähigkeit, greifen aber unterschiedlich. NIS-2 erfasst Sektoren breit, DORA regelt den Finanzsektor tiefer und geht als speziellere Regelung vor. Wer bereits ein Managementsystem nach ISO 27001 betreibt, hat einen erheblichen Teil der Grundlagen, ohne damit die spezifischen Melde- und Testpflichten zu erfüllen. Der Vergleich lohnt gegenüber der Kompetenzseite zu NIS-2.
Wer ist von DORA betroffen?
Der Anwendungsbereich umfasst zwei Gruppen, die sich in ihren Pflichten deutlich unterscheiden.
Finanzunternehmen im unmittelbaren Anwendungsbereich
Erfasst sind Finanzunternehmen nach Artikel 2 der Verordnung, darunter Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherer, Fondsverwalter, Handelsplätze, Zentralverwahrer und Anbieter von Krypto-Dienstleistungen.
Für diese Unternehmen gelten sämtliche Anforderungen unmittelbar. Die Verantwortung liegt ausdrücklich bei der Geschäftsleitung und lässt sich nicht auf die IT-Abteilung oder einen Dienstleister verschieben. Erleichterungen bestehen für kleine und nicht verflochtene Einheiten, sie betreffen jedoch den Umfang, nicht die grundsätzliche Geltung.
Wann Finanzunternehmen ihre Dienstleister einbeziehen müssen
Sobald eine IKT-Leistung von außen bezogen wird, greifen die Anforderungen an das Drittparteienrisiko. Das gilt unabhängig davon, ob es sich um Hosting, Softwareentwicklung, Wartung oder Betrieb handelt.
Finanzunternehmen führen ein Register aller vertraglichen Vereinbarungen über IKT-Leistungen und unterscheiden dabei, welche Funktionen kritisch oder wichtig sind. Die Einstufung entscheidet über die Tiefe der Anforderungen und wird vom Finanzunternehmen vorgenommen, nicht vom Dienstleister.
Anforderungen an IKT-Drittdienstleister
Für Dienstleister wirkt DORA überwiegend mittelbar, über die Verträge ihrer Auftraggeber. Kritische Anbieter unterliegen zusätzlich einer direkten europäischen Überwachung.
Praktisch bedeutet das, dass Verträge bestimmte Regelungen enthalten müssen. Ohne sie darf ein Finanzunternehmen die Leistung nicht beziehen, was Vertragsverhandlungen deutlich verändert hat.
- Beschreibung der Leistung und der Orte der Datenverarbeitung
- Zugangs-, Einsichts- und Prüfrechte für Auftraggeber und Aufsicht
- Mitwirkung bei Resilienztests und bei der Meldung von Vorfällen
- Vereinbarte Dienstgütevorgaben mit messbaren Zielwerten
- Kündigungsrechte und geregelte Ausstiegsszenarien
Die Ausstiegsstrategie ist der Punkt mit der größten praktischen Sprengkraft. Sie verlangt, dass ein Wechsel ohne Betriebsunterbrechung möglich bleibt, also dokumentierte Schnittstellen, exportierbare Daten und übergabefähige Betriebsverfahren. Verwandte Überlegungen finden sich auf der Seite zum Anbieterwechsel bei EVB-IT-Verträgen.
Das Register der Informationen
Finanzunternehmen führen ein strukturiertes Verzeichnis aller vertraglichen Vereinbarungen über IKT-Leistungen und melden es der Aufsicht. Für Dienstleister bedeutet das konkrete Zulieferpflichten, weil ohne ihre Angaben Felder leer bleiben.
- Eindeutige Kennung des Unternehmens und der Konzernstruktur
- Beschreibung der erbrachten Funktion und ihrer Kritikalität
- Orte der Datenverarbeitung und der Datenspeicherung
- Eingesetzte Unterauftragnehmer in der gesamten Kette
- Laufzeiten, Kündigungsfristen und vereinbarte Dienstgüten
Die Kette der Unterauftragnehmer überrascht viele Anbieter. Wer Cloud-Dienste, Monitoring oder Backup zukauft, muss diese Vorleistungen offenlegen, weil das Risiko durchgereicht wird und nicht beim ersten Vertragspartner endet.
Fristen und Übergangsfragen
Anders als bei einer Richtlinie gab es keine nationale Umsetzung, an die sich ein späterer Starttermin hätte knüpfen lassen. Seit dem Geltungsbeginn gelten die Anforderungen vollständig.
Praktisch bedeutet das, dass Altverträge angepasst werden mussten und weiterhin angepasst werden, sobald sie verlängert oder geändert werden. Ein bestehender Vertrag genießt keinen Bestandsschutz, wenn er die geforderten Regelungen nicht enthält. Für Dienstleister lohnt deshalb eine Bestandsaufnahme der eigenen Verträge mit Finanzkunden, geordnet nach Verlängerungszeitpunkt, weil sich daraus die Reihenfolge der Nachverhandlungen ergibt.
Was DORA für Entwicklung und Betrieb bedeutet
Die Verordnung wirkt bis in die Architektur hinein, weil sich mehrere Anforderungen nachträglich nur schwer erfüllen lassen.
Was bedeutet DORA für IT-Dienstleister konkret?
Wer für Finanzunternehmen arbeitet, muss nachweisbar liefern, was der Vertrag zusagt. Aus vier Anforderungen folgen unmittelbare technische Konsequenzen.
- Protokollierung, die eine Vorfallanalyse innerhalb der Meldefristen erlaubt
- Nachvollziehbare Verwaltung eingesetzter Komponenten und ihrer Schwachstellen
- Wiederanlaufverfahren, die geprüft und nicht nur beschrieben sind
- Trennung von Umgebungen, damit Tests den Betrieb nicht gefährden
Die Meldefristen sind der schärfste Treiber. Wer im Ernstfall erst Protokolle zusammensuchen muss, hält sie nicht ein. Grundlagen dazu behandelt die Seite zur sicheren Softwareentwicklung.
Auswirkungen auf bestehende Anwendungen
Ältere Fachanwendungen erfüllen die Anforderungen an Protokollierung und Wiederanlauf häufig nicht. Eine vollständige Neuentwicklung ist selten nötig, eine strukturierte Bestandsaufnahme dagegen schon.
Sinnvoll ist eine Bewertung entlang der vier Säulen, aus der hervorgeht, welche Lücken vertraglich, welche organisatorisch und welche technisch zu schließen sind. Nicht jede Lücke ist ein Entwicklungsauftrag, viele lassen sich durch Dokumentation und geregelte Verfahren schließen. Für den fachlichen Kontext lohnt der Blick auf die Seite zu Software für Finanzdienstleister.
Wiederanlauf als Prüfstein
Von allen Anforderungen ist der geprüfte Wiederanlauf diejenige, an der Bestandsanwendungen am häufigsten scheitern. Ein beschriebenes Verfahren genügt nicht, verlangt ist der Nachweis, dass es funktioniert.
In der Praxis zeigen erste Übungen regelmäßig dieselben Lücken. Sicherungen sind vorhanden, aber nie zurückgespielt worden. Abhängigkeiten zu Umsystemen sind nicht dokumentiert. Zugangsdaten liegen ausschließlich in der Umgebung, die gerade ausgefallen ist. Diese Befunde sind unangenehm, aber wertvoll, weil sie sich außerhalb eines echten Vorfalls beheben lassen.
Der Aufwand einer solchen Übung ist überschaubar und liefert zugleich die Belege, die im Rahmen der Resilienztests ohnehin verlangt werden. Wer sie einmal jährlich fest einplant, erfüllt eine Pflicht und gewinnt gleichzeitig eine belastbare Aussage über den eigenen Betrieb. Ohne diesen Nachweis bleibt jede Zusage zur Wiederherstellungszeit eine Schätzung.
Sinnvoll ist es, die Übung auf ein klar umrissenes Szenario zuzuschneiden, statt einen Totalausfall zu simulieren. Der Verlust einer Datenbank oder der Ausfall einer einzelnen Umgebung liefert bereits belastbare Erkenntnisse und lässt sich ohne Risiko für den laufenden Betrieb durchführen. Wichtiger als der Umfang ist die Protokollierung des Ablaufs, weil sie den Nachweis erbringt und zugleich die Grundlage für die nächste Verbesserung bildet.
TenMedia entwickelt und betreibt Individualsoftware mit den Nachweispflichten regulierter Umfelder im Blick und übernimmt dabei auch bestehende Anwendungen. Wie sich Betrieb, Protokollierung und Wiederanlaufverfahren belastbar aufsetzen lassen, zeigt die Seite zu Softwarebetrieb und Wartung.