Eine mittelgroße Vermögensverwaltung verlässt sich für Portfoliodaten auf einen einzigen Cloud-Anbieter, ohne dessen Subdienstleisterkette dokumentiert zu haben. Bei einem Ausfall des Anbieters fällt das Reporting für 48 Stunden aus. Die Aufsicht fragt das Drittparteien-Register, die Ausstiegsstrategie und das Resilienztest-Protokoll an. Wer DORA erst dann ernst nimmt, wenn die Aufsicht klingelt, kommt strukturell zu spät.
Der Digital Operational Resilience Act (DORA) ist die zentrale EU-Verordnung zur digitalen Betriebsstabilität im Finanzsektor. Sie bündelt Anforderungen an IKT-Risikomanagement, Vorfallmeldung, Resilienztestung, Drittparteien-Steuerung und Informationsaustausch in einem einheitlichen Rahmen — und löst damit einen Großteil der bisher fragmentierten nationalen Aufsichtsmitteilungen ab.
Wer ist betroffen?
DORA hat einen ungewöhnlich breiten Adressatenkreis. Erfasst sind 21 Kategorien von Finanzunternehmen und erstmals auch IKT-Drittdienstleister direkt:
- Finanzunternehmen — Banken, Versicherungen, Rückversicherungen, Wertpapierfirmen, Zahlungs- und E-Geld-Institute, Krypto-Asset-Dienstleister, zentrale Gegenparteien, Handelsplätze, Datenbereitstellungsdienste, Verwalter alternativer Investmentfonds, OGAW-Verwaltungsgesellschaften, Versicherungsvermittler u. a.
- IKT-Drittdienstleister — alle Anbieter digitaler Dienste an Finanzunternehmen, von Cloud-Plattformen über Software-Anbieter bis zu Managed-Security-Diensten.
- Kritische IKT-Drittdienstleister (CTPP) — von den ESAs benannte Anbieter, die ein Konzentrationsrisiko für den Finanzsektor darstellen. Sie unterliegen einem direkten europäischen Aufsichtsrahmen mit jährlichen Aufsichtsplänen und Sanktionsbefugnissen.
Die Proportionalität (Art. 4) erlaubt vereinfachte Anforderungen für Kleinstunternehmen und kleine Wertpapierfirmen. Die Kernpflichten zu Vorfallmeldung und Drittparteien-Register bleiben universell.
Was verlangt das Gesetz?
DORA ist in fünf Säulen strukturiert. Jede Säule enthält detaillierte Anforderungen, die über delegierte Rechtsakte (RTS/ITS) weiter konkretisiert werden:
- IKT-Risikomanagement (Kap. II, Art. 5–16) — dokumentiertes Rahmenwerk, jährlich überprüft, vom Leitungsorgan verabschiedet. Inventarisierung aller IKT-Assets, kontinuierliche Risikobewertung, Schutz- und Erkennungsmaßnahmen, Backup- und Wiederherstellungsstrategien.
- IKT-Vorfälle (Kap. III, Art. 17–23) — Klassifizierungssystem, Meldepflicht für schwerwiegende Vorfälle nach festen Schwellwerten, Erst-, Zwischen- und Abschlussmeldung an die Aufsicht. Cyberangriffe sind mit erfasst.
- Resilienztests (Kap. IV, Art. 24–27) — risikobasiertes Testprogramm, mindestens jährlich; für signifikante Unternehmen alle drei Jahre erweiterte Threat-Led Penetration Tests (TLPT) nach TIBER-EU-Methodik.
- IKT-Drittparteienrisiko (Kap. V, Art. 28–44) — Vertragsregister mit Pflichtangaben, Konzentrationsrisikoanalyse, vertragliche Mindestklauseln (Audit-Rechte, Subdienstleister-Kontrolle, Ausstiegsstrategie), direkter Aufsichtsrahmen für kritische Drittdienstleister.
- Informationsaustausch (Kap. VI, Art. 45) — freiwilliger Austausch von Cyber-Bedrohungsinformationen zwischen Finanzunternehmen.
In der Praxis
Vertragsregister vor Auditstart vollständig haben. Die häufigste Lücke nach Inkrafttreten: Das Register wurde aus alten Auslagerungslisten zusammengezogen, ohne die DORA-Pflichtfelder (Funktion, Datenkategorie, Subdienstleister, Land der Verarbeitung, Wesentlichkeitseinstufung) konsequent zu pflegen. Die Aufsicht kann das Register jederzeit anfordern.
Schwellwerte für die Vorfallklassifikation operationalisieren. Die delegierte Verordnung definiert harte Kriterien (betroffene Kunden, Dauer, geografische Reichweite, Datenverlust, wirtschaftliche Auswirkung, Reputation). Wer die Schwellwerte nicht in den Incident-Response-Prozess eingebaut hat, läuft Gefahr, die initialen 4-Stunden-Frist und die nachfolgenden Meldetermine zu verfehlen.
Ausstiegsstrategien testen, nicht nur dokumentieren. Für jede wesentliche IKT-Funktion verlangt DORA eine dokumentierte Exit-Strategie inklusive Übergangszeitraum. Eine Strategie, die nie geprüft wurde, hält keiner Krise stand. Tabletop-Übungen mit dem Anbieter sind die praktikabelste Form der Validierung.
Mapping zu ISO 27001
DORA überlappt strukturell stark mit ISO 27001 und ISO 22301. Wer ein zertifiziertes ISMS und BCMS betreibt, hat einen Großteil der DORA-Anforderungen technisch bereits abgedeckt — die DORA-spezifische Dokumentationsstruktur und die Meldepflichten bleiben aber separat zu erfüllen.
Direkt relevante Kontrollen:
- A.5.7 — Bedrohungsinformationen: Grundlage für den Informationsaustausch nach Art. 45 DORA.
- A.5.19 — Informationssicherheit in Lieferantenbeziehungen: Brücke zum DORA-Kapitel V.
- A.5.20 — Behandlung der Informationssicherheit in Lieferantenvereinbarungen: vertragliche Mindestinhalte.
- A.5.21 — Verwaltung der Informationssicherheit in der IKT-Lieferkette: Subdienstleister-Transparenz.
- A.5.22 — Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten: laufende Aufsicht über Drittdienstleister.
- A.5.23 — Informationssicherheit für die Nutzung von Cloud-Diensten: Cloud-spezifische DORA-Erwartungen.
- A.5.24 — Planung der Informationssicherheitsvorfallreaktion: Voraussetzung für die DORA-Meldepflichten.
- A.5.25 — Bewertung und Entscheidung über Informationssicherheitsereignisse: Klassifizierung nach DORA-Schwellwerten.
- A.5.29 — Informationssicherheit bei Störungen: operationelle Resilienz im Krisenfall.
- A.5.30 — IKT-Bereitschaft für die Geschäftskontinuität: zentraler Brückenpunkt zur Resilienzpflicht aus Kap. II.
- A.8.6 — Kapazitätsmanagement: Grundlage stabiler IKT-Dienste.
- A.8.8 — Handhabung technischer Schwachstellen: Voraussetzung für Threat-Led Tests.
- A.8.14 — Redundanz von informationsverarbeitenden Einrichtungen: technische Resilienz.
- A.8.15 — Protokollierung: Nachweis für Vorfallmeldungen.
- A.8.16 — Überwachung von Aktivitäten: Erkennung anormaler IKT-Ereignisse.
Typische Audit-Befunde
- Drittparteienregister unvollständig — Subdienstleister fehlen, Wesentlichkeitseinstufung wurde nie systematisch vergeben, Konzentrationsrisiko ist nicht analysiert.
- Vorfallklassifikation nicht operationalisiert — der Incident-Response-Prozess kennt die DORA-Schwellwerte nicht, die initiale 4-Stunden-Meldung wird nur theoretisch beherrscht.
- Resilienztest-Programm zu schmal — Tests konzentrieren sich auf Penetrationstests einzelner Anwendungen, ohne die DORA-geforderte Bandbreite (Szenarioanalysen, Open-Source-Komponententests, Performance-Tests).
- Ausstiegsstrategien sind reine Textbausteine — keine Migrationsabschätzung, keine Übergangsfrist, keine geprüfte Datenportabilität.
- Leitungsorgan nicht aktiv eingebunden — der IKT-Risikorahmen wurde formal verabschiedet, die jährliche Überprüfung ist aber Kosmetik.
- TLPT-Vorbereitung zu spät begonnen — die Auswahl des Threat-Intelligence- und Red-Team-Anbieters, die Scope-Definition und die TIBER-EU-konforme Durchführung brauchen mehr Vorlauf als oft eingeplant.
Quellen
- Verordnung (EU) 2022/2554 (EUR-Lex) — amtliche EU-Fassung in allen Sprachen
- DORA-Seite der EBA — technische Standards und Leitlinien
- DORA-Seite der EIOPA — versicherungsspezifische Konkretisierungen
- DORA-Seite der ESMA — kapitalmarktbezogene Hinweise
- BaFin-Fachartikel zu DORA — nationale Aufsichtspraxis und Meldewege