Was ist DORA? Digital Operational Resilience Act

Wer ist betroffen?

DORA gilt für rund 20 Kategorien von Finanzunternehmen in der EU sowie für kritische ICT-Drittanbieter, die von den ESAs als solche eingestuft werden. Der Kreis ist breiter als unter MiFID oder CRD allein.

Kreditinstitute, Zahlungsinstitute, E-Geld-Institute. Wertpapierfirmen, Krypto-Asset-Dienstleister (CASP nach MiCA). Zentralverwahrer (CSD), zentrale Gegenparteien (CCP), Handelsplätze, Transaktionsregister.

Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler. Einrichtungen der betrieblichen Altersversorgung (EbAV). AIFM und OGAW-Verwaltungsgesellschaften.

Ratingagenturen, Administratoren kritischer Referenzwerte. Crowdfunding-Dienstleister, Verbriefungs-Register, Anbieter von Krypto-Vermögenswert-Diensten. Plus: kritische ICT-Drittanbieter, die nach Art. 31 eingestuft werden, unterliegen direkter EU-Aufsicht.

Die fünf Säulen

Säule 1: ICT-Risikomanagement-Rahmen (Art. 5-16). Geschäftsleitung billigt und überprüft jährlich, dokumentierte Strategie, klare Verantwortung, Asset-Management, Erkennung, Schutz, Reaktion, Wiederherstellung.

Säule 2: ICT-Vorfallsmanagement und Meldung (Art. 17-23). Klassifizierung nach RTS, Meldefristen 24h/72h/1 Monat, freiwilliges Reporting bei signifikanten Cyberbedrohungen.

Säule 3: Digital Operational Resilience Testing (Art. 24-27). Mindestens jährlich Basistests, Threat-Led Penetration Testing (TLPT) mindestens alle drei Jahre für signifikante Entitäten.

Säule 4: Management von ICT-Drittanbieter-Risiken (Art. 28-44). Informationsregister, Eignungsprüfung, Pflichtklauseln nach Art. 30, dokumentierte Exit-Strategie, Konzentrationsrisiken.

Säule 5: Informationsaustausch über Cyberbedrohungen (Art. 45). Freiwillige Teilnahme an Threat-Intelligence-Communities mit Datenschutz-Schutzklauseln.

Art. 28-30: das harte Drittanbieter-Regime

Art. 28 fordert eine dokumentierte Strategie für ICT-Drittanbieter-Risiken, ein Informationsregister aller Verträge, Eignungsprüfungen vor Vertragsschluss, kontinuierliche Überwachung, eine getestete Exit-Strategie und die explizite Bewertung von Konzentrationsrisiken.

Art. 29 erweitert auf systemweite Konzentrationsrisiken: Die zuständige Aufsicht kann Anweisungen erteilen, wenn ein Markt zu abhängig von einem ICT-Drittanbieter wird.

Art. 30 listet die zwingenden Vertragsklauseln. Für normale Funktionen: klare Beschreibung der Dienstleistung, Speicherort, SLAs, Verfügbarkeitsregelungen, Datenpfaditen, Kündigung, Prüfrechte. Für kritische oder wichtige Funktionen zusätzlich: umfangreiche Audit-Rechte, vollständige Sub-Outsourcing-Kontrolle, Exit-Strategien mit angemessenen Übergangsfristen, Verpflichtungen zum Incident-Reporting, Cooperation mit Aufsichtsbehörden.

Praktisch heißt das: jedes Cloud-, SaaS- oder Outsourcing-Memo eines Finanzunternehmens muss Art. 28-30 explizit adressieren, bevor unterschrieben wird.

TLPT, Threat-Led Penetration Testing

Art. 26-27 DORA. Mindestens alle drei Jahre für signifikante Finanzunternehmen, identifiziert durch die nationale Aufsicht (in Deutschland BaFin). Methodisch angelehnt an TIBER-EU: Threat-Intel-gestützte Szenarien, Tests in Produktivumgebungen, strenge Trennung von Tester und Beauftragten, Reporting an die Aufsicht. Wer die Anforderungen nicht erfüllt, riskiert Anweisungen oder Bußgelder.

Incident-Reporting unter DORA

Erstmeldung: innerhalb von 24 Stunden ab Klassifizierung eines Vorfalls als schwerwiegend. Inhalt: erste Information, vermutete Ursache, vorläufige Einschätzung der Auswirkungen.

Zwischenmeldung: innerhalb von 72 Stunden ab Klassifizierung. Inhalt: aktualisierte Daten zu Schweregrad, Auswirkungen, getroffene Maßnahmen, Indikatoren.

Abschlussmeldung: spätestens einen Monat nach dem Vorfall. Inhalt: vollständige Ursachenanalyse (Root Cause), umgesetzte Maßnahmen, Lessons Learned, finanzielle Auswirkungen.

Klassifizierungskriterien stehen in der RTS Incident Classification: betroffene Kunden, Dauer, geografische Verbreitung, Datenintegrität, Kritikalität der Dienste, wirtschaftlicher Schaden, Reputationsschaden.

Sanktionen

DORA selbst gibt keinen einheitlichen Bußgeldrahmen vor; Sanktionen folgen nationalem Recht. In Deutschland greift das Finanzmarktdigitalisierungsgesetz (FinmadiG). Erwartet werden Bußgelder im Bereich von Hunderttausenden bis Millionen Euro pro Verstoss, plus persönliche Verantwortlichkeit der Geschäftsleitung. Für kritische ICT-Drittanbieter unter direkter EU-Aufsicht können tägliche Zwangsgelder verhängt werden.

Was Finanzunternehmen jetzt tun sollten

1. ICT-Risikomanagement-Framework formal verabschieden lassen, dokumentiert und durch Geschäftsleitung gebilligt.

2. Informationsregister aller ICT-Drittanbieter aufbauen, mit Mapping kritisch/wichtig vs. unterstützend.

3. Bestehende Verträge gegen Art. 30 prüfen, fehlende Pflichtklauseln nachverhandeln. Neue Verträge nur mit konformen Klauseln abschließen.

4. Incident-Klassifizierung und Meldeprozess implementieren und testen. Eine ungeprobte Meldekette ist ein DORA-Risiko.

5. TLPT-Pflicht klären: bin ich signifikant? Wenn ja, Anbieter vorqualifizieren, Testpläne aufsetzen.

6. Strukturierte IT-Entscheidungen mit DORA-Mapping: jedes Memo zu EDR, IAM, Cloud, SIEM oder Outsourcing dokumentiert Art. 5 (Framework), Art. 28-30 (Drittanbieter), ggf. Art. 26 (Testing-Anforderungen).

DecisionOS und DORA

DecisionOS ist die Entscheidungsinfrastruktur für DORA-relevante IT-Beschaffungen. Jedes Memo ordnet sich direkt Art. 5, Art. 28 bis 30 und den DORA-Pflichtklauseln zu, dokumentiert die Abstimmung zwischen CISO, CRO, Rechtsabteilung und Vorstand, hält die Ausschlusskriterien sichtbar (Datenresidenz in der EU, Ausstiegsstrategie, Prüfrechte) und liefert eine Entscheidungsreife, die zeigt, ob die Entscheidung einer BaFin-Prüfung standhält. DecisionOS läuft auf dedizierten Servern in Deutschland. Die KI-Verarbeitung und die Auslieferung laufen über US-Anbieter auf Grundlage von Standardvertragsklauseln, die Unterauftragsverarbeiter stehen unter nexalign.io/hosting. Demo unter nexalign.io/demo-buchen.