DORA-Verordnung: Was der Digital Operational Resilience Act ab 17. Januar 2025 von Finanzunternehmen verlangt

Die Verordnung (EU) 2022/2554 über die Betriebsstabilität digitaler Systeme im Finanzsektor (Digital Operational Resilience Act, DORA) gilt seit dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten. Sie adressiert Banken, Wertpapierfirmen, Versicherer, Zahlungs- und E-Geld-Institute, Krypto-Dienstleister, Verwaltungsgesellschaften, Handelsplätze, zentrale Gegenparteien sowie ihre IKT-Drittdienstleister. Wer dem Anwendungsbereich unterliegt, hat fünf Pflichtenkreise nachzuweisen: IKT-Risikomanagement, Meldung schwerwiegender Vorfälle, regelmäßige Resilienz-Tests, Drittparteienmanagement und Informationsaustausch.

Dieser Beitrag ordnet DORA aus der Officer-Perspektive. Wo wird im Unternehmen operativ entschieden, wo dokumentiert, wo geprüft. Wir zeigen, welche Schnittstellen zu ISO/IEC 27001:2022, BAIT und KAIT bestehen, wann eine Vorfallsmeldung an die nationale Aufsicht erfolgt und wie kritische IKT-Drittdienstleister unter die direkte Aufsicht der Europäischen Aufsichtsbehörden (ESAs) fallen. Den Schluss macht ein 90-Tage-Fahrplan, der die Pflichten in Bestand bringt.

Art. 2 DORA listet 20 Kategorien von Finanzunternehmen, von Kreditinstituten über Versicherungsvermittler bis zu Anbietern von Kryptowerte-Dienstleistungen, Crowdfunding-Anbietern und zentralen Wertpapierverwahrern. Hinzu treten IKT-Drittdienstleister, sobald sie für ein erfasstes Finanzunternehmen IKT-Dienstleistungen erbringen. Damit ist die Verordnung erkennbar weiter als die Vorgängerregelungen BAIT, VAIT, KAIT und ZAIT, die nationale Aufsichtspraxis bleibt jedoch fortgesetzt anwendbar, soweit DORA Raum lässt.

Für kleine und nicht verflochtene Wertpapierfirmen, Kleinstversicherer und ähnliche Akteure sieht Art. 16 DORA ein vereinfachtes IKT-Risikomanagement-Regime vor. Es bleibt aber bei der vollen Pflicht zu Vorfallsmeldungen und Drittparteienmanagement. Die nationale Umsetzung erfolgt in Deutschland durch das Finanzmarktdigitalisierungsgesetz (FinmadiG), das KWG, VAG, WpHG und ZAG anpasst und die Aufsicht bei BaFin und Deutscher Bundesbank verankert. Wer als Informationssicherheitsbeauftragter in einem Finanzunternehmen tätig ist, übernimmt zentrale Aufgaben in der DORA-Umsetzung, von der Risikoinventur bis zur Berichtslinie an den Vorstand.

Das IKT-Risikomanagement nach Art. 6 ff. DORA verlangt einen dokumentierten, regelmäßig überprüften Rahmen. Er umfasst Strategie, Richtlinien, Verfahren, Protokolle, Werkzeuge und Personalressourcen. Verantwortlich ist das Leitungsorgan, das eine ausdrückliche Genehmigung, regelmäßige Überprüfung und Schulungsverpflichtung tragen muss (Art. 5 DORA). Operative Schichten sind die Identifikation kritischer Funktionen und Informationsassets, die Detektion von Anomalien, die Reaktion mit Containment und Eradikation, die Wiederherstellung und das Lernen aus Vorfällen.

Die Schnittstelle zu ISO/IEC 27001:2022 ist eng. 93 Controls in Anhang A der Norm decken Teilbereiche der Art. 8 bis 15 DORA ab, ersetzen sie aber nicht. DORA verlangt Spezifika, etwa Backup-Standorte, alternative Verarbeitungseinrichtungen, Wiederanlaufzeiten je kritischer Funktion und die Trennung von Produktiv- und Sicherungsdaten. Das gemeinsam mit ESAs veröffentlichte technische Regulierungsstandard-Paket (RTS, EBA/EIOPA/ESMA-Mandate) konkretisiert die Anforderungen weiter. Wer bereits ein ISMS nach ISO 27001:2022 führt, kann DORA als zusätzliche Pflichtenklammer auf den vorhandenen Bestand aufsetzen, statt parallele Strukturen aufzubauen. Die Berichtspflicht an das Leitungsorgan ist mindestens jährlich, bei wesentlichen Veränderungen anlassbezogen.

Art. 17 DORA verlangt einen Vorfallsmanagement-Prozess mit Klassifizierung, Eskalation, Ursachenanalyse und Lessons-Learned. Art. 18 DORA legt die Klassifizierungskriterien fest, darunter Anzahl betroffener Kundinnen, Datenverlust, Dauer der Beeinträchtigung, geografische Ausbreitung, wirtschaftliche Auswirkungen und Reputationseffekte. Die zugehörige Delegierte Verordnung (EU) 2024/1772 definiert die Schwellenwerte für „schwerwiegende“ Vorfälle und „erhebliche“ Cyberbedrohungen.

Schwerwiegende IKT-Vorfälle sind nach Art. 19 DORA dreistufig zu melden: Erstmeldung innerhalb von vier Stunden nach Klassifizierung als schwerwiegend, spätestens jedoch 24 Stunden nach Kenntnis; Zwischenbericht innerhalb von 72 Stunden; Abschlussbericht innerhalb eines Monats. Die Erstmeldung enthält Kontaktdaten, Beschreibung des Vorfalls und betroffener Funktionen. Der Zwischenbericht beziffert Auswirkungen, der Abschlussbericht ordnet Ursachen und Maßnahmen. Frist läuft ab Kenntnis. Die Meldung erfolgt an die nationale Aufsicht, in Deutschland regelmäßig an die BaFin. Parallel besteht die Meldepflicht nach Art. 33 DSGVO, sofern personenbezogene Daten betroffen sind, ebenfalls binnen 72 Stunden. Eine doppelte, aber jeweils eigenständige Meldekette ist Standard. Die NIS-2-Meldefristen ähneln im Aufbau, sind aber rechtlich getrennt.

Art. 24 bis 27 DORA verlangen ein Testprogramm. Der Grundkatalog umfasst Schwachstellenanalysen, Open-Source-Analysen, Netzwerksicherheits- und Penetrationstests, Source-Code-Reviews und szenariobasierte Tests. Häufigkeit und Tiefe richten sich nach Risikoprofil, mindestens jährlich für kritische IKT-Systeme. Die Tests sind unabhängig durchzuführen, die Berichte gehen an das Leitungsorgan und an die Aufsicht auf Verlangen.

Für signifikante Institute kommen Threat-Led Penetration Tests (TLPT) nach Art. 26 f. DORA hinzu, mindestens alle drei Jahre. Die TLPT-Methodik folgt eng dem TIBER-EU-Rahmen der EZB: Threat Intelligence, Red Team, Closed-Loop-Berichterstattung. Welche Institute TLPT-pflichtig sind, ergibt sich aus quantitativen und qualitativen Kriterien, die die EBA in Abstimmung mit den anderen ESAs definiert hat (RTS unter Art. 26 Abs. 11). Die Tests adressieren echte Produktionssysteme inklusive ausgewählter IKT-Drittdienstleister; entsprechend hoch sind Anforderungen an Vertraulichkeit, Vorbereitung und Eskalationsplan. Die nationale TLPT-Behörde in Deutschland ist die Bundesbank gemeinsam mit der BaFin. Tests, die unter dem TIBER-DE-Rahmen erfolgreich abgeschlossen sind, können auf DORA-Pflichten angerechnet werden, sofern die Methodik und der Berichtsstand den RTS-Anforderungen entsprechen. Der Prüfer ruft an, der Nachweis liegt bereit.

Art. 28 bis 30 DORA strukturieren die Vertragsbeziehungen zu IKT-Drittdienstleistern. Pflicht ist ein Informationsregister sämtlicher Verträge mit Drittdienstleistern, das jährlich an die Aufsicht zu übermitteln ist (Art. 28 Abs. 3). Verträge müssen Mindestklauseln enthalten: Beschreibung der Funktionen, Standorte der Datenverarbeitung, Verfügbarkeits- und Sicherheitsniveaus, Kooperation mit der Aufsicht, Audit-Rechte, Exit- und Übergangspläne, Berichtspflichten bei Vorfällen.

Vor Vertragsschluss verlangt Art. 28 DORA eine Risikobewertung und die Prüfung, ob die Funktion kritisch oder wesentlich ist. Subunternehmer-Ketten müssen transparent und vorab vertraglich gestattet sein, mit Zustimmungsrecht des Finanzunternehmens (Art. 30 Abs. 2 Buchstabe a). Konzentrationsrisiken sind aktiv zu steuern; eine Häufung kritischer Funktionen bei einem einzelnen Anbieter, einer Region oder einer Plattform ist begründet zu dokumentieren. Für IKT-Drittdienstleister, die als kritisch eingestuft werden, gilt das Aufsichtsregime der Art. 31 ff. DORA: Eine der ESAs übernimmt die direkte Aufsicht, kann Empfehlungen aussprechen, Audits anordnen und Zwangsgelder verhängen. Die Liste kritischer Dienstleister wird jährlich aktualisiert. Wer als ISMS-Verantwortlicher die Lieferanten führt, verzahnt das Register, die Risikoanalysen und das Vertragscontrolling in einem Bestand, sodass Aufsicht und interne Revision auf eine einzige Quelle blicken.

DORA überschreibt nationale Aufsichtspraxis dort, wo die Verordnung sie regelt. BAIT, VAIT, KAIT und ZAIT bleiben als ergänzende Aufsichtsmitteilungen relevant, soweit sie nicht in Widerspruch zu DORA stehen. Die Schnittstelle zur DSGVO bleibt strikt: Art. 33 DSGVO verlangt eine eigenständige Meldung bei Verletzungen des Schutzes personenbezogener Daten innerhalb von 72 Stunden ab Kenntnis. Die DORA-Meldung an die BaFin ersetzt sie nicht. Der externe Datenschutzbeauftragte bleibt zuständig für die Datenschutzbewertung; die IKT-Sicherheitsfunktion bleibt zuständig für DORA.

Das Verhältnis zur NIS-2-Richtlinie ist gesetzlich entflochten: Art. 1 Abs. 2 NIS-2 stuft Finanzunternehmen als „lex specialis“ ein, sobald DORA gilt. NIS-2 entfaltet damit für Banken, Versicherer und Wertpapierfirmen keine eigenständige Cyberpflichtenwirkung; sie bleibt nur dort relevant, wo Konzerngesellschaften außerhalb des Finanzsektors operieren. Die EU-AI-Act-Schichten knüpfen, soweit KI-Systeme im Finanzsektor relevant werden, zusätzlich an DORA an, etwa bei der Risikoklassifizierung interner Algorithmen. Im operativen Alltag bedeutet das eine konsolidierte Meldelandkarte: DORA an BaFin, DSGVO an Landesdatenschutz, NIS-2 an BSI für Nicht-Finanzteile, AI-Act gemäß zuständiger Behörde.

Art. 50 DORA verpflichtet Mitgliedstaaten, „wirksame, verhältnismäßige und abschreckende“ Sanktionen vorzusehen. Deutschland setzt dies in den Fachgesetzen um. Im KWG, VAG, WpHG und ZAG sind seit Inkrafttreten des FinmadiG Bußgeldtatbestände aktualisiert, die Geldbußen bis in den siebenstelligen Bereich und ein Prozentsatz des Jahresumsatzes ermöglichen, abhängig vom Sektor. Hinzu treten aufsichtsrechtliche Anordnungen, Geschäftsleiteruntersagungen und Veröffentlichungspflichten.

Kritische IKT-Drittdienstleister können nach Art. 35 DORA mit Zwangsgeldern belegt werden, die 1 Prozent des durchschnittlichen weltweiten Tagesumsatzes betragen können, je Tag des Verstoßes, für maximal sechs Monate. Diese Sanktion adressiert ausdrücklich Cloud-Anbieter, Rechenzentrumsbetreiber und ähnliche Schwergewichte. Aufsichtsrechtlich treibt die Lead Overseer-Funktion der EBA, EIOPA oder ESMA das Verfahren, koordiniert mit den nationalen Behörden. In der Praxis hängt das tatsächliche Sanktionsniveau stark von der Klassifizierung des Verstoßes, der Dauer und vom Maß der Kooperation ab. Die Erfahrung aus DSGVO-Verfahren legt nahe, dass die ersten Bußgelder ab 2026 in publikumswirksamen Bereichen erwartet werden können, etwa wenn Meldepflichten oder Drittparteienregister demonstrativ unzureichend geführt sind. Audit-fest, dokumentiert, § ...-fest.

Tag 1 bis 14: Anwendbarkeitsanalyse. Klären Sie, welche Konzerngesellschaften unter Art. 2 DORA fallen, welche Sondervorschriften greifen (Art. 16 vereinfachtes Regime) und welche IKT-Dienstleister relevant sind. Erstellen Sie eine Erstinventur der kritischen Funktionen und der zugehörigen IKT-Assets.

Tag 15 bis 45: Risikomanagement-Rahmen. Bringen Sie die Governance-Vorgaben in die Geschäftsordnung des Vorstands und in die Berichtslinie des Informationssicherheitsbeauftragten. Ergänzen Sie das vorhandene ISMS um die DORA-spezifischen Elemente: Wiederanlaufzeiten je Funktion, Detektionswerkzeuge, Backup-Konzept, alternative Verarbeitungseinrichtungen, RTS-konforme Klassifizierung. Tag 46 bis 75: Drittparteien. Erfassen Sie alle IKT-Verträge im Register, prüfen Sie sie gegen Art. 30 DORA, schließen Sie Nachträge, soweit Klauseln fehlen, klären Sie Subunternehmer-Ketten. Tag 76 bis 90: Tests und Vorfälle. Definieren Sie Klassifizierungs- und Meldepfade nach Art. 17 bis 19 DORA mit klaren Fristen (vier, 24, 72 Stunden, ein Monat). Planen Sie das Testprogramm 2026, einschließlich TLPT-Bedarf. CIVAC begleitet diesen Fahrplan im Workspace, mit Audit-Vorlagen für das Register, die Klassifizierungsmatrix und den dreistufigen Meldepfad, und unterstützt die Berichtslinie an das Leitungsorgan.

CIVAC ist Compliance-Plattform und Officer-as-a-Service. Lizenzieren Sie den Workspace für Ihre internen Beauftragten, damit IKT-Risikoinventur, Vorfallsklassifizierung, Drittparteienregister und Meldepfade in einem nachvollziehbaren Bestand laufen. Oder lassen Sie unsere Beauftragten bestellen, mit Bestellurkunde, unterschrieben, abgelegt, belegbar. Die ISO 27001:2022-Basis, die 93 Controls und 37 Audit-Vorlagen sowie die EU-Datenresidenz bilden das technische Fundament, auf das DORA aufsetzt.

Wer DORA-relevant ist, kennt die Berichtspfade gegenüber BaFin und Bundesbank. Der eigentliche Aufwand entsteht im Tagesgeschäft: jedes Asset einem Verantwortlichen zuordnen, jeden Vertrag einer Klausel zuordnen, jeden Vorfall einer Frist zuordnen. CIVAC hält diese Zuordnung im Workspace, mit Wiedervorlagen, Audit-Spuren und Eskalationspfaden. Wenn Sie wissen wollen, welche Schritte Ihr Haus konkret in den ersten 30 Tagen abdecken sollte, schreiben Sie an info@civac.de oder nutzen Sie das Kontaktformular auf civac.de. Aus dem Lesen einen Auftrag machen.