DORA-Compliance: Was die Testanforderungen tatsächlich verlangen

Der Digital Operational Resilience Act gilt seit dem 17. Januar 2025 – und er ist eine Verordnung, keine Richtlinie. Die Verordnung (EU) 2022/2554 bindet Finanzunternehmen in jedem EU-Mitgliedstaat unmittelbar. Es gibt keine nationale Umsetzung, auf die sich warten liesse, und keinen Spielraum, den Text als blosse Empfehlung zu lesen.

Der grösste Teil von DORA lässt sich mit Dokumenten erfüllen: Richtlinien, Register, Vertragsklauseln, Meldeformulare. Ein Teil nicht. Artikel 24(6) verlangt, dass Tests tatsächlich durchgeführt werden – mindestens jährlich und auf jedem IKT-System, das eine kritische oder wichtige Funktion unterstützt.

Genau hier hilft ein Ordner voller Richtlinien nicht weiter, und genau diesem Teil widmet sich dieser Leitfaden.

Was ist der Digital Operational Resilience Act?

DORA ist die Antwort der EU auf eine schlichte Beobachtung: Ein Finanzinstitut kann vollkommen solvent und trotzdem nicht erreichbar sein. Kapitalpuffer sagen nichts darüber aus, ob das E-Banking-Frontend eine Lastspitze übersteht oder ob der Ausfall eines zentralen Dienstleisters eine Kettenreaktion durch den ganzen Sektor auslöst.

Verabschiedet wurde die Verordnung am 14. Dezember 2022; Artikel 64 setzt den Geltungsbeginn auf den 17. Januar 2025. Seither kann die Aufsicht jedes erfasste Unternehmen am vollständigen Anforderungskatalog messen.

Artikel 3(1) definiert die digitale operationale Resilienz über die Fähigkeit eines Finanzunternehmens, seine operative Integrität aufzubauen, sicherzustellen und zu überprüfen. Das entscheidende Wort in dieser Definition ist «überprüfen».

DORA verlangt nicht, dass Sie resilient sind. DORA verlangt, dass Sie sich fortlaufend davon überzeugen – und die Prüfung dokumentieren.

Für wen gilt DORA?

Artikel 2(1) führt einundzwanzig Kategorien von Unternehmen auf, Buchstabe (a) bis (u). Kreditinstitute, Zahlungsinstitute, E-Geld-Institute und Wertpapierfirmen liegen auf der Hand. Die Liste reicht aber weiter: Anbieter von Krypto-Dienstleistungen, zentrale Gegenparteien, Handelsplätze, Fondsverwalter, Versicherungs- und Rückversicherungsunternehmen, Einrichtungen der betrieblichen Altersversorgung, Ratingagenturen, Schwarmfinanzierungsdienstleister, Verbriefungsregister.

Ein Detail in Artikel 2(2) überliest man leicht: Die Buchstaben (a) bis (t) werden gemeinsam als «Finanzunternehmen» definiert, während Buchstabe (u) – die IKT-Drittdienstleister – gesondert im Geltungsbereich steht. Wer als kritischer Anbieter eingestuft wird, unterliegt einem eigenen EU-Überwachungsregime. Ein Cloud- oder Softwareanbieter mit Kunden im Finanzsektor kann also in den Blick der Aufsicht geraten, ohne selbst ein Finanzunternehmen zu sein.

Für Mikrounternehmen gilt der Grundsatz der Verhältnismässigkeit. Mehrere Testpflichten in Kapitel IV beginnen mit «Finanzunternehmen, die keine Mikrounternehmen sind», und Artikel 25(3) erlaubt Mikrounternehmen stattdessen, einen risikobasierten Ansatz mit einer strategischen Planung ihrer Tests zu verbinden.

Schweizer Institute sind nicht unmittelbar erfasst. Schweizer Gruppen erfüllen DORA dennoch über ihre EU-Tochtergesellschaften und -Niederlassungen, Schweizer Anbieter über die Anforderungen an das IKT-Drittparteirisiko, sobald ein EU-Finanzunternehmen von ihnen abhängt. Zur Schweizer Lage weiter unten mehr.

Was sind die fünf Säulen von DORA?

Die Anforderungen von DORA gliedern sich in fünf Blöcke, üblicherweise die fünf Säulen genannt:

• IKT-Risikomanagement. Ein dokumentierter Risikomanagementrahmen in der Verantwortung des Leitungsorgans: identifizieren, schützen, erkennen, reagieren, wiederherstellen, lernen.
• Behandlung und Meldung IKT-bezogener Vorfälle. Vorfälle nach einheitlichen Kriterien klassifizieren und schwerwiegende Fälle innerhalb fester Fristen an die zuständige Behörde melden.
• Tests der digitalen operationalen Resilienz. Kapitel IV, Artikel 24 bis 27. Ein dauerhaft verankertes Testprogramm, jährliche Tests der Systeme hinter kritischen oder wichtigen Funktionen und erweiterte bedrohungsorientierte Tests für benannte Unternehmen.
• IKT-Drittparteirisiko. Vertragliche Mindestinhalte, ein Register sämtlicher IKT-Dienstleistungsvereinbarungen, die Analyse von Konzentrationsrisiken und eine EU-weite Überwachung kritischer Anbieter.
• Informationsaustausch. Eine Rechtsgrundlage, auf der Finanzunternehmen Erkenntnisse zu Cyberbedrohungen in vertrauenswürdigen Kreisen austauschen können – freiwillig.

Vier der fünf Säulen sind überwiegend Governance-Arbeit. Sie bringen Dokumente, Register und Meldewege hervor; eine gut aufgestellte Compliance-Funktion kann sie tragen.

Der Testteil ist von anderer Art. Er verlangt, dass auf produktionsrelevanten Systemen nach Plan etwas geschieht, und er bringt Befunde hervor, die jemand beheben und deren Behebung jemand belegen muss.

Was verlangt DORA für Resilienztests?

Artikel 24 steckt den Rahmen ab. Finanzunternehmen, die keine Mikrounternehmen sind, müssen ein solides und umfassendes Programm für Tests der digitalen operationalen Resilienz aufstellen, unterhalten und überprüfen – als integralen Bestandteil des IKT-Risikomanagementrahmens. Der Zweck steht ausdrücklich im Text: die Abwehrbereitschaft bewerten, Schwächen und Lücken erkennen und Korrekturmassnahmen zügig umsetzen.

Vier Bedingungen kommen hinzu; an ihnen entscheidet sich, ob ein Programm einer aufsichtlichen Prüfung standhält:

• Bandbreite. Das Programm muss eine Reihe von Bewertungen, Tests, Methoden, Verfahren und Werkzeugen umfassen, angewendet wie in den Artikeln 25 und 26 beschrieben (Artikel 24(2)). Ein einzelner jährlicher Penetrationstest ergibt noch kein Programm.
• Risikobasis. Die Tests folgen einem risikobasierten Ansatz, der die sich wandelnde IKT-Risikolage und die Kritikalität der betroffenen Systeme berücksichtigt (Artikel 24(3)).
• Unabhängigkeit. Getestet wird durch unabhängige Parteien, intern oder extern; bei internen Testern braucht es Vorkehrungen gegen Interessenkonflikte (Artikel 24(4)).
• Behebung. Unternehmen brauchen Verfahren, um jeden Befund aus einem Test zu priorisieren, zu klassifizieren und zu beheben, dazu eine interne Validierung, dass die Schwächen vollständig ausgeräumt sind (Artikel 24(5)). Ein Befund, der unbearbeitet im Bericht liegen bleibt, ist für sich genommen bereits ein Verstoss.

Dann folgt der Satz, der die meisten Testkalender im EU-Finanzsektor bestimmt. Artikel 24(6): Finanzunternehmen, die keine Mikrounternehmen sind, stellen sicher, dass mindestens jährlich geeignete Tests auf allen IKT-Systemen und -Anwendungen durchgeführt werden, die kritische oder wichtige Funktionen unterstützen.

Gemeint ist keine Stichprobe, sondern jedes einzelne System, Jahr für Jahr.

Artikel 25(1) zählt auf, was als Test gilt, und fasst den Begriff weit: Schwachstellenbewertungen und -scans, Open-Source-Analysen, Bewertungen der Netzwerksicherheit, Lückenanalysen, Überprüfungen der physischen Sicherheit, Fragebögen und Scans von Softwarelösungen, Quellcodeprüfungen soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetrationstests. Eingeleitet wird die Aufzählung mit «wie»; sie ist damit beispielhaft und nicht abschliessend. Eines macht sie gleichwohl deutlich: Was DORA unter Testen versteht, geht weit über den jährlichen Penetrationstest hinaus. Die Verfügbarkeit unter Last gehört ebenso dazu wie ausnutzbare Schwachstellen im Code.

Eine schärfere Regel enthält Artikel 25(2): Zentralverwahrer und zentrale Gegenparteien müssen vor jeder Bereitstellung oder erneuten Bereitstellung von Anwendungen, Infrastrukturkomponenten oder IKT-Diensten, die kritische oder wichtige Funktionen unterstützen, Schwachstellenbewertungen durchführen. Für Marktinfrastrukturen ist der Test damit fester Bestandteil des Release-Prozesses.

Was sind bedrohungsorientierte Penetrationstests unter DORA?

Artikel 3(17) definiert TLPT als Regelwerk, das Taktiken, Techniken und Verfahren realer Angreifer nachbildet. In der Praxis ist das eine beaufsichtigte Red-Team-Übung auf Grundlage aktueller Bedrohungsanalysen – und für einen Teil des Sektors macht DORA daraus eine Pflicht statt einer Kür.

Artikel 26 legt die Bedingungen fest. Benannte Finanzunternehmen müssen mindestens alle drei Jahre erweiterte Tests mittels TLPT durchführen; die zuständige Behörde kann diese Häufigkeit je nach Risikoprofil des Unternehmens herauf- oder herabsetzen.

Wer dazugehört, entscheidet die Aufsicht – nach Auswirkungsfaktoren, Erwägungen der Finanzstabilität sowie dem IKT-Risikoprofil und dem Reifegrad des Unternehmens. TLPT trifft nicht alle; die Anforderung zielt auf jene Unternehmen, deren Ausfall am schwersten wöge.

Der Test selbst ist bewusst unbequem angelegt. Er muss mehrere oder alle kritischen oder wichtigen Funktionen abdecken und auf Live-Produktionssystemen stattfinden.

Laufen diese Funktionen auf ausgelagerter IKT, gehören die Drittdienstleister in den Prüfumfang; die volle Verantwortung bleibt beim Finanzunternehmen. Würde eine direkte Teilnahme die Servicequalität oder die Vertraulichkeit gefährden, bleibt als Ausweg gepooltes TLPT über mehrere Finanzunternehmen hinweg. Die Regulierungsstandards für die Durchführung dieser Tests haben die Europäischen Aufsichtsbehörden im Einklang mit TIBER-EU entwickelt, dem von der EZB stammenden Regelwerk für Threat-Intelligence-basiertes Red Teaming.

Artikel 27 regelt, wer testen darf. Tester brauchen nachgewiesene Expertise in Bedrohungsanalyse, Penetrationstests und Red-Team-Operationen, Zertifizierungen oder die Bindung an formelle Verhaltenskodizes, eine unabhängige Prüfbestätigung zu ihrem eigenen Risikomanagement und eine Berufshaftpflichtversicherung.

Interne Tester sind zulässig, doch Artikel 27 verlangt dafür die Zustimmung der zuständigen Behörde und einen externen Anbieter von Bedrohungsanalysen; Artikel 26(8) ergänzt, dass bei jedem dritten Test ein externer Tester zu beauftragen ist. Bedeutende Kreditinstitute müssen ausschliesslich externe Tester einsetzen.

Nach dem Test stellt die Behörde eine Bescheinigung darüber aus, dass er anforderungsgemäss durchgeführt wurde; andere EU-Aufsichtsbehörden erkennen sie an. Dieses Detail verrät viel über die Denkweise hinter DORA: Das Ergebnis eines Tests ist ein überprüfbarer Nachweis, den eine Aufsichtsbehörde an die nächste weiterreicht – keine interne Foliensammlung.

Welche Nachweise erwartet die Aufsicht?

Wer die Artikel 24 bis 27 mit den Augen eines Prüfers liest, erkennt ein Muster. Das Programm muss dokumentiert sein. Befunde müssen klassifiziert und priorisiert werden.

Die Behebung muss validiert sein, nicht bloss behauptet. Genau deshalb gehört zu TLPT-Ergebnissen eine förmliche Bescheinigung: Eine zweite Behörde kann sich darauf stützen, ohne die Übung zu wiederholen.

Die praktische Frage für einen Compliance-Verantwortlichen lautet deshalb nicht «Haben wir getestet?», sondern «Können wir belegen, was wir getestet, was wir gefunden und was wir behoben haben?». Der Screenshot eines Monitoring-Dashboards beantwortet davon nichts. Er stammt aus keiner unabhängigen Quelle, ist gegen nachträgliche Änderungen nicht geschützt und sagt nichts darüber aus, wie der Test abgelaufen ist.

Nachweise, die einer aufsichtlichen Prüfung standhalten, entstehen im Test selbst, durch eine Partei ohne Interesse am Ergebnis, in einer Form, die sich nachträglich nicht unbemerkt ändern lässt. Diesen Massstab sollten Sie an jeden Anbieter in Ihrem Testprogramm anlegen, unabhängig davon, was er prüft. Fragen Sie, woran sein Bericht belegt, dass der Test wie beschrieben stattgefunden hat – und was verhindert, dass zwischen Durchführung und Ablage jemand an den Zahlen dreht.

Wo gehören DDoS-Resilienztests in die DORA-Compliance?

Verfügbarkeit ist die Resilienzeigenschaft, auf die Denial-of-Service-Angriffe zielen, und die Bedrohungslage verschärft sich weiter. Cloudflares Threat Report 2026, veröffentlicht im März 2026, weist für das Jahr 2025 insgesamt 47,1 Millionen abgewehrte DDoS-Angriffe im Netz des Anbieters aus – ein Plus von 121 Prozent gegenüber dem Vorjahr. Bereits der DDoS-Bedrohungsbericht desselben Anbieters für das erste Quartal 2025 verzeichnete 20,5 Millionen blockierte Angriffe in einem einzigen Quartal, ein Anstieg von 358 Prozent im Jahresvergleich – und Banken und Finanzdienstleister rückten in der Rangliste der meistangegriffenen Sektoren weiter nach oben.

Bei einer Bank zielen diese Angriffe auf genau die Systeme, die Artikel 24(6) im Blick hat: das E-Banking-Portal, das Zahlungs-Gateway, das Trading-Frontend. Systeme also, die kritische oder wichtige Funktionen unterstützen und mindestens jährlich mit geeigneten Tests zu prüfen sind.

Ein Blick zurück auf die Aufzählung in Artikel 25(1) zeigt, wie genau ein solcher Test dort hineinpasst. Eine kontrollierte DDoS-Simulation gegen die eigene Infrastruktur ist szenariobasierter Test, Leistungstest und End-to-End-Test der Verfügbarkeit in einem. Sie beantwortet die Frage, an der jede Schreibtischübung scheitert: Hält der Abwehr-Stack, für den Sie bezahlen, tatsächlich stand, wenn realistischer Angriffsverkehr eintrifft?

Unser Leitfaden zum Testen Ihres DDoS-Schutzes zeigt, wie Sie den ersten Durchlauf aufbauen; unser Beitrag zum DDoS-Stresstest beschreibt, wie ein kontrollierter Testlauf in der Praxis abläuft.

Obsidio führt Tests genau dieser Art durch, zugeschnitten auf die Rahmenbedingungen, unter denen regulierte Unternehmen arbeiten. Die Domain-Inhaberschaft wird vor dem ersten Paket über einen DNS-TXT-Eintrag geprüft; eine Simulation kann also nie Infrastruktur treffen, über die Sie keine Verfügungsgewalt haben. Jeder Durchlauf steigert die Intensität schrittweise und lässt sich jederzeit live abbrechen.

Der Angriffsverkehr stammt von über 100’000 weltweit verteilten echten Geräten und nicht von einer Handvoll Rechenzentrums-IPs. Genau das macht das Ergebnis aussagekräftig: Abwehrmechanismen, die die Konzentration der Quellen als Schlüssel verwenden, verhalten sich gegen eine einzelne Maschine völlig anders als gegen ein realistisch verteiltes Muster. Zehn Simulationstypen decken Floods auf der Anwendungsschicht, langsame Angriffe, das Erschöpfen von Verbindungen und protokollspezifische Vektoren ab; im Jahresprogramm lassen sich die Szenarien also durchwechseln, statt immer dasselbe zu wiederholen.

Beim Nachweis wird der DORA-Bezug konkret. Obsidio erzeugt kryptografisch attestierte Berichte, die sich nachträglich nicht unbemerkt ändern lassen: Sie entstehen in Trusted Execution Environments und sind DORA, FINMA und NIS2 zugeordnet.

Der Bericht eines Durchlaufs taugt zur Vorlage bei der Aufsicht – ein unabhängiger, überprüfbarer Nachweis darüber, was wann, mit welcher Intensität und mit welchem Ergebnis getestet wurde. Genau diese Form von Nachweis setzen die Artikel 24(5) und 24(6) voraus. Ein erneuter Test nach der Behebung liefert anschliessend die Validierung, die die Verordnung verlangt.

Stärke wird bewiesen, nicht versprochen. DORA hat diesen Grundsatz in geltendes Recht überführt: Seit dem 17. Januar 2025 fragt die Aufsicht nicht, ob Sie Ihre kritischen Systeme für resilient halten, sondern welche Nachweise Sie vorlegen können.

Was gilt für Schweizer Institute?

Die Schweiz ist kein EU-Mitgliedstaat; DORA gilt für Schweizer Unternehmen also nicht unmittelbar. Die Schweizer Aufsicht ist auf eigenem Weg am selben Punkt angelangt: Das FINMA-Rundschreiben 2023/1 zu operationellen Risiken und Resilienz bei Banken, in Kraft seit dem 1. Januar 2024, verankert die Grundsätze des Basler Ausschusses zur operationellen Resilienz – mit Übergangsfristen für die Resilienzbestimmungen bis Anfang 2026. Die aufsichtliche Erwartung weist damit beidseits der Grenze in dieselbe Richtung: kritische Funktionen identifizieren, die Systeme dahinter testen und die Ergebnisse belegen.

Die NIS2-Richtlinie der EU (Richtlinie (EU) 2022/2555) rundet das Bild ab. Die Mitgliedstaaten mussten sie bis zum 17. Oktober 2024 umsetzen; sie erfasst wesentliche und wichtige Sektoren weit über den Finanzbereich hinaus. Für Finanzunternehmen geht DORA als spezifischeres Regime vor – die IKT-Risiko- und Testpflichten einer Bank laufen also über DORA und nicht über NIS2, während Gruppengesellschaften ausserhalb des Finanzperimeters durchaus unter NIS2 selbst fallen können.

Für ein Schweizer Institut mit EU-Geschäft sind das drei Regime mit einem gemeinsamen Nenner. Ein Resilienztest, der den Aufwand lohnt, sollte Nachweise liefern, die sich in allen dreien verwenden lassen. Deshalb ordnet Obsidio jeden attestierten Bericht gleichzeitig FINMA, DORA und NIS2 zu statt nur einem einzelnen Regelwerk.

Wie wird ein Testprogramm DORA-tauglich?

Die Reihenfolge ergibt sich aus den Artikeln selbst:

• Zuerst die kritischen oder wichtigen Funktionen identifizieren. Artikel 24(6) setzt an den Systemen an, die sie unterstützen; die Funktionsübersicht entscheidet also darüber, was überhaupt zu testen ist.
• Diese Systeme inventarisieren, einschliesslich derer, die bei Dritten laufen.
• Einen Jahreskalender aufsetzen, der die Bandbreite aus Artikel 25(1) ausschöpft, statt einen einzelnen Testtyp zu wiederholen – mit Verfügbarkeitsszenarien neben den klassischen Schwachstellenprüfungen.
• Jeden Befund in einen dokumentierten Behebungsprozess überführen, mit Validierung am Schluss. Artikel 24(5) behandelt einen unbehobenen Befund als offene Pflicht.
• Den TLPT-Zyklus früh planen, falls Ihre Aufsicht Sie zu den benannten Unternehmen zählt. Artikel 27 macht qualifizierte Tester zur zwingenden Voraussetzung, und für den Dreijahresrhythmus müssen die Verträge mit den Testern rechtzeitig stehen.

Um einen autorisierten DDoS-Resilienztest in diesen Kalender aufzunehmen – mit Nachweisen, die Sie der Aufsicht vorlegen können, statt auf Zusagen angewiesen zu sein, für die jemand bürgen muss –, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.