Die Entscheidung, bei der Ihnen dieser Leitfaden hilft
Richten Sie den Auftrag nach der Verpflichtung und der zu treffenden Entscheidung aus. Ein herkömmlicher Pentest untersucht einen vereinbarten technischen Umfang; ein DORA-TLPT umfasst zusätzlich ein festgelegtes Behördenverfahren, Threat Intelligence, den Umfang kritischer Funktionen und einen formellen Abschluss. Eine Organisation kann beide Prüfungen für unterschiedliche Zwecke benötigen.
Für die verantwortliche Person des Engagements. Unterscheiden Sie die Engagements anhand ihres Ziels, ihrer Governance und ihres Abdeckungsmodells. Ein technischer Befund kann in ein TLPT einfließen, macht die ursprüngliche Prüfung aber nicht zu einem TLPT.
Der Unterschied liegt in der Fragestellung des Tests
Ein herkömmlicher Penetrationstest untersucht üblicherweise Schwachstellen innerhalb eines festgelegten technischen Umfangs. Ein bedrohungsorientierter Penetrationstest stellt eine umfassendere Frage: Wie könnte ein glaubwürdiger Angreifer die kritischen Funktionen der Organisation beeinträchtigen, und wie würden ihre Mitarbeitenden, Prozesse und Technologien darauf reagieren?
Der Unterschied besteht nicht nur in Dauer oder Intensität. Ein DORA-TLPT umfasst ein Verfahren mit der zuständigen Behörde, gezielte Threat Intelligence, Anforderungen an die Tester, einen an kritischen oder wichtigen Funktionen ausgerichteten Umfang und formelle Abschlussarbeiten. Die Bezeichnung einer Übung als „Red Teaming“ belegt nicht, dass diese Anforderungen erfüllt wurden.
Diagrammtext lesen
- Technische Bewertung
- Definierte Systeme und Kontrollen bewerten
- Bedrohungsgeleitete Übung
- Glaubwürdige Angriffspfade bis zu Auswirkungen auf Funktionen nachverfolgen
- Governance
- Das vorgeschriebene Bereitstellungsverfahren anwenden
Vergleichen Sie die Engagementmodelle
| Dimension | Konventioneller Penetrationstest | DORA-TLPT |
|---|---|---|
| Ausgangspunkt | Oft eine technische Assetliste oder ein definierter Anwendungsumfang. | Kritische Funktionen, relevante Bedrohungen und durch die Aufsicht validierter Umfang. |
| Bedrohungsgrundlage | Kann Standardtechniken und ein allgemeines Angreifermodell verwenden. | Gezielte Bedrohungsanalysen liefern die Grundlage für realistische Szenarien. |
| Umgebung | Abhängig vom vereinbarten Auftrag. | Relevante kritische Live-Produktionssysteme. |
| Abwehrfähigkeit | Liegt möglicherweise außerhalb des Testziels. | Prävention, Erkennung und Reaktion gehören zum Lernprozess. |
| Governance | Im Rahmen des Auftrags und der einschlägigen Standards festgelegt. | DORA, RTS, Beteiligung der Aufsichtsbehörde und spezifische Rollen der Beteiligten. |
| Abschluss | Üblicherweise ein technischer Bericht und vereinbarte Folgemaßnahmen. | Berichterstattung von Red und Blue Teams, Replay, Purple Teaming, Zusammenfassung und Behebungsprozess. |

Warum Organisationen möglicherweise beides benötigen
Das allgemeine Testprogramm nach DORA und die Pflicht zu fortgeschrittenen TLPT erfüllen verwandte, aber unterschiedliche Zwecke. Regelmäßige technische Tests können Schwachstellen erkennen, bevor sie Teil eines umfassenderen Angriffspfads werden. TLPT kann anschließend zeigen, ob mehrere Kontrollebenen unter realistischen Bedingungen zusammenwirken.
Eine große Anzahl von Schwachstellen zu finden, macht einen Test nicht mit einem TLPT gleichwertig. Ebenso ist eine bedrohungsorientierte Übung nicht dazu gedacht, jedes Asset erschöpfend auf jeden denkbaren Fehler zu untersuchen. Ziele und Nachweisanforderungen müssen klar bleiben.
Diagrammtext lesen
- API-Feststellung
- Eine bestimmte Berechtigung schlug fehl
- Bedrohungsgeleitete Beobachtung
- Ein Szenario deckte ein Resilienzproblem auf
- Nicht getestete Angriffsfläche
- Keine Schlussfolgerung aus fehlender Abdeckung
Die Beschaffung passt nicht zum Bedarf
Eine Beschaffungsanfrage, die lediglich einen „DORA-Pentest“ anfordert, ist mehrdeutig. Ein Anbieter könnte eine kurze Anwendungsprüfung kalkulieren, ein anderer hingegen einen mehrstufigen TLPT mit Bedrohungsanalyse und umfangreichen Nachbereitungspflichten annehmen.
Geben Sie an, ob das Institut für einen TLPT benannt wurde, welche Behörde beteiligt ist, welche kritischen Funktionen voraussichtlich betroffen sind, in welchem Zeitraum die Tests stattfinden sollen und welche Ergebnisse erwartet werden. Bitten Sie Anbieter zu erläutern, wie ihr Vorgehen den einschlägigen Anforderungen entspricht. Vergleichen Sie Angebote mit gleichwertigen Annahmen zu Umfang, Ressourcen und Governance.
Beauftragen Sie keinen Test allein deshalb, weil im Angebot das richtige Akronym steht. Prüfen Sie das vorgeschlagene Team und die Nachweise anhand von Artikel 27 und vereinbaren Sie betriebliche Schutzmaßnahmen, bevor Tests beginnen.
Diagrammtext lesen
- Ausgangslage
- Zugriff, Unterstützung und Annahmen
- Beobachtete Aktivität
- Maßnahmen und Abwehrreaktion
- Einschränkungen
- Nicht getestete Pfade und ausgeschlossene Systeme
Eine sinnvolle Vorbereitungsbewertung erkennen
Eine Bank, die sich auf eine fortgeschrittene Übung vorbereitet, kann eine gezielte Prüfung einer Zahlungs-API, eines privilegierten Zugriffswegs oder einer Bereitstellungspipeline beauftragen. Diese Arbeit kann Schwachstellen identifizieren, das Wissen über den Umfang verbessern und betriebliche Schutzmaßnahmen klären. Dokumentieren Sie sie als separate Prüfung mit eigenen Ausgangspositionen und Einschränkungen. Ihre Ergebnisse können in die Vorbereitung einfließen, ersetzen jedoch weder Threat Intelligence noch die Abstimmung mit den zuständigen Stellen oder andere Bestandteile des geltenden TLPT-Prozesses.
Unser Vergleich von Bank-Penetrationstests überträgt diese Unterscheidung auf Beschaffungsfragen. Er hilft dem beauftragenden Team zu erläutern, ob eine Prüfung einer klar definierten technischen Angriffsfläche oder eine umfassendere Bewertung einer kritischen Funktion anhand eines plausiblen Bedrohungsszenarios benötigt wird.
Fragen Sie, was die einzelnen Ergebnisse tatsächlich belegen
Ein API-Test kann zeigen, dass ein synthetischer Kunde eine nicht autorisierte Änderung des Transaktionsstatus vornehmen kann. Eine threat-led Übung kann untersuchen, wie ein Angreifer ein folgenreiches Ziel erreichen könnte und wie die Organisation den Angriff auf dem Weg dorthin erkennt und darauf reagiert. Beide Beobachtungen können relevant sein, doch keine der beiden Testarten deckt automatisch die jeweils andere Fragestellung umfassend ab. Ein Bericht sollte seine Schlussfolgerungen mit der getesteten Ausgangslage, den ausgeführten Aktionen und den Beobachtungen verknüpfen und nicht getestete Folgen als solche kennzeichnen.
Für Produkte, die über mehrere APIs und Dienstleister bereitgestellt werden, bietet der Leitfaden zum Umfang von Fintech-API-Tests praktische Grundlagen für den technischen Teil dieser Übersicht. Die Einrichtung muss den geeigneten TLPT-Umfang und die Governance weiterhin über das maßgebliche Verfahren festlegen. Verwenden Sie eindeutige Bezeichnungen für die Beauftragungen im Beschaffungsbriefing, im Nachweisregister und in der Management-Berichterstattung, damit diese Zuständigkeiten sichtbar bleiben.
Diagrammtext lesen
- Das Ziel benennen
- Die Entscheidung ermitteln, über die die Übung informieren soll
- Vorbereitung getrennt betrachten
- Gezielte Bewertungen klar voneinander abgrenzen
- Den Prozess abstimmen
- Umfang und Governance-Pflichten klären
Setzen Sie Ihre Vorbereitung fort
Primärquellen
- DORA · Verordnung (EU) 2022/2554
- TLPT-RTS · Delegierte Verordnung (EU) 2025/1190
- EZB · TIBER-EU-Rahmenwerk und Leitlinien
Allgemeine Informationen, keine Rechtsberatung. Bestätigen Sie die geltenden Anforderungen und Testvereinbarungen mit der zuständigen Behörde.
Dieser Leitfaden und die oben verlinkten Fachpublikationen werden von Atlant Security veröffentlicht. Die technischen Beispiele dienen der Planung und neigen sich nicht auf abgeschlossene Kundentests.
Veröffentlicht von Atlant Security. Quellen, redaktionelle Richtlinien und Korrekturen.

