DORA TLPT: Zeitplan, Rollen und Fristen nach RTS 2025/1190

Wenn die BaFin oder die EZB Ihr Institut für einen bedrohungsgeleiteten Penetrationstest nach DORA benennt, beginnt ein Projekt, das deutlich mehr ist als ein großer Pentest. Ein Threat-Led Penetration Testing (TLPT) läuft auf Produktivsystemen, bindet Aufsicht, externe Threat-Intelligence-Anbieter und Red-Team-Tester ein und folgt festen Fristen aus dem technischen Regulierungsstandard (RTS) 2025/1190. Wer die Rollen und den Zeitplan erst versteht, wenn die Behörde bereits anklopft, verliert Monate.

Dieser Beitrag ordnet, wer von der TLPT-Pflicht betroffen ist, welche Rollen ein Test braucht, welche Fristen die RTS für die einzelnen Phasen vorgibt und wie ein realistischer Zeitplan über sechs bis zwölf Monate aussieht. Außerdem klären wir, welche Anforderungen an Tester gelten und wie IKT-Dienstleister über Pooled Testing eingebunden werden.

Wir schreiben aus der Perspektive des Red-Team-Testers, der diese Tests durchführt. Die regulatorischen Angaben folgen DORA (Verordnung (EU) 2022/2554) und der RTS 2025/1190; sie ersetzen keine Abstimmung mit Ihrer Aufsicht.

Wer ist betroffen – und wie oft

DORA gilt seit dem 17. Januar 2025 für Finanzunternehmen in der EU. Die Pflicht zum TLPT nach Art. 26 und 27 trifft aber nicht alle Beaufsichtigten, sondern nur die Institute, die die zuständige Behörde auf Basis von Kriterien wie Systemrelevanz, Marktanteil und Komplexität der IKT-Landschaft benennt. In Deutschland ist das die BaFin, für bedeutende Institute im einheitlichen Aufsichtsmechanismus die EZB. Operativ begleitet die Deutsche Bundesbank den Test mit ihrem TLPT-Team (dem TIBER Cyber Team), das als Test Manager auftritt.

Benannte Unternehmen müssen mindestens alle drei Jahre einen TLPT durchführen. Die Behörde kann den Rhythmus im Einzelfall anpassen. Der Test findet auf Produktivsystemen statt, die kritische oder wichtige Funktionen unterstützen, und umfasst mindestens drei Angriffsszenarien, die aus der Bedrohungslage des Instituts abgeleitet werden. Mehr zu den Hintergründen des Rahmenwerks finden Sie im Glossar unter DORA und TLPT.

Wer nicht benannt ist, kann freiwillig nach TIBER-EU beziehungsweise TIBER-DE testen. Das Vorgehen ist weitgehend identisch; der Unterschied liegt im regulatorischen Status des Ergebnisses. Den Vergleich der Rahmenwerke behandelt unser Beitrag TIBER-EU, DORA TLPT und CBEST im Vergleich.

Die Rollen im TLPT

Ein TLPT ist ein Mehrparteienprojekt. Jede Rolle hat einen klaren Auftrag, und die Trennung zwischen eingeweihten und nicht eingeweihten Personen ist der Kern der Methodik.

• Control Team (CT): Das kleine, eingeweihte Team im Institut, früher White Team genannt. Es steuert den Test, hält Kontakt zur Behörde, bewertet Risiken einzelner Angriffsschritte und gibt Freigaben. Typisch sind drei bis fünf Personen aus CISO-Bereich, IT-Betrieb und Compliance, mit einem benannten Control Team Lead. Details zur Rolle stehen im Glossar unter Control Team.
• Blue Team: SOC, Incident Response und IT-Betrieb, die vom Test nichts wissen. Ihre Reaktion auf die Angriffe ist das eigentliche Messobjekt. Wird die Vertraulichkeit verletzt, verliert der Test an Aussagekraft.
• Threat-Intelligence-Provider (TIP): Ein externer Dienstleister, der die Bedrohungslage des Instituts analysiert, die relevanten Angreifergruppen identifiziert und den Targeted Threat Intelligence Report erstellt. Daraus entstehen die Angriffsszenarien.
• Red-Team-Tester (RTT): Das Angriffsteam, das die Szenarien auf Produktivsystemen umsetzt, wöchentlich an das Control Team berichtet und am Ende den Red-Team-Report liefert.
• TLPT-Behörde: In Deutschland die Bundesbank mit dem TLPT-Team im Auftrag der BaFin oder EZB. Sie begleitet Scoping, Szenarien und Abschluss, nimmt die Berichte entgegen und stellt am Ende die Attestierung aus.

Eine weitere Konstellation ist der Einsatz interner Tester. DORA erlaubt das unter Bedingungen, verlangt dann aber zwingend einen externen Threat-Intelligence-Provider und für jeden dritten Test externe Tester.

Phasen und Fristen nach RTS 2025/1190

Die RTS gliedert den Test in drei Phasen: Vorbereitung, Test und Abschluss. Für einzelne Schritte nennt sie Mindestdauern und Fristen, die wir hier zusammenfassen.

Wichtig für die Planung: Die zwölf Wochen aktive Phase sind ein Minimum, kein Richtwert. In der Praxis verlängern Freigabeprozesse, Wartungsfenster und die Bedingung, Produktivsysteme nicht zu stören, die Phase häufig. Das Control Team sollte Reserve einplanen.

Realistischer Zeitplan über 6 bis 12 Monate

Der folgende Zeitplan ist eine Orientierung aus unserer Projekterfahrung. Je nach Komplexität des Instituts und Verfügbarkeit der Beteiligten verschieben sich die Monate.

Die Beschaffung ist häufig der unterschätzte Zeitfresser. Rahmenverträge mit qualifizierten Anbietern, die schon vor der Benennung stehen, verkürzen den Zeitplan um Wochen. Wie Sie Rules of Engagement für Tests auf Produktivsystemen ausgestalten, beschreibt unser Beitrag zu sicheren Red-Team-Einsätzen.

Anforderungen an Tester und TI-Provider

DORA Art. 27 und die RTS stellen Anforderungen an externe Tester und Threat-Intelligence-Provider. Sie sollen sicherstellen, dass ein Test auf Produktivsystemen von Teams durchgeführt wird, die dafür qualifiziert und abgesichert sind.

1. Eignung und Reputation: Nachgewiesene Erfahrung in Threat Intelligence beziehungsweise Red Teaming, insbesondere im Finanzsektor.
2. Zertifizierung: Anerkannte Zertifikate der eingesetzten Personen oder Akkreditierung des Unternehmens; typische Nachweise sind Zertifizierungen wie OSCP, OSEP oder CRTO sowie Zertifizierungen über CREST.
3. Methodik und Qualitätssicherung: Dokumentiertes Vorgehen, Risikomanagement für den Test selbst, Schutz der im Test gewonnenen Daten.
4. Berufshaftpflicht: Eine Versicherung, die Fehlverhalten und Fahrlässigkeit im Rahmen des Tests abdeckt.
5. Unabhängigkeit: Bei internen Testern ist der Threat-Intelligence-Provider zwingend extern, und Interessenkonflikte müssen ausgeschlossen sein.

Prüfen Sie bei der Auswahl auch weiche Kriterien: Wie geht der Anbieter mit Abbruchkriterien um, wie sieht ein Beispielbericht aus, wie läuft der Rückbau von Persistenzmechanismen nach dem Test? Diese Punkte entscheiden über die Sicherheit eines Tests auf Produktivsystemen.

IKT-Dienstleister und Pooled Testing

Kritische Funktionen laufen heute selten vollständig im eigenen Rechenzentrum. Kernbankensysteme, Zahlungsabwicklung oder Cloud-Plattformen werden von IKT-Drittdienstleistern betrieben. DORA verlangt, dass solche Dienstleister in den TLPT einbezogen werden, wenn sie Systeme unterstützen, die im Scope liegen.

Weil ein Dienstleister nicht für jeden seiner Kunden einen eigenen Test auf seiner Infrastruktur dulden kann, sieht DORA das Pooled Testing vor: Mehrere Finanzunternehmen, die denselben Dienstleister nutzen, führen einen gemeinsamen Test durch. Der Dienstleister beauftragt dabei die Tester, die Finanzunternehmen bleiben über ein gemeinsames Control Team verantwortlich, und die Behörde stimmt dem Vorgehen zu. Voraussetzung ist, dass der Dienstleister die Qualität und Sicherheit des Tests nachweisen kann und das Ergebnis jedem beteiligten Institut zugänglich wird.

Für das Control Team heißt das: Vertragsgrundlagen mit Dienstleistern früh prüfen. Enthält der Vertrag ein Recht auf Sicherheitstests? Wer trägt Haftungsrisiken, wenn ein Test den Betrieb beeinträchtigt? Diese Fragen gehören in die Scoping-Phase, nicht in Monat fünf. Allgemeine Hinweise zum Umgang mit Drittparteien finden Sie im Beitrag Lieferkette und Drittparteien-Risiko testen.

Abschluss, Remediation und Attestierung

Nach der aktiven Phase wird das Blue Team informiert. Der Red-Team-Report dokumentiert die Angriffspfade mit Zeitstempeln und Indikatoren, der Blue-Team-Report hält fest, was erkannt wurde und welche Alarme ohne Reaktion blieben. Im Replay-Workshop gehen beide Teams die Timeline gemeinsam durch, im anschließenden Purple Teaming werden Detektionslücken direkt bearbeitet. Was ein belastbarer Bericht enthalten muss, haben wir in Red-Team-Bericht: Was drin stehen muss zusammengefasst.

Der zusammenfassende Bericht an die Behörde enthält den Remediation-Plan mit Root-Cause-Analyse: nicht nur die Schwachstelle, sondern die organisatorische oder technische Ursache dahinter. Nach Prüfung stellt die Behörde die Attestierung aus, die innerhalb der EU gegenseitig anerkannt wird. Die Umsetzung der Maßnahmen begleitet die Aufsicht im Rahmen ihrer regulären Tätigkeit.

Fazit

Ein DORA-TLPT ist ein Projekt von sechs bis zwölf Monaten mit klaren Rollen und festen Fristen: mindestens zwölf Wochen aktive Phase, vier Wochen für den Red-Team-Report, zehn Wochen für Blue-Team-Report, Replay und Purple Teaming, acht Wochen für die Zusammenfassung an die Behörde. Wer das Control Team früh aufstellt, Beschaffung und Dienstleisterverträge vor der Benennung klärt und Freigabeprozesse vorab definiert, hält den Zeitplan. Dieser Beitrag ersetzt keine Rechtsberatung und keine Abstimmung mit Ihrer Aufsichtsbehörde. Wenn Sie einen TLPT vorbereiten oder einen freiwilligen TIBER-Test planen, finden Sie unter TIBER-EU & DORA TLPT unser Vorgehen – oder sprechen Sie uns direkt über Kontakt an.

Quellen

• Verordnung (EU) 2022/2554 (DORA), Art. 26 und 27, eur-lex.europa.eu
• Delegierte Verordnung (EU) 2025/1190 (RTS zu TLPT), 2025, eur-lex.europa.eu
• Europäische Zentralbank, TIBER-EU Framework, Fassung Februar 2025, ecb.europa.eu
• Deutsche Bundesbank, TIBER-DE und TLPT, bundesbank.de
• BaFin, Informationen zu DORA, bafin.de

Häufige Fragen zum Thema