DORA-TLPT-RTS: Anforderungen und Fristen gemäß 2025/1190

Die Entscheidung, bei der Ihnen dieser Leitfaden hilft

Die endgültigen technischen Regulierungsstandards (RTS) für TLPT konkretisieren die DORA-Pflicht zu einem spezifischen Durchführungsprozess. Trennen Sie zunächst die Zeitpläne für Vorbereitung, aktive Tests und Abschluss und ordnen Sie dann die erforderlichen Entscheidungen und Nachweise den verantwortlichen Personen zu. Dieser Leitfaden folgt der Verordnung (EU) 2025/1190 und behandelt einen früheren Entwurf nicht als geltende Vorschrift.

Was sind die RTS für DORA TLPT?

Die DORA-TLPT-RTS ist die Delegierte Verordnung (EU) 2025/1190 der Kommission. Sie überführt die DORA-Pflicht zu fortgeschrittenen bedrohungsgeleiteten Penetrationstests in einen detaillierten Prozess: welche Finanzunternehmen ausgewählt werden, wie ein Test gesteuert und abgegrenzt wird, welche Nachweise Anbieter erbringen müssen, wie die Tests ablaufen und welche Belege anschließend vorliegen müssen.

Für einen CISO, die Leitung eines Kontrollteams oder eine für die Beschaffung verantwortliche Person besteht die praktische Herausforderung darin, diese Anforderungen zu einem einzigen umsetzbaren Programm zu verbinden. Ein hervorragender technischer Bericht kann fehlende behördliche Genehmigungen, einen unzureichend begründeten Umfang oder einen nie geplanten Abschlussprozess nicht ausgleichen. Ebenso ist ein vollständiger Dokumentensatz nur begrenzt nützlich, wenn er nicht erklären kann, was mit den geprüften kritischen Funktionen geschehen ist.

Dieser Leitfaden orientiert sich an den endgültigen RTS und unterscheidet gesetzliche Anforderungen von unseren praktischen Planungsvorschlägen. Einen Überblick über den Auftrag finden Sie auf unserer Startseite zu DORA-TLPT-Dienstleistungen. Einen kürzeren Einstieg bietet der Leitfaden zu den DORA-TLPT-Anforderungen.

Quellen: endgültige TLPT-RTS, einschließlich Artikel 17; DORA-Artikel 26. Die beiden Fotografien sind KI-generierte Illustrationen und keine Dokumentation eines Kundenauftrags.

DORA, die TLPT-RTS und TIBER-EU: Was hat Vorrang?

DORA ist die übergeordnete Verordnung. Die Artikel 26 und 27 behandeln fortgeschrittene Tests und die Anforderungen an Tester. Die TLPT-RTS enthalten die detaillierten Regeln, die auf dieser Grundlage erlassen wurden. TIBER-EU bietet einen etablierten operativen Rahmen und ergänzende Leitlinien für nachrichtendienstgestützte Red-Team-Tests.

Die EZB hat TIBER-EU 2025 aktualisiert, um es an DORA anzupassen. Der Umsetzungsleitfaden für bedeutende Institute unterscheidet ausdrücklich zwischen den verbindlichen Rechtsvorschriften und dem Rahmenwerk zu deren Umsetzung. Dieser Leitfaden betrifft das Verfahren der EZB für benannte bedeutende Institute; er sollte nicht als Verfahren der zuständigen Behörde für jedes Finanzunternehmen in Europa dargestellt werden.

Verlangen Sie bei der Beschaffung, dass das Angebot alle drei Ebenen ausweist: die rechtlichen Anforderungen, das Verfahren der zuständigen Behörde und die Durchführungsmethode. „TIBER-style“ ist kein Genehmigungsstatus. Eine freiwillige Red-Team-Übung erhält selbst bei gründlicher Durchführung nicht automatisch die Anerkennung als vorgeschriebenes DORA-TLPT des Unternehmens.

Nützliche offizielle Referenzen: die EZB-Mitteilung zum aktualisierten TIBER-EU-Rahmenwerk, die Bibliothek mit TIBER-EU-Rahmenwerk und Leitlinien sowie der Leitfaden zur Umsetzung von TIBER-EU im SSM.

Wer muss gemäß den RTS TLPT durchführen?

Artikel 2 verbindet Auswahlkriterien mit einer Bewertung der Auswirkungen, der systemischen Bedeutung und des IKT-Risikos durch die zuständige Behörde. Die erfasste Gruppe wird weder durch eine allgemeine Beschäftigtenzahl noch durch einen pauschalen Umsatzschwellenwert oder allein dadurch bestimmt, dass ein Unternehmen ein Finanzprodukt vertreibt. Auch das Unterschreiten eines einzelnen Schwellenwerts beantwortet nicht jede Frage zur Anwendbarkeit.

Die RTS behandelt unter anderem Kategorien wie systemisch wichtige Kreditinstitute, qualifizierte Zahlungs- und E-Geld-Institute, Zentralverwahrer, zentrale Gegenparteien, bestimmte elektronische Handelsplätze sowie qualifizierte Versicherungs- und Rückversicherungsunternehmen. Die detaillierten Voraussetzungen unterscheiden sich je nach Kategorie. Die Behörden verfügen im Rahmen des Auswahlverfahrens zudem über Befugnisse, die einen einfachen Online-Ja-Nein-Rechner unzuverlässig machen.

Betrachten Sie diese Beispiele als Ausgangspunkte für eine Prüfung der Anwendbarkeit, nicht als abschließende Beurteilung. Dokumentieren Sie die juristische Person, den aufsichtsrechtlichen Perimeter, die relevante Meldung, die federführende Behörde und etwaige Vereinbarungen auf Gruppenebene. Eine an ein Gruppenunternehmen gerichtete Anweisung sollte nicht ohne Weiteres als für alle Tochtergesellschaften oder gemeinsam genutzten Plattformen geltend angenommen werden.

Auswahlkriterien: TLPT-RTS Artikel 2.

Unser Leitfaden dazu, wer TLPT benötigt hilft bei der Strukturierung der ersten Fragen. Klären Sie die Schlussfolgerung über das Verfahren der zuständigen Behörde, bevor Sie sich auf einen Durchführungstermin festlegen.

Rollen, Geheimhaltung und Entscheidungsfindung

Artikel 3 verpflichtet die zuständige Behörde, einen Testmanager und mindestens eine Stellvertretung zu benennen. Artikel 4 verpflichtet das Finanzunternehmen, eine Leitung des Kontrollteams zu bestellen und organisatorische Schutzmaßnahmen einzurichten. Die Leitung des Kontrollteams benötigt das Mandat, zeitnah Entscheidungen zu treffen; die Rolle darf sich nicht auf die Terminverwaltung beschränken.

Vertraulichkeit ist wichtig, da der Test das tatsächliche Abwehrverhalten untersucht. Beschränken Sie Informationen zu geplanten und laufenden Tests nach dem Need-to-know-Prinzip auf die jeweils relevanten Personen. Vereinbaren Sie, wie das Kontrollteam über erkannte Aktivitäten informiert wird, ohne die Übung unnötig offenzulegen, und wie es mit den Testverantwortlichen kommuniziert, bevor Blue-Team-Mitarbeitende einbezogen werden. Verwenden Sie den vereinbarten Codenamen und durchgehend sichere Kommunikationskanäle.

Ein praxistaugliches Governance-Paket sollte festlegen, wer eine Anpassung genehmigen, Aktivitäten unterbrechen, einen IKT-Dienstleister einbeziehen, einen tatsächlichen Vorfall behandeln und die Wiederaufnahme autorisieren kann. Legen Sie Vertretungen und Kontakte außerhalb der Geschäftszeiten fest. Wenn eine Entscheidung den Umfang oder den Testplan betrifft, befolgen Sie den Genehmigungsweg gemäß RTS, statt sich auf ein informelles Gespräch zwischen den Durchführungsteams zu verlassen.

• Leitungsorgan: Genehmigt die Spezifikation des Leistungsumfangs und stellt Ressourcen für die Verantwortlichkeiten des Unternehmens bereit.
• Kontrollteam: während des gesamten Tests das Risikobild, die Geheimhaltung und die Entscheidungen wahren.
• Testmanager der zuständigen Behörde: überwachen die Einhaltung und wirken am festgelegten Genehmigungsprozess mit.
• Anbieter von Bedrohungsinformationen: unternehmensspezifische Erkenntnisse entwickeln und während der Tests verfügbar bleiben.
• Red und Blue Teams: Erstellen Sie sich ergänzende Nachweise zu offensiven Aktivitäten und defensiver Reaktion.

Organisatorische Anforderungen: TLPT-RTS Artikel 4.

Weitere Informationen zur Vorbereitung finden Sie unter Organisation des TLPT-Kontrollteams.

Fristen der DORA-TLPT-RTS: Verwechseln Sie die Fristen nicht

Die letzten beiden Fristen werden häufig falsch verstanden. Auslöser ist die Mitteilung der Behörde, dass sie die Red-Team- und Blue-Team-Berichte auf die erforderlichen Inhalte der Anhänge geprüft hat. Es handelt sich nicht automatisch um den letzten Tag der Red-Team-Einsätze. Nehmen Sie die Mitteilung selbst in die Projektunterlagen auf, damit das Datum nachvollziehbar ist.

Die Frist von sechs Monaten für die Festlegung des Umfangs bedeutet nicht, dass Sie sechs Monate mit Maßnahmen warten sollen. Die Beschaffung von Anbietern, die Erfassung von Abhängigkeiten, die Genehmigung durch die Geschäftsleitung und Berechtigungen Dritter können zu Engpässen werden. Planen Sie rückwärts ab den erforderlichen Einreichungen und reservieren Sie Zeit für Rückfragen und Überarbeitungen. Die RTS machen aus dem gesamten Auftrag kein festes Zwölf-Wochen-Paket.

Anforderungen an den Abschluss: TLPT-RTS Artikel 12.

Planungshinweise finden Sie in unserem Leitfaden zum TLPT-Zeitplan.

Umfang festlegen: mit den Funktionen beginnen und dann den Abhängigkeiten folgen

Artikel 26 der DORA verlangt die Prüfung mehrerer oder aller kritischen oder wichtigen Funktionen auf den Live-Produktivsystemen, die diese unterstützen. Artikel 9 und Anhang II der RTS konkretisieren die Spezifikation des Umfangs. Das Dokument führt die von der Einrichtung ermittelten kritischen oder wichtigen Funktionen auf und erläutert deren Ein- oder Ausschluss. Für einbezogene Funktionen benennt es unterstützende IKT-Systeme, Auslagerungen, Rechtsräume und vorläufige Einstufungen.

Ein Flag ist ein vereinbartes Testziel, das mit einem Sicherheitsaspekt wie Vertraulichkeit, Integrität, Authentizität oder Verfügbarkeit verknüpft ist. Es sollte den beabsichtigten Nachweis verständlich machen. „Die Bank kompromittieren“ ist zu vage, um sicher als Vorgabe zu dienen; ein klar definiertes Ziel für einen benannten Geschäftsdienst gibt dem Team etwas, das es bewerten kann, und dem Kontrollteam etwas, das es autorisieren kann.

Ordnen Sie für eine beispielhafte Zahlungsfunktion den Kundenkanal, die Identitätsebene, den Genehmigungsworkflow, die Transaktionsverarbeitung, privilegierte Vorgänge und externe Verbindungen zu. Ermitteln Sie, wer für jede Abhängigkeit verantwortlich ist und welche Anbietervereinbarungen die Prüfung beeinflussen. Unterscheiden Sie zwischen einer direkt getesteten Komponente und einer Abhängigkeit, die dokumentiert ist, aber einer vereinbarten Einschränkung unterliegt. Stellen Sie Letztere nicht stillschweigend als getestet dar.

Führen Sie ein Register der Umfangsentscheidungen. Jeder Eintrag kann die Funktion, die Systeme, die Begründung für die Einbeziehung, die verantwortliche Person, Drittparteien, geografische Abhängigkeiten, vorgeschlagene Kennzeichnungen und offene Berechtigungen erfassen. Dies ist ein praktikables Arbeitsformat und kein Ersatz für Anhang II oder die Vorlage der zuständigen Behörde. Es erleichtert die Prüfung von Änderungen, wenn Informationen oder technische Erkenntnisse den vorgeschlagenen Ansatz beeinflussen.

Vorbereitung und Genehmigung des Umfangs: TLPT-RTS Artikel 9.

Verwandte Themen: Festlegung des Umfangs eines DORA-TLPT und TLPT-Bereitschaftscheckliste.

Anforderungen an Anbieter: Was Artikel 7 tatsächlich verlangt

Bei der Due-Diligence-Prüfung eines Anbieters müssen die dem Test zugewiesenen Personen und die Nachweise hinter dem Angebot bewertet werden. Artikel 7 ergänzt Artikel 27 der DORA um spezifische Anforderungen an den Anbieter von Threat Intelligence und die externen Tester. Ein Zertifizierungslogo auf einer Website reicht für die Bewertung nicht aus.

Bitten Sie den Anbieter, die Nachweise den jeweiligen einschlägigen Absätzen zuzuordnen, statt pauschal „RTS-Konformität“ zu behaupten. Prüfen Sie die Verfügbarkeit während des vorgeschriebenen Zeitraums, die Kontrollen für Ersatzpersonal, die Zuständigkeiten für Berichte und die geplante Zusammenarbeit mit den Testmanagern der Behörde. Referenzen und Erfahrung sind getrennte Fragen: Das bisherige Projektportfolio eines Unternehmens belegt nicht, dass das namentlich vorgesehene Team die Anforderungen an die Personalausstattung erfüllt.

Artikel 7 enthält eine Bestimmung für außergewöhnliche Umstände, die Abweichungen von bestimmten Kriterien unter Einbeziehung geeigneter Minderungsmaßnahmen und einer entsprechenden Dokumentation ermöglicht. Behandeln Sie sie weder als routinemäßige Abkürzung im Beschaffungsprozess noch als pauschale Ausnahmegenehmigung. Stimmen Sie jede beabsichtigte Ausnahme über das Verfahren der zuständigen Behörde ab und dokumentieren Sie die Begründung, bevor die Ernennungen endgültig erfolgen.

Anforderungen an die Auswahl des Anbieters: TLPT-RTS Artikel 7.

Nutzen Sie unseren Beschaffungsleitfaden und unsere Erläuterung der Anforderungen an Prüfer gemäß DORA-Artikel 27, um Fragen zu strukturieren. Dieser Artikel beschreibt Bewertungskriterien; er enthält keine ungeprüften Behauptungen zu den Qualifikationen eines Anbieters.

Interne Tester, externe Tester und Gruppenteams

Interne Tests sind eine kontrollierte Option und kein allgemeiner Anspruch. DORA legt die Bedingungen für die Genehmigung durch die zuständige Behörde, die Trennung, die Ressourcen und die Vermeidung von Interessenkonflikten fest. Bei Einsatz interner Tester sind externe Threat Intelligence und mindestens bei jedem dritten Test externe Tester vorgeschrieben. Bedeutende Institute unter dem Einheitlichen Aufsichtsmechanismus müssen externe Tester einsetzen.

RTS-Artikel 15 enthält zusätzliche Anforderungen an Vereinbarungen für interne Tests. Tester, die bei einem IKT-Intragruppen-Dienstleister beschäftigt sind, gelten als interne Tester. Die Verordnung regelt außerdem die Offenlegung des Einsatzes interner Tester in den Einleitungsinformationen, im Red-Team-Bericht und im Zusammenfassungsbericht. Ein Team wird nicht allein deshalb zu einem externen Team, weil es einer anderen Konzerngesellschaft angehört.

Trennen Sie bei der Planung Kapazität und Unabhängigkeit. Ein technisch starkes internes Red Team kann dennoch Interessenkonflikte haben oder für wesentliche Abwehrmaßnahmen benötigt werden. Dokumentieren Sie, wie die Übung den regulären Sicherheitsbetrieb der Einrichtung nicht beeinträchtigen wird. Werden interne und externe Tester kombiniert, prüfen Sie die einschlägige Behandlung interner Tester, statt anzunehmen, dass durch die externen Mitglieder die entsprechenden Anforderungen entfallen.

Quellen: DORA-Artikel 26, Artikel 27 und RTS-Artikel 15.

Bedrohungsinformationen und die drei Szenariodimensionen

Artikel 10 verlangt nach Genehmigung des Prüfungsumfangs durch die zuständige Behörde gezielte nachrichtendienstliche Erkenntnisse. Erkenntnisse zum Sektor sind ein Ausgangspunkt, das Ergebnis muss jedoch das betreffende Unternehmen berücksichtigen: seine offengelegten Informationen, relevante Bedrohungsprofile, Abhängigkeiten und plausible Angriffspfade. Ein allgemeiner Katalog aktueller Cyberbedrohungen reicht als Grundlage für ein maßgeschneidertes TLPT nicht aus.

Anhang III fordert mindestens drei durchgängige Bedrohungsszenarien für die relevanten Bedrohungsprofile mit dem höchsten Schweregrad, die Verfügbarkeit, Datenintegrität und Vertraulichkeit von Informationen abdecken. Jedes Szenario kann mehr als eine Sicherheitsdimension umfassen. Diese Anforderungen berechtigen nicht zu destruktiven Demonstrationen; Risikokontrollen bestimmen, wie ein Ziel verfolgt und belegt wird.

Fragen Sie bei jedem Szenario: Warum dieser Bedrohungsakteur oder dieses Profil, warum diese Funktion, warum dieser Pfad und welche Beobachtung würde das Ergebnis nützlich machen? Verfolgen Sie anschließend die nachrichtendienstliche Annahme bis in den Red-Team-Testplan. Erweist sich eine Annahme während des Tests als falsch, dokumentieren Sie die Änderung und die dafür geltende Genehmigung, statt stillschweigend einen bequemen Angriff an ihre Stelle zu setzen.

Eine praxisorientierte Rückverfolgbarkeitszeile kann die Referenz zur Bedrohungsanalyse, die Funktion, das Szenario, die Kennzeichnung als geplant, die zulässigen Techniken, Risikobeschränkungen, Ausführungsnachweise und das Endergebnis enthalten. Sehen Sie ein Feld vor, in dem Unsicherheiten erläutert werden können. Informationen können darauf hindeuten, dass ein Angriffsweg plausibel ist; sie belegen nicht vorab, dass das Ziel verwundbar ist.

Threat-Intelligence-Phase und Anhang III: TLPT-RTS Artikel 10.

Aktive Tests, Risikokontrollen und zusätzliche Zugänge

Artikel 11 verlangt vor Beginn der aktiven Durchführung den Red-Team-Testplan und die erforderlichen Genehmigungen. Anhang IV behandelt Kommunikation, zulässige und unzulässige Techniken, ethische Grenzen für Social Engineering, Risikomaßnahmen und die weiteren erforderlichen Planbestandteile. Während der aktiven Tests müssen mindestens wöchentlich Fortschrittsberichte an das Kontrollteam und die Testmanager erfolgen.

Ein Leg-up ist eine kontrollierte Unterstützung, die es ermöglicht, spätere Phasen eines Tests zu untersuchen, wenn ein Szenario sonst nicht wie vorgesehen fortgesetzt werden kann. Es ist kein Nachweis dafür, dass die vorherige Phase erfolgreich war. Wird Zugriff bereitgestellt, um ein Szenario fortzuführen, muss die abschließende Darstellung diese Unterstützung von tatsächlich durch den Test erlangtem Zugriff unterscheiden. So bleiben die Schlussfolgerungen für die Geschäftsleitung und die Verteidigungsteams aussagekräftig.

Das Kontrollteam muss die Bewertung der operationellen Risiken aktuell halten. Artikel 5 berücksichtigt ausdrücklich Risiken, die sich aus Aktivitäten des Red Teams und des Blue Teams, der Eskalation von Vorfällen und einer unvollständigen Wiederherstellung ergeben. Auch eine defensive Reaktion kann störend wirken. Vereinbaren Sie, wie echte Vorfälle von Testereignissen unterschieden werden, welche Kontakte Aktivitäten stoppen können und wie die Bereinigung nachgewiesen wird.

Artikel 11 erlaubt eine Aussetzung unter außergewöhnlichen Risikoumständen und als letztes Mittel mit vorheriger Validierung durch die zuständige Behörde eine Fortsetzung in Form eines begrenzten Purple Teamings, wenn eine Fortsetzung andernfalls unmöglich ist. Diese begrenzte Übung wird auf das angegebene Mindestmaß der aktiven Phase angerechnet. Es handelt sich um eine geregelte Ausnahme und nicht um eine allgemeine Grundlage dafür, einen Workshop als zwölf Wochen aktive Tests zu verkaufen.

Aktive Tests, Anpassung und außergewöhnliche Maßnahmen: TLPT-RTS Artikel 11.

Unsere Übersicht zur TLPT-Methodik erläutert, wie Governance und technische Durchführung zusammenspielen.

Drittparteien, gebündelte Tests und gemeinsame Tests

Die Auslagerung entbindet nicht von der Verantwortung für die Funktion. Umfasst der Prüfungsumfang einen IKT-Dienstleister, ist festzulegen, wie dieser mitwirkt, wie die Kommunikation mit der zuständigen Behörde abläuft, auf welche Umgebungen zugegriffen werden darf und wie Auswirkungen auf andere Kunden verhindert werden. Diese Fragen müssen geklärt sein, bevor der Durchführungsplan davon abhängt.

Gebündelte und gemeinsame TLPT-Vorhaben erfordern eine eigene Koordination. Die Artikel 6 und 8 behandeln das Risikomanagement und verfahrensbezogene Besonderheiten, während Artikel 16 die Zusammenarbeit zwischen den Behörden regelt. In der Regel befolgt jede beteiligte Stelle die festgelegten Schritte, sofern die federführende Behörde nicht anders entscheidet. Das Kontrollteam jedes Finanzunternehmens führt eine eigene Risikobewertung durch; ein gemeinsamer Projektplan hebt unternehmensspezifische Risiken nicht auf.

Für eine gemeinsam genutzte Plattform ordnet eine aussagekräftige Planungsmatrix jeder juristischen Person ihre kritischen Funktionen, unterstützenden Systeme, Ansprechpartner bei Anbietern, Rechtsordnungen, Genehmigungsverantwortlichkeiten und erwarteten Nachweise zu. Heben Sie hervor, welche Feststellungen gemeinsam gelten und welche Schlussfolgerungen nur für eine bestimmte juristische Person gezogen werden können. Verhindern Sie, dass ein gruppenweiter Bericht weitergehende Aussagen enthält, als der geprüfte Umfang zulässt.

Quellen: DORA-Artikel 26 und RTS-Artikel 16. Weiterführende Hinweise: Drittdienstleister im TLPT.

Die acht RTS-Anhänge: Ihr Dokumentenüberblick

Verwenden Sie die Anhänge als Matrix zur Inhaltskontrolle und nicht als acht leere Vorlagen, die erst am Ende ausgefüllt werden. Benennen Sie für jedes Dokument eine verantwortliche Person, eine prüfende Person, einen Auslöser für den Fälligkeitstermin und den Freigabestatus. Vereinbaren Sie den sicheren Speicherort und die Regeln für den Umgang mit Dokumenten, bevor die Informationsbeschaffung beginnt. Dokumentieren Sie die Versionen, damit sich Änderungen am Umfang im Testplan und in der Berichterstattung nachvollziehen lassen.

Insbesondere sind die Kennzeichnungen und Szenarien im Threat-Intelligence-Bericht, Testplan, Red-Team-Bericht und in der Zusammenfassung abzugleichen. Sowohl erreichte als auch nicht erreichte Ziele sind relevant. Der Unterschied muss erhalten bleiben zwischen einer Kontrolle, die der getesteten Aktion standhielt, einer aus Sicherheitsgründen nicht versuchten Aktion und einer Aktion, die scheiterte, weil eine Voraussetzung fehlte.

Quelle: RTS-Anhänge I–VIII. Unsere Übersicht der Liefergegenstände und der fiktive DORA-TLPT-Musterbericht zeigen den Berichtskontext. Ein Musterbericht ersetzt nicht das vollständige Einreichungspaket für die zuständige Behörde.

Abschluss: Red-Team-Bericht, Blue-Team-Bericht, Replay und Purple Teaming

Der Abschluss beginnt damit, dass die Leitung des Kontrollteams das Blue Team über die Durchführung eines TLPT informiert. Der Bericht des Red Teams dokumentiert die offensiven Aktivitäten. Anschließend erläutert das Blue Team seine defensive Sicht. Ziel ist es, die beiden Perspektiven auf dieselbe Aktivität abzugleichen, einschließlich Abweichungen zwischen verfügbarer Telemetrie, tatsächlicher Erkennung und getroffenen Entscheidungen.

Wiedergabe und Purple-Teaming sollten zu konkreten Erkenntnissen führen. Wählen Sie Ereignisse aus, bei denen Annahmen voneinander abwichen: eine simulierte Aktion, die keinen verwertbaren Alarm auslöste, ein Alarm ohne ausreichenden Kontext für die Triage oder eine Eskalation an die falsche zuständige Stelle. Erläutern Sie, welcher Teil der Kette geändert werden muss. Eine Feststellung mit dem Titel „Das SOC hat den Angriff nicht erkannt“ ist weniger umsetzbar als eine belegte Beschreibung des fehlenden Ereignisses, der fehlenden Korrelation oder der ausgebliebenen Reaktionsentscheidung.

Unterscheiden Sie die abschließende Purple-Teaming-Übung von dem außergewöhnlichen, begrenzten Purple Teaming, das während aktiver Tests zulässig ist. Sie erfüllen im RTS unterschiedliche Aufgaben. Planen Sie die erforderlichen Abschlussarbeiten bereits bei der Beschaffung ein, einschließlich des Zugangs zu den zuständigen Verteidigungsteams und ausreichender Zeit für den Abgleich der Zeitabläufe. Gehen Sie nicht davon aus, dass es sich um eine freiwillige Zusatzleistung nach dem Abzug des Red Teams handelt.

Sensible Details in den dafür vorgesehenen, zugriffskontrollierten Unterlagen festhalten. Artikel 12 erlaubt es der zuständigen Behörde, Informationen in Berichten anzufordern, auch wenn sie sensibel sind. Eine Managementzusammenfassung sollte Folgen und erforderliche Entscheidungen vermitteln, ohne zu einem unkontrollierten Verbreitungskanal für operative Angriffsinformationen zu werden.

Abschluss und Berichterstattung: TLPT-RTS Artikel 12.

Weiterführende Informationen: TLPT-Berichterstattung und Abhilfemaßnahmen.

Behebung und Bestätigung: Nachweise nach der Übung

Artikel 13 verlangt, dass der Plan auf jeden Befund eingeht: den Mangel, vorgeschlagene Maßnahmen, Priorität und erwarteten Abschluss, Grundursache, verantwortliche Mitarbeitende oder Funktionen sowie die Risiken einer Nichtumsetzung oder gegebenenfalls einer Umsetzung der Maßnahmen. Machen Sie aus einem bereichsübergreifenden Versagen keine Liste unverbundener Korrekturen, nur weil sich Tickets für einzelne Patches leicht zählen lassen.

Betrachten Sie eine beispielhafte Schwäche der Identitätskontrolle, die sich über mehrere Systeme erstreckt. Die Sofortmaßnahme könnte darin bestehen, eine Berechtigung einzuschränken; die Ursache könnte jedoch eine Lücke bei den Zuständigkeiten im Zugriffslebenszyklus sein. Ein sinnvoller Plan dokumentiert beides, weist es den passenden Verantwortlichen zu und definiert eine beobachtbare Abschlussbedingung. Andernfalls kann dasselbe Problem vor dem nächsten TLPT in einem anderen System erneut auftreten.

Nachtests und die Überprüfung von Nachweisen sind praktische Möglichkeiten, zwischen „Änderung umgesetzt“ und „Risikominderung nachgewiesen“ zu unterscheiden. Verknüpfen Sie die Abnahmenachweise mit dem ursprünglichen Befund und der vereinbarten Einschränkung. Kann eine Maßnahme noch nicht abgeschlossen werden, dokumentieren Sie die Entscheidung, kompensierende Maßnahmen und das verbleibende Risiko im Governance-Prozess des Unternehmens.

Die Bescheinigung gemäß DORA-Artikel 26 Absatz 7, RTS-Artikel 14 und Anhang VIII unterstützt die gegenseitige Anerkennung des TLPT. Sie wird im Rahmen des Behördenverfahrens ausgestellt. Ein Anbieter kann sie nicht einfach durch ein allgemeines „DORA-zertifiziert“-Siegel ersetzen. Die Bescheinigung besagt auch nicht, dass die Organisation keine Schwachstellen aufweist oder alle Anforderungen der DORA erfüllt hat.

Anforderungen an den Sanierungsplan: TLPT-RTS Artikel 13.

Anforderungen an die Bescheinigung: TLPT-RTS Artikel 14.

Ein praktischer 30-Tage-Vorbereitungsplan

Der folgende Vorschlag zur internen Mobilisierung ist weder eine neue regulatorische Frist noch die Behauptung, dass ein TLPT innerhalb von dreißig Tagen abgeschlossen werden kann. Er soll eine Verpflichtung in einen gesteuerten Beschaffungs- und Vorbereitungsprozess überführen, bevor technische Aktivitäten beginnen.

Planen Sie das gesamte Programm ein. Bitten Sie um Angebote, die Nachrichtendienstarbeit, aktive Tests, Unterstützung des Kontrollteams, Koordination mit Dritten, Berichtserstellung, Replay, Purple Teaming und Unterstützung bei der Behebung getrennt ausweisen. Es gibt keinen allgemeinen RTS-Preistarif. Ein scheinbar günstiger Preis, bei dem verpflichtende Arbeiten ausgeschlossen sind, kann später zu kostspieligen Änderungen des Leistungsumfangs führen.

Verwenden Sie den Ersteller für DORA-TLPT-Scoping-Briefs, um allgemeine Informationen für ein Gespräch zusammenzustellen. Geben Sie in einem ersten Formular keine Zugangsdaten, sensiblen Diagramme oder Kundendaten an. Übermitteln Sie eine NDA oder eine bestehende RFP über den Kontaktprozess, bevor Sie detaillierte Unterlagen weitergeben.

Häufige Fehler bei der RTS-Planung und wie Sie sie vermeiden

Stellen Sie vor der Unterzeichnung der Leistungsbeschreibung noch eine letzte Frage: Lässt sich jede erforderliche Leistung einem benannten Verantwortlichen, einem Genehmigungsweg und einem auslösenden Datum zuordnen? Falls nicht, ist der kommerzielle Leistungsumfang noch nicht konkret genug, um ihn zuverlässig zu steuern.

DORA-TLPT-RTS: häufig gestellte Fragen

Was sind die RTS für DORA TLPT?

Es handelt sich um die Delegierte Verordnung (EU) 2025/1190 der Kommission. Sie ergänzt DORA um Vorschriften zur Auswahl von Unternehmen für TLPT, zur Organisation und Durchführung von Tests, zur Auswahl von Anbietern, zur Berichterstattung, zur Behebung von Mängeln, zur Bescheinigung und zur Zusammenarbeit zwischen Behörden.

Sind die RTS zum DORA-TLPT endgültig oder noch ein Entwurf?

Die endgültige Verordnung wurde am 18. Juni 2025 im Amtsblatt veröffentlicht und trat am 8. Juli 2025 in Kraft. Maßgeblich ist der verabschiedete Text; der frühere Konsultationsentwurf oder der endgültige Entwurf ist nicht als verbindlicher Rechtsakt zu behandeln.

Benötigt jedes DORA-regulierte Unternehmen einen TLPT?

Nein. Ein erweitertes TLPT gilt für Finanzunternehmen, die im einschlägigen Auswahlverfahren nach DORA und den RTS bestimmt wurden. Die weiter gefassten Anforderungen von DORA an Tests der digitalen operationalen Resilienz sind davon getrennt. Klären Sie Ihren Status mit der zuständigen Behörde.

Deckt die Mindestdauer von 12 Wochen das gesamte Projekt ab?

Nein. RTS-Artikel 11 Absatz 5 legt für aktive Red-Team-Tests eine Mindestdauer von 12 Wochen fest. Vorbereitung, Bedrohungsanalyse, Berichterstattung, Wiederholungstests, Purple Teaming und Abstimmungen mit Behörden erfordern zusätzliche Zeit.

Wann sind die TLPT-Zusammenfassung und der Maßnahmenplan zur Behebung fällig?

Für beide gilt eine Frist von acht Wochen, die an die Behördenmitteilung gemäß Artikel 12 Absatz 7 geknüpft ist und deren Bewertung der Berichte des Red und Blue Teams betrifft. Diese acht Wochen dürfen nicht automatisch ab dem Ende der aktiven Tests gerechnet werden.

Kann ein gewöhnlicher Penetrationstest DORA-TLPT ersetzen?

Ein gewöhnlicher Penetrationstest ist nicht automatisch ein DORA-TLPT. Die erforderliche Einbindung der Behörden, der Umfang, die Bedrohungsinformationen, der Testprozess, die Abschlussnachweise und weitere Bedingungen müssen erfüllt sein. Die Bezeichnung eines Anbieters begründet keine regulatorische Anerkennung.

Kann ein einzelner Anbieter Threat Intelligence und Red Teaming bereitstellen?

Die RTS sehen Anbieter innerhalb desselben Unternehmens vor; die zugewiesenen Mitarbeitenden der Threat Intelligence müssen jedoch von den Mitarbeitenden getrennt sein und dürfen diesen nicht unterstellt sein, die externe Tester für dieselbe TLPT bereitstellen. Weitere Anforderungen an Unabhängigkeit und den Umgang mit Interessenkonflikten gelten weiterhin.

Bedeutet eine TLPT-Bescheinigung, dass die Organisation vollständig DORA-konform ist?

Nein. Die Bescheinigung der Behörde bezieht sich auf das TLPT und unterstützt die gegenseitige Anerkennung. Sie ist weder ein allgemeines DORA-Compliance-Zertifikat noch ein Unbedenklichkeitsnachweis oder eine Garantie dafür, dass alle Schwachstellen beseitigt wurden.

Planen Sie ein DORA-TLPT-Engagement mit Atlant Security

Der DORA-TLPT-Service von Atlant Security richtet das Gespräch auf Ihre kritischen Funktionen, den Kontext der zuständigen Behörden, betriebliche Einschränkungen und die erforderlichen Nachweise aus. Beginnen Sie mit der juristischen Person, dem Meldestatus, den infrage kommenden Funktionen, Abhängigkeiten von Drittanbietern und dem angestrebten Zeitrahmen. Diese Angaben schaffen die Grundlage für ein zielführendes Gespräch zur Abgrenzung des Umfangs, bevor ein Angebot erstellt wird.

Entdecken Sie die DORA-TLPT-Startseite, erstellen Sie ein Abgrenzungsbriefing oder senden Sie Ihre Ausschreibung oder Vertraulichkeitsvereinbarung. Wenn Sie sich zunächst einen technischen Bericht ansehen möchten, fordern Sie den DORA-TLPT-Musterbericht an; der Download-Link wird per E-Mail zugestellt.