Wissen
Artikel 24 ist kurz. Sechs Absätze. Das meiste, was ihm zugeschrieben wird, steht nicht darin. Dieser Leitfaden zitiert daher den Wortlaut und sagt anschließend klar, woher der Rest stammt.
Das Programm für Tests der digitalen operationalen Resilienz steht in Kapitel IV der Verordnung (EU) 2022/2554, verteilt über die Artikel 24 bis 27. Artikel 24 begründet die Programmpflicht, Artikel 25 zählt die Testarten auf, und die Artikel 26 und 27 regeln bedrohungsorientierte Penetrationstests. DORA gilt seit dem 17. Januar 2025.
Drei Aussagen, die anderswo kursieren und die Sie prüfen sollten, bevor Sie ein Programm darauf aufbauen: dass Artikel 24 die Genehmigung des Testprogramms durch das Leitungsorgan verlangt, dass Artikel 25 eine feste Liste von zehn Testarten vorschreibt und dass alle drei Jahre ein Penetrationstest fällig ist. Die erste stimmt nur über eine Argumentationskette, die man kennen sollte. Die zweite und die dritte stimmen überhaupt nicht.
| Die Programmpflicht | Artikel 24 Absatz 1. Gilt für Finanzunternehmen mit Ausnahme von Kleinstunternehmen. |
| Die einzige feste Frequenz in Artikel 24 | Artikel 24 Absatz 6: mindestens jährlich angemessene Tests aller IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen. |
| Wer die Tests durchführt | Artikel 24 Absatz 4: unabhängige Parteien, intern oder extern. Interne Tester erfordern eigens zugewiesene Ressourcen und gesteuerte Interessenkonflikte. |
| Die Testarten | Artikel 25 Absatz 1 nennt eine beispielhafte Liste, eingeleitet mit den Worten "wie etwa". Es handelt sich um eine Aufzählung von Beispielen statt um eine Pflichtliste von zehn Punkten. |
| Bedrohungsorientierte Penetrationstests | Artikel 26 Absatz 1: mindestens alle 3 Jahre, aber nur für Unternehmen, die ihre zuständige Behörde nach Artikel 26 Absatz 8 benannt hat. |
| Was DORA zu Testkosten sagt | Nichts. Die Verordnung nennt keine Zahlen. Siehe den Abschnitt zu Kosten weiter unten. |
Was Artikel 24 tatsächlich sagt
Artikel 24 Absatz 1 verpflichtet Finanzunternehmen mit Ausnahme von Kleinstunternehmen, "ein solides und umfassendes Programm für die Tests der digitalen operationalen Resilienz als integralen Bestandteil des in Artikel 6 genannten IKT-Risikomanagementrahmens einzurichten, aufrechtzuerhalten und zu überprüfen". Der letzte Halbsatz trägt die entscheidende Last, und darauf kommen wir beim Thema Leitungsorgan zurück.
Artikel 24 gehört zu den besser formulierten Teilen von DORA: kurz, frei von Querverweislabyrinthen und ehrlich in dem Punkt, dass ein Testprogramm eine Ermessensentscheidung ist. Die Schwierigkeit, die daraus entsteht, ist das Gegenteil der üblichen. Es gibt so wenig Vorgabe, dass fast alles in Ihrem Programm Ihre eigene, zu verteidigende Entscheidung ist, und eine Entscheidung lässt sich schwerer belegen als eine Checkliste.
Der Rest des Artikels, kurz gefasst und in seinen eigenen Begriffen:
| Absatz | Was er verlangt |
| 24(1) | Das Programm einrichten, aufrechterhalten und überprüfen, als integralen Bestandteil des IKT-Risikomanagementrahmens. Kleinstunternehmen bleiben außen vor. |
| 24(2) | Das Programm umfasst eine Reihe von Bewertungen, Tests, Methoden, Verfahren und Instrumenten, die im Einklang mit den Artikeln 25 und 26 angewandt werden. |
| 24(3) | Einem risikobasierten Ansatz folgen, der die sich verändernde IKT-Risikolandschaft, spezifische Risiken sowie die Kritikalität von Informationsassets und Diensten berücksichtigt. |
| 24(4) | Tests werden von unabhängigen Parteien durchgeführt, intern oder extern. Interne Tester benötigen ausreichende eigens zugewiesene Ressourcen, und Interessenkonflikte sind über Konzeption und Durchführung hinweg zu vermeiden. |
| 24(5) | Verfahren und Leitlinien einrichten, um sämtliche im Test zutage getretenen Probleme zu priorisieren, zu klassifizieren und zu beheben, sowie interne Validierungsmethoden, mit denen festgestellt wird, dass alle ermittelten Schwachstellen, Mängel oder Lücken vollständig behoben sind. |
| 24(6) | Mindestens jährlich angemessene Tests aller IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen. |
Beachten Sie, was fehlt. Artikel 24 erwähnt das Leitungsorgan nicht. Er setzt außer dem jährlichen Test in Absatz 6 keine Frequenzen. Er ermächtigt zu keinem technischen Regulierungsstandard. Wenn Ihnen eine Fundstelle "der RTS nach Artikel 24 Absatz 2" begegnet ist: den gibt es nicht. Der RTS, der in diesem Kapitel zählt, betrifft TLPT und beruht auf Artikel 26 Absatz 11.
Muss das Leitungsorgan das Testprogramm wirklich genehmigen?
Ja, allerdings nicht, weil Artikel 24 das so sagt, und dieser Unterschied zählt, sobald jemand Sie bittet, auf den entsprechenden Satz zu zeigen. Artikel 24 schweigt zum Leitungsorgan. Die Pflicht ergibt sich aus zwei Bestimmungen im Zusammenspiel:
Artikel 24 Absatz 1: Das Testprogramm ist "integraler Bestandteil des in Artikel 6 genannten IKT-Risikomanagementrahmens".
Artikel 5 Absatz 2: "Das Leitungsorgan des Finanzunternehmens legt alle Regelungen im Zusammenhang mit dem IKT-Risikomanagementrahmen gemäß Artikel 6 Absatz 1 fest, genehmigt sie, überwacht ihre Umsetzung und trägt die Verantwortung dafür."
Das Programm ist integraler Bestandteil des Rahmens. Das Leitungsorgan muss alle Regelungen im Zusammenhang mit dem Rahmen genehmigen. Also muss das Leitungsorgan das Programm genehmigen.
Die Genehmigung selbst einzuholen ist einfach: ein kurzer Tagesordnungspunkt und ein protokollierter Beschluss. Die Arbeit steckt darin, ein Programm zu haben, das man dem Leitungsorgan vorlegen kann, und darin, einer Aufsicht ohne Zögern zu erklären, woraus sich die Pflicht ableitet.
Die Kette ist tragfähig, und so werden Aufseher sie auch lesen. Sie bleibt aber eine Argumentationskette, und das sollten Sie von vornherein wissen statt erst bei der Nachfrage. Artikel 5 Absatz 2 listet in den Buchstaben a bis i durchaus konkrete Genehmigungspflichten auf, und das Testprogramm gehört nicht zu den namentlich genannten Punkten. Genannt und daher separat nachzuweisen sind unter anderem die Strategie für digitale operationale Resilienz unter Buchstabe d, die IKT-Geschäftsfortführungsleitlinie sowie die Reaktions- und Wiederherstellungspläne unter Buchstabe e, der Plan für interne IKT-Audits unter Buchstabe f, das Budget unter Buchstabe g und die Strategie für das IKT-Drittparteienrisiko unter Buchstabe h.
Zwei weitere Bestimmungen gehören dem Leitungsorgan selbst vorgelegt. Artikel 5 Absatz 4 verlangt von den Mitgliedern, "ausreichende Kenntnisse und Fähigkeiten aktiv auf dem neuesten Stand zu halten, um IKT-Risiken verstehen und bewerten zu können", einschließlich regelmäßiger spezieller Schulungen. Und Artikel 50 Absatz 5 sieht vor, dass die Mitgliedstaaten den zuständigen Behörden nach Maßgabe des nationalen Rechts die Befugnis übertragen, Verwaltungsstrafen und Abhilfemaßnahmen "gegen Mitglieder des Leitungsorgans und andere Personen, die nach nationalem Recht für den Verstoß verantwortlich sind", zu verhängen.
Die persönliche Haftung ist also real, aber sie ist genau auf die Weise real, wie die Verordnung sie konstruiert: über nationales Recht, gestützt auf Artikel 50 Absatz 5. Sie steht nicht frei im Raum, und eine präzise Darstellung überzeugt ein Leitungsorgan mehr als eine reißerische.
Artikel 25: eine beispielhafte Liste statt zehn Pflichttests
Das ist die folgenreichste Fehllesart im Umlauf. Artikel 25 Absatz 1 sieht vor, dass das Programm "die Durchführung angemessener Tests wie etwa Schwachstellenbewertungen und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Gap-Analysen, Überprüfungen der physischen Sicherheit, Fragebögen und Scan-Software-Lösungen, Quellcodeprüfungen, soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetrationstests" vorsieht.
"Wie etwa" ist beispielhaft gemeint. Die Pflicht besteht darin, angemessene Tests durchzuführen, ausgewählt über den risikobasierten Ansatz, den Artikel 24 Absatz 3 verlangt. Es handelt sich um eine Auswahlgrundlage statt um eine Compliance-Checkliste mit zehn abzuhakenden Punkten, und ein Programm, das jede aufgeführte Technik ohne Risikobegründung mechanisch gegen jedes System fährt, steht Artikel 24 Absatz 3 wohl ferner als eines, das begründet, was angemessen ist, und diese Begründung aufschreibt.
Diese Begründung aufzuschreiben geht schnell, für die meisten Landschaften ist es ein Nachmittag, und es ist die wertvollste Seite des gesamten Programmdokuments. Jede Technik der Liste mechanisch auf jedes System anzuwenden verbraucht ein Jahresbudget für sichtbare Betriebsamkeit und lässt Sie dennoch ohne das eine zurück, wonach Artikel 24 Absatz 3 tatsächlich fragt.
Unten steht die Liste aus Artikel 25 Absatz 1 vollständig, ergänzt um eine Spalte mit Turnus. Die Turnusangaben stammen von uns und sind als Ausgangspunkt gedacht. DORA setzt für keinen dieser Tests eine Frequenz fest, mit Ausnahme der jährlichen Pflicht in Artikel 24 Absatz 6. Wenn Sie sie übernehmen, übernehmen Sie sie als eigene Entscheidung, nicht als regulatorische Vorgabe.
| Testart (Wortlaut Artikel 25 Absatz 1) | Beispielhafter Turnus (von uns, nicht von DORA) | Hinweis |
| Schwachstellenbewertungen und -scans | Laufend oder monatlich | Zentralverwahrer und zentrale Gegenparteien trifft nach Artikel 25 Absatz 2 die besondere Pflicht, diese vor jeder Bereitstellung oder erneuten Bereitstellung durchzuführen. |
| Open-Source-Analysen | Laufend | Wird in Zusammenfassungen von Artikel 25 oft ganz weggelassen, obwohl der Text sie ausdrücklich nennt. |
| Netzwerksicherheitsbewertungen | Vierteljährlich oder halbjährlich | Segmentierung, Firewall-Regeln, Zugriffspfade. |
| Gap-Analysen | Jährlich | Speist die Rahmenüberprüfung nach Artikel 6 Absatz 5. |
| Überprüfungen der physischen Sicherheit | Jährlich | In Artikel 25 Absatz 1 ausdrücklich genannt; in rein IKT-orientierten Programmen häufig vergessen. |
| Fragebögen und Scan-Software-Lösungen | Nach Bedarf | Ebenfalls im Text genannt und ebenfalls meist in den Listen der "zehn Testarten" nicht enthalten. |
| Quellcodeprüfungen, soweit durchführbar | Je Release | Die Worte "soweit durchführbar" stehen in der Verordnung. Dokumentieren Sie die Begründung dort, wo es nicht durchführbar ist. |
| Szenariobasierte Tests | Halbjährlich oder jährlich | Tabletop-Übungen und Simulationen. |
| Kompatibilitätstests | Bei jeder wesentlichen Änderung | Interoperabilität nach Updates und Migrationen. |
| Leistungstests | Vierteljährlich oder halbjährlich | Last, Stress, Kapazität. |
| End-to-End-Tests | Halbjährlich oder jährlich | Vollständige Prozessketten einschließlich Failover und Wiederherstellung. |
| Penetrationstests | Jährlich für kritische Systeme | Ein gewöhnlicher Penetrationstest. Etwas anderes als TLPT, und DORA setzt dafür keine eigene Frequenz. |
Zwei Behauptungen, die aus Ihrem Programmdokument verschwinden sollten. Erstens: "Penetrationstests müssen mindestens alle drei Jahre durchgeführt werden." Das steht so nirgends in DORA. Der Dreijahreszyklus in Artikel 26 Absatz 1 gehört zu bedrohungsorientierten Penetrationstests und gilt nur für Unternehmen, die nach Artikel 26 Absatz 8 benannt wurden. Für gewöhnliche Penetrationstests gibt es in DORA keine eigene Frequenz; maßgeblich ist Artikel 24 Absatz 6, der mindestens jährlich angemessene Tests an Systemen verlangt, die kritische oder wichtige Funktionen unterstützen. Zweitens: "Artikel 25 formuliert mit 'umfasst', also sind alle Testarten verpflichtend." Er formuliert mit "wie etwa".
Wer tatsächlich in den Anwendungsbereich fällt
Hier lohnt Sorgfalt, denn die Ausnahmen werden häufig falsch wiedergegeben, und es sind nicht überall dieselben Ausnahmen.
- Die Programmpflicht aus Artikel 24 gilt für Finanzunternehmen mit Ausnahme von Kleinstunternehmen. Kleinstunternehmen stehen außerhalb der Programmpflicht selbst.
- Artikel 25 Absatz 3 sagt Kleinstunternehmen, wie sie an die Tests aus Artikel 25 Absatz 1 herangehen: durch die Verbindung eines risikobasierten Ansatzes mit strategischer Planung, wobei Ressourcen und Zeit gegen Dringlichkeit, Risikoart und Kritikalität abgewogen werden. Von Tests befreit sind sie damit nicht, sie unterliegen lediglich einer anderen Steuerung.
- Artikel 16 Absatz 1 ist wiederum etwas Eigenes: ein vereinfachter IKT-Risikomanagementrahmen für eine bestimmte abschließende Liste von Unternehmen, darunter kleine und nicht verflochtene Wertpapierfirmen sowie bestimmte ausgenommene Zahlungs- und E-Geld-Institute. Es handelt sich um ein eigenes Regime jenseits der Kleinstunternehmen, und die Vermengung beider ist ein häufiger Fehler.
- TLPT nach Artikel 26 Absatz 1 nimmt sowohl Kleinstunternehmen als auch die Unternehmen nach Artikel 16 Absatz 1 aus und greift dann nur für jene Unternehmen, die eine zuständige Behörde nach Artikel 26 Absatz 8 benannt hat.
Die Kleinstunternehmensausnahme und das vereinfachte Regime nach Artikel 16 Absatz 1 werden ständig vermengt, und der Fehler kostet in beide Richtungen: Häuser nehmen sich von einem Programm aus, das sie schulden, oder bauen eines auf, das sie nie gebraucht hätten. Ein sorgfältiger Blick auf die beiden Definitionen klärt das in einer Sitzung.
Wenn Sie unsicher sind, welcher Kategorie Sie angehören, ist diese Einordnung selbst ein Nachweis, nach dem eine Aufsicht fragen kann. Schreiben Sie sie auf und datieren Sie sie.
Das Jahresprogramm aufbauen
Ein konformes Programm ist ein gesteuertes Dokument, das Testaktivitäten an Ihre IKT-Risikolandschaft bindet, mit Verantwortlichen, Zeitplänen und einem Weg von der Feststellung über die Behebung bis zum Leitungsorgan. Sechs Bausteine, in der Reihenfolge ihrer Abhängigkeiten.
1. Anwendungsbereich
Beginnen Sie bei den kritischen oder wichtigen Funktionen, denn daran knüpft Artikel 24 Absatz 6 die jährliche Pflicht. DORA definiert eine kritische oder wichtige Funktion in Artikel 3 Nummer 22 als eine Funktion, deren Ausfall "die finanzielle Leistungsfähigkeit eines Finanzunternehmens oder die Solidität oder Fortführung seiner Dienstleistungen und Tätigkeiten erheblich beeinträchtigen würde". Jedes IKT-System und jede Anwendung, die eine solche Funktion unterstützt, fällt unter die mindestens jährliche Testpflicht, auch wenn die unterstützende Leistung von einem Dritten erbracht wird.
2. Kalender
Ordnen Sie jeder gewählten Testart einen Turnus zu und kennzeichnen Sie klar, welche Turnusangaben regulatorisch und welche Ihre eigenen sind. Genau eine ist regulatorisch: der jährliche Test an Systemen, die kritische oder wichtige Funktionen unterstützen, nach Artikel 24 Absatz 6. Für Unternehmen, die nach Artikel 26 Absatz 8 benannt wurden, läuft TLPT mindestens alle drei Jahre. Alles Übrige in Ihrem Kalender ist eine risikobasierte Entscheidung, die Sie getroffen haben und nach Artikel 24 Absatz 3 begründen können müssen.
3. Wer die Tests durchführt
Artikel 24 Absatz 4 verlangt unabhängige Tester, intern oder extern. Sind sie intern, müssen Sie ausreichende Ressourcen eigens zuweisen und Interessenkonflikte sowohl bei der Konzeption als auch bei der Durchführung des Tests vermeiden. TLPT verschärft das erheblich: Nach Artikel 27 Absatz 2 setzt der Einsatz interner Tester für einen TLPT voraus, dass die zuständige Behörde dies genehmigt und überprüft hat, dass Sie über ausreichende eigens zugewiesene Ressourcen verfügen und Interessenkonflikte gesteuert werden, und der Anbieter der Bedrohungsanalyse muss außerhalb des Unternehmens stehen. Artikel 26 Absatz 8 ergänzt, dass Unternehmen, die interne Tester einsetzen, bei jedem dritten Test externe Tester beauftragen müssen und dass als bedeutend eingestufte Kreditinstitute ausschließlich externe Tester einsetzen dürfen.
4. Priorisierung
Artikel 24 Absatz 3 verlangt den risikobasierten Ansatz und benennt die Abwägungspunkte: die sich verändernde IKT-Risikolandschaft, die spezifischen Risiken, denen das Unternehmen ausgesetzt ist, die Kritikalität von Informationsassets und Diensten sowie sonstige Faktoren, die das Unternehmen für angemessen hält. Dieser letzte Halbsatz verschafft Ihnen Spielraum, und Spielraum, den Sie nutzen, ohne Ihre Überlegungen aufzuschreiben, ist Spielraum, den Sie nicht verteidigen können.
5. Feststellungen
Artikel 24 Absatz 5 wird am häufigsten zu etwas paraphrasiert, das dort nicht steht. Hier der tatsächliche Wortlaut: Finanzunternehmen "richten Verfahren und Leitlinien ein, um sämtliche im Zuge der Durchführung der Tests zutage getretenen Probleme zu priorisieren, zu klassifizieren und zu beheben, und legen interne Validierungsmethoden fest, um festzustellen, dass alle ermittelten Schwachstellen, Mängel oder Lücken vollständig behoben werden."
Zwei Pflichten. Die Probleme priorisieren, klassifizieren und beheben; und validieren, dass sie vollständig behoben sind. Die zweite überspringen Programme regelmäßig, und deshalb genügt es nicht, eine Feststellung allein auf die Zusicherung eines Ingenieurs hin zu schließen. Schweregradklassen und nach Schweregrad gestaffelte Behebungsfristen sind sinnvolle Praxis, aber Sie legen sie selbst fest: DORA schreibt keine vor.
An der Validierung faulen Testprogramme still vor sich hin. Eine Behebung nachzutesten kostet einen Bruchteil dessen, was das Auffinden der Schwachstelle gekostet hat, und doch ist es der Schritt, der in einem vollen Quartal wegfällt, und zugleich der, den eine Aufsicht am leichtesten prüft: Wer hat diesen Abschluss bestätigt, und was hat diese Person konkret angesehen?
6. Berichterstattung an das Leitungsorgan
Legen Sie fest, was das Leitungsorgan wann erreicht. Artikel 5 Absatz 2 Buchstabe i verlangt Berichtswege, die das Leitungsorgan unter anderem über zumindest schwerwiegende IKT-bezogene Vorfälle und deren Auswirkungen sowie über Reaktions-, Wiederherstellungs- und Korrekturmaßnahmen informiert halten. Testergebnisse sind die natürliche Ergänzung dazu. Kritische Feststellungen sollten nicht auf den Quartalsrhythmus warten.
Was Tests kosten, und warum dieser Artikel es Ihnen nicht mehr sagt
Eine frühere Fassung dieses Artikels nannte Zahlen: 15.000 bis 50.000 EUR für einen externen Penetrationstest, 150.000 bis 500.000 EUR für ein TLPT-Mandat, sechs bis zwölf Monate Laufzeit. Diese Zahlen wurden entfernt, und es lohnt zu sagen, warum, statt sie stillschweigend zu löschen.
Sie ließen sich nicht belegen. DORA nennt keine Zahlen. Das TIBER-EU-Rahmenwerk der EZB und der technische Standard zu TLPT beschreiben die Phasen und die erforderlichen Rollen, veröffentlichen aber keine Kosten. Die ESAs ebenso wenig. Was am Markt existiert, ist eine Streuung von Anbieter- und Beratungsschätzungen, die um ein Vielfaches auseinandergehen, was zeigt, dass es Angebote für unterschiedliche Zuschnitte sind statt eine Messung von irgendetwas. Eine davon mit einem Eurozeichen davor zu wiederholen hätte eine Vermutung als Tatsache verkleidet, und ein Leitungsorgan, das danach budgetiert und dann die echte Zahl erfährt, ist schlecht beraten worden.
Belegbar ist Engeres und Nützlicheres. Artikel 5 Absatz 2 Buchstabe g macht das Budget zu einer eigenständigen Pflicht des Leitungsorgans: Es muss "ein angemessenes Budget zur Erfüllung der Anforderungen des Finanzunternehmens an die digitale operationale Resilienz in Bezug auf alle Arten von Ressourcen zuweisen und regelmäßig überprüfen", einschließlich Programmen zur Sensibilisierung für IKT-Sicherheit, Resilienzschulungen und IKT-Fähigkeiten der Mitarbeitenden. Das Leitungsorgan ist also verpflichtet, Resilienz angemessen zu finanzieren und diese Finanzierung erneut zu prüfen. Was "angemessen" in Ihrem Fall kostet, hängt von Ihrem Zuschnitt, Ihrer Systemlandschaft und Ihren Dienstleistern ab, und der einzige verlässliche Weg dorthin führt über eine Zuschnittsdefinition und eingeholte Angebote.
Dass DORA beim Preis schweigt, ist richtig. Eine in eine Verordnung geschriebene Zahl wäre binnen eines Jahres veraltet und würde jedes Unternehmen an einen Wert binden, der für die Systemlandschaft eines anderen gesetzt wurde. Die unbequeme Folge ist, dass die gesamte Budgetlast bei Ihnen liegt, und das erste Jahr wird von Häusern durchgängig unterschätzt.
Der Kostentreiber, den man aus der Verordnung ablesen kann, ist der Zuschnitt der Arbeit. TLPT verlangt beim Einsatz interner Tester einen externen Anbieter für Bedrohungsanalysen, bezieht die zuständige Behörde ein, läuft nach Artikel 26 Absatz 2 gegen produktive Systeme und folgt den Phasen des technischen TLPT-Standards. Das ist strukturell teurer als ein Scan. Dafür brauchen Sie einem Leitungsorgan keine erfundene Zahl zu nennen.
Das Programm in Venvera steuern
Venvera hat ein Modul für Resilienztests, und hier steht genau, was es leistet. Tests werden mit Art, Anwendungsbereich, Methodik, Testdienstleister, geplantem Termin und Status erfasst, aus einer Bibliothek von DORA-Testarten heraus, die zu jeder Art einen empfohlenen Turnus und Hinweise zum Zuschnitt mitbringt. Es gibt einen Zeitplan für wiederkehrende Tests, und das Dashboard zeigt, was geplant ist, was läuft und was überfällig ist.
Feststellungen hängen an dem Test, der sie hervorgebracht hat, jeweils mit Schweregrad, verantwortlicher Person, Fälligkeitsdatum, Behebungsplan und Behebungsstatus, sodass eine offene Feststellung eine verantwortliche Person und ein Datum hat statt nur eine Zeile in einem Bericht. Das ist die Mechanik, die Artikel 24 Absatz 5 für die Hälfte "priorisieren, klassifizieren und beheben" verlangt.
Die Validierungshälfte, also die interne Methodik, mit der festgestellt wird, dass eine Schwachstelle vollständig behoben ist, bleibt eine Disziplin, die Sie selbst ausüben müssen. Das Modul führt den Status, den Sie setzen; es entscheidet nicht für Sie, dass eine Behebung bewiesen ist, und das sagen wir lieber offen, als Sie ein Kontrolltor annehmen zu lassen, das es nicht gibt.
DORA ist eines von mehreren Regelwerken, die die meisten Finanzunternehmen gleichzeitig tragen, und Nachweise aus Resilienztests gehören zu dem Material, das sich am besten mehrfach verwenden lässt. Die Crosswalk-Engine lässt einmal erzeugte Nachweise auch ihre Gegenstücke unter NIS2 oder ISO 27001 bedienen, statt sie erneut aufzubauen. Speziell zur TLPT-Seite siehe unseren Leitfaden zu bedrohungsorientierten Penetrationstests nach den Artikeln 26 und 27.
Häufig gestellte Fragen
Verlangt DORA Artikel 24, dass das Leitungsorgan das Testprogramm genehmigt?
Mit diesen Worten nicht, und Artikel 24 erwähnt das Leitungsorgan überhaupt nicht. Die Pflicht besteht, sie ergibt sich aber über eine Kette aus zwei Bestimmungen. Artikel 24 Absatz 1 macht das Testprogramm zum "integralen Bestandteil des in Artikel 6 genannten IKT-Risikomanagementrahmens", und Artikel 5 Absatz 2 verlangt vom Leitungsorgan, alle Regelungen im Zusammenhang mit diesem Rahmen festzulegen, zu genehmigen, ihre Umsetzung zu überwachen und die Verantwortung dafür zu tragen. Die Genehmigung des Programms folgt aus beiden zusammen. Beachten Sie, dass Artikel 5 Absatz 2 in den Buchstaben a bis i konkrete Genehmigungspflichten aufführt und das Testprogramm dort nicht namentlich vorkommt; wer also behauptet, Artikel 24 verlange die Genehmigung aus sich heraus, hat Artikel 24 nicht gelesen.
Sind die zehn Testarten in Artikel 25 alle verpflichtend?
Nein. Artikel 25 Absatz 1 leitet seine Liste mit den Worten "wie etwa" ein, was sie beispielhaft macht statt abschließend oder verpflichtend. Die eigentliche Pflicht besteht darin, angemessene Tests durchzuführen, ausgewählt über den risikobasierten Ansatz, den Artikel 24 Absatz 3 verlangt. Die Liste enthält zudem mehr als zehn Punkte, darunter Open-Source-Analysen sowie "Fragebögen und Scan-Software-Lösungen", die beide in den kursierenden Tabellen der "zehn Pflichtarten" regelmäßig fehlen. Wählen Sie, was zu Ihrem Risiko passt, und dokumentieren Sie, warum.
Wie oft verlangt DORA Penetrationstests?
Für gewöhnliche Penetrationstests setzt DORA keine Frequenz. Die Behauptung, alle drei Jahre sei ein Penetrationstest fällig, verwechselt sie mit bedrohungsorientierten Penetrationstests, die Artikel 26 Absatz 1 mindestens alle drei Jahre verlangt und nur von Unternehmen, die ihre zuständige Behörde nach Artikel 26 Absatz 8 benannt hat. Die Frequenz, die Sie tatsächlich bindet, steht in Artikel 24 Absatz 6: mindestens jährlich angemessene Tests aller IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen. Ob der angemessene Test für ein bestimmtes System ein Penetrationstest ist, ist eine risikobasierte Bewertung nach Artikel 24 Absatz 3.
Was sagt DORA zu den Kosten eines Programms für Resilienztests?
Nichts. DORA nennt keine Kostenangaben, und weder das TIBER-EU-Rahmenwerk der EZB noch die ESAs veröffentlichen welche. Die zu Penetrationstests und TLPT-Mandaten kursierenden Zahlen stammen aus Anbieter- und Beratungsschätzungen, die weit auseinandergehen, weil sie unterschiedliche Zuschnitte bepreisen. Was die Verordnung sagt, steht in Artikel 5 Absatz 2 Buchstabe g: Das Leitungsorgan muss ein angemessenes Budget zur Erfüllung der Anforderungen des Unternehmens an die digitale operationale Resilienz über alle Ressourcenarten hinweg zuweisen und regelmäßig überprüfen. Das Budget ist eine Pflicht des Leitungsorgans; die Zahl ergibt sich aus einer Zuschnittsanalyse.
Gilt das Testprogramm auch für Kleinstunternehmen?
Die Programmpflicht aus Artikel 24 gilt für Finanzunternehmen mit Ausnahme von Kleinstunternehmen, sodass Kleinstunternehmen außerhalb der Programmpflicht selbst stehen. Von Tests befreit sind sie damit nicht: Artikel 25 Absatz 3 verlangt von ihnen, die in Artikel 25 Absatz 1 genannten Tests durchzuführen, indem sie einen risikobasierten Ansatz mit einer strategischen Planung der IKT-Tests verbinden und die zugewiesenen Ressourcen und die Zeit gegen Dringlichkeit, Risikoart und Kritikalität von Informationsassets und Diensten abwägen. Halten Sie das getrennt von Artikel 16 Absatz 1, der eine gänzlich andere Ausnahme darstellt und einen vereinfachten IKT-Risikomanagementrahmen für eine bestimmte abschließende Liste von Unternehmen vorsieht.
Was genau verlangt Artikel 24 Absatz 5 für Feststellungen?
Zwei Dinge, und das zweite wird meist übersehen. In den Worten der Verordnung selbst: Unternehmen "richten Verfahren und Leitlinien ein, um sämtliche im Zuge der Durchführung der Tests zutage getretenen Probleme zu priorisieren, zu klassifizieren und zu beheben, und legen interne Validierungsmethoden fest, um festzustellen, dass alle ermittelten Schwachstellen, Mängel oder Lücken vollständig behoben werden." Sie brauchen also einen Triage- und Behebungsprozess, und Sie brauchen zusätzlich eine Validierungsmethodik, die belegt, dass eine Feststellung wirklich geschlossen ist. Schweregradklassen und nach Schweregrad gestaffelte Behebungsfristen sind sinnvoll, bleiben aber Ihre Wahl: DORA schreibt keine vor.
Primärquellen
Jede Artikelfundstelle, jedes Zitat und jede Frequenz in diesem Leitfaden wurde gegen die untenstehenden Texte geprüft. Die früher in diesem Artikel enthaltenen Kostenangaben wurden entfernt, weil keine Primärquelle sie stützt.
- Verordnung (EU) 2022/2554 (DORA) - Artikel 3 Nummer 22, 5, 6, 16, 24, 25, 26, 27 und 50. Sie umfasst 64 Artikel und gilt seit dem 17. Januar 2025.
- Delegierte Verordnung (EU) 2025/1190 der Kommission - der RTS zu bedrohungsorientierten Penetrationstests: Kriterien, Anforderungen an Tester, Umfang, Phasen und Methodik.
- Delegierte Verordnung (EU) 2024/1774 der Kommission - der RTS zu Instrumenten, Methoden, Prozessen und Leitlinien des IKT-Risikomanagements.
- TIBER-EU-Rahmenwerk der EZB - das auf Bedrohungsanalysen gestützte Red-Teaming-Rahmenwerk, das TLPT zugrunde liegt. Veröffentlicht keine Kostenangaben.
Bringen Sie das Testprogramm dorthin, wo das Leitungsorgan es sieht
Geplante Tests, Feststellungen mit Verantwortlichen und Fristen sowie Berichte für das Leitungsorgan, geführt neben Ihren übrigen Pflichten.
Demo buchen →Zuletzt aktualisiert: Juli 2026. Allgemeine Information, keine Rechtsberatung. Die in diesem Artikel vorgeschlagenen Testfrequenzen sind beispielhafte Voreinstellungen von Venvera und keine regulatorischen Vorgaben; die einzige Frequenz, die DORA in Artikel 24 festlegt, ist der jährliche Test nach Artikel 24 Absatz 6. Gleichen Sie Artikelfundstellen mit dem geltenden Wortlaut und den Hinweisen Ihrer zuständigen Behörde ab.
