DORA-Compliance,
verständlich erklärt

DORA ist der Digital Operational Resilience Act — Verordnung (EU) 2022/2554. Sie legt einen einzigen, harmonisierten Satz von Anforderungen dafür fest, wie Finanzunternehmen in der gesamten EU das Risiko steuern, dass ihre Informations- und Kommunikationstechnologie (ICT) ausfällt, gestört oder angegriffen wird. Das Ziel ist einfach: Eine Bank, ein Versicherer oder ein Zahlungsdienstleister soll weiterarbeiten und sich erholen können, wenn etwas in seinem Technologie-Stack schiefgeht.

Zwei Tatsachen prägen alles Weitere. Erstens ist DORA eine Verordnung, keine Richtlinie, und gilt damit unmittelbar in jedem Mitgliedstaat, statt in 27 einzelne nationale Gesetze umgesetzt zu werden. Der Text, der für Sie gilt, ist der EU-Text. Zweitens gilt sie seit dem 17. Januar 2025; das ist keine künftige Pflicht, die man einplanen muss, sondern eine bereits geltende.

Sie ist auch kein Zertifikat. Es gibt kein DORA-Siegel für die Wand und keine akkreditierte Stelle, die Sie zertifiziert. DORA setzt gesetzliche Anforderungen, die Sie erfüllen und gegenüber Ihrer Aufsichtsbehörde nachweisen müssen. Der richtige Rahmen ist deshalb Compliance und Nachweis, nicht Zertifizierung.

DORA erfasst nahezu den gesamten EU-Finanzsektor. Sie deckt Banken und Kreditinstitute ab, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherungs- und Rückversicherungsunternehmen und ihre Vermittler, Anbieter von Krypto-Dienstleistungen, Fonds- und Vermögensverwalter, Handelsplätze und eine lange Liste weiterer regulierter Finanzunternehmen. Wenn Sie als Finanzunternehmen in der EU beaufsichtigt werden, ist die Arbeitsannahme, dass DORA für Sie gilt.

Entscheidend ist, dass sie auch die ICT-Drittanbieter erreicht, von denen diese Unternehmen abhängen. Die Cloud-Plattformen, Softwareanbieter und Managed-Service-Anbieter hinter einem regulierten Unternehmen werden über die vertraglichen und aufsichtsrechtlichen Anforderungen in den Anwendungsbereich gezogen. Die systemisch wichtigsten von ihnen werden direkt auf EU-Ebene benannt und beaufsichtigt, worauf wir weiter unten eingehen.

DORA gilt verhältnismässig. Kleinere und weniger komplexe Unternehmen können statt des vollen Umfangs ein vereinfachtes ICT-Risikomanagement-Rahmenwerk erfüllen, und nicht jedes Unternehmen muss die anspruchsvollsten Tests durchführen. Doch die Verhältnismässigkeit verengt, wie viel Sie tun, nicht ob die Verordnung gilt.

Die erste und grundlegende Säule verlangt ein solides, umfassendes und gut dokumentiertes ICT-Risikomanagement-Rahmenwerk. Es ist das System, das die übrigen Säulen zusammenhält: die ICT-Risiken für Ihre kritischen Funktionen erkennen, sich davor schützen, Anomalien aufspüren, reagieren und wiederherstellen sowie danach lernen. Alles andere in DORA setzt voraus, dass dieses Rahmenwerk existiert und betrieben wird.

Was diese Säule von einer generischen Sicherheitsrichtlinie unterscheidet, ist die Verantwortlichkeit. DORA stellt ausdrücklich klar, dass das Leitungsorgan, der Vorstand oder das Äquivalent das ICT-Risiko verantwortet. Es genehmigt das Rahmenwerk, legt die Risikotoleranz fest, weist das Budget zu und bleibt informiert; das ist keine Verantwortung, die man stillschweigend an die IT delegieren und vergessen kann. Ein Prüfer oder eine Aufsichtsbehörde erwartet, dass sich diese Verantwortung in echten Entscheidungen und einem Überprüfungsrhythmus zeigt, nicht nur in einer Unterschrift auf einem Dokument.

In der Praxis muss das Rahmenwerk den gesamten Lebenszyklus abdecken: eine aktuelle Übersicht der ICT-Assets und der Geschäftsfunktionen, die sie tragen, schützende Massnahmen, kontinuierliches Monitoring, getestete Vorkehrungen für Geschäftskontinuität und Notfallwiederherstellung sowie einen Prozess, der Vorfälle in Verbesserungen zurückfliessen lässt. Die Arbeit besteht weniger darin, das Rahmenwerk einmal zu schreiben, als darin, es aktuell und nachweisbar lebendig zu halten.

In der zweiten Säule geht es darum, was passiert, wenn etwas schiefgeht. DORA verlangt einen definierten Prozess, um ICT-bezogene Vorfälle zu erkennen, zu handhaben, zu protokollieren und zu klassifizieren, und die wichtigsten an Ihre zuständige Behörde zu melden. Es geht darum, aus einem Durcheinander ein Verfahren zu machen: eine bekannte Art, einen Vorfall zu erkennen, seinen Ernst einzuschätzen und zu handeln.

Die Klassifizierung ist der Dreh- und Angelpunkt. DORA legt Kriterien fest, etwa die Zahl der betroffenen Kunden, die Dauer und die geografische Ausbreitung der Störung sowie die betroffenen Daten, die bestimmen, ob ein Vorfall als "schwerwiegend" gilt und damit eine Meldepflicht auslöst. Die Klassifizierung unter Druck richtig hinzubekommen, ist genau das, wofür ein schriftlicher, eingeübter Prozess da ist.

Bei schwerwiegenden Vorfällen läuft die Meldung nach festen Fristen: eine Erstmeldung, sobald der Vorfall als schwerwiegend eingestuft ist, ein Zwischenbericht, sobald sich das Bild verfestigt, und ein Abschlussbericht, sobald Sie die Ursache verstehen. Die Fristen sind so knapp, dass sich die Antwort nicht jedes Mal von Grund auf zusammenstellen lässt. Wer zurechtkommt, hat Vorfalldaten, Kontakte und Vorlagen bereits an einem Ort.

Die dritte Säule verlangt, dass Sie Resilienz beweisen, statt sie zu behaupten. Jedes erfasste Unternehmen muss regelmässig ein Testprogramm betreiben, das Schwachstellenanalysen, szenariobasierte Tests und Überprüfungen der Massnahmen umfasst, die kritische Funktionen schützen, und die Ergebnisse in das Risiko-Rahmenwerk zurückspielen. Tests sind die Art, wie Sie die Lücke finden, bevor ein Vorfall es tut.

Über diese Grundlage hinaus müssen die bedeutendsten Unternehmen bedrohungsorientierte Penetrationstests, kurz TLPT, durchführen. Das ist fortgeschrittenes, nachrichtendienstgestütztes Testen nach dem Vorbild des TIBER-EU-Rahmens: realistische Angreiferszenarien, die in einem mehrjährigen Zyklus gegen Ihre Live-Produktionssysteme laufen und prüfen, wie Sie sich tatsächlich gegen einen entschlossenen Angreifer behaupten würden. Nicht jedes Unternehmen muss TLPT durchführen, da die Aufsicht bestimmt, welche müssen, doch wo es gilt, ist es eine ernsthafte, klar abgegrenzte Übung, kein Routine-Scan.

Der rote Faden dieser Säule ist der Nachweis. Eine Aufsichtsbehörde will nicht hören, dass Sie testen; sie will das Programm sehen, die Befunde, die Behebung und den Beleg, dass sich der Kreis schliesst. Diesen Nachweis aktuell zu halten, ist das Meiste, was die Säule zwischen den Übungen von Ihnen verlangt.

Die vierte Säule erkennt eine einfache Realität an: Die meisten Finanzunternehmen laufen auf Technologie, die ihnen nicht gehört. DORA setzt deshalb klare Anforderungen an das Risikomanagement von ICT-Drittanbietern, von der Sorgfaltsprüfung vor dem Vertragsabschluss über bestimmte vertragliche Klauseln, auf deren Vorhandensein die Verordnung besteht, bis hin zu Monitoring und einer glaubwürdigen Ausstiegsstrategie für die Dienste, die kritische Funktionen tragen.

Das zentrale Dokument ist hier das Informationsregister. Jedes Unternehmen muss ein strukturiertes Register all seiner vertraglichen Vereinbarungen über ICT-Dienstleistungen führen: wer der Anbieter ist, was er tut, welche Funktionen er trägt und wie kritisch diese sind. Dieses Register ist kein privates Inventar; zuständige Behörden können es anfordern, und es speist die EU-weite Sicht darauf, wo systemisches Konzentrationsrisiko sitzt. Die vertraglichen Klauseln, die DORA verlangt, zu Zugang, Auditrechten, Unterauslagerung, Sicherheit und Kündigung, müssen sich in Ihren Verträgen widerspiegeln, was für viele Unternehmen bedeutet, Verträge nachzuverhandeln, die älter sind als die Verordnung.

Das ist die Säule, die am ehesten Menschen ausserhalb der eigenen Mauern einbezieht, und jene, bei der sich ein aktuelles, korrektes Register am schnellsten auszahlt. Ein Register, das jedes Mal aus verstreuten Verträgen rekonstruiert wird, wenn eine Aufsicht fragt, ist eine wiederkehrende Last; eines, das als lebendiger Datensatz gepflegt wird, ist einfach etwas, das Sie aktuell halten.

DORA tut etwas Ungewöhnliches für eine Finanzregulierung: Sie reicht über die regulierten Unternehmen hinaus bis zu den Anbietern dahinter. Die grössten und systemisch wichtigsten ICT-Drittanbieter, etwa die grossen Cloud-Plattformen, können formell als kritische ICT-Drittanbieter, kurz CTPPs, benannt und auf EU-Ebene direkt von den European Supervisory Authorities (den ESAs) beaufsichtigt werden.

Für die meisten Finanzunternehmen wirkt dieses Aufsichtsregime oberhalb ihrer eigenen Pflichten, nicht an deren Stelle. Sie müssen Ihre Anbieter weiterhin unter Säule vier steuern; die ESA-Aufsicht über einen benannten CTPP ist eine zusätzliche Ebene, die das Konzentrationsrisiko eines ganzen Marktes adressiert, der sich auf eine Handvoll derselben Anbieter stützt. Die praktische Folge für Unternehmen ist, dass die Anbieter, von denen sie abhängen, selbst geprüft werden, und dass Ihre vertraglichen und Register-Pflichten Teil davon sind, wie dieses EU-weite Bild zusammengesetzt wird.

DORA begegnet oft Teams, die bereits ISO 27001 halten oder sich durch NIS2 arbeiten, und das Verhältnis ist wichtig, weil die Überschneidung real, aber teilweise ist. ISO 27001 ist ein freiwilliger, zertifizierbarer Managementsystem-Standard für Informationssicherheit im Allgemeinen; DORA ist eine verbindliche, sektorspezifische Verordnung mit Fokus auf operationale Resilienz im Finanzwesen. Ein starkes ISO-27001-ISMS verschafft Ihnen einen grossen Vorsprung bei DORA und deckt das Asset-Inventar, die Massnahmen und den Risikoprozess ab, doch es deckt nicht die DORA-spezifischen Pflichten ab wie die Meldefristen, das Informationsregister oder TLPT.

NIS2 ist der andere Nachbar. Es ist die EU-Richtlinie zur Cybersicherheit über kritische und wichtige Sektoren hinweg, und wo DORA für ein Finanzunternehmen gilt, hat DORA als das speziellere Regime für ICT-Risiko in der Regel Vorrang. Die beiden sind so angelegt, dass sie zusammenpassen, statt sich redundant zu stapeln. Das praktische Fazit für alle, die mehr als eines davon betreiben: Die zugrundeliegende Arbeit, seine Assets zu kennen, seine Anbieter zu steuern, Vorfälle zu managen, ist weitgehend geteilt, und der Wert liegt darin, sie einmal zu pflegen statt in drei parallelen Ordnern.

Weil DORA bereits gilt, bedeutet "bereit werden" in Wahrheit, die Lücke zwischen dem, was Sie heute tun, und dem, was die Verordnung verlangt, zu schliessen und es nachweisen zu können. Der übliche Ausgangspunkt ist eine Gap-Analyse entlang der fünf Säulen: Wo ist das ICT-Risiko-Rahmenwerk solide, wo ist die Vorfallklassifizierung undefiniert, ist das Testprogramm echt, und existiert ein Informationsregister tatsächlich und stimmt es mit Ihren Verträgen überein.

Die Drittpartei-Säule fördert meist die meiste Arbeit zutage, weil sie Vereinbarungen berührt, die Sie nicht vollständig kontrollieren, und ein Register, das die meisten Teams nie als einzelnen Datensatz geführt haben. Bauen Sie dieses Register früh auf. Es ist das Dokument, nach dem eine Aufsicht am ehesten fragt, und das am schmerzhaftesten unter Zeitdruck zu rekonstruieren ist.

Vor allem belohnt DORA ein System, das Sie betreiben, kein Projekt, das Sie abschliessen. Die Unternehmen, denen Erneuerungen und Aufsichtsanfragen leichtfallen, sind jene, deren ICT-Risiko-Rahmenwerk, Vorfalldaten, Testergebnisse und Anbieterregister an einem Ort liegen und aktuell bleiben. Compliance nachzuweisen heisst dann, auf das zu zeigen, was bereits da ist.