Praxisorientierte Einordnung zu DORA umsetzen: Praxisfahrplan für Finanzunternehmen und IKT-Dienstleister: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für DORA aufbauen.
Der Digital Operational Resilience Act gilt seit dem 17. Januar 2025 unmittelbar in der Europäischen Union. Finanzunternehmen müssen ihre digitale operationale Resilienz nicht nur dokumentieren, sondern über Governance, IKT-Risikomanagement, Vorfallmeldung, Tests und Drittparteiensteuerung praktisch nachweisen. IKT-Dienstleister werden durch detaillierte Vertrags-, Informations- und Unterstützungsanforderungen einbezogen; als kritisch eingestufte Anbieter unterliegen zusätzlich der europäischen Überwachung.
Ein tragfähiger Umsetzungsfahrplan beginnt bei kritischen oder wichtigen Funktionen und deren IKT-Abhängigkeiten. Von dort werden Governance, Kontrollen, Meldung, Tests, Informationsregister und Exit-Fähigkeit aufgebaut. Wer DORA als Sammlung isolierter Policies behandelt, übersieht die geforderte Verbindung zwischen Dienst, System, Risiko, Anbieter und Widerstandsfähigkeit.
Wer DORA anwenden muss
Artikel 2 erfasst zahlreiche Arten von Finanzunternehmen, darunter Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherungsunternehmen, Einrichtungen der betrieblichen Altersversorgung, Fondsverwalter, Krypto-Dienstleister und weitere Marktinfrastrukturen. Für einzelne Kategorien gelten Ausnahmen oder vereinfachte Anforderungen.
Die Betroffenheitsanalyse ordnet jeden Rechtsträger seiner beaufsichtigten Kategorie, zuständigen Behörde und Proportionalitätsregel zu. Gruppenstrukturen ändern nicht die Verantwortung des einzelnen Finanzunternehmens. Gemeinsame Konzernservices werden als IKT-Dritt- oder gruppeninterne Abhängigkeiten transparent erfasst.
DORA und NIS2 nicht doppelt umsetzen
DORA gilt für die erfassten Finanzunternehmen als sektorspezifischer Unionsrechtsakt im Sinne von Artikel 4 NIS2. Die Europäische Kommission stellt klar, dass DORA-Regeln zu IKT-Risikomanagement, Vorfällen, Tests, Informationsaustausch und IKT-Drittparteirisiko anstelle der entsprechenden NIS2-Pflichten gelten, soweit die Voraussetzungen erfüllt sind.
Das bedeutet keine allgemeine Befreiung von jedem nationalen Sicherheitsrecht. Andere Tätigkeiten, kritische Anlagen oder nicht von DORA erfasste Konzerngesellschaften können weiterhin unter das BSI-Gesetz fallen. Eine Scope-Matrix verhindert Doppelarbeit und unbeabsichtigte Lücken.
Phase 1: Governance und Managementverantwortung
Artikel 5 überträgt dem Leitungsorgan die Verantwortung für das IKT-Risiko. Es genehmigt Rollen, Strategie, Risikotoleranz, Kontinuität, Auditpläne und wesentliche Drittparteienregelungen. Mitglieder müssen ihr Wissen aktuell halten und regelmäßig angemessene Schulungen absolvieren.
Der Umsetzungsstart umfasst ein Governance-Mandat, klare Entscheidungsrechte und einen Berichtskalender. Kennzahlen verbinden technische Lage mit Auswirkungen auf Finanzdienstleistungen. Die Leitung erhält etwa kritische Ausfälle, Restrisiken, Testmängel, Drittparteienkonzentration und überfällige Maßnahmen.
Phase 2: IKT-Risikomanagementrahmen aufbauen
Artikel 6 verlangt einen soliden, umfassenden und gut dokumentierten Rahmen als Teil des Gesamtrisikomanagements. Er umfasst Strategien, Richtlinien, Verfahren, Protokolle und Werkzeuge zum Schutz von Informations- und IKT-Assets sowie relevanter physischer Infrastruktur.
Der Rahmen wird mindestens jährlich überprüft, bei Mikro-Unternehmen periodisch, außerdem nach wesentlichen Vorfällen, Aufsichtshinweisen, Tests oder Audits. Verbesserungen werden aus Betrieb und Kontrollergebnissen abgeleitet. Ein Bericht über die Überprüfung muss auf Anfrage vorgelegt werden können.
Phase 3: Kritische oder wichtige Funktionen identifizieren
DORA knüpft viele vertiefte Pflichten an „critical or important functions“. Das Finanzunternehmen beschreibt Leistungen, deren Ausfall die finanzielle Leistungsfähigkeit, Fortführung, Zulassung oder Kundenversorgung wesentlich beeinträchtigen würde. Die Beurteilung ist fachlich und nicht nur technisch.
Jede Funktion wird mit Prozessen, Informationswerten, Anwendungen, Infrastruktur, Standorten, Personal und IKT-Dienstleistern verknüpft. Diese Karte trägt Risikobewertung, Testplanung, Vertragsklassifizierung, Informationsregister und Exit-Strategien.
Phase 4: IKT-Assets und Abhängigkeiten inventarisieren
Ein vollständiges Inventar umfasst Hardware, Software, Daten, Schnittstellen, Netzwerkressourcen, Cloud-Services, End-of-Life-Status und Verantwortliche. Veränderungen werden nachvollziehbar gepflegt. Verborgene gruppeninterne Dienste und Unterauftragnehmer sind ebenso relevant wie externe Cloudanbieter.
Stichproben gleichen CMDB, Netzsicht, Beschaffung, Vertragsregister und realen Betrieb ab. Kritische Datenflüsse und Einzelfehler werden sichtbar. Ohne diese Basis bleiben Schwachstellenmanagement, Tests und Vorfallauswirkungsanalyse unzuverlässig.
Phase 5: Schutz und Prävention operationalisieren
Der Rahmen umfasst Zugriffskontrolle, Kryptografie, Konfigurationsmanagement, Patchen, Segmentierung, physische Sicherheit, sichere Entwicklung und Change Management. Kontrollen werden proportional zu Risiko und Kritikalität ausgestaltet. Ausnahmen sind befristet und genehmigt.
Für jede zentrale Kontrolle werden Sollzustand, technische Umsetzung und Wirksamkeitsnachweis definiert. Beispielsweise belegt privilegierter Zugriff nicht nur eine Policy, sondern starke Authentisierung, zeitlich begrenzte Rechte, Sitzungsprotokollierung und periodische Negativtests.
Phase 6: Erkennung und Überwachung verbessern
Finanzunternehmen müssen Anomalien und IKT-bezogene Vorfälle erkennen. Dazu werden geeignete Datenquellen, Schwellen, Erkennungsfälle und Verantwortlichkeiten definiert. Die Überwachung umfasst interne Systeme und relevante Dienstleisterbeziehungen.
Erkennungsqualität wird durch Simulationen gemessen. Wichtige Kennzahlen sind Abdeckung, Zeit bis zur Erkennung, Fehlalarme und Zeit bis zur qualifizierten Bewertung. Ein zentraler Alarm ohne besetzte Reaktionsfunktion schafft keine Resilienz.
Phase 7: Business Continuity und Recovery verbinden
DORA verlangt IKT-Kontinuität, Reaktions- und Wiederherstellungspläne sowie geeignete Backupverfahren. Ziele orientieren sich an Geschäftsfolgen und kritischen Funktionen. Abhängigkeiten zwischen Anwendungen, Daten, Identitäten und Drittanbietern müssen in der Wiederanlaufreihenfolge berücksichtigt werden.
Restore- und Krisentests prüfen nicht nur Technik, sondern die Erbringung der Finanzdienstleistung. Testszenarien umfassen Cyberangriff, Cloudausfall, Datenkorruption und Kommunikationsverlust. Ergebnisse führen zu konkreten Verbesserungen und aktualisierten Plänen.
Phase 8: IKT-Vorfälle klassifizieren und melden
Artikel 17 bis 23 verlangen einen Managementprozess zur Erkennung, Behandlung und Klassifizierung IKT-bezogener Vorfälle. Kriterien umfassen betroffene Kunden oder Gegenparteien, Dauer, geografische Verbreitung, Datenverluste, Kritikalität betroffener Dienste und wirtschaftliche Auswirkungen.
Schwerwiegende Vorfälle werden über die zuständige Behörde gemeldet. Die Durchführungsverordnung (EU) 2025/302 konkretisiert Formate und Fristen. In Deutschland fungiert die BaFin als nationaler Melde-Hub für beaufsichtigte Finanzunternehmen. Datenschutz-, Straf- und Kundenkommunikation werden parallel koordiniert.
Phase 9: Meldeprozess praktisch testen
Ein Incident-Playbook ordnet Schwellen, Entscheidung, Datenfelder, Freigabe und Vertretung. Die Organisation muss aus begrenzten Anfangsinformationen fristgerecht melden und später aktualisieren können. Ausgelagerte Meldung entbindet nicht von Verantwortung.
Eine Tabletop-Übung misst, wann Kenntnis entsteht, wer den Vorfall klassifiziert und ob Pflichtfelder verfügbar sind. Ein simuliertes Ereignis bei einem gemeinsamen Cloudanbieter prüft zugleich Aggregation, Dienstleisterkommunikation und Mehrfachbetroffenheit.
Phase 10: Testprogramm für digitale Resilienz
Artikel 24 verlangt für Finanzunternehmen außerhalb der Mikro-Unternehmensausnahme ein solides, umfassendes Testprogramm. Es kombiniert verschiedene Bewertungen und Tests risikobasiert. Alle IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, sind mindestens jährlich angemessen zu testen.
Das Programm führt Inventar, Kritikalität, Bedrohungen, Änderungen und frühere Findings zusammen. Methoden reichen von Schwachstellenanalyse und Codeprüfung über Szenario-, Leistungs- und Ende-zu-Ende-Tests bis zu Penetrationstests. Unabhängigkeit und Interessenkonflikte werden kontrolliert.
Phase 11: TLPT-Anforderungen vorbereiten
Bestimmte von der zuständigen Behörde identifizierte Finanzunternehmen müssen mindestens alle drei Jahre Threat-Led Penetration Testing durchführen. Der Test umfasst produktive Systeme, Prozesse und Technologien, die kritische oder wichtige Funktionen unterstützen, und kann relevante IKT-Drittdienstleister einbeziehen.
Vorbereitung umfasst Scope, Threat Intelligence, Testerqualifikation, Kontrollteam, Schutzmaßnahmen, Krisenabbruch und Behandlung von Findings. Auch bei Beteiligung eines Dienstleisters bleibt das Finanzunternehmen für die DORA-Compliance verantwortlich.
Phase 12: IKT-Drittparteienrisiko über den Lebenszyklus steuern
Artikel 28 bis 30 verlangen, Drittparteienrisiko als Bestandteil des IKT-Risikos zu behandeln. Vor Vertragsabschluss werden Kritikalität, Abhängigkeit, Konzentration, Standort, Unterauftragnehmer, Sicherheitsniveau und Exit bewertet. Die BaFin betont Ex-ante-Risikobewertung und Due Diligence.
Während der Laufzeit werden Leistung, Vorfälle, Änderungen und Kontrollnachweise überwacht. Bei Vertragsende muss die Funktion ohne unangemessene Unterbrechung oder Qualitätsverlust übertragbar sein. Ein Papier-Exit ohne getestete Datenportabilität und Ersatzkapazität ist unzureichend.
Phase 13: Verträge DORA-konform gestalten
Verträge müssen klare Leistungsbeschreibungen, Standorte, Datenzugang, Verfügbarkeit, Integrität, Vertraulichkeit, Unterstützung bei Vorfällen, Kündigung und weitere Mindestinhalte enthalten. Für Dienste, die kritische oder wichtige Funktionen unterstützen, gelten erweiterte Regelungen zu Leistungszielen, Meldung, Kontinuität, Audit und Exit.
Das Unternehmen führt eine Klauselmatrix und priorisiert Verträge nach Kritikalität. Neben der Unterschrift wird geprüft, ob Rechte praktisch nutzbar sind. Ein Auditrecht ohne Zugang zu geeigneten Berichten oder ein Exit ohne technische Exportmöglichkeit erfüllt seinen Zweck nicht.
Phase 14: Informationsregister aufbauen
Artikel 28 Absatz 3 verpflichtet Finanzunternehmen, ein Register aller vertraglichen Vereinbarungen über IKT-Dienstleistungen zu führen. Technische Standards definieren strukturierte Vorlagen und Beziehungen zwischen Unternehmen, Funktionen, Verträgen, Diensten und Anbietern.
Datenqualität erfordert Eigentümer, Validierungsregeln und Abgleich mit Einkauf, Kreditoren, Architektur und Vertragsablage. Gruppenmeldungen benötigen konsistente Identifikatoren und Hierarchien. Das Register ist nicht nur eine Aufsichtsdatei, sondern Grundlage für Konzentrationsanalyse und kritische Anbieterüberwachung.
Phase 15: Kritische IKT-Drittdienstleister richtig einordnen
Nicht jeder Cloudanbieter ist automatisch kritischer IKT-Drittdienstleister. Die europäischen Aufsichtsbehörden bewerten Anbieter anhand gesetzlicher Kriterien und Informationsregister und benennen kritische Anbieter im Einzelfall. Für diese entsteht ein europäischer Lead-Overseer.
Die Überwachung des Anbieters ersetzt nicht das eigene Drittparteienmanagement des Finanzunternehmens. Vertrag, Risiko, Kontrolle und Exit bleiben in seiner Verantwortung. Umgekehrt sollten IKT-Dienstleister auch ohne formelle Kritikalität DORA-fähige Informationen und Prozesse bereitstellen.
Phase 16: Informationsaustausch nutzen
DORA ermöglicht Finanzunternehmen, Cyberbedrohungsinformationen in vertrauenswürdigen Gemeinschaften auszutauschen. Governance, Vertraulichkeit, Datenschutz und Zweck müssen geregelt sein. Erkenntnisse sollen in Erkennung, Risikoanalyse und Schutzmaßnahmen einfließen.
Ein reiner Empfang von Warnmeldungen genügt nicht. Verantwortliche bewerten Relevanz, passen Indikatoren an, verfolgen Maßnahmen und teilen geeignete Erkenntnisse zurück. Wirkung wird über erkannte Risiken und verbesserte Reaktionszeit gemessen.
Ein 180-Tage-Verbesserungsfahrplan
- Bis Tag 30 Betroffenheit, Governance, kritische Funktionen und Aufsichtswege bestätigen.
- Bis Tag 60 IKT-Assets, Dienstleister, Risiken und bestehende Kontrollnachweise konsolidieren.
- Bis Tag 90 Vorfallklassifizierung, Meldung, Kontinuität und jährliches Testprogramm üben.
- Bis Tag 120 Verträge und Informationsregister nach Kritikalität bereinigen.
- Bis Tag 150 Exit- und Konzentrationsrisiken sowie TLPT-Bereitschaft bewerten.
- Bis Tag 180 unabhängige Readiness-Prüfung und Managemententscheidung durchführen.
Was IKT-Dienstleister vorbereiten sollten
Dienstleister benötigen eine eindeutige Leistungs- und Unterauftragnehmerstruktur, belastbare Sicherheits- und Kontinuitätsnachweise, Incident-Unterstützung, Auditfähigkeit und exportierbare Registerdaten. Vertriebszusagen müssen zum realen Betriebsmodell passen.
Besonders wichtig sind schnelle Kundeninformation, abgestimmte Klassifizierungsdaten und die Fähigkeit, mehrere betroffene Finanzunternehmen parallel zu unterstützen. Exit und Datenrückgabe werden technisch geplant. Eine Zertifizierung kann Evidenz liefern, ersetzt aber keine DORA-spezifische Vertrags- und Informationspflicht.
Typische Umsetzungsfehler
Häufig werden vorhandene BAIT-, VAIT- oder ISO-Dokumente nur umbenannt, ohne kritische Funktionen und DORA-Datenmodell zu verknüpfen. Andere Programme behandeln das Informationsregister als jährliche Tabellenübung und verlieren Änderungen während des Jahres.
Weitere Fehler sind ungeprüfte Auditklauseln, fehlende Exit-Tests, technische Tests ohne fachliche Dienstwirkung und Vorfallprozesse ohne regulatorische Zeitmessung. Ein wirksames Programm prüft den End-to-End-Ablauf.
Fazit: DORA verlangt nachweisbare Betriebsfähigkeit
DORA verbindet Managementverantwortung, IKT-Kontrollen, Vorfallmeldung, Testen und Drittparteiensteuerung zu einem Resilienzmodell. Erfolg zeigt sich nicht an der Zahl neuer Policies, sondern daran, ob kritische Finanzfunktionen auch bei Angriff, Ausfall oder Anbieterproblem kontrolliert fortgeführt und wiederhergestellt werden.
BlackMount unterstützt Finanzunternehmen und IKT-Dienstleister bei der DORA-Umsetzung von kritischen Funktionen und Governance bis zu Tests, Informationsregister, Vertragsremediation und Exit-Fähigkeit.
