Schluss mit der Suche nach DORA-Compliance-Software

Wer Risiko oder Compliance bei einer Bank, einem Versicherer oder einer Wertpapierfirma verantwortet, kennt das neue Dauerthema im Posteingang. Jeder IKT-Anbieter, jede GRC-Plattform, jede Beratung verkauft DORA-Compliance-Software. Der Pitch ist immer derselbe: Der Digital Operational Resilience Act gilt, die Frist ist verstrichen, und Sie brauchen ein Tool dafür.

Sie brauchen kein Tool dafür. Sie müssen operationale Resilienz steuern, und wer das bereits gut tut, hat den Großteil von DORA schon. Hier ist der Grund, warum der Kaufreflex der falsche ist, und worauf Sie stattdessen schauen sollten, bevor Sie irgendetwas unterschreiben.

DORA hat kein neues Problem geschaffen

Der Digital Operational Resilience Act gilt seit dem 17. Januar 2025 für Finanzunternehmen in der EU. Es ist eine echte Verordnung mit echten Zähnen, und sie ist nicht vage: Sie definiert Anforderungen an IKT-Risikomanagement, Vorfallsmeldungen, Resilienztests, IKT-Drittparteirisiko und Informationsaustausch. Zwanzig Arten von Finanzunternehmen sind im Anwendungsbereich, von Kreditinstituten bis zu Anbietern von Krypto-Dienstleistungen, dazu die IKT-Dienstleister, von denen sie abhängen.¹

Lesen Sie die Anforderungen und achten Sie darauf, was fehlt: irgendetwas Neues. IKT-Risikomanagement ist Risikomanagement. Vorfallsmeldung ist Vorfallsmeldung. Drittparteiaufsicht ist das Lieferantenrisiko, das Sie ohnehin hätten steuern sollen. DORA hat eine Reihe von Praktiken, die reife Finanzinstitute bereits lebten, rechtlich durchsetzbar und im gesamten Binnenmarkt einheitlich gemacht. Das Neue ist die Durchsetzung, nicht die Substanz.

Das ist wichtig, weil es die Frage verändert. "Welches DORA-Produkt sollen wir kaufen" unterstellt, DORA sei ein abgegrenztes Ding, das man anbaut. Ist es nicht. Es ist ein rechtlicher Boden unter Disziplinen, die man entweder betreibt oder nicht. Ein Unternehmen mit einem funktionierenden Rahmen für operationale Resilienz, einem lebenden Register seiner IKT-Abhängigkeiten und einem Vorfallsprozess, der enge Meldefristen bereits einhält, ist fast am Ziel. Ein Unternehmen, das 2026 ein DORA-Tool kauft, gesteht damit meist ein, dass es diese Disziplinen nicht betrieben hat, und hofft, Software werde die Lücke übertünchen.

Software übertüncht keine Governance-Lücke. Sie macht die Lücke prüfbar.

Das Informationsregister ist ein Symptom, nicht die Krankheit

Die meistgesuchte Panik rund um DORA ist das Informationsregister: das strukturierte Verzeichnis aller vertraglichen Vereinbarungen über IKT-Dienstleistungen, mit einem vorgeschriebenen Schema, das Aufsichtsbehörden einsammeln können. Es ist wirklich kleinteilig. Es hat konkrete Felder, Unternehmenskennungen und ein Format, das Regulierer erwarten. Anbieter haben ganze Produkte darum gebaut, es einreichungsfertig zu erzeugen, und Unternehmen bezahlen dafür.

Treten Sie einen Schritt zurück und fragen Sie, warum das Register schwer ist. Es ist schwer, weil die meisten Unternehmen ihre IKT-Drittparteilandschaft nicht kennen. Verträge liegen verstreut in Einkauf, Security und Fachbereichen. Niemand weiß, welche Anbieter kritische oder wichtige Funktionen stützen. Niemand kann auf Abruf sagen, welche vierten Parteien hinter den eigenen Abhängigkeiten stehen. Das Register ist schwer zu erstellen, weil das zugrunde liegende IKT-Drittparteirisiko nie als lebendes Inventar gemanagt wurde.

Ein Produkt, das das Register aus einer einmal befüllten Tabelle erzeugt, löst das Artefakt und ignoriert die Krankheit. Nächstes Jahr ist die Landschaft gedriftet, Verträge haben sich geändert, ein Anbieter wurde übernommen, und Sie füllen die Tabelle wieder aus. Das Informationsregister ist kein Dokument, das man produziert. Es ist der Output davon, seine IKT-Abhängigkeiten kontinuierlich zu kennen. Wer diese Landschaft ordentlich managt, für den ist das Register ein Bericht, den man abruft. Wer nicht, den rettet kein Tool, denn das Tool ist immer nur so aktuell wie die letzte manuelle Pflege.

Wie gutes IKT-Risikomanagement aussieht

Hier kommt der unbequeme Teil für alle, die sich freikaufen wollen. Jede DORA-Säule läuft auf eine Praxis hinaus, die kontinuierlich ist, nicht auf ein einmaliges Liefergut.

IKT-Risikomanagement ist kein Richtliniendokument. Es ist eine lebende Kontrollumgebung mit Verantwortlichen, Nachweisen und Überprüfungszyklen. Vorfallsmeldung ist keine Vorlage. Es ist ein Vorfallsprozess, der eng genug verdrahtet ist, um einen schwerwiegenden Vorfall zu klassifizieren und die Aufsicht innerhalb des Meldefensters zu informieren, das für die Erstmeldung in Stunden gemessen wird, nicht in Tagen. Resilienztests sind kein jährlicher Pentest. Für Unternehmen, die ihre Aufsicht benennt, gehören bedrohungsorientierte Penetrationstests in einem Mehrjahreszyklus dazu, und für alle ein Testprogramm, dessen Ergebnisse in die Kontrollen zurückfließen. IKT-Drittparteirisiko ist kein unterschriebener Vertrag. Es ist laufende Aufsicht über Konzentration, Exit-Strategien und die konkreten Anbieter hinter kritischen Funktionen.

Ein Rahmen für operationale Resilienz, der den Namen verdient, verbindet all das. Er kartiert die wichtigen Geschäftsdienstleistungen, identifiziert die IKT- und Drittparteiabhängigkeiten unter jeder einzelnen, setzt Auswirkungstoleranzen und belegt mit Nachweisen, dass das Unternehmen innerhalb dieser Toleranzen bleibt, wenn etwas bricht. Das ist die Disziplin, die DORA prüft. Eine Checkliste, die im Dezember abgehakt und im Januar vergessen wird, ist diese Disziplin nicht. Sie ist Theater mit Audit-Trail.

Die Unternehmen, die eine DORA-Aufsichtsprüfung entspannt bestehen, sind nicht die mit der besten DORA-Software. Es sind die, für die DORA eine Berichtsschicht über Governance ist, die sie ohnehin betrieben haben.

Großbritannien hat dieses Spiel schon gespielt

Nichts davon ist Spekulation, denn ein sehr ähnliches Experiment lief bereits nebenan. Die Regeln von FCA und PRA zur operationalen Resilienz verpflichteten britische Finanzunternehmen, wichtige Geschäftsdienstleistungen zu identifizieren, Auswirkungstoleranzen zu setzen und ihre Abhängigkeiten zu kartieren, mit der Erwartung, bis zum Stichtag 31. März 2025 innerhalb der Toleranzen zu bleiben. Die Logik deckt sich fast Zeile für Zeile mit DORA; nur der regulatorische Akzent unterscheidet sich.

Die Unternehmen, die das britische Regime als einmalige Kartierungs- und Toleranzübung behandelten, erledigt und abgeheftet, mussten es wiederholen. Die Unternehmen, die es als Betriebsmodell behandelten, in dem Abhängigkeitskartierung und Tests kontinuierlich laufen, haben DORA mit deutlich weniger Drama absorbiert, weil die harte Arbeit bereits institutionalisiert war. Die Lektion überträgt sich direkt. Regulierer über Jurisdiktionen hinweg konvergieren auf dieselbe Erwartung: Weisen Sie laufend nach, dass Sie Störungen standhalten und sich davon erholen können. Sie konvergieren nicht auf die Erwartung, dass Sie eine bestimmte Software besitzen.

Wer seine DORA-Aufstellung bewertet, vergleicht am nützlichsten nicht mit anderen DORA-Tools, sondern damit, wie das eigene Haus die operationale Resilienz nach FCA und PRA gehandhabt hat. Die Lücken reimen sich.

Der Test: Kaufen Sie ein Tool oder bauen Sie eine Disziplin

Es gibt eine einfache Diagnose dafür, ob Sie Ihr Geld gut ausgeben werden. Fragen Sie, was das Produkt zwischen den Audits tut.

Ein DORA-Tool, das beim Erzeugen des Registers hilft, ein Richtlinienpaket generiert und ein Nachweisbündel für den Prüfer exportiert, optimiert für den Moment der Inspektion. Es macht das Audit glatter. Es tut nichts für die übrigen einundfünfzig Wochen des Jahres, in denen sich die Landschaft weiter verändert. Ein solches Tool behandelt Compliance als Ereignis. Zwischen den Ereignissen liegt es brach, während die Governance leise unter dem sauberen Bericht verrottet.

Die Alternative ist, DORA als ein weiteres Rahmenwerk zu behandeln, das auf einer kontinuierlich betriebenen Fähigkeit für IKT-Risiko und Drittpartei-Governance aufsetzt. In diesem Modell werden Anforderungen auf Kontrollen abgebildet, Kontrollen tragen Verantwortliche und Nachweise, die IKT-Drittparteilandschaft ist ein gepflegtes Inventar statt einer jährlichen Rekonstruktion, und das Informationsregister ist eine Sicht auf dieses Inventar statt eines Dokuments, das man neu baut. Wenn die nächste Regulierung kommt, und sie kommt, bilden Sie sie auf dieselbe Kontrollumgebung ab, statt eine weitere Punktlösung zu kaufen.

Das ist der Unterschied zwischen dem Kauf von DORA-Compliance-Software und dem Aufbau operationaler Resilienz. Die Disziplin überlebt die nächste Regulierung; der Tool-Kauf bereitet nur den nächsten Beschaffungszyklus vor.

Wo eine Plattform hilft, und wo nicht

Um fair zur Kategorie zu sein: Tooling ist nicht der Feind. Der Fehler ist, ein Tool zu kaufen, das auf eine einzige Regulierung begrenzt ist. Eine Governance-Plattform verdient ihren Platz, wenn sie das Gegenteil tut: eine Kontrollumgebung hält, auf die viele Rahmenwerke abgebildet werden, ein lebendes Inventar von Lieferanten und IKT-Abhängigkeiten pflegt und Nachweise an Kontrollen anhängt, sodass der Audit-Trail ein Nebenprodukt der Arbeit ist statt einer Feuerwehrübung zum Jahresende.

Das ist das Modell, auf dem VerifyWise aufbaut. Die Plattform managt Rahmenwerke als Anforderungen, die auf Kontrollen mit Nachweisen und Assessments abgebildet sind, pflegt ein Lieferanten- und Drittparteiregister als lebende Daten und steuert bereits Modellrisiko im Finanzsektor unter Regimen wie SR 11-7 (jetzt SR 26-2), SS1/23 und OSFI E-23. Die IKT-Drittparteilandschaft, um die es DORA geht, ist dieselbe Landschaft, die ein Vendor-Risk-Modul verfolgt. Die kontinuierlichen Nachweise, die ein Rahmen für operationale Resilienz braucht, sind dieselben Nachweise, die eine Kontrollumgebung produziert.

Zur Klarheit beim Umfang: DORA ist eine Regulierung, für deren Governance die Architektur von VerifyWise gebaut ist, keine vorgefertigte Checkliste zum Einschalten. Jeder Anbieter, der behauptet, seine Software mache Sie standardmäßig DORA-konform, verkauft Ihnen ein Produkt für den Prüfungstag in schönerer Verpackung.

Die ehrliche Version des Pitches ist kleiner und nützlicher als die des Marktes. Keine Software macht Sie resilient. Software macht Resilienz messbar, wiederholbar und prüfbar, sobald Sie die Governance betreiben. Wenn Sie die Governance nicht betreiben, fangen Sie dort an, nicht im Beschaffungsportal.

Wenn Sie sehen möchten, wie kontinuierliche Steuerung statt der Suche nach einem Ein-Regulierungs-Tool aussieht, sprechen Sie mit uns.

Bevor Sie kaufen, fragen Sie das

DORA ist nicht die letzte Regulierung zur operationalen Resilienz, der Sie begegnen werden. Sie ist eine aus einer konvergierenden Reihe, und die nächsten werden dieselbe Kernfrage in leicht anderen Worten stellen: Können Sie kontinuierlich nachweisen, dass Sie Ihre IKT-Abhängigkeiten verstehen und kritische Dienste innerhalb ihrer Toleranzen halten, wenn etwas ausfällt.

Bevor Sie also DORA-Compliance-Software einkaufen, fragen Sie, ob Ihnen ein Tool fehlt oder die Disziplin, über die das Tool berichten soll. Fehlt die Disziplin, wird ein Punktprodukt sie nicht ersetzen, und das Informationsregister ist nächstes Jahr genauso schmerzhaft. Fehlt wirklich nur die Berichtsschicht, dann kaufen Sie eine Plattform, die die Disziplin kontinuierlich steuert und DORA als ein Rahmenwerk unter vielen behandelt, nicht ein Ein-Regulierungs-Tool, das Sie ersetzen, sobald das nächste Akronym eintrifft.

Die Unternehmen, die aufhören einzukaufen und anfangen zu steuern, sind die, für die die nächste Regulierung eine Kartierungsübung ist statt einer Feuerwehrübung.

Footnotes

1. Artikel 2 der Verordnung listet 21 Buchstabenkategorien auf. Die einundzwanzigste sind IKT-Drittdienstleister, die keine Finanzunternehmen sind; die Zahl der Finanzunternehmens-Typen ist also zwanzig. Manche öffentlichen Zusammenfassungen nennen einundzwanzig, weil sie alle Buchstabenpunkte zusammenzählen. ↩