DORA-Bereitschaft für Finanzunternehmen und ihre IKT-Dienstleister

DORA gilt seit dem 17. Januar 2025. Für Finanzunternehmen bedeutet Bereitschaft heute, ein Betriebsmodell für digitale operationale Resilienz aufrechtzuerhalten, nicht sich auf eine künftige Frist vorzubereiten. Für Technologielieferanten bedeutet sie, die Verantwortlichkeiten gegenüber Kunden zu verstehen und zu klären, ob ein eigenständiger direkter Überwachungsrahmen gilt.

Die Frage an die Leitung ist praktischer Natur: Kann die Organisation erklären, welche Finanzdienstleistungen von welchen IKT-Systemen abhängen, wie mit Störungen umgegangen wird und welche Nachweise ihre Annahmen zur Wiederherstellung stützen? Richtlinien sind wichtig, können diese Frage aber nicht allein beantworten. Die Leitung braucht eine zusammenhängende Sicht auf Verantwortlichkeiten, Abhängigkeiten, Verträge, Tests, Vorfälle und offene Risiken.

Bestimmen Sie Ihre Rolle, bevor Sie die Checkliste erstellen

Beginnen Sie mit einer dokumentierten Anwendbarkeitsentscheidung für jede relevante juristische Person. Artikel 2 DORA nennt die erfassten Kategorien und Ausnahmen. Ein Unternehmen, das sich als FinTech, Start-up oder KMU bezeichnet, ist nicht automatisch erfasst oder ausgenommen.

Beispiele für erfasste Finanzunternehmen sind Kreditinstitute, Zahlungsinstitute, Wertpapierfirmen und Versicherungsunternehmen, vorbehaltlich der detaillierten Regeln zum Anwendungsbereich der Verordnung. Dokumentieren Sie die anwendbare Kategorie, etwaige Ausnahmen oder Befreiungen, die zuständige Behörde und die Begründung Ihres Ergebnisses.

Unterscheiden Sie bei Lieferanten drei Positionen:

Ein Lieferant, der eine kritische oder wichtige Funktion eines Finanzunternehmens unterstützt, ist allein deshalb noch kein benannter kritischer IKT-Drittdienstleister. Finanzunternehmen bewerten die Bedeutung ihrer Funktionen und Abhängigkeiten; die Benennung kritischer Dienstleister erfolgt über den Aufsichtsrahmen nach Artikel 31.

Der Standort klärt die Frage für Lieferanten nicht. Ein Cloud- oder Softwareanbieter mit Sitz in den USA kann DORA-bezogenen Kundenanforderungen unterliegen, wenn er Finanzunternehmen in der EU bedient. Diese geschäftliche Beziehung unterwirft ihn aber nicht automatisch jeder Pflicht, die für ein Finanzunternehmen gilt.

Auch die Verhältnismäßigkeit erfordert eine begründete Bewertung. Artikel 4 berücksichtigt Faktoren wie Größe, Gesamtrisikoprofil sowie Art, Umfang und Komplexität der Dienstleistungen. Artikel 16 sieht für bestimmte Kategorien einen vereinfachten IKT-Risikomanagementrahmen vor. Diese Konzepte sind nicht austauschbar, und der gewöhnliche KMU-Status ist keine allgemeine Abkürzung. Halten Sie die Prüfung der Voraussetzungen zusammen mit der Entscheidung zum Anwendungsbereich fest.

Machen Sie die Verantwortung der Leitung sichtbar

Nach Artikel 5 DORA trägt das Leitungsorgan die endgültige Verantwortung für das Management der IKT-Risiken des Finanzunternehmens. Die Delegation der Umsetzung an einen CISO, ein Technologieteam oder einen externen Dienstleister überträgt diese Verantwortung nicht.

Die Leitung sollte festlegen, wer Entscheidungen vorschlägt, wer sie freigibt und wer prüft, ob die Umsetzung funktioniert. Das Betriebsmodell sollte Geschäftsfortführung, Reaktion auf Vorfälle und Wiederherstellung, Drittparteienvereinbarungen, Budget und das für eine wirksame Aufsicht nötige Wissen abdecken.

Eine praktische Empfehlung ist, der Leitung ein entscheidungsorientiertes Berichtspaket statt eines Dashboards mit prozentualem Erfüllungsgrad vorzulegen. Es sollte enthalten:

• Kritische oder wichtige Funktionen mit ungetesteten Wiederherstellungsannahmen.
• Schwerwiegende Vorfälle, Auswirkungen auf Kunden und offene Korrekturmaßnahmen.
• Lieferantenabhängigkeiten mit unvollständigen Verträgen oder schwachen Ausstiegsoptionen.
• Wesentliche Lücken bei Maßnahmen, verantwortliche Personen und Termine für die Behebung.
• Entscheidungen, die Finanzierung, einen Lieferantenwechsel oder eine ausdrückliche Risikoreaktion erfordern.

Jede Lücke sollte die regulatorische Anforderung, die aktuelle betriebliche Schwäche und die vorgeschlagene Abhilfe unterscheiden. Ein fehlender Freigabevermerk ist etwas anderes als eine Datensicherung, die sich nicht wiederherstellen lässt. Beides kann Handeln erfordern, aber mit unterschiedlichen Verantwortlichen und Prioritäten.

Die Freigabe eines Behebungsplans durch die Leitung ist keine Erlaubnis, anwendbare Pflichten auf unbestimmte Zeit aufzuschieben. Bei einer wesentlichen Lücke sollten neben der langfristigen Lösung sofortige Schutzmaßnahmen, Eskalation und mögliche aufsichtliche Folgen geprüft werden.

Richten Sie das Programm an den Finanzfunktionen aus

Ein Inventar der Werte ist notwendig, doch die Resilienzplanung sollte mit der Dienstleistung beginnen, die weiterlaufen muss. Ermitteln Sie die Finanzfunktion, die fachlich verantwortliche Person, die Folgen einer Störung sowie die unterstützenden Systeme und Dienstleister.

Erfassen Sie für einen Zahlungsdienst Identität, Cloud-Infrastruktur, Transaktionsverarbeitung, Überwachung und Eskalation beim Lieferanten. Berücksichtigen Sie weniger sichtbare Abhängigkeiten wie DNS, Konnektivität, privilegierte Zugriffe, Verschlüsselungsschlüssel und Support-Werkzeuge. Eine alternative Produktivumgebung kann unbrauchbar sein, wenn sie vom selben ausgefallenen Identitätsdienst abhängt.

Die daraus entstehende Übersicht sollte jede Funktion verbinden mit:

• Unterstützenden Anwendungen, Infrastruktur, Informationswerten und externen Diensten.
• Relevanten Verträgen und Dienstverantwortlichen.
• Wiederherstellungszielen und der Business-Impact-Analyse, die sie begründet.
• Regelungen zu Erkennung, Reaktion, Wiederherstellung und Kommunikation.
• Tests, Feststellungen und offenen Abhängigkeitsrisiken.

Validieren Sie die Übersicht gemeinsam mit Betriebs- und Fachteams. Beschaffungsunterlagen zeigen, was gekauft wurde; sie zeigen nicht unbedingt, wie ein Dienst heute funktioniert.

Nutzen Sie dieses Modell, um IKT-Risikomanagement, Behandlung und Meldung von Vorfällen, Resilienztests und IKT-Drittparteienrisiken zu ordnen. DORA enthält außerdem Bestimmungen zum freiwilligen Austausch von Informationen über Cyberbedrohungen. Legen Sie bei einer Teilnahme Mitgliedschaft, Vertraulichkeit, zulässige Verwendung und Handhabungsregeln fest, statt den Austausch als unbeschränkte Weitergabe von Vorfalldaten zu behandeln.

Machen Sie das IKT-Risikomanagement zu finanzierter Arbeit

Die Bestimmungen von DORA zum IKT-Risikomanagement umfassen Identifizierung, Schutz und Prävention, Erkennung, Reaktion und Wiederherstellung, Lernen sowie Kommunikation. Der Rahmen muss diese Tätigkeiten verbinden, statt sie als getrennte Richtliniensammlungen stehen zu lassen.

Beginnen Sie die Lückenanalyse mit den erfassten Funktionen. Fragen Sie, ob Zugriffskontrollen ihre Systeme schützen, Schwachstellen behoben werden, Änderungen gesteuert werden, verdächtige Aktivitäten erkannt werden und die Wiederherstellungsregelungen realistische Ausfälle abbilden. Berücksichtigen Sie neben böswilligen Angriffen auch technische Fehler und Bedienfehler.

Legen Sie für jede wesentliche Schwäche einen Behebungseintrag mit verantwortlicher Person, geschäftlicher Auswirkung, erforderlicher Maßnahme, Abschlusskriterien und Nachweis des Abschlusses an. Abhängigkeiten sind wichtig: Eine Verbesserung der Wiederherstellungsverfahren kann Änderungen am Zugriff auf Datensicherungen, an Lieferantenzusagen und an der Schulung der Mitarbeitenden erfordern, bevor ein erfolgreicher Test möglich ist.

Wiederherstellungsziele sollten sich aus geschäftlichen Anforderungen und der Auswirkungsanalyse ergeben, nicht aus dem, was das Standard-Service-Level eines Anbieters zufällig bietet. Kann die technische Fähigkeit das Ziel nicht erreichen, muss die Leitung entscheiden, ob die Architektur verbessert, die Leistungsvereinbarung geändert oder das Betriebsmodell überdacht wird. Ein in einem Notfallplan festgehaltenes Ziel ist kein Nachweis der Wiederherstellbarkeit.

Bereiten Sie Entscheidungen zu Vorfällen vor der Störung vor

DORA verlangt von Finanzunternehmen, IKT-bezogene Vorfälle zu behandeln und schwerwiegende Vorfälle der zuständigen Behörde zu melden. Die Artikel 17 bis 23 bilden den Rahmen; die anwendbaren technischen Regulierungs- und Durchführungsstandards enthalten die detaillierten Klassifizierungskriterien, Schwellenwerte, Meldeinhalte und Verfahren.

Verlassen Sie sich beim detaillierten Meldezeitplan nicht auf eine allgemeine Vorfallcheckliste. Pflegen Sie eine aktuelle Meldematrix mit den anwendbaren Standards, Vorgaben der Behörde, Übermittlungskanal, Meldestufen und Fristberechnungen. Weisen Sie die Verantwortung für ihre Aktualisierung zu.

Der Reaktionsprozess sollte mehrere Entscheidungen unter Druck umsetzbar machen:

• Wer dokumentiert die Zeitpunkte von Erkennung, Bewertung und Klassifizierung?
• Wer holt Informationen zu den Auswirkungen beim Betrieb und bei Lieferanten ein?
• Wer entscheidet, ob die Kriterien für einen schwerwiegenden Vorfall erfüllt sind?
• Wer gibt Meldungen frei und übermittelt sie, auch außerhalb der regulären Arbeitszeiten?
• Wer übernimmt die Kommunikation mit Kunden und andere anwendbare Benachrichtigungen?

Dokumentieren Sie die Begründung der Klassifizierung auch dann, wenn ein Vorfall nicht als schwerwiegend gemeldet wird. Ein unvollständiges erstes Bild sollte eine erneute Bewertung auslösen, sobald neue Informationen vorliegen, statt dauerhaft anzunehmen, das Ereignis sei geringfügig.

Die Benachrichtigungszusagen von Lieferanten sollten dem Finanzunternehmen genug Zeit lassen, seine eigenen Pflichten zu bewerten und zu erfüllen. Meldeaufgaben können, soweit zulässig, ausgelagert werden, die Verantwortung bleibt jedoch beim Finanzunternehmen.

Wirkt sich ein schwerwiegender IKT-bezogener Vorfall auf die finanziellen Interessen von Kunden aus, verlangt DORA, dass Finanzunternehmen diese Kunden unverzüglich über den Vorfall und die zur Minderung seiner nachteiligen Auswirkungen ergriffenen Maßnahmen informieren. Prüfen Sie Pflichten bei Verletzungen des Schutzes personenbezogener Daten und andere anwendbare Vorschriften gesondert. Eine einzige Störung kann mehrere Meldeentscheidungen mit unterschiedlichen Empfängern und rechtlichen Kriterien auslösen.

Testen Sie die Annahmen, auf die sich die Leitung verlässt

Ein Programm zum Testen der digitalen operationalen Resilienz sollte verhältnismäßig und risikobasiert sein. Schwachstellenbewertungen, Szenarioübungen, Sicherheitstests und Wiederherstellungstests beantworten unterschiedliche Fragen; keiner davon sollte als allgemeiner Ersatz für die anderen gelten.

Eine Planspielübung kann zeigen, ob Entscheidungsträger die Eskalation verstehen. Sie kann nicht beweisen, dass Transaktionsdaten korrekt wiederhergestellt werden können. Ein Penetrationstest kann ausnutzbare Schwachstellen aufdecken, ohne zu beweisen, dass ein alternativer Lieferant einen Dienst übernehmen kann.

Legen Sie für jeden Test Funktion, Szenario, Umfang, Erfolgskriterien, gegebenenfalls erforderliche Regelungen zur Unabhängigkeit und erwartete Nachweise fest. Bewahren Sie Ergebnisse, Feststellungen, Behebungsentscheidungen und die Ergebnisse von Wiederholungstests auf. Prüfen Sie die anwendbaren Anforderungen an Abdeckung und Häufigkeit anhand von DORA und den einschlägigen Standards, einschließlich etwaiger Ausnahmen oder Bestimmungen zum vereinfachten Rahmen.

Bedrohungsorientierte Penetrationstests (TLPT) sind nach Artikel 26 eine eigenständige aufsichtliche Anforderung für ausgewählte Finanzunternehmen. Sie sind keine pauschale Pflicht für jedes Finanzunternehmen oder jeden IKT-Lieferanten.

Die Leitung sollte widerlegte Annahmen prüfen, nicht nur, ob Tests stattgefunden haben. Zeigt eine Übung, dass die Wiederherstellung von einer einzigen nicht verfügbaren Administratorin abhängt, ist das Ergebnis ein betriebliches Risiko, das Handeln erfordert, kein abgeschlossener Testmeilenstein.

Behandeln Sie Drittparteienrisiken als Frage der Dienstfortführung

Nach DORA bleibt ein Finanzunternehmen für seine Pflichten verantwortlich, wenn es IKT-Dienstleister nutzt. Die Artikel 28 bis 30 verbinden die Bewertung von Drittparteienrisiken, vertragliche Vereinbarungen, Überwachung und Ausstiegsplanung.

Führen Sie das Register und das betriebliche Gesamtbild

Finanzunternehmen müssen ein Informationsregister über vertragliche Vereinbarungen zu IKT-Dienstleistungen auf Einzel-, teilkonsolidierter und konsolidierter Ebene führen, soweit gefordert. Verwenden Sie für die Struktur die anwendbaren Durchführungsstandards. Eine Beschaffungstabelle oder eine Liste genehmigter Anbieter genügt nicht automatisch.

Gleichen Sie das Register mit Verträgen, Dienstverantwortung und Abhängigkeitsübersichten ab. Halten Sie die geforderten Unterscheidungen für Dienstleistungen fest, die kritische oder wichtige Funktionen unterstützen. Ein neuer Unterauftragnehmer, ein neuer Leistungsort oder ein erweiterter Umfang kann das Risikobild verändern, auch wenn der Name des Lieferanten gleich bleibt.

Prüfen Sie Verträge anhand der tatsächlichen Leistung

Bewerten Sie die anwendbaren vertraglichen Anforderungen, darunter Leistungsbeschreibungen, Standorte, Datenschutz, Zugang zu und Wiederherstellung von Daten, Unterstützung bei Vorfällen, Mitwirkung, Kündigungsrechte und Service-Levels. Vereinbarungen zur Unterstützung kritischer oder wichtiger Funktionen erfordern zusätzliche Bestimmungen, darunter relevante Regelungen zu Berichterstattung, Fortführung, Zugang, Inspektion, Prüfung und Ausstieg.

Recht, Einkauf, Technologie und Fachbereich sollten diese gemeinsam prüfen. Ein vertragliches Prüfrecht kann in der Praxis schwer auszuüben sein; eine zugesagte Wiederherstellungsregelung deckt womöglich nicht die gesamte Leistungskette des Kunden ab. Ermitteln Sie solche Grenzen, bevor Sie die Vereinbarung akzeptieren.

Untersuchen Sie Konzentration und Ausstiegsfähigkeit

Konzentrationsrisiko beschränkt sich nicht darauf, mehrere Dienste bei einem Unternehmen zu kaufen. Verschiedene Lieferanten können auf dieselbe Cloud-Plattform, Region, dasselbe Netzwerk oder denselben Unterauftragnehmer angewiesen sein. Bewerten Sie Ersetzbarkeit, Migrationsaufwand und die Folgen eines gemeinsamen Ausfalls.

Ein Ausstiegsplan sollte Datenformate, Extraktion, Zugriff, Migrationsabhängigkeiten, Übergangsunterstützung, Löschung und die Fortführung während des Wechsels behandeln. Behandeln Sie bei kritischen oder wichtigen Funktionen das Testen und Überprüfen des Ausstiegs als inhaltliche Arbeit, nicht als Schreibübung.

Lieferanten können ein einheitliches Nachweispaket mit Leistungsumfang, Verantwortungsgrenzen, Kontakten für Vorfälle, Nachweisen zur Fortführung, Informationen zu Unterauftragsvergaben und Vertragspositionen vorbereiten. Kundenspezifische Anforderungen müssen dennoch geprüft werden; ein Zertifikat ersetzt sie nicht.

Verstehen Sie, wo DORA und NIS2 sich treffen

DORA ist eine unmittelbar geltende EU-Verordnung. NIS2 ist eine Richtlinie, die durch nationales Recht umgesetzt wird; ihre Anwendbarkeit hängt von Sektor, Größe, Dienst und Einbeziehungsregeln ab. Die Frist für die nationale Umsetzung lief am 17. Oktober 2024 ab; Organisationen müssen die jeweils anwendbare nationale Umsetzung prüfen, statt ein einheitliches, identisches Regime anzunehmen.

Artikel 1 Absatz 2 DORA begründet zusammen mit Artikel 4 NIS2 das sektorspezifische Verhältnis für erfasste Finanzunternehmen in den betreffenden Bereichen. Verstehen Sie das nicht als Aufforderung, gleichwertige Maßnahmen zum Risikomanagement und zur Meldung von Vorfällen doppelt umzusetzen. Gehen Sie ebenso wenig davon aus, dass es jedem Unternehmen einer Finanzgruppe oder ihrer Lieferkette Pflichten abnimmt.

Ein Managed-Service-Provider, der eine Bank bedient, kann eine eigene NIS2-Prüfung benötigen und gleichzeitig DORA-bezogene vertragliche Zusagen erfüllen müssen. Eine Pflichtenmatrix je juristischer Person sollte Rechtsgrundlage, Anwendungsbereich, Behörde, Meldeweg und erforderliche Nachweise festhalten.

Gemeinsame Maßnahmen können DORA, ISO 27001, Datenschutzpflichten und Kundennachweise unterstützen, wenn Umfang und Nachweise übereinstimmen. Verwenden Sie eine Zugriffsüberprüfung oder einen Wiederherstellungstest wieder, wenn sie tatsächlich mehrere Anforderungen stützen, und bewahren Sie dabei die Besonderheiten des Finanzsektors. Ein ISO-27001-Zertifikat belegt keine DORA-Konformität.

Auch die Durchsetzung unterscheidet sich. Die Aufsichtsbefugnisse und Sanktionen gegenüber Finanzunternehmen hängen von den Bestimmungen der Verordnung und den anwendbaren nationalen Maßnahmen ab; für benannte kritische Dienstleister gilt ein eigener Überwachungsrahmen. Planen Sie Risiken nicht anhand einer vermeintlich einheitlichen DORA-Geldbuße. Bewerten Sie das relevante rechtliche Risiko und die betrieblichen Folgen unzureichender Resilienz.

Beispiel: Überprüfung der Abhängigkeiten eines Zahlungsdienstes

Betrachten Sie als Beispiel ein Zahlungsinstitut, das eine Cloud-Plattform, einen Identitätsanbieter und einen ausgelagerten Überwachungsdienst nutzt. Angenommen, das Institut fällt in den Anwendungsbereich von DORA, und die Ausführung von Zahlungen ist als kritische oder wichtige Funktion eingestuft.

Die erste Überprüfung ergibt drei Schwächen: Produktiv- und Wiederherstellungsumgebung teilen dieselbe Identitätsabhängigkeit; der Eskalationsprozess des Überwachungsdienstleisters bei Vorfällen ist unklar; und der Cloud-Ausstiegsplan nennt einen alternativen Anbieter, ohne Datenextraktion und Migration nachzuweisen.

Die Leitung beauftragt drei miteinander verknüpfte Arbeitspakete:

Die fachlich verantwortliche Person prüft, ob die Wiederherstellungsziele für Zahlungen erreichbar bleiben. Compliance prüft, ob Meldeverfahren und Registereinträge die Vereinbarungen abbilden. Die Leitung gibt die nötige Finanzierung frei und prüft die verbleibenden Einschränkungen.

Dieses Beispiel begründet für sich genommen keine Konformität. Es zeigt, wie eine einzige Funktion Entscheidungen sichtbar machen kann, die in getrennten Checklisten für Richtlinien, Lieferanten und Tests verborgen blieben.

Etablieren Sie einen nachweisbasierten Überprüfungsrhythmus

Für DORA gibt es kein allgemeines Zertifizierungsverfahren, das laufende Pflichten ersetzt. Unabhängige Prüfungen können die Leitung informieren, doch die Bereitschaft muss durch funktionierende Maßnahmen, Aufzeichnungen und, wo erforderlich, den Austausch mit der Aufsicht nachgewiesen werden.

Ein praktischer nächster Schritt ist, eine kritische oder wichtige Funktion auszuwählen und deren Entscheidung zum Anwendungsbereich, Abhängigkeitsübersicht, Risikobeurteilung, Verträge, Vorfallverfahren, Testergebnisse und offene Maßnahmen zusammenzustellen. Prüfen Sie, ob diese Unterlagen ein stimmiges Bild ergeben.

Secani unterstützt diesen Ablauf, indem es Systeme und Dienste modelliert, Abhängigkeiten verbindet und Anforderungen, Nachweise, Verantwortliche, Aufgaben und Prüfentscheidungen im Zusammenhang hält. Laden Sie vorhandenes Material zu den relevanten Objekten hoch, machen Sie Lücken zu zugewiesener Arbeit und behalten Sie eine ausdrückliche menschliche Freigabe für KI-gestützte Vorschläge und Schlussfolgerungen bei.

Erweitern Sie den Umfang über diese erste Funktion hinaus, sobald Verantwortlichkeiten und Nachweiswege klar sind. Die Leitung sollte sehen können, was nachgewiesen ist, was noch unsicher ist und welche Entscheidung als Nächstes ansteht.