DORA-Software für Banken und Versicherungen: Was sie abdecken muss

Euer Informationsregister ist vollständig. Doch beim Ausfall eines Dienstleisters bleibt offen, welche Geschäftsfunktion zuerst wieder anlaufen muss, welche Systeme sie benötigt und ob der letzte Wiederherstellungstest das bestätigt. Dann ist ein wichtiger DORA-Baustein erledigt, die Betriebsresilienz aber noch nicht beherrscht.

Diese Auswahlhilfe verbindet die DORA-Arbeitsbereiche mit konkreten Beschaffungsfragen. An einer Störung der Schadenbearbeitung prüft ihr, ob die Software von der Auswirkung bis zur überprüften Maßnahme führt.

DORA ist mehr als ein Anforderungskatalog

Der reguläre IKT-Risikomanagementrahmen verlangt ein zusammenhängendes Bild der Funktionen, Informationswerte, IKT-Assets und Abhängigkeiten. Artikel 11 Absatz 5 verlangt eine Business-Impact-Analyse für schwere Betriebsstörungen. Artikel 12 behandelt Sicherung und Wiederherstellung. Weitere Kapitel betreffen Vorfälle, Tests und IKT-Drittparteienrisiken. Die rechtliche Grundlage ist die DORA-Verordnung.

Prüft zuerst euren Anwendungsbereich und ob der reguläre oder ein vereinfachter Rahmen einschlägig ist. Die nachfolgenden Beschaffungsfragen sind auf einen umfassenden Arbeitsablauf ausgerichtet; sie ersetzen diese Einordnung nicht.

Diese Tabelle ist unsere Beschaffungshilfe, kein abschließender Gesetzeskatalog. Ergänzt Anforderungen an Meldung, Registerformat und bestehende Fachsysteme ausdrücklich.

Eine BIA muss erklären, wann der Betrieb nicht mehr tragbar ist

„Geschäftskritisch: ja“ beantwortet nicht, wie ein Ausfall eskaliert. Die Schadenbearbeitung eines Versicherers, eine Zahlungsfunktion und ein internes Berichtssystem haben unterschiedliche zeitliche Anforderungen. Auch Spitzenzeiten und aufgelaufene Rückstände verändern die Bewertung.

In Kopexa führt die BIA am Prozess durch Scoping, Schadensdimensionen und Zeitfenster. Ihr bewertet die Auswirkungen über die Zeit, legt tolerierbaren Datenverlust und Mindestbetriebsniveau fest und begründet Wiederanlaufziele. Freigegebene Bewertungen bleiben als unveränderliche Version erhalten. Die Produktdokumentation zur BIA beschreibt den Ablauf und seine Freigaben.

Das ist für eine Auswahl praktisch prüfbar: Ändert eine Annahme und erstellt eine neue BIA-Version. Könnt ihr später noch erklären, warum die frühere Entscheidung anders ausfiel? Ein aktueller Zahlenwert ohne damalige Bewertungsgrundlage beantwortet diese Frage nicht.

Ein eigener Ressourcen-Schritt im BIA-Assistenten ist laut Dokumentation noch geplant. Prüft im Pilot, wie ihr die benötigten Ressourcen mit den heute verfügbaren Funktionen erfasst.

Für einen eigenen Prüffall nutzt unsere Business Impact Analyse mit Excel-Vorlage: Sie zeigt an einer Kundenplattform, wie ein Wiederanlaufziel an einer zu spät verfügbaren Ressource scheitert.

Prozessmanagement macht aus Wiederanlaufzielen einen Ablauf

Die angestrebte Wiederanlaufzeit (RTO) legt fest, wie schnell ein Prozess wieder verfügbar sein soll. Für den Wiederanlaufplan braucht ihr außerdem einen Ablauf: Wer entscheidet über den Notbetrieb? Welche Freigabe benötigt die Umschaltung? Wer prüft anschließend Datenkonsistenz und fachliche Funktionsfähigkeit?

Mit Kopexas BPMN-Prozessen könnt ihr diese Übergaben beschreiben. Informationswerte, Assets, Risiken und Maßnahmen geben ihnen den fachlichen Bezug. Nachweise liegen an Maßnahmen; Maßnahmen werden den einschlägigen Controls zugeordnet. Damit bleibt ein Wiederherstellungstest Teil derselben Umsetzung, statt als unverbundenes PDF im Auditordner zu landen.

BPMN ist dabei eine Modellierungsmöglichkeit, keine von DORA vorgeschriebene Notation. Ebenso führt die Darstellung eines Wiederanlaufs keine technische Umschaltung aus. Betrieb, Testwerkzeuge und GRC müssen zusammenarbeiten.

Register, Lieferantenrisiko und Exit getrennt prüfen

Ein Lieferant kann mehrere Leistungen erbringen. Dieselbe Leistung kann mehrere Funktionen unterstützen. Deshalb sollte euer Test nicht beim Firmennamen enden: Ändert eine konkrete Vertragsleistung und verfolgt ihre Auswirkungen auf Registerdaten, Risikoentscheidung und Ausstiegsplanung.

Für das Informationsregister braucht ihr zusätzlich die geforderten Datenfelder, Validierungen und das passende Ausgabeformat. Ein generischer CSV-Export ist keine Zusage für ein einreichbares Register. Der Guide zur Datenqualität im DORA-Informationsregister hilft bei der Prüfung.

Auch Incident Management und Behördenmeldung sind getrennte Leistungen. Lasst Meldewege und Schnittstellen vorführen, statt aus einem vorhandenen Vorfallmodul automatisch einen aufsichtsrechtlichen Meldekanal abzuleiten.

Ein durchgehender Auswahlfall für eure Shortlist

Nutzt eine fiktive Störung eines Dienstes zur Schadenbearbeitung. Der Dienst fällt aus; ein alternativer Betriebsweg ist vorhanden, aber im letzten Test blieb ein Datenabgleich offen.

Geht mit jedem Anbieter dieselbe Kette durch: betroffene Geschäftsfunktion finden, Auswirkungen und Wiederanlaufziel erklären, Abhängigkeit zum Dienstleister nachvollziehen, die offene Testfeststellung prüfen und die zugehörige Maßnahme samt Nachweis aufrufen. Zum Schluss soll die zuständige Leitung erkennen, welches Restrisiko bleibt und was sie entscheiden muss.

Bewertet nicht nur, ob jedes Element einzeln existiert. Entscheidend ist, ob die Beteiligten den Zusammenhang ohne eine zusätzliche Excel-Verknüpfung herstellen können. Prüft außerdem Rollen, nachvollziehbare Änderungen und den Export der entscheidungsrelevanten Unterlagen.

Wann Kopexa auf eure Shortlist gehört

Mit Kopexa könnt ihr den Zusammenhang zwischen Prozess, BIA, Informationswerten, Assets und Sicherheitsmaßnahmen bearbeiten. In einer begleiteten zweiwöchigen Testphase könnt ihr dafür einen abgegrenzten Geschäftsprozess verwenden.

Wenn eure übrigen Abläufe bereits funktionieren und ausschließlich ein bestimmtes aufsichtsrechtliches Ausgabeformat fehlt, kann eine spezialisierte Registerlösung die engere Beschaffung sein. Haltet diese Entscheidung anhand der Lücke fest, die ihr wirklich schließen müsst.