DORA-Manager

Die Verordnung · Kapitel IV: Testen der digitalen operationalen Resilienz

Artikel 25

Testen von IKT-Tools und -Systemen

Wen dieser Artikel betrifft

  • VVoller Rahmen
  • 16Artikel 16
  • IKTIKT-Dienstleister

Verordnung (EU) 2022/2554 · Kapitel IV, Artikel 25 · gilt seit dem 17. Januar 2025 · Amtlicher Text bei EUR-Lex (CELEX 32022R2554)
Rechtsstand dieser Seite: 28. September 2026

Wortlaut

Amtliche deutsche Fassung, Verordnung (EU) 2022/2554, veröffentlicht im Amtsblatt der Europäischen Union L 333 vom 27.12.2022. Verbindlich ist der dort veröffentlichte Wortlaut.

(1) Das in Artikel 24 genannte Programm für die Tests der digitalen operationalen Resilienz beinhaltet im Einklang mit den in Artikel 4 Absatz 2 aufgeführten Kriterien die Durchführung angemessener Tests, wie etwa Schwachstellenbewertung und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, 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.

(2) Zentralverwahrer und zentrale Gegenparteien führen Schwachstellenbewertungen durch, bevor Anwendungen und Infrastrukturkomponenten sowie IKT-Dienstleistungen, die kritische oder wichtige Funktionen des Finanzunternehmens unterstützen, eingesetzt oder wieder eingesetzt werden.

(3) Kleinstunternehmen führen die in Absatz 1 genannten Tests durch, indem sie einen risikobasierten Ansatz mit einer strategischen Planung für IKT-Tests kombinieren, wobei sie gebührend berücksichtigen, dass zwischen dem Umfang von Ressourcen und der Zeit, die für die IKT-Tests gemäß diesem Artikel aufzuwenden sind, einerseits, und der Dringlichkeit, der Art des Risikos, der Kritikalität von Informationsassets und erbrachten Dienstleistungen sowie allen sonstigen relevanten Faktoren, einschließlich der Fähigkeit des Finanzunternehmens, kalkulierte Risiken einzugehen, andererseits, ein ausgewogenes Verhältnis gewahrt werden muss.

Neben jedem Absatz steht ein . Ein Klick darauf setzt die Adresse genau dieses Absatzes in die Adresszeile, zum Kopieren in Ihre eigene Richtlinie, eine Vorlage oder ein Prüfungsprotokoll. Verweise auf andere Artikel dieser Verordnung sind verlinkt.

Worum es geht

Artikel 25 Absatz 1 zählt auf, was in ein Testprogramm gehören kann: Schwachstellenbewertungen und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Lückenanalysen, Überprüfungen der physischen Sicherheit, Fragebögen, Scans von Softwarelösungen, Quellcodeprüfungen soweit durchführbar, szenariobasierte Tests, Kompatibilitäts-, Leistungs-, End-to-End- und Penetrationstests.

Das ist eine Auswahlliste, kein Pflichtenheft: Sie wird „im Einklang mit den in Artikel 4 Absatz 2 aufgeführten Kriterien“ angewendet, also nach Größe, Risikoprofil, Art, Umfang und Komplexität.

In der Praxis

Die Liste ist ein Angebot, aber die Auswahl muss begründet sein

„Wie etwa“ heißt: nicht jede der aufgezählten Arten, aber auch nicht beliebig wenige. Was fehlt, muss erklärbar sein, und zwar aus dem Risiko, nicht aus dem Budget.

Eine brauchbare Form ist eine Tabelle mit drei Spalten: Testart, angewendet ja oder nein, Begründung. Eine Seite, jährlich überprüft. Damit ist Absatz 1 in Verbindung mit Artikel 4 Absatz 2 nachweisbar erfüllt, und die Diskussion in der Prüfung dauert Minuten statt Stunden.

Überprüfung der physischen Sicherheit steht in derselben Liste

Zwischen Netzwerkbewertung und Lückenanalyse steht ein Punkt, der in IT-getriebenen Testprogrammen fast immer fehlt: die physische Sicherheit. Serverraum, Zutritt, Klimatisierung, Verkabelung, Löschanlage.

Für Häuser mit eigenem Technikraum ist das der Test mit dem besten Verhältnis von Aufwand zu Erkenntnis. Für Häuser, die vollständig auslagern, verlagert sich die Frage in die Dienstleisterprüfung nach Artikel 28 Absatz 6, aber sie verschwindet nicht.

Absatz 2: Zentralverwahrer und CCPs testen vor dem Einsatz

Für Zentralverwahrer und zentrale Gegenparteien ist die Schwachstellenbewertung vor dem Einsatz und vor dem Wiedereinsatz von Anwendungen, Infrastrukturkomponenten und IKT-Dienstleistungen verpflichtend, die kritische oder wichtige Funktionen unterstützen.

Das ist eine Freigabebedingung, keine Jahresaufgabe; sie gehört in den Änderungsmanagementprozess, nicht in den Testplan.

Absatz 3: Kleinstunternehmen testen auch, nur anders

Kleinstunternehmen führen die Tests durch, indem sie einen risikobasierten Ansatz mit strategischer Planung verbinden und dabei ein ausgewogenes Verhältnis zwischen Ressourcen und Zeit einerseits und Dringlichkeit, Risikoart und Kritikalität andererseits wahren.

Übersetzt: Es gibt keine Befreiung, sondern eine ausdrückliche Erlaubnis zur Beschränkung, und zwar eine, die begründet sein muss. Ein Kleinstunternehmen, das gar nicht testet, kann sich auf Absatz 3 nicht berufen.

Konkretisiert durch

  • Delegierte Verordnung (EU) 2024/1774, Artikel 36. IKT-Sicherheitstests im vereinfachten Rahmen, die einzige Stelle in den technischen Standards, an der Testarten näher beschrieben werden. Amtlicher Text (CELEX 32024R1774)
  • Delegierte Verordnung (EU) 2024/1774, Artikel 25 und 40. Test des IKT-Geschäftsfortführungsplans; diese Tests folgen aus Artikel 11 und sind nicht dasselbe wie das Programm nach Artikel 24. Amtlicher Text (CELEX 32024R1774)

Die Zuordnung der einzelnen Artikel ist eine fachliche Einschätzung. Verbindlich ist allein der Wortlaut der jeweiligen Verordnung.

Was am Ende vorliegen muss

Erfüllt ist die Anforderung, wenn diese Unterlagen vorliegen, aktuell sind und zueinander passen, nicht, wenn sie einzeln existieren:

  • Die Übersicht der Testarten mit Angabe, welche angewendet werden und warum die übrigen nicht
  • Bei eigener Infrastruktur: der Nachweis einer Überprüfung der physischen Sicherheit
  • Bei Zentralverwahrern und zentralen Gegenparteien: die Schwachstellenbewertung vor jedem Einsatz und Wiedereinsatz, im Änderungsprozess verankert
  • Bei Kleinstunternehmen: die Begründung des gewählten Umfangs nach Absatz 3

Häufige Fragen zu Artikel 25

Welche Tests verlangt DORA?

Artikel 25 Absatz 1 DORA nennt als Beispiele Schwachstellenbewertungen und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, 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. Die Auswahl richtet sich nach den Kriterien des Artikels 4 Absatz 2 DORA.

Müssen Kleinstunternehmen nach DORA testen?

Ja, aber in verringertem Umfang. Artikel 25 Absatz 3 DORA verlangt von Kleinstunternehmen, die Tests mit einem risikobasierten Ansatz und einer strategischen Planung durchzuführen und dabei Ressourcen und Zeit gegen Dringlichkeit, Risikoart und Kritikalität abzuwägen. Von dem Programm nach Artikel 24 DORA sind sie ausgenommen.

Weiter

Stand: 28. September 2026