Praxisorientierte Einordnung zu DORA-Readiness-Check: Governance, Vorfälle, Tests und Drittparteien: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für DORA aufbauen.
Ein DORA-Readiness-Check sollte nicht fragen, ob alle verlangten Richtlinien vorhanden sind. Er muss zeigen, ob ein Finanzunternehmen seine kritischen oder wichtigen Funktionen auch bei IKT-Störungen beherrscht, schwerwiegende Vorfälle fristgerecht meldet, Kontrollen risikobasiert testet und IKT-Dienstleister einschließlich Unterauftragnehmern wirksam steuert. Seit 17. Januar 2025 ist DORA unmittelbar anwendbar; Readiness bedeutet daher belastbare Betriebs- und Aufsichtsfähigkeit.
Der Check verbindet die Verordnung (EU) 2022/2554 mit den delegierten und durchführenden Rechtsakten. Besonders relevant sind der technische Standard zum IKT-Risikomanagement, die Vorfallklassifizierung und -meldung, die Testanforderungen sowie die strukturierten Vorlagen des Informationsregisters. Die Prüfung wird proportional zur Finanzunternehmenskategorie und zum Risikoprofil gestaltet.
Das Ergebnis des Checks klar definieren
Ein Readiness-Bericht liefert vier Aussagen: Welche Anforderungen sind anwendbar? Welche Kontrollen sind wirksam umgesetzt? Welche Lücken gefährden kritische Funktionen oder Aufsichtspflichten? Welche Maßnahmen müssen mit welchem Termin und Verantwortlichen abgeschlossen werden?
Eine pauschale Prozentzahl reicht nicht. Eine fehlende Meldeentscheidung oder ein ungetesteter Exit kann trotz vieler erfüllter Dokumentenpunkte kritisch sein. Der Bericht trennt daher Design, Umsetzung, Wirksamkeit und regulatorische Dringlichkeit.
Prüffeld 1: Anwendungsbereich und Proportionalität
Zunächst werden Rechtsträger, Erlaubnistatbestand, Finanzunternehmenskategorie, zuständige Behörde und mögliche Ausnahmen bestimmt. Artikel 4 verlangt Proportionalität nach Größe, Risikoprofil sowie Art, Umfang und Komplexität der Dienstleistungen. Bestimmte Unternehmen nutzen den vereinfachten Rahmen nach Artikel 16.
Die Prüfung dokumentiert, warum der volle oder vereinfachte Rahmen gilt. Konzernvorgaben werden auf die einzelne beaufsichtigte Einheit heruntergebrochen. Gruppeninterne IKT-Leistungen bleiben als Drittparteienabhängigkeiten sichtbar.
Prüffeld 2: Kritische oder wichtige Funktionen
Das Unternehmen benötigt eine genehmigte Methodik zur Bestimmung kritischer oder wichtiger Funktionen. Kriterien umfassen Auswirkungen eines Ausfalls auf Leistung, Kunden, finanzielle Stabilität, Geschäftskontinuität und regulatorische Zulassung. Die Bewertung wird regelmäßig und bei wesentlichen Änderungen aktualisiert.
Stichproben prüfen, ob ausgewählte Funktionen vollständig mit Prozessen, Daten, IKT-Assets, Standorten, Personal und Dienstleistern verknüpft sind. Widersprüche zwischen Business-Impact-Analyse, Informationsregister, Vertragsklassifizierung und Testscope sind zentrale Findings.
Prüffeld 3: Verantwortung des Leitungsorgans
Das Leitungsorgan muss den IKT-Risikomanagementrahmen definieren, genehmigen, überwachen und verantworten. Geprüft werden Strategie, Risikotoleranz, Rollen, Budgets, Kontinuität, Auditplan, Drittparteienentscheidungen und regelmäßige Schulung.
Sitzungsunterlagen sollten Entscheidungen und kritische Nachfragen zeigen, nicht nur Kenntnisnahmen. Managementberichte verbinden Vorfälle, Kontrollwirkung, Testmängel, Konzentrationsrisiken und Maßnahmen mit den betroffenen Finanzfunktionen. Überfällige Hochrisikopunkte werden eskaliert.
Prüffeld 4: Drei Verteidigungslinien und Unabhängigkeit
Artikel 6 verlangt außerhalb der vorgesehenen Ausnahmen eine Kontrollfunktion für IKT-Risiko mit angemessener Unabhängigkeit. Risikomanagement, Kontrollfunktionen und interne Revision sollen entsprechend dem Drei-Linien-Modell oder einem geeigneten internen Modell getrennt sein.
Der Check betrachtet Berichtslinien, Ressourcen, Interessenkonflikte und Entscheidungsrechte. Eine kleine Organisation kann Funktionen proportional gestalten, muss aber Selbstprüfung und operative Verantwortung nachvollziehbar kontrollieren.
Prüffeld 5: IKT-Risikomanagementrahmen
Der Rahmen umfasst Strategien, Richtlinien, Verfahren, Protokolle und Werkzeuge zum Schutz von Informations- und IKT-Assets sowie physischer Infrastruktur. Er wird mindestens jährlich beziehungsweise bei vereinfachten Unternehmen periodisch überprüft und nach Vorfällen, Tests, Audits oder Aufsichtshinweisen verbessert.
Die Prüfung verfolgt ausgewählte Risiken vom Asset und Bedrohungsszenario über Bewertung und Maßnahme bis zum Restrisiko. Risikotoleranz, Kennzahlen und Genehmigungen müssen zusammenpassen. Registereinträge ohne operative Eigentümer oder Testbeleg gelten nicht als wirksam.
Prüffeld 6: Asset- und Informationsklassifizierung
Alle relevanten Informations- und IKT-Assets sowie ihre Abhängigkeiten werden identifiziert, klassifiziert und dokumentiert. Der technische Standard (EU) 2024/1774 verlangt auch im vereinfachten Rahmen eine Zuordnung zu kritischen oder wichtigen Funktionen.
Stichproben vergleichen CMDB, Cloudinventar, Netzwerk, Softwareverteilung, Verträge und reale Systeme. End-of-Life-Komponenten, unbekannte Schnittstellen und nicht erfasste SaaS-Dienste sind besonders kritisch. Änderungen müssen zeitnah in Inventar und Risikoanalyse ankommen.
Prüffeld 7: Schutz, Prävention und Change
Geprüft werden Zugriff, Kryptografie, Netzsicherheit, Konfiguration, Patchen, sichere Entwicklung, Projekt- und Change Management. Der delegierte Standard verlangt kontrollierte Aufzeichnung, Test, Bewertung, Genehmigung, Umsetzung und Verifikation von Änderungen.
Eine Stichprobe startet bei einem produktiven Change und prüft Sicherheitsanforderung, Test, Trennung, Rückfallplan und Freigabe. Notfalländerungen benötigen beschleunigte, aber nachvollziehbare Kontrollen und eine nachträgliche Bewertung.
Prüffeld 8: Erkennung und Incident Management
Finanzunternehmen müssen Anomalien, Netz- und Systemausfälle, Datenverlust und Hinweise auf schädliche Aktivität erkennen. Kritikalität der betroffenen Dienste beeinflusst die Reaktion. Alarmquellen, Schwellwerte, Betriebszeiten und Eskalationswege werden dokumentiert.
Der Check nutzt kontrollierte Tests: Wird ein verdächtiger privilegierter Zugriff erkannt? Kommt ein Dienstleisteralarm rechtzeitig an? Kann die Organisation Ursache, Reichweite und betroffene Funktion bestimmen? Ergebnisse messen Detektions- und Bewertungszeit.
Prüffeld 9: Vorfallklassifizierung und Meldung
Der Prozess bewertet die DORA-Kriterien für schwerwiegende IKT-bezogene Vorfälle. Dazu gehören betroffene Kunden und Gegenparteien, Dauer, geografische Ausbreitung, Datenverluste, Kritikalität der Dienste und wirtschaftliche Wirkung. Die zuständige Behörde erhält Meldungen im vorgeschriebenen Format.
Eine Simulation beginnt mit unvollständigen Informationen und verfolgt die regulatorische Uhr. Rollen für Klassifizierung, Freigabe, BaFin-Meldung, Aktualisierung und Abschlussbericht werden getestet. Parallele Datenschutz-, Straf- oder Kundenkommunikation wird koordiniert, ohne die DORA-Frist zu gefährden.
Prüffeld 10: IKT-Business-Continuity
Der technische Standard verlangt eine IKT-Kontinuitätsrichtlinie, die BIA, Aktivierungs- und Deaktivierungskriterien, Governance, Ressourcen, Szenarien, Wiederherstellungsziele und Krisenkommunikation verbindet. Pläne müssen mit der allgemeinen Geschäftskontinuität abgestimmt sein.
Der Check wählt eine kritische Funktion und prüft RTO, RPO, Abhängigkeiten, Personal, Backup, alternativen Standort und Drittanbieter. Ziele müssen fachlich genehmigt und technisch erreichbar sein. Widersprüche zwischen Vertrag, Architektur und BIA werden priorisiert.
Prüffeld 11: Backup, Restore und Wiederherstellung
Backups benötigen definierte Datenumfänge, Frequenzen, Schutz und Trennung. Wiederherstellungspläne berücksichtigen schwerwiegende, aber plausible Szenarien. Ein erfolgreicher Backupjob ist kein Beleg, dass eine Finanzfunktion fristgerecht wieder arbeitet.
Restore-Tests prüfen Datenintegrität, Identitäten, Schnittstellen und fachliche Verarbeitung. Umschaltung auf redundante Kapazität muss für ausreichende Zeit funktionieren; anschließend wird die Rückkehr zur Primärumgebung getestet. Findings gelangen an das Leitungsorgan.
Prüffeld 12: Allgemeines Resilienz-Testprogramm
Außer Mikro-Unternehmen benötigen Finanzunternehmen ein umfassendes, risikobasiertes Testprogramm. Alle Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, werden mindestens jährlich angemessen getestet. Methoden reichen von Scans bis zu Ende-zu-Ende- und Penetrationstests.
Die Prüfung betrachtet Abdeckung, Unabhängigkeit, Qualifikation, Produktionsnähe, Schutzmaßnahmen und Nachverfolgung. Findings werden priorisiert, behoben und intern validiert. Wiederholte Schwächen trotz formaler Schließung zeigen mangelnde Ursachenbehandlung.
Prüffeld 13: TLPT-Bereitschaft
Für von der Behörde identifizierte Finanzunternehmen ist Threat-Led Penetration Testing mindestens alle drei Jahre erforderlich. Der Readiness-Check bewertet, ob Scope, Threat Intelligence, Kontrollteam, Testerqualifikation, Geheimhaltung, Krisenabbruch und Dienstleisterbeteiligung vorbereitet sind.
Besonders schwierig sind ausgelagerte produktive Systeme. Verträge und operative Kontakte müssen die Teilnahme ermöglichen. Kann ein Dienstleister nicht teilnehmen, braucht das Finanzunternehmen eine mit der Behörde tragfähige Alternative; die Verantwortung bleibt bei ihm.
Prüffeld 14: IKT-Drittparteienstrategie
Das Unternehmen muss IKT-Drittparteienrisiko in den allgemeinen Rahmen integrieren. Geprüft werden Strategie, Rollen, Kritikalität, Konzentration, Genehmigung, laufende Überwachung und Bericht an das Leitungsorgan. Gruppeninterne Anbieter werden nicht unsichtbar gemacht.
Für eine Stichprobe wird der gesamte Lebenszyklus verfolgt: Bedarf, Ex-ante-Risikoanalyse, Due Diligence, Vertrag, Serviceüberwachung, Vorfall, Änderung und Exit. Eine Lieferantenbewertung ohne Bezug zur unterstützten Funktion ist nicht ausreichend.
Prüffeld 15: DORA-Vertragsanforderungen
Artikel 30 verlangt Mindestinhalte für sämtliche IKT-Verträge und erweiterte Inhalte bei Unterstützung kritischer oder wichtiger Funktionen. Dazu zählen Leistungsbeschreibung, Standorte, Datenzugang, Schutz, Unterstützung, Kündigung sowie vertiefte Service-, Audit-, Kontinuitäts- und Exit-Regelungen.
Der Check gleicht Vertragsklauseln mit der tatsächlichen Leistung ab. Audit- und Zugangsrechte müssen nutzbar sein, Unterauftragnehmer transparent und Exit-Fristen realistisch. Abweichungen werden nach Kritikalität remediert und nicht nur in einer Standardklausel überdeckt.
Prüffeld 16: Informationsregister und Datenqualität
Das Register enthält strukturierte Informationen zu allen IKT-Vertragsbeziehungen. Die technischen Vorlagen verbinden Rechtsträger, Funktionen, Verträge, Dienste, Anbieter, Unterauftragnehmer und Standorte. Es muss auf Einzel- und Gruppenebene konsistent sein.
Die Prüfung führt Validierungen gegen Kreditoren, Einkauf, Vertragsmanagement und Architektur durch. Fehlende Identifikatoren, widersprüchliche Funktionskritikalität und unbekannte Unterauftragnehmer werden quantifiziert. Verantwortliche pflegen Änderungen kontinuierlich statt nur vor Einreichung.
Prüffeld 17: Konzentrationsrisiko
DORA verlangt vor Vertragsabschluss eine Bewertung, ob mehrere kritische Funktionen von demselben oder schwer ersetzbaren Anbieter abhängen. Konzentration kann auf Anbieter-, Konzern-, Technologie-, Standort- oder Unterauftragnehmerebene entstehen.
Der Check aggregiert Registerdaten und modelliert Ausfallszenarien. Eine Multi-Cloud-Strategie reduziert Risiko nur, wenn Anwendungen, Identitäten und Daten tatsächlich übertragbar sind. Gleiche Unterauftragnehmer hinter verschiedenen Marken werden berücksichtigt.
Prüffeld 18: Exit-Fähigkeit
Exit-Strategien sollen den Wechsel oder die Beendigung ohne unangemessene Betriebsunterbrechung, Regelverstoß oder Qualitätseinbuße ermöglichen. Sie enthalten Auslöser, Zieloptionen, Datenportabilität, Übergangsunterstützung, Ressourcen und Zeitplan.
Ein Tabletop- oder technischer Test prüft Exportformat, Schlüssel, Dokumentation, Ersatzkapazität und Abhängigkeiten. Das Ergebnis wird gegen RTO und Geschäftsauswirkung bewertet. Ein Vertrag mit Exitklausel ohne realistische Alternative gilt nicht als einsatzbereit.
Prüffeld 19: Interne Revision und Findings
Der IKT-Risikomanagementrahmen ist regelmäßig unabhängig zu prüfen. Revision benötigt ausreichende IKT-Kompetenz, risikobasierten Auditplan und Zugang zu Dienstleisterinformationen. Managementmaßnahmen werden nachverfolgt.
Der Readiness-Check analysiert alte Findings auf Wiederholung, Fristverlängerung und Ursachen. Kritische Punkte dürfen nicht allein administrativ geschlossen werden. Ein Nachtest belegt die Wirksamkeit der Korrektur.
Bewertungsskala ohne Scheingenauigkeit
Für jedes Prüffeld werden Anwendbarkeit, Design, Umsetzung, Wirksamkeit und Evidenz separat bewertet. Status können „nicht vorhanden“, „konzipiert“, „teilweise umgesetzt“, „wirksam nachgewiesen“ oder „nicht anwendbar mit Begründung“ sein. Kritikalität und Maßnahmenfrist ergänzen die Bewertung.
Ein Gesamtwert wird nur zusammen mit Blockern gezeigt. Fehlende Vorfallmeldung, unvollständiges Register oder nicht getesteter Wiederanlauf können eine positive Gesamtbewertung verhindern, selbst wenn viele Policies existieren.
Ein kompakter Ablauf des Readiness-Checks
- Scope, Finanzunternehmenskategorie und anwendbare DORA-Rechtsakte festlegen.
- Kritische Funktionen und repräsentative End-to-End-Stichproben auswählen.
- Dokumente, Systeme, Verträge und Registerdaten prüfen.
- Vorfälle, Wiederherstellung, Test und Exit praktisch simulieren.
- Findings nach Funktionswirkung und Aufsichtsrisiko priorisieren.
- Nach kritischen Maßnahmen einen unabhängigen Nachtest durchführen.
Typische Scheinsicherheit
Häufig wird Readiness aus der Existenz von BAIT-, VAIT- oder ISO-Dokumenten abgeleitet. DORA verlangt jedoch spezifische Funktions-, Register-, Test- und Drittparteienbeziehungen. Ebenso schwach sind Register ohne laufende Datenpflege und Verträge ohne überprüfbare operative Rechte.
Ein anderer Fehler ist die Beschränkung auf interne IT. DORA umfasst gruppeninterne und externe IKT-Dienstleister sowie physische Komponenten. Die Prüfung muss den vollständigen Dienst über Organisationsgrenzen hinweg verfolgen.
Fazit: Readiness zeigt sich im End-to-End-Test
Ein Finanzunternehmen ist DORA-ready, wenn Governance, Risiko, Vorfall, Kontinuität, Tests und Drittparteiensteuerung für kritische Funktionen zusammenwirken. Der stärkste Nachweis ist eine kontrollierte Simulation, die technische Reaktion, Managemententscheidung, Meldung und Wiederherstellung verbindet.
BlackMount führt DORA-Readiness-Checks mit dokumentenbasierten und praktischen Prüfschritten durch. Das Ergebnis ist ein priorisierter Maßnahmenplan mit prüffähigen Evidenzen statt einer bloßen Compliance-Checkliste.
