DORA-Anforderungen an Penetrationstests jenseits von TLPT — das Testprogramm nach Artikel 24–25

Kapitel IV der Verordnung (EU) 2022/2554 baut das Testen in zwei Stufen auf.

• Das Testprogramm (Art. 24 und 25) gilt für Finanzunternehmen, die keine Kleinstunternehmen sind. Auch Kleinstunternehmen testen, kombinieren aber nach Art. 25(3) einen risikobasierten Ansatz mit strategischer Planung und wägen den Ressourceneinsatz gegen Dringlichkeit und Art des Risikos ab.
• Bedrohungsorientierte Penetrationstests (TLPT, Art. 26 und 27) gelten nur für Finanzunternehmen, die die zuständigen Behörden anhand ihrer Auswirkungen, ihrer systemischen Bedeutung und ihres IKT-Risikoprofils benennen. Kleinstunternehmen und Unternehmen unter dem vereinfachten IKT-Risikomanagementrahmen nach Art. 16(1) sind ausgenommen. Benannte Unternehmen führen mindestens alle drei Jahre einen TLPT durch.

Die meisten Banken, Versicherer, Wertpapierfirmen, Zahlungs- und E-Geld-Institute werden nie eine TLPT-Mitteilung erhalten. Keines von ihnen ist von der ersten Stufe befreit, und genau dort prüft die Aufsicht, ob regelmäßig getestet wird, ob die kritischen oder wichtigen Funktionen abgedeckt sind und ob die Tests tatsächlich zur Behebung führen. Zur zweiten Stufe siehe TLPT nach DORA Art. 26 und das Playbook zum DORA-TLPT-Einsatz.

Artikel 24 setzt den Rahmen. Das Programm muss sein:

1. Solide und umfassend, Teil des IKT-Risikomanagementrahmens nach Art. 6, um die Vorbereitung auf IKT-bezogene Vorfälle zu bewerten, Schwächen, Mängel und Lücken zu ermitteln und Korrekturmaßnahmen umgehend umzusetzen (Art. 24(1)).
2. Eine Reihe von Bewertungen, Tests, Methoden, Verfahren und Tools, angewandt nach Art. 25 und 26 (Art. 24(2)).
3. Risikobasiert, unter Berücksichtigung der sich wandelnden IKT-Risikolandschaft, der spezifischen Risiken des Unternehmens und der Kritikalität von Informationsassets und Diensten (Art. 24(3)).
4. Von unabhängigen Parteien durchgeführt, intern oder extern. Interne Tester benötigen ausreichende Ressourcen und die Vermeidung von Interessenkonflikten während Konzeption und Durchführung (Art. 24(4)).
5. An die Behebung gekoppelt: Verfahren und Strategien, um alle festgestellten Probleme zu priorisieren, zu klassifizieren und zu beheben, sowie interne Validierungsmethoden, die bestätigen, dass jede Schwäche vollständig behoben ist (Art. 24(5)).
6. Jährlich bei dem, was zählt: mindestens jährlich angemessene Tests aller IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen (Art. 24(6)).

Artikel 25(1) nennt die Tests, die das Programm vorsieht, im Einklang mit den Verhältnismäßigkeitskriterien des Art. 4(2): Schwachstellenbewertungen und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Lückenanalysen, Überprüfungen der physischen Sicherheit, Fragebögen und Scansoftwarelösungen, Quellcodeprüfungen, soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetrationstests. Artikel 25(2) fügt einen ausdrücklichen Auslöser hinzu: Zentralverwahrer und zentrale Gegenparteien führen Schwachstellenbewertungen vor jeder Bereitstellung oder erneuten Bereitstellung neuer oder bestehender Anwendungen, Infrastrukturkomponenten und IKT-Dienste durch, die kritische oder wichtige Funktionen unterstützen.

Die Delegierte Verordnung (EU) 2024/1774 der Kommission, der RTS zum IKT-Risikomanagementrahmen, ergänzt operative Details, die in das Testprogramm einfließen.

• Wöchentliche Scans (Art. 10(2)): Die Verfahren für das Schwachstellenmanagement müssen automatisierte Schwachstellenscans und -bewertungen der IKT-Assets sicherstellen, mit Häufigkeit und Umfang entsprechend ihrer Klassifizierung und ihrem Risikoprofil, und mindestens wöchentlich für IKT-Assets, die kritische oder wichtige Funktionen unterstützen. Derselbe Artikel verlangt die Nachverfolgung von Drittanbieter- und Open-Source-Bibliotheken, die Priorisierung von Patches nach Kritikalität und Asset-Risiko, die Überwachung und Überprüfung der Behebung sowie die Aufzeichnung jeder entdeckten Schwachstelle bis zu ihrer Behebung.
• Code- und Pakettests (Art. 16): Das Verfahren für Erwerb, Entwicklung und Wartung umfasst Quellcodeprüfungen mit statischen und dynamischen Tests, Sicherheitstests von aus dem Internet erreichbaren Systemen und Anwendungen, Sicherheitstests von Softwarepaketen spätestens in der Integrationsphase und, soweit durchführbar, Analyse und Test von Drittanbieter- und Open-Source-Code, bevor er in die Produktion gelangt.
• Vereinfachter Rahmen (Art. 36): Unternehmen nach Art. 16(1) DORA erstellen einen Plan für IKT-Sicherheitstests, der die Wirksamkeit ihrer Sicherheitsmaßnahmen validiert, und aktualisieren diese Maßnahmen nach Tests an Systemen, die kritische oder wichtige Funktionen unterstützen, unverzüglich.

Der wöchentliche Scan ist die konkreteste Häufigkeit im gesamten DORA-Testgefüge, und er steht im RTS zum Risikomanagement, nicht in den Artikeln 24 und 25. Teams, die nur um den jährlichen Test herum planen, übersehen ihn häufig.

Streng gelesen nennt Artikel 25(1) den Penetrationstest nur als eines der Beispiele für Tests, die das Programm vorsieht, und Artikel 24(6) verlangt mindestens jährlich „angemessene Tests“ kritischer oder wichtiger Systeme. Die Verordnung sagt nicht, dass jedes System jedes Jahr einem Penetrationstest unterzogen werden muss.

In der Praxis ist der Spielraum, darauf zu verzichten, gering. Der erklärte Zweck des Programms ist es, Schwächen und Lücken zu ermitteln (Art. 24(1)). Ein Schwachstellenscan sagt Ihnen, was fehlt; er sagt Ihnen nicht, ob ein Angreifer es nutzen kann, um eine kritische Funktion zu erreichen. Für einen aus dem Internet erreichbaren Dienst, ein Fernzugriffs-Gateway oder die Identitätsinfrastruktur hinter einer kritischen Funktion lässt sich kaum argumentieren, dass Scans allein der angemessene Test sind. Die vertretbare Position: Halten Sie für jede kritische oder wichtige Funktion fest, welche Testarten Sie anwenden und warum, und sehen Sie Penetrationstests überall dort vor, wo die Ausnutzbarkeit die Frage ist. Wenn Sie für ein System einen leichteren Test wählen, dokumentieren Sie die Begründung; das Programm ist risikobasiert, und eine begründete Entscheidung ist genau das, was der Text verlangt.

Ein Programm, das in der Aufsicht Bestand hat, umfasst in der Regel:

• Eine Zuordnung kritischer oder wichtiger Funktionen zu IKT-Systemen und -Anwendungen, einschließlich derjenigen, die an IKT-Drittdienstleister ausgelagert sind. Art. 24(6) wird an dieser Liste gemessen, daher braucht jedes System darauf mindestens einen angemessenen Test pro Jahr.
• Eine Testmatrix pro System: wöchentliche automatisierte Scans (RTS Art. 10), Schwachstellenanalyse und Netzwerksicherheitsbewertung, Penetrationstests von außen und von innen mit den Rechten eines Standardbenutzers, Quellcodeprüfung für selbst entwickelten und angepassten Code, soweit durchführbar, szenariobasierte und End-to-End-Tests für die Funktionen selbst.
• Dokumentierte Unabhängigkeit: wer getestet hat, ob intern oder extern, wie Interessenkonflikte vermieden wurden und welche Ressourcen eingesetzt wurden (Art. 24(4)).
• Ein Register der Befunde: Klassifizierung, Priorität, Verantwortlicher, Zieltermin, Behebung und ein Validierungsschritt, der die Korrektur bestätigt (Art. 24(5)). Ein Befund ist geschlossen, wenn der Retest bestanden ist, nicht wenn das Ticket geschlossen ist.
• Auslöser außerhalb des Kalenders: größere Änderungen, neue aus dem Internet erreichbare Dienste und, bei Zentralverwahrern und zentralen Gegenparteien, jede Bereitstellung oder erneute Bereitstellung für kritische Funktionen (Art. 25(2)).

Halten Sie die Unterscheidung zwischen Black-Box und Gray-Box in der Matrix ausdrücklich fest; siehe Black-Box- vs. Gray-Box-Tests. Ein Test von innen nach außen zeigt, ob die Segmentierung rund um eine kritische Funktion hält, wenn ein einzelner Arbeitsplatzrechner kompromittiert ist.

Die Delegierte Verordnung (EU) 2025/1190 der Kommission vom 13. Februar 2025, veröffentlicht am 18. Juni 2025, ist der RTS zu TLPT. Sie legt die Kriterien fest, die die Behörden anwenden, sowie eine Standardliste von Unternehmen, von denen sie TLPT verlangen, sofern die Bewertung nicht zeigt, dass dies nicht gerechtfertigt ist: Kreditinstitute, die G-SRI oder A-SRI sind oder einem solchen angehören, Zahlungsinstitute und E-Geld-Institute mit mehr als EUR 150 Milliarden an Zahlungsvorgängen in jedem der beiden Vorjahre (oder, bei E-Geld-Instituten, EUR 40 Milliarden ausstehendem E-Geld), Zentralverwahrer, zentrale Gegenparteien, Handelsplätze mit dem größten nationalen oder einem erheblichen EU-Marktanteil sowie bestimmte Versicherungs- und Rückversicherungsunternehmen (Art. 2).

Die Merkmale, die TLPT von jedem internen Testen unterscheiden:

• Produktive Live-Systeme, die mehrere oder alle kritischen oder wichtigen Funktionen unterstützen, mit einem von der Behörde validierten Umfang (DORA Art. 26(2)).
• Bedrohungsorientierte Szenarien eines Anbieters von Bedrohungsinformationen, der extern zum Finanzunternehmen sein muss, auch wenn interne Tester eingesetzt werden (DORA Art. 27(2)(c)).
• Tester: externe Tester, die Art. 27(1) erfüllen, oder interne Tester nur mit Genehmigung der Behörde, ausreichenden Ressourcen und ohne Interessenkonflikte; ein Unternehmen mit internen Testern muss bei jedem dritten Test externe Tester beauftragen, und bedeutende Kreditinstitute im SSM müssen ausschließlich externe Tester einsetzen (DORA Art. 26(8) und 27(2)). Nach den Erwägungsgründen des RTS gilt ein Team aus internen und externen Testern als Test mit internen Testern.
• Eine aktive Red-Team-Phase von mindestens 12 Wochen, danach ein Replay und eine Purple-Teaming-Übung mit dem Blue Team innerhalb von 10 Wochen nach deren Ende (RTS Art. 11(5) und 12(5)).
• Eine Bestätigung der Behörde nach der Zusammenfassung der Befunde und den Behebungsplänen (DORA Art. 26(6) und (7)).

Kein Tool, so autonom es auch sein mag, macht aus internen Tests einen TLPT. Interne Tests können aber sicherstellen, dass der TLPT für die richtigen Fragen eingesetzt wird.

Zwölf Wochen bedrohungsorientiertes Red Teaming sind teuer. Wenn das externe Team über ein ungepatchtes Edge-Gerät oder ein Standardpasswort eindringt, das ein wöchentlicher Scan hätte finden können, beweist der Test etwas, das Sie bereits hätten wissen müssen, und für die Fragen zu Erkennung und Reaktion, die TLPT beantworten soll, bleibt weniger Zeit.

Kontinuierliche interne Tests in den Monaten vor einem TLPT schließen diese Lücke:

• Zuerst die bekannten ausnutzbaren Pfade beseitigen. Validieren Sie, welche Befunde auf den Systemen im künftigen TLPT-Umfang tatsächlich ausnutzbar sind, beheben Sie sie und testen Sie erneut.
• Das Innere testen, nicht nur den Perimeter. TLPT-Szenarien setzen meist einen ersten Zugangspunkt voraus; Gray-Box-Kampagnen von einem Standardbenutzerkonto aus zeigen, wie weit laterale Bewegung heute reicht.
• Die Nachweise proben. Die Behebungspläne und Befundzusammenfassungen, die der TLPT-Abschluss erfordert, lassen sich leichter erstellen, wenn die Organisation bereits ein Befundregister mit Validierung nach Art. 24(5) führt.
• Das Blue Team auf die Probe stellen. Zu wissen, dass interne Tests nach Zeitplan laufen, ist nicht dasselbe wie zu wissen, ob das SOC sie erkennt; vergleichen Sie, was getestet wurde, mit dem, was alarmiert wurde.

Dieselbe Arbeit deckt den jährlichen Test nach Art. 24(6) für Unternehmen ab, die nie benannt werden; sie ist also nicht verloren, wenn die TLPT-Mitteilung nie eintrifft.

Ein autonomes KI-Red-Team für Netzwerke und Infrastruktur ist kein TLPT-Anbieter, liefert keine Bedrohungsinformationen und macht Ihr internes Team nicht unabhängig im Sinne von Art. 24(4); Ressourcen und Kontrollen gegen Interessenkonflikte müssen Sie weiterhin selbst dokumentieren. Es gibt Ihnen eine Möglichkeit, einen Großteil des Programms nach Art. 24–25 zwischen externen Einsätzen durchzuführen und nachzuweisen.

• Zeitgesteuerte und änderungsgetriebene Kampagnen im Black-Box-Modus von außen und im Gray-Box-Modus mit Standardbenutzerrechten, auf den Systemen, die kritische oder wichtige Funktionen unterstützen.
• Nachweislich ausnutzbare Befunde, also genau die Eingabe, die die Priorisierung nach Art. 24(5) braucht, und Retests auf Abruf als Validierungsschritt, der jeden Befund schließt.
• Framework-Mapping der Ergebnisse auf DORA- (Art. 24 bis 27) und TIBER-EU-Kontrollen, unter den 34 von der Engine unterstützten Frameworks, mit exportierbaren Compliance-Berichten.
• Menschliche Freigabe riskanter Schritte: Fünf Autonomiestufen legen fest, was auf einen Operator wartet, und Exploit-Proofs-of-Concept können zur Prüfung zurückgehalten werden. Auf Produktivsystemen, die kritische Funktionen unterstützen, ist das die Kontrolle, die verhindert, dass der Test selbst zum Vorfall wird; siehe Human-in-the-Loop.
• Integrität der Nachweise: Jeder Angriffsversuch ist ein Ed25519-signierter Eintrag in einer SHA-256-Hash-Kette pro Kampagne, offline überprüfbar, und Berichte und Bundles sind signiert.
• Keine Kundendaten verlassen die Appliance: Die Modelle laufen auf der Appliance ohne externen KI-Dienst, sodass Befunde über Ihre kritischen Systeme nicht an einen externen KI-Anbieter gesendet werden. Siehe On-Premise-KI-Red-Team.

• Verordnung (EU) 2022/2554 (DORA), Art. 16 und 24 bis 27 (EUR-Lex)
• Delegierte Verordnung (EU) 2024/1774 der Kommission, RTS zum IKT-Risikomanagementrahmen, Art. 10, 16 und 36 (EUR-Lex)
• Delegierte Verordnung (EU) 2025/1190 der Kommission, RTS zu bedrohungsorientierten Penetrationstests (EUR-Lex)