Digital Operational Resilience Testing und TLPT unter DORA

Problem in der Praxis

Viele Institute behandeln Resilienztests als technische Disziplin der IT. Es gibt jährliche Pentests, Schwachstellenscans laufen automatisiert, und die interne Revision prüft Kontrollen. Das wirkt wie ein solides Testprogramm, deckt die DORA-Logik aber nur teilweise ab.

Die erste Lücke entsteht beim Programmgedanken. DORA verlangt kein loses Bündel einzelner Tests, sondern ein zusammenhängendes Programm mit klarer Abdeckung der kritischen Systeme, mit Priorisierung nach Risiko, mit Nachverfolgung der Befunde und mit Nachweis gegenüber der Aufsicht. Einzelne Pentest-Reports erfüllen das nicht.

Die zweite Lücke entsteht beim TLPT. Sobald ein Institut als bedeutend identifiziert wird, reicht der gewohnte, eng umrissene Pentest nicht mehr. TLPT zielt auf reale Bedrohungsszenarien gegen produktive Systeme und erfordert Bedrohungsaufklärung, definierte Rollen und behördliche Begleitung. Wird das spät erkannt, fehlen Vorlauf, Mandat und interne Spielregeln.

CISO-Einordnung

Der CISO sollte die dritte Säule in zwei Ebenen denken.

Ebene eins ist das regelmäßige Testprogramm, das grundsätzlich alle DORA-pflichtigen Unternehmen betrifft. Dazu gehören je nach Risikoprofil verschiedene Testarten, etwa Schwachstellenscans und Penetrationstests; Basistests sind grundsätzlich jährlich vorgesehen. Für kleinere Einheiten greift die Proportionalität der Verordnung, die den Aufwand am Größen- und Risikoprofil ausrichtet.

Ebene zwei ist das TLPT, das nur für identifizierte, in der Regel bedeutende oder systemrelevante Einheiten verpflichtend ist. Welche Institute konkret in den Anwendungsbereich fallen und welche Anforderungen an Geltungsbereich, Testdurchführung und an die Tester gelten, ergibt sich aus dem Verordnungstext und dem zugehörigen technischen Regulierungsstandard (RTS) zu TLPT; diese Quellen sind für verbindliche Aussagen heranzuziehen.

Die wichtigste Einordnung ist die Abgrenzung. Ein regulärer Penetrationstest ist meist eng abgegrenzt, oft den Verteidigern bekannt und auf technische Befunde ausgerichtet. Ein Audit bewertet Kontrollen und Konformität gegen Kriterien, dokumenten- und nachweisbasiert. TLPT dagegen ist bedrohungsgeleitet: Ein Red Team emuliert reale Angreifer und deren Vorgehen gegen die produktiven Systeme, die kritische oder wichtige Funktionen stützen. Es wird behördlich begleitet, folgt definierten Rollen und prüft nicht nur Technik, sondern auch Erkennung und Reaktion der Organisation unter realistischen Bedingungen.

Umsetzungsperspektive

Aus CISO-Sicht trägt ein gestufter Aufbau.

• Bestandsaufnahme: Welche kritischen oder wichtigen Funktionen gibt es, und welche Systeme tragen sie? Diese Landkarte bestimmt den Geltungsbereich der Tests.
• Programmlogik statt Einzeltests: Testarten, Frequenzen, Verantwortliche, Befundnachverfolgung und Eskalation in einem Programm zusammenführen, das jährlich betrieben und nachgewiesen wird.
• TLPT-Betroffenheit klären: Frühzeitig prüfen, ob das Institut zu den identifizierten Einheiten gehören könnte, und den mehrjährigen Zyklus von mindestens drei Jahren in die Planung einbauen.
• TLPT-Vorbereitung: Bedrohungsaufklärung, Rollenmodell und die behördliche Begleitung organisieren. Typische Rollen sind ein steuerndes White Team, ein nicht eingeweihtes Blue Team und ein Red Team; die Bereitstellung der Bedrohungsinformationen erfolgt über spezialisierte Anbieter.
• Verzahnung mit Incident Response und BCM: Erkenntnisse aus Tests müssen in Wiederanlauf, Reaktionsprozesse und das IKT-Risikomanagement zurückfließen.

Der Methodenbezug zu TIBER-EU hilft, weil dort der Ablauf eines bedrohungsgeleiteten Tests, das Rollenmodell und die Einbindung der Behörde bereits etabliert sind. In Deutschland sind BaFin und Deutsche Bundesbank die zuständigen Stellen; sie begleiten auch die TLPT-Praxis.

Typische Fehler

1. TLPT wird wie ein größerer Pentest budgetiert und beauftragt, ohne Bedrohungsaufklärung, Rollenmodell und behördliche Begleitung.
2. Das Testprogramm bleibt eine Sammlung einzelner Reports ohne gemeinsame Abdeckung, Priorisierung und Befundnachverfolgung.
3. Der Geltungsbereich orientiert sich an Testumgebungen statt an den produktiven Systemen kritischer Funktionen.
4. Die TLPT-Betroffenheit wird zu spät geprüft, sodass Vorlauf und internes Mandat fehlen.
5. Testergebnisse fließen nicht in IKT-Risikomanagement, Incident Response und BCM zurück.
6. Das Leitungsorgan wird nicht eingebunden, obwohl es nach DORA die Gesamtverantwortung für den IKT-Rahmen trägt.

Risiken und Trade-offs

Tests auf produktiven Systemen erzeugen ein reales Betriebsrisiko. TLPT muss so gesteuert werden, dass kritische Dienste nicht gefährdet werden; das verlangt ein eingeweihtes Steuerungsteam und klare Abbruchregeln. Gleichzeitig verliert ein Test an Aussagekraft, wenn er zu stark abgesichert oder den Verteidigern bekannt ist.

Es gibt einen Trade-off zwischen Realitätsnähe und Beherrschbarkeit. Je echter das Szenario, desto höher der Erkenntniswert, aber auch der Aufwand und das Risiko. Ein weiterer Trade-off betrifft interne versus externe Tester: Externe bringen Unabhängigkeit und Spezialwissen, interne kennen die Umgebung; die zulässige Konstellation und die Anforderungen an Unabhängigkeit ergeben sich aus dem Verordnungstext und dem TLPT-RTS.

Schließlich besteht das Risiko der Scheinsicherheit. Ein bestandenes Audit oder ein unauffälliger Pentest bedeutet nicht, dass die Organisation einem realistischen, bedrohungsgeleiteten Angriff standhält.

Entscheidungspunkte

• Welche Funktionen gelten als kritisch oder wichtig, und welche Systeme definieren damit den Testgeltungsbereich?
• Ist das Institut potenziell ein identifiziertes Institut für TLPT, und wie wird der Dreijahreszyklus geplant?
• Welche Testarten und Frequenzen bilden ein angemessenes Programm für das eigene Risikoprofil?
• Werden Tester intern, extern oder gemischt gestellt, und wie wird Unabhängigkeit sichergestellt?
• Wie werden produktive Tests abgesichert (Steuerungsteam, Abbruchkriterien, Kommunikation)?
• Wie werden Befunde in IKT-Risikomanagement, Incident Response und BCM zurückgeführt?

Praktische Empfehlungen

1. Bauen Sie ein zusammenhängendes Testprogramm auf, nicht eine Sammlung einzelner Pentests, und weisen Sie Abdeckung, Priorisierung und Befundnachverfolgung nach.
2. Klären Sie die TLPT-Betroffenheit früh und planen Sie den mehrjährigen Zyklus mit Vorlauf für Bedrohungsaufklärung und behördliche Begleitung.
3. Trennen Sie in der internen Kommunikation klar zwischen Pentest, Audit und TLPT, damit Erwartungen, Budget und Risiko zusammenpassen.
4. Definieren Sie für produktive Tests ein Steuerungsteam und Abbruchregeln, bevor der erste Angriff läuft.
5. Verankern Sie die Rückführung der Befunde in IKT-Risikomanagement, Incident Response und BCM als festen Schritt.
6. Binden Sie das Leitungsorgan ein und dokumentieren Sie Entscheidungen, da die Gesamtverantwortung für den IKT-Rahmen dort liegt.

Relevante Normreferenzen

• DORA, Verordnung (EU) 2022/2554, Kapitel IV (Testen der digitalen operationalen Resilienz, im Wesentlichen Art. 24 bis 27): regelmäßiges Testprogramm und TLPT. Maßgeblich ist der EUR-Lex-Volltext.
• Technischer Regulierungsstandard (RTS) zu TLPT der Europäischen Aufsichtsbehörden (Joint Committee aus EBA, EIOPA, ESMA): Konkretisierung von Geltungsbereich, Durchführung und Testeranforderungen. Maßgeblich ist die jeweils geltende delegierte Verordnung.
• TIBER-EU: methodischer Bezugsrahmen für bedrohungsgeleitete Tests.
• ISO/IEC 27001: ISMS als möglicher Umsetzungsrahmen für Teile des IKT-Risikomanagements; deckt jedoch das DORA-spezifische TLPT nicht ab (nur Referenz).
• NIST-Rahmenwerke (z. B. CSF): nutzbar als Control- und Outcome-Bezug für die operative Umsetzung, nicht normativ.