DORA regelt, wie Finanzunternehmen ihre IT beherrschen müssen, damit ein technischer Ausfall nicht zum Marktereignis wird. Die Verordnung (EU) 2022/2554 gilt seit dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten — ohne nationales Umsetzungsgesetz, ohne Wahlmöglichkeit.
Was DORA nicht verlangt, ist ebenso aufschlussreich: Die Verordnung schreibt keine Produkte vor, keine Mindestverfügbarkeit und keine bestimmte Architektur. Sie verlangt, dass Sie Ihre kritischen Funktionen kennen, die IKT-Abhängigkeiten dahinter benennen können, Vorfälle nach eigenen, vorab festgelegten Kriterien klassifizieren und für jede wesentliche Auslagerung wissen, wie Sie ohne den Dienstleister weiterarbeiten. Das Prüfobjekt ist Ihre Steuerungsfähigkeit, nicht Ihre Technik.
Der Anwendungsbereich ist breiter, als der Begriff „Finanzsektor” vermuten lässt. Erfasst sind Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherungs- und Rückversicherungsunternehmen und deren Vermittler, Einrichtungen der betrieblichen Altersversorgung, Kapitalverwaltungsgesellschaften, Handelsplätze, Zentralverwahrer, zentrale Gegenparteien, Ratingagenturen, Schwarmfinanzierungsdienstleister und Anbieter von Kryptowerte-Dienstleistungen. Dazu kommen die IKT-Drittdienstleister, die für diese Unternehmen arbeiten.
Der Unterschied zu einer Managementsystemnorm ist grundsätzlich. ISO 27001 beschreibt, wie ein System aussehen soll, das Sie freiwillig aufbauen. DORA beschreibt Pflichten, die Sie erfüllen, weil sie gelten. Das verschiebt auch die Beweislast: Nicht die Zertifizierungsstelle prüft im Dreijahresrhythmus, sondern die Aufsicht fragt, wann sie will.
Die fünf Säulen und was dahintersteckt
Die Verordnung ist in fünf inhaltliche Blöcke gegliedert. Jeder verlangt Nachweise, die in klassisch aufgestellten IT-Abteilungen selten vollständig vorliegen.
| Säule | Kern der Anforderung | Typische Lücke |
|---|---|---|
| IKT-Risikomanagement | Rahmenwerk mit Strategie, Leitlinien, Schutz- und Erkennungsmaßnahmen, Wiederherstellung und Lernprozessen; Letztverantwortung beim Leitungsorgan | Das Leitungsorgan hat formal beschlossen, kann den Inhalt aber nicht erläutern |
| Vorfallmanagement | Einheitliche Klassifizierung von IKT-Vorfällen, dreistufige Meldung schwerwiegender Vorfälle an die zuständige Behörde | Schwellenwerte für „schwerwiegend” sind nie festgelegt worden |
| Resilienztests | Regelmäßiges Testprogramm; für bestimmte Unternehmen zusätzlich bedrohungsgeleitete Penetrationstests, mindestens alle drei Jahre | Es gibt Schwachstellenscans, aber kein Testprogramm mit Planung und Auswertung |
| IKT-Drittparteienrisiko | Informationsregister, Vorabbewertung, Pflichtinhalte in Verträgen, Ausstiegsstrategien, Steuerung der Unterauftragskette | Verträge ohne Prüf- und Zugangsrechte, keine Exit-Planung |
| Informationsaustausch | Freiwilliger Austausch über Cyberbedrohungen in vertrauenswürdigen Kreisen | Wird ausgelassen — was zulässig ist |
Zwei Punkte werden regelmäßig unterschätzt. Erstens die Ausstiegsstrategie: Für jede IKT-Dienstleistung, die eine kritische oder wichtige Funktion unterstützt, muss beschrieben sein, wie Sie ohne diesen Dienstleister weiterarbeiten. Ein Satz im Vertrag genügt dafür nicht. Zweitens die Unterauftragskette — der Cloud-Anbieter Ihres Softwarehauses gehört ins Register, auch wenn Sie ihn nie beauftragt haben.
Die Meldung schwerwiegender Vorfälle
Die Meldepflicht ist die Anforderung mit der kürzesten Reaktionszeit und deshalb die, an der Organisation zuerst sichtbar wird. Ein schwerwiegender IKT-Vorfall wird in drei Stufen an die zuständige Behörde gemeldet: eine Erstmeldung, sobald die Einstufung feststeht, eine Zwischenmeldung mit dem Sachstand und eine Abschlussmeldung mit Ursachenanalyse und Maßnahmen. Die genauen Fristen und Meldeformulare stehen nicht in der Verordnung selbst, sondern in den technischen Standards der Aufsichtsbehörden.
Der schwierige Teil ist die Einstufung. Die Verordnung nennt Kriterien wie die Zahl betroffener Kunden, die Dauer, die geografische Ausbreitung, Datenverluste, die Kritikalität der betroffenen Dienste und den wirtschaftlichen Schaden. Diese Kriterien müssen Sie in eigene, im Betrieb anwendbare Schwellen übersetzen — vorher, nicht während des Vorfalls. Wer das versäumt, verliert die knappe Zeit der Erstmeldung mit einer Zuständigkeitsdiskussion.
Praktisch bewährt sich, die Einstufung an eine benannte Rolle mit Vertretung zu binden, sie in der Rufbereitschaft zu verankern und im Rahmen einer Übung durchzuspielen. Der Meldeweg selbst gehört ebenfalls geübt: Zugänge zu Meldeportalen, die im Ernstfall zum ersten Mal benutzt werden, funktionieren erfahrungsgemäß nicht.
Der Weg zur Umsetzung
Ein Zertifizierungsverfahren gibt es nicht, eine sinnvolle Reihenfolge schon. Sie ergibt sich aus den Abhängigkeiten zwischen den Anforderungen.
- Betroffenheit klären. Fällt das Unternehmen unter die Verordnung, und greift der vereinfachte Rahmen?
- Kritische und wichtige Funktionen bestimmen. Ableitung aus den Geschäftsprozessen, nicht aus dem Systeminventar.
- IKT-Abhängigkeiten je Funktion erfassen. Systeme, Dienstleister, Unterauftragnehmer, Standorte.
- Informationsregister aufbauen. Vertragsdaten aus Einkauf, Recht und Fachbereichen zusammenführen und dem vorgegebenen Format zuordnen.
- Risikomanagementrahmen beschließen. Strategie, Leitlinien und Rollen — mit einem Leitungsbeschluss, der inhaltlich getragen wird.
- Meldeprozess und Schwellenwerte festlegen und mit einer Übung erproben.
- Verträge nachziehen. Prüf- und Zugangsrechte, Meldepflichten des Dienstleisters, Kündigungs- und Ausstiegsregelungen.
- Testprogramm aufsetzen und die Ergebnisse in das Risikomanagement zurückspielen.
- Nachweisführung ordnen. Interne Revision, Berichte an das Leitungsorgan, Prüfungsunterlagen.
Der kritische Pfad läuft fast immer über die Schritte 2 bis 4. Erst wenn feststeht, welche Funktionen kritisch sind, lässt sich entscheiden, welche Verträge nachverhandelt und welche Systeme getestet werden müssen. Häuser, die parallel bei den Verträgen beginnen, verhandeln Klauseln für Dienstleistungen, die sich später als unkritisch herausstellen — und übersehen andere.
Wo Erleichterungen greifen und wo nicht
DORA arbeitet mit Verhältnismäßigkeit. Größe, Risikoprofil und Komplexität der Dienstleistungen bestimmen, wie umfangreich die Umsetzung ausfallen muss. Für Kleinstunternehmen und bestimmte kleinere Finanzunternehmen sieht die Verordnung einen vereinfachten IKT-Risikomanagementrahmen vor.
Das ist eine echte Erleichterung, aber keine Befreiung. Auch im vereinfachten Rahmen bleiben die Kernpflichten bestehen: Vorfälle erkennen, klassifizieren und melden; Dienstleister vertraglich einbinden; ein Register führen. Was entfällt, ist vor allem der Detaillierungsgrad — nicht die Existenz der Prozesse.
Nicht verhältnismäßig skalierbar ist die Meldepflicht. Ein schwerwiegender Vorfall ist auch bei einem kleinen Institut ein schwerwiegender Vorfall. Wer die eigenen Schwellenwerte nicht vorab festgelegt hat, entscheidet unter Zeitdruck — und meldet im Zweifel zu spät.
Für IKT-Dienstleister lohnt sich eine nüchterne Einordnung. Sie fallen in der Regel nicht direkt unter die Verordnung, bekommen die Anforderungen aber über Verträge zugestellt: Prüfrechte, Meldefristen an den Kunden, Unterauftragnehmer-Transparenz, Mitwirkung an Tests. Wer den Finanzsektor beliefert und diese Klauseln pauschal ablehnt, verliert Ausschreibungen.
Warum es kein DORA-Zertifikat gibt
Dies ist der häufigste Irrtum bei DORA, und er kostet Geld. Es existiert kein Zertifizierungsschema, keine Akkreditierung und keine Stelle, die Konformität mit der Verordnung verbindlich bescheinigen könnte. Wenn ein Anbieter ein „DORA-Zertifikat” verkauft, verkauft er eine Bestätigung ohne aufsichtsrechtliche Wirkung.
Nachgewiesen wird stattdessen im Aufsichtsverhältnis: durch das Informationsregister, durch Berichte der internen Revision, durch Sonderprüfungen, durch Auskünfte an die Aufsicht und im Rahmen der Jahresabschlussprüfung. Der Adressat ist die Behörde, nicht der Markt.
Sinnvoll sind Zertifikate trotzdem — als Bausteine. Ein ISO-27001-Zertifikat belegt ein funktionierendes Informationssicherheits-Managementsystem und deckt weite Teile des IKT-Risikomanagements ab. Ein Zertifikat nach ISO 22301 belegt die Kontinuitätsplanung samt Übungen. Bei Cloud-Dienstleistern ist ein Prüfungstestat nach dem BSI-Kriterienkatalog C5 das gebräuchlichste Mittel, um die eigene Sorgfaltsprüfung abzukürzen. Der Ablauf einer solchen Zertifizierung ist der übliche und wird hier nicht wiederholt.
Der Unterschied bleibt: Diese Zertifikate belegen Teilbereiche. Sie ersetzen weder die Meldeprozesse noch das Register noch die Vertragsanpassungen.
Woran die Umsetzung scheitert
Das Register wird als IT-Aufgabe behandelt. Die Daten liegen im Einkauf, in der Rechtsabteilung und in den Fachbereichen. Wer das Informationsregister allein der IT überträgt, bekommt eine Liste von Systemen statt eine Liste von Verträgen.
Kritische und wichtige Funktionen sind nicht bestimmt. Fast jede Folgeanforderung — Ausstiegsstrategie, Testumfang, Vertragspflichten — hängt an dieser Einordnung. Ohne saubere Herleitung aus den Geschäftsprozessen ist sie angreifbar. Die Mechanik ist dieselbe wie bei der Business-Impact-Analyse: Die Kritikalität kommt aus dem Geschäft, nicht aus dem Systeminventar.
Meldeschwellen fehlen. Die Klassifizierungskriterien der Verordnung müssen in eigene, im Betrieb anwendbare Schwellen übersetzt werden. Sonst diskutiert der Krisenstab während des Vorfalls über Zuständigkeiten.
Altverträge bleiben unangetastet. Rahmenverträge mit mehrjähriger Laufzeit enthalten die geforderten Klauseln nicht. Nachverhandlungen dauern Monate und scheitern bei großen Anbietern häufig an deren Standardbedingungen — das ist ein Beschaffungsproblem, kein IT-Problem.
Tests ohne Programm. Einzelne Penetrationstests werden beauftragt, aber es gibt keine dokumentierte Planung, welche Systeme wann mit welcher Methode getestet werden und wie mit den Ergebnissen verfahren wird.
Die Auslagerungssteuerung läuft weiter wie bisher. Viele Häuser haben ihr Auslagerungsregister aus MaRisk-Zeiten und halten es für ausreichend. Der Zuschnitt ist ein anderer: DORA erfasst IKT-Dienstleistungen unabhängig davon, ob sie aufsichtsrechtlich als Auslagerung gelten.
Abgrenzung zu benachbarten Regelwerken
| Regelwerk | Rechtsnatur | Für wen | Verhältnis zu DORA |
|---|---|---|---|
| NIS2 | EU-Richtlinie, nationale Umsetzung erforderlich | Betreiber wichtiger und besonders wichtiger Einrichtungen in vielen Sektoren | DORA geht als spezielleres Recht vor; Finanzunternehmen richten sich nach DORA |
| ISO 27001 | Zertifizierbare Norm, freiwillig | Alle Organisationen | Liefert das Managementsystem, deckt aber Register, Meldewege und Tests nicht ab |
| ISO 22301 | Zertifizierbare Norm, freiwillig | Alle Organisationen | Deckt Kontinuität und Übungen ab, kennt keine aufsichtsrechtliche Meldepflicht |
| BSI C5 | Prüfungsstandard mit Testat | Cloud-Dienstleister | Hilfsmittel der Dienstleisterbewertung, kein Konformitätsnachweis für DORA |
| BAIT, VAIT, KAIT, ZAIT | Aufsichtliche Rundschreiben | Deutsche Finanzunternehmen | Mit dem Geltungsbeginn von DORA aufgehoben |
Die praktische Konsequenz: DORA ersetzt die frühere deutsche Sonderlage, hebt das Anforderungsniveau aber vor allem beim Drittparteienrisiko an. Wer BAIT sauber umgesetzt hatte, ist beim Risikomanagement gut aufgestellt und beim Informationsregister trotzdem am Anfang.