DORA Compliance: Was Finanzunternehmen in der EU über Penetration Testing wissen müssen

Der Digital Operational Resilience Act – DORA – stellt die bedeutendste Veränderung in der Cybersicherheitsregulierung dar, die der EU-Finanzsektor je erlebt hat. Im Kern, direkt neben den ICT-Risikomanagementrahmen und den Meldepflichten für Vorfälle, steht eine Reihe von Testanforderungen, die Penetration Testing von einer freiwilligen Übung in eine gesetzlich vorgeschriebene Aktivität mit definierten Frequenzen, Scoping-Regeln, Testerqualifikationen und Aufsichtsbehörden verwandelt.

Wenn Sie eine Bank, ein Versicherer, ein Zahlungsinstitut, eine Wertpapierfirma oder eine andere nach EU-Finanzdienstleistungsrecht regulierte Einrichtung sind, betrifft Sie dies. Wenn Sie von systemischer Bedeutung sind, wird es noch intensiver. Und wenn Sie ein ICT-Drittanbieter sind, der diese Einrichtungen bedient, sind Sie auch nicht aus dem Schneider.

Dieser Leitfaden führt Sie durch alles, was Sie verstehen müssen: was DORA verlangt, wer in den Anwendungsbereich fällt, der Unterschied zwischen standardmäßigen jährlichen Tests und dem fortgeschrittenen Threat-Led Penetration Testing (TLPT)-Regime, und wie Sie ein Testprogramm aufbauen, das Sie konform hält, ohne in regulatorischer Komplexität zu ertrinken.

---

Was ist DORA und warum gibt es das?

Der Digital Operational Resilience Act (EU-Verordnung 2022/2554) wurde im Dezember 2022 vom Europäischen Rat angenommen, trat am 16. Januar 2023 in Kraft und wurde am 17. Januar 2025 anwendbar. Im Gegensatz zu einer Richtlinie, die eine Umsetzung in nationales Recht erfordert, ist DORA eine Verordnung – das heißt, sie gilt unmittelbar in allen EU-Mitgliedstaaten ohne Änderungen.

DORA existiert, weil der EU-Finanzsektor ein Flickenteppichproblem hatte. Zuvor wandten verschiedene Länder unterschiedliche Cybersicherheitsanforderungen auf ihre Finanzinstitute an. Einige hatten robuste Testframeworks (die Niederlande hatten TIBER-NL, Deutschland hatte TIBER-DE), während andere minimale technische Anforderungen hatten. Eine grenzüberschreitende Bank konnte mit drei verschiedenen Testregimen konfrontiert sein, je nachdem, welche Gerichtsbarkeit zuständig war.

Inzwischen wurde der Finanzsektor zunehmend von digitaler Infrastruktur und ICT-Drittanbietern abhängig. Ein einziger Cloud-Ausfall oder Cyberangriff könnte sich kaskadenartig über Institutionen, Grenzen und Märkte auswirken. DORA wurde entwickelt, um einen harmonisierten Rahmen zu schaffen, der sicherstellt, dass jede Finanzinstitution in der EU IKT-bedingten Störungen standhalten, darauf reagieren und sich davon erholen kann.

Die Verordnung beruht auf fünf Säulen: ICT-Risikomanagement, Management und Meldung von ICT-bezogenen Vorfällen, digitale operationelle Resilienztests, ICT-Drittparteienrisikomanagement und Informationsaustausch. Penetration Testing fällt unter die dritte Säule, die in Kapitel IV (Artikel 24 bis 27) der Verordnung behandelt wird – und es ist die Säule mit den schärfsten Zähnen für die täglichen Sicherheitsteams.

Wer fällt in den Anwendungsbereich?

DORA gilt flächendeckend für den Finanzsektor. Zu den Einrichtungen, die ihren Anforderungen unterliegen, gehören Kreditinstitute (Banken), Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, Versicherungs- und Rückversicherungsunternehmen, Krypto-Asset-Dienstleister gemäß MiCA, Zentralverwahrer, Handelsplätze, Transaktionsregister, Fondsverwaltungsgesellschaften, Ratingagenturen und Crowdfunding-Dienstleister, unter anderem.

In der Praxis: Wenn Ihre Organisation nach EU-Finanzdienstleistungsrecht reguliert ist, fallen Sie mit ziemlicher Sicherheit unter den Anwendungsbereich von DORA. Die Verordnung zielt bewusst darauf ab, ein breites Netz zu spannen, um sicherzustellen, dass die digitale operationelle Resilienz im gesamten Sektor einheitlich ist.

Es gibt eine Ausnahme, die erwähnenswert ist. Kleinstunternehmen – definiert als Unternehmen mit weniger als 10 Mitarbeitern und einem Jahresumsatz oder einer Bilanzsumme von unter 2 Millionen Euro – unterliegen einem leichteren Testregime. Sie müssen weiterhin einen risikobasierten Ansatz für ICT-Tests anwenden, aber die Anforderungen sind proportional skaliert. Für alle anderen gelten die vollen Testpflichten.

Und kritisch ist, dass die Reichweite von DORA über die Finanzinstitute selbst hinausgeht. ICT-Drittanbieter – Cloud-Plattformen, SaaS-Anbieter, Managed Service Provider, Datenanalyseunternehmen – fallen unter den Aufsichtsrahmen von DORA, insbesondere wenn sie als kritisch für die Stabilität des Finanzsektors gelten. Wenn Sie ein Technologieanbieter sind, der EU-Finanzinstitute bedient, werden die DORA-Verpflichtungen Ihrer Kunden schnell zu Ihrem Problem.

Die zwei Stufen der DORA-Tests

DORA etabliert einen zweistufigen Ansatz für Resilienztests. Das Verständnis dieser Struktur ist unerlässlich, da sich die Anforderungen, die Häufigkeit und die Komplexität zwischen den Stufen erheblich unterscheiden.

Dimension	Stufe 1: Standardtests	Stufe 2: TLPT (Fortgeschritten)
Wer	Alle DORA-regulierten Einrichtungen (außer Kleinstunternehmen)	Systemisch wichtige Einrichtungen, die von den zuständigen Behörden identifiziert werden
Frequenz	Mindestens jährlich für kritische/wichtige Funktionen	Mindestens alle 3 Jahre (Behörde kann anpassen)
Umfang	ICT-Systeme, die kritische oder wichtige Funktionen unterstützen	Kritische Funktionen auf Live-Produktionssystemen, einschließlich ICT von Drittanbietern
Ansatz	Schwachstellenbewertungen, Penetration Testing, szenariobasierte Tests und andere	Intelligence-gesteuerte Red Team-Übung, die reale Bedrohungsakteure nachahmt
Blue Team Awareness	In der Regel über Tests informiert	Nicht bewusst – Tests werden im Geheimen durchgeführt
Regulatorische Aufsicht	Testprogramm dokumentiert und auf Anfrage verfügbar	Umfang von der zuständigen Behörde validiert; Bescheinigung nach Abschluss ausgestellt

Stufe 1: Jährliches Penetration Testing gemäß Artikel 24 und 25

Die grundlegende Testanforderung gilt für jede DORA-regulierte Finanzinstitution, die kein Kleinstunternehmen ist. Artikel 24 verpflichtet Finanzinstitutionen, im Rahmen ihres ICT-Risikomanagementrahmens ein umfassendes Programm für digitale operationelle Resilienztests einzurichten, aufrechtzuerhalten und zu überprüfen.

Artikel 24 Absatz 6 ist die entscheidende Klausel: Finanzinstitutionen müssen sicherstellen, dass geeignete Tests auf allen ICT-Systemen und -Anwendungen durchgeführt werden, die kritische oder wichtige Funktionen unterstützen, und zwar mindestens einmal jährlich.

Artikel 25 listet dann die Arten von Tests auf, die das Testprogramm umfassen sollte. Die Verordnung verpflichtet nicht jede Einrichtung, jede Art von Test durchzuführen – der Grundsatz der Verhältnismäßigkeit gilt – aber die Beispiele geben ein klares Bild davon, was die Aufsichtsbehörden erwarten. Dazu gehören Schwachstellenbewertungen und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Gap-Analysen, physische Sicherheitsüberprüfungen, Quellcodeüberprüfungen (sofern möglich), szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetration Testing.

Für die meisten Finanzinstitutionen mit einer bedeutenden ICT-Infrastruktur wird Penetration Testing ein Kernbestandteil ihres jährlichen Programms sein. Die Verordnung ist eindeutig: Sie müssen nachweisen, dass Ihre Systeme realen Angriffstechniken standhalten können, und nicht nur, dass sie auf bekannte Schwachstellen gescannt wurden.

Was "kritische oder wichtige Funktionen" bedeutet

DORA definiert eine kritische oder wichtige Funktion als eine Funktion, deren Störung die Leistung der Finanzinstitution, die Solidität oder Kontinuität ihrer Dienstleistungen oder die fortlaufende Einhaltung ihrer regulatorischen Verpflichtungen wesentlich beeinträchtigen würde. In der Praxis umfasst dies Ihre Kerngeschäftsabläufe: Zahlungsabwicklung, Handelsplattformen, kundenorientierte Portale, Kreditentscheidungssysteme, Versicherungsanspruchsplattformen, Abrechnungsinfrastruktur und die Backendsysteme, die sie unterstützen.

Die Identifizierung dieser Funktionen ist der erste Schritt bei der Festlegung des Umfangs Ihres Testprogramms. Wenn ein System eine kritische oder wichtige Funktion unterstützt – direkt oder über Abhängigkeiten – fällt es in den Anwendungsbereich der jährlichen Tests.

Verhältnismäßigkeit: Skalierung von Tests auf Ihr Risikoprofil

DORA räumt ausdrücklich ein, dass nicht jede Finanzinstitution die gleiche Größe hat oder dem gleichen Risikoprofil ausgesetzt ist. Artikel 4 Absatz 2 legt einen Grundsatz der Verhältnismäßigkeit fest: Die Tiefe und Häufigkeit Ihrer Tests sollte auf die Größe und Komplexität Ihrer Einrichtung, das allgemeine Risikoprofil, die Kritikalität der getesteten ICT-Systeme, die Exposition durch Outsourcing- oder Cloud-Abhängigkeiten, wesentliche Änderungen an Ihrer ICT-Infrastruktur sowie die Schwere und die Ergebnisse früherer Vorfälle abgestimmt sein.

Dies bedeutet, dass von einem kleinen Fintech-Unternehmen mit einem fokussierten Produkt und einer begrenzten Infrastruktur nicht erwartet wird, dass es das Testprogramm einer G-SII (global systemisch bedeutendes Institut) erfüllt. Es bedeutet aber auch, dass Sie die Verhältnismäßigkeit nicht als pauschale Entschuldigung für die Durchführung minimaler Tests verwenden können. Der Grundsatz skaliert die Tiefe der Tests, nicht die Verpflichtung zu testen.

Stufe 2: Threat-Led Penetration Testing (TLPT) gemäß Artikel 26 und 27

Wenn standardmäßige jährliche Tests die Grundlage von DORA bilden, ist TLPT die fortgeschrittene Stufe – und es ist ein grundlegend anderes Konzept.

TLPT ist eine umfassende, intelligence-gesteuerte Red Team-Übung, die auf Live-Produktionssystemen durchgeführt wird, im Geheimen vor den Abwehrteams der Organisation und die Taktiken, Techniken und Verfahren nachahmt, die reale Bedrohungsakteure gegen die Einrichtung einsetzen würden. Es ist kein Schwachstellenscan mit einem ausgefallenen Namen. Es ist ein kontrollierter Cyberangriff, der darauf abzielt, zu testen, ob Ihr Institut – seine Technologie, seine Prozesse und seine Mitarbeiter – einem ausgeklügelten, gezielten Eindringen standhalten und es erkennen kann.

TLPT ist nur für bestimmte Finanzinstitute obligatorisch, die von ihren zuständigen Behörden auf der Grundlage der Systemrelevanz, des Risikoprofils und der ICT-Reife identifiziert werden. Zu den Einrichtungen, die am wahrscheinlichsten benannt werden, gehören global systemrelevante Banken (G-SIIs) und andere systemrelevante Institute (O-SIIs), die größten Zahlungsinstitute (die in den letzten zwei Jahren jeweils Transaktionen im Gesamtwert von über 150 Milliarden Euro verarbeiten), große Versicherungs- und Rückversicherungsunternehmen, zentrale Gegenparteien und Zentralverwahrer sowie wichtige Handelsplätze.

Wenn Ihre zuständige Behörde Sie für TLPT benennt, müssen Sie mindestens alle drei Jahre fortgeschrittene Tests durchführen. Die Behörde kann diese Häufigkeit auch auf der Grundlage Ihres Risikoprofils und Ihrer betrieblichen Gegebenheiten erhöhen oder verringern.

Wie TLPT funktioniert: Die sechs Phasen

Die technischen Regulierungsstandards zu TLPT (delegierte Verordnung (EU) 2025/1190 der Kommission, veröffentlicht im Juni 2025) definieren einen strukturierten Prozess, der mehrere verschiedene Phasen umfasst.

Die Vorbereitungsphase beginnt, wenn die zuständige Behörde (Ihre TLPT-Behörde) Ihrer Einrichtung mitteilt, dass sie eine TLPT durchführen muss. Sie stellen ein Kontrollteam zusammen – eine kleine, vertrauenswürdige Gruppe innerhalb Ihrer Organisation, die den Test verwaltet – und identifizieren die kritischen Funktionen, die getestet werden sollen. Der Umfang wird dann der TLPT-Behörde zur Validierung vorgelegt.

Die Bedrohungsinformationsphase umfasst die Erstellung eines gezielten Bedrohungsinformationsberichts durch einen Bedrohungsinformationsanbieter speziell für Ihr Institut. Dieser Bericht analysiert die Bedrohungsakteure, die Ihr Unternehmen am wahrscheinlichsten ins Visier nehmen, ihre bekannten Taktiken und Techniken sowie die Angriffsszenarien, die für Ihr Geschäftsmodell, Ihren Technologie-Stack und Ihre geografische Lage am relevantesten sind. Diese Informationen treiben den gesamten Test an – und stellen sicher, dass er reale Bedrohungen widerspiegelt und keine generischen Angriffsdrehbucher.

Die Red Team-Testphase ist die Ausführung. Das Red Team – ausgehend von den Bedrohungsinformationen – führt eine nachhaltige Angriffskampagne gegen Ihre Live-Produktionssysteme durch. Im Gegensatz zu Standard-Penetration Testing läuft der Test über einen längeren Zeitraum (in der Regel drei bis vier Monate), das Blue Team (Ihre Verteidiger) wird nicht informiert und das Ziel ist es, eine echte Advanced Persistent Threat zu simulieren.

Die Abschlussphase umfasst eine obligatorische Purple Teaming-Übung, was ein wesentlicher Unterschied zum vorherigen TIBER-EU-Framework ist, bei dem Purple Teaming nur empfohlen wurde. Während des Purple Teamings arbeiten das Red Team und das Blue Team zusammen, um die Angriffsszenarien durchzugehen, zu überprüfen, was erkannt wurde und was übersehen wurde, und gemeinsam Verbesserungen zu identifizieren. Dies stellt sicher, dass der Test Lernen generiert und nicht nur Ergebnisse.

Schließlich erstellt die Berichts- und Behebungsphase eine Dokumentation, die der zuständigen Behörde zur Validierung und Bescheinigung vorgelegt wird. Die Behörde bestätigt, dass die TLPT in Übereinstimmung mit den Anforderungen von DORA durchgeführt wurde und stellt eine formelle Bescheinigung aus.

TLPT vs. Standard Penetration Testing: Den Unterschied verstehen

Die Unterscheidung zwischen TLPT und Standard Penetration Testing ist eines der wichtigsten Konzepte für die Einhaltung von DORA und eines der am häufigsten missverstandenen.

Ein Standard Penetration Test zielt in der Regel auf ein bestimmtes System oder eine bestimmte Anwendung ab – eine Webanwendung, eine API, ein Netzwerksegment. Er dauert ein bis drei Wochen. Das Sicherheitsteam weiß, dass er stattfindet. Der Umfang ist begrenzt und im Voraus vereinbart. Der Tester sucht nach technischen Schwachstellen, versucht, sie auszunutzen, und erstellt einen Bericht mit Ergebnissen und Anleitungen zur Behebung. Es ist eine technische Bewertung einer definierten Oberfläche.

Eine TLPT deckt die gesamte Organisation ab. Sie zielt auf kritische Geschäftsfunktionen ab – nicht auf bestimmte Systeme. Sie dauert Monate, nicht Wochen. Das Verteidigungsteam ist völlig ahnungslos. Der Test wird von maßgeschneiderten Bedrohungsinformationen gesteuert, nicht von einer generischen Methodik. Die Tester simulieren den gesamten Lebenszyklus eines realen Angriffs: Aufklärung, anfänglicher Zugriff, Persistenz, laterale Bewegung, Privilegienerweiterung und Datenexfiltration oder operative Störung. Und er testet nicht nur die Technologie, sondern auch die Mitarbeiter (fallen Mitarbeiter auf Phishing herein?) und Prozesse (erkennt das SOC das Eindringen? Funktioniert der Incident-Response-Plan tatsächlich?).

Stellen Sie es sich so vor: Ein Penetration Test fragt "Kann jemand in diesen Raum einbrechen?" TLPT fragt "Kann ein ausgeklügelter Gegner in unser Gebäude gelangen, den Tresor finden, ihn öffnen, das nehmen, was er will, und gehen, ohne dass es jemand bemerkt?"

ICT-Drittanbieter: Sie sind nicht aus dem Schneider

Eine der bedeutendsten Innovationen von DORA ist die Behandlung des ICT-Drittparteienrisikos als systemisches Problem und nicht als bilaterale Vertragsangelegenheit. Wenn Sie ein Cloud-Anbieter, ein SaaS-Anbieter, ein Managed Security Service oder ein anderes Technologieunternehmen sind, das EU-Finanzinstitutionen bedient, erreicht Sie DORA in verschiedenen wichtigen Punkten.

Erstens müssen Finanzinstitute vertraglich von ihren ICT-Drittanbietern verlangen, dass sie an TLPT teilnehmen und mit ihr zusammenarbeiten, wenn diese Anbieter in den Testumfang einbezogen werden. Artikel 30 Absatz 3 Buchstabe d von DORA macht dies explizit. Wenn Ihre Cloud-Plattform die Zahlungsabwicklungsinfrastruktur einer Bank hostet und diese Bank für TLPT benannt wird, muss die Bank Ihre Teilnahme an dem Test sicherstellen – und Sie müssen dies ermöglichen.

Zweitens werden ICT-Anbieter, die als kritisch für die Stabilität des Finanzsektors gelten, von den Europäischen Aufsichtsbehörden (ESAs) als Critical Third-Party Providers (CTPPs) benannt. CTPPs unterliegen der direkten Aufsicht der ESAs, einschließlich spezifischer Anforderungen an Sicherheitstests, Risikomanagement und operationelle Resilienz. Die erste Welle von CTPP-Benennungen wird voraussichtlich im Jahr 2025 erfolgen, nach Kritikalitätsbewertungen durch die ESAs.

Drittens wird DORA, selbst wenn Sie nicht als CTPP benannt sind, schnell zu einem Beschaffungsfilter. Finanzinstitute, die Technologieanbieter evaluieren, werden zunehmend Nachweise über robuste Sicherheitstestprogramme, die Fähigkeit zur Unterstützung von kundenorientierten Simulationen und die Bereitschaft zu gemeinsamen operativen Tests verlangen. Nichteinhaltung bedeutet nicht nur regulatorisches Risiko, sondern auch den Verlust des Zugangs zu europäischen Finanzkunden.

Wenn Sie EU-regulierte Finanzinstitute bedienen, ist der praktische Rat einfach: Bereiten Sie sich darauf vor, die DORA-Testanforderungen Ihrer Kunden zu unterstützen, bieten Sie gegebenenfalls isolierte Testumgebungen an und seien Sie bereit, Ihre eigene operationelle Resilienz durch dokumentierte Testprogramme nachzuweisen.

Wer kann Tests durchführen?

DORA legt spezifische Qualifikationsanforderungen für Tester fest, insbesondere für TLPT.

Standardtests (Artikel 24–25)

Für das jährliche Testprogramm erlaubt DORA, dass Tests von unabhängigen internen Teams oder von qualifizierten externen Anbietern durchgeführt werden. Die wichtigste Anforderung ist die Unabhängigkeit – Tester dürfen keine Interessenkonflikte haben und dürfen kein Eigeninteresse an den Ergebnissen haben. Wenn Sie interne Tester einsetzen, ist eine angemessene organisatorische Trennung erforderlich.

Die Verordnung schreibt keine spezifischen Zertifizierungen für Standardtests vor, verlangt aber, dass die Tester über die notwendigen Fähigkeiten und Fachkenntnisse verfügen. In der Praxis erwarten die zuständigen Behörden, dass die Tester anerkannte Berufsqualifikationen und nachweisbare Erfahrung in den durchgeführten Testarten haben.

TLPT (Artikel 26–27)

Für TLPT sind die Anforderungen wesentlich strenger. Die Verordnung schreibt vor, dass die Tester von höchster Eignung und Reputation sind, über technische und organisatorische Fähigkeiten mit spezifischen Fachkenntnissen in den Bereichen Bedrohungsinformationen, Penetration Testing oder Red Team-Tests verfügen, von einer Akkreditierungsstelle in einem Mitgliedstaat zertifiziert sind oder formellen Verhaltensregeln oder ethischen Rahmenbedingungen folgen und für externe Tester eine Berufshaftpflichtversicherung gegen das Risiko von Fehlverhalten abschließen.

Eine wichtige Nuance: DORA erlaubt internen Testern, die Red Team-Komponente von TLPT durchzuführen, jedoch mit zwei wesentlichen Einschränkungen. Die Bedrohungsinformationen müssen immer von einer externen Partei bereitgestellt werden, und jede dritte TLPT muss von einem externen Red Team-Anbieter durchgeführt werden. In der Praxis bedeutet dies, dass Sie auch dann, wenn Sie eine interne Red Team-Fähigkeit aufbauen, für mindestens einen von drei TLPT-Zyklen externe Tester benötigen.

Behebung, Berichterstattung und Bescheinigung

DORA behandelt Tests nicht als eigenständige Aktivität – sie sind in einen kontinuierlichen Verbesserungskreislauf eingebettet. Die Verordnung verpflichtet Finanzinstitute, Verfahren und Richtlinien festzulegen, um alle durch Tests aufgedeckten Probleme zu priorisieren, zu klassifizieren und zu beheben und sicherzustellen, dass alle identifizierten Schwachstellen und Mängel vollständig behoben werden.

Für standardmäßige jährliche Tests wird erwartet, dass Ihr Testprogramm dokumentierte Ergebnisse generiert, diese Ergebnisse nach Schweregrad eingeteilt werden, die Behebung verfolgt und abgeschlossen wird und die Ergebnisse in Ihren ICT-Risikomanagementrahmen zurückfließen. Ihre Dokumentation muss den zuständigen Behörden auf Anfrage zur Verfügung stehen.

Für TLPT sind die Anforderungen formeller. Nach Abschluss des Tests – einschließlich der obligatorischen Purple Teaming-Übung – legen die Finanzinstitution und die externen Tester der zuständigen Behörde eine Dokumentation vor, die bestätigt, dass die TLPT in Übereinstimmung mit den Anforderungen von DORA durchgeführt wurde. Die zuständige Behörde validiert diese Dokumentation und stellt eine Bescheinigung aus. Diese Bescheinigung kann dann an andere zuständige Behörden weitergegeben werden, um die gegenseitige Anerkennung zu ermöglichen, wodurch die Notwendigkeit doppelter Tests über verschiedene Gerichtsbarkeiten hinweg reduziert wird.

Der Mechanismus der gegenseitigen Anerkennung ist eine der praktischsten Innovationen von DORA. Wenn Sie eine grenzüberschreitende Institution sind, die in mehreren EU-Mitgliedstaaten tätig ist, kann eine einzige TLPT-Bescheinigung die Aufsichtsanforderungen in allen Gerichtsbarkeiten erfüllen – eine deutliche Verbesserung gegenüber der Zeit vor DORA, in der separate nationale Testrahmen separate Tests erforderten.

Wichtige Zeitpläne

Der Zeitplan ist strategisch wichtig. Wenn Sie ein Kandidat für die TLPT-Benennung sind, werden die ersten Benachrichtigungen im Jahr 2026 erwartet. Das sechsmonatige Fenster von der Benachrichtigung bis zur Einreichung des Umfangs ist für Organisationen, die nicht die Grundlagen gelegt haben, knapp bemessen. Beginnen Sie mit der Funktionszuordnung, identifizieren Sie Ihren Kontrollteamleiter und bewerten Sie Ihre Anbieteroptionen, bevor Sie das Schreiben erhalten.

Aufbau Ihres DORA-Testprogramms

Egal, ob Sie ein mittelgroßes Zahlungsinstitut sind, das ein Testprogramm von Grund auf aufbaut, oder ein G-SII, das ein bestehendes Programm an die Anforderungen von DORA anpasst, hier ist ein praktischer Rahmen.

Schritt 1: Ordnen Sie Ihre kritischen und wichtigen Funktionen zu

Bevor Sie etwas testen können, müssen Sie wissen, was wichtig ist. Identifizieren Sie alle Funktionen, deren Störung die Leistung Ihrer Einrichtung, die Kontinuität Ihrer Dienstleistungen oder die Einhaltung der regulatorischen Bestimmungen wesentlich beeinträchtigen würde. Ordnen Sie dann die ICT-Systeme, Anwendungen und Drittanbieterabhängigkeiten zu, die jede Funktion unterstützen. Diese Zuordnung wird zur Grundlage Ihres Testumfangs und fließt direkt in Ihren ICT-Risikomanagementrahmen ein.

Schritt 2: Richten Sie ein risikobasiertes Testprogramm ein

Entwerfen Sie ein Testprogramm, das alle ICT-Systeme abdeckt, die kritische oder wichtige Funktionen unterstützen, die in Artikel 25 aufgeführten Testarten umfasst (skaliert auf Ihr Verhältnismäßigkeitsprofil), mindestens jährlich durchgeführt wird und sich an wesentliche Änderungen Ihrer Infrastruktur, die Ergebnisse früherer Tests und sich entwickelnde Bedrohungsinformationen anpasst.

Dokumentieren Sie das Programm formell. DORA verlangt, dass Ihr Testprogramm dokumentiert, überprüft und als Teil Ihres ICT-Risikomanagementrahmens aufrechterhalten wird. Diese Dokumentation muss Ihrer zuständigen Behörde auf Anfrage zur Verfügung stehen.

Schritt 3: Beziehen Sie qualifizierte Testanbieter ein

Für die meisten Einrichtungen werden externe Penetration Testing-Anbieter die jährliche Testkomponente bereitstellen. Wählen Sie Anbieter aus, die über nachgewiesene Erfahrung im Finanzsektor verfügen, die spezifischen Anforderungen von DORA verstehen und Berichte erstellen können, die den regulatorischen Erwartungen entsprechen. Stellen Sie sicher, dass die Engagement-Verträge die Anforderungen an die Unabhängigkeit, die Vertraulichkeitsverpflichtungen und den Prozess der Umfangsangleichung berücksichtigen.

Wenn Sie ein Kandidat für TLPT sind, müssen Sie auch Anbieter von Bedrohungsinformationen und Red Team-Anbieter identifizieren, die die strengen Qualifikationen erfüllen, die in Artikel 27 und der TLPT RTS aufgeführt sind. Beginnen Sie diese Bewertung frühzeitig – der Pool qualifizierter TLPT-Anbieter ist kleiner als der allgemeine Penetration Testing-Markt, und die Terminplanungsfenster füllen sich schnell.

Schritt 4: Bauen Sie den Behebungskreislauf auf

Tests ohne Behebung sind Leistung ohne Zweck. Richten Sie einen dokumentierten Workflow ein, der Ergebnisse von der Identifizierung über die Behebung bis zur Verifizierung verfolgt. Klassifizieren Sie die Ergebnisse nach Schweregrad, weisen Sie die Verantwortung zu, definieren Sie Reaktionszeiten und verfolgen Sie den Abschluss. Jede Behebung sollte verifiziert werden – entweder durch erneute Tests oder durch eine validierte Kontrollimplementierung.

Speisen Sie Ihre Testergebnisse in Ihren ICT-Risikomanagementrahmen zurück. DORA betrachtet Tests als einen Input in ein umfassenderes Bild der Resilienz – nicht als eine eigenständige Compliance-Übung.

Schritt 5: Bereiten Sie sich auf TLPT vor (falls zutreffend)

Wenn Ihre Einrichtung wahrscheinlich für TLPT benannt wird, sollte die Vorbereitung beginnen, lange bevor die Benachrichtigung eintrifft. Identifizieren Sie einen Kontrollteamleiter – jemanden, der erfahren genug ist, um den Test über organisatorische Grenzen hinweg zu verwalten, und dem genügend Vertrauen entgegengebracht wird, um die Geheimhaltung vor dem Blue Team zu wahren. Ordnen Sie die kritischen Funktionen zu, die wahrscheinlich in den Anwendungsbereich fallen werden. Bewerten Sie Drittanbieterabhängigkeiten, die möglicherweise einbezogen werden müssen. Überprüfen Sie Ihre vertraglichen Vereinbarungen mit ICT-Anbietern, um sicherzustellen, dass DORA-konforme Beteiligungsklauseln vorhanden sind.

Häufige Fehler bei der DORA-Test-Compliance

Behandlung von Tests als Kontrollkästchen

Die gesamte Philosophie von DORA ist Resilienz – nicht Compliance-Theater. Die Aufsichtsbehörden haben die Testanforderungen entwickelt, um sicherzustellen, dass Finanzinstitute Cyberangriffen wirklich standhalten können, und nicht nur Berichte erstellen, die besagen, dass sie es versucht haben. Wenn Ihr Testprogramm Ergebnisse generiert, die nie behoben werden, die einfachen Systeme abdeckt und die komplexen vermeidet oder Berichte erstellt, die bis zum nächsten Audit in einer Schublade liegen, verfehlen Sie den Punkt und die Aufsichtsbehörde wird es bemerken.

Verwechslung von Schwachstellenscans mit Penetration Testing

Artikel 25 listet sowohl Schwachstellenbewertungen und -scans als auch Penetration Testing als Bestandteile eines Testprogramms auf. Dies sind unterschiedliche Aktivitäten. Automatisierte Schwachstellenscans identifizieren bekannte Schwachstellen in großem Maßstab. Penetration Testing beinhaltet, dass ein qualifizierter menschlicher Tester aktiv versucht, diese Schwachstellen auszunutzen, sie miteinander zu verketten und die Auswirkungen in der realen Welt zu bewerten. Einen Nessus-Scan durchzuführen und ihn als Penetration Test zu bezeichnen, wird DORA nicht zufriedenstellen.

Ignorieren von Drittanbieterabhängigkeiten

Wenn Ihre kritischen Funktionen von ICT-Drittanbietern abhängen – und im modernen Finanzdienstleistungsbereich ist dies mit ziemlicher Sicherheit der Fall –, muss Ihr Testprogramm diese Abhängigkeiten berücksichtigen. Für Standardtests bedeutet dies, die Sicherheitslage Ihrer Drittanbieterverbindungen und -schnittstellen zu bewerten. Für TLPT bedeutet dies, vertraglich sicherzustellen, dass Ihre Anbieter an dem Test teilnehmen. Finanzinstitute, die das Drittparteienrisiko in ihrem Testumfang ignorieren, schaffen genau die Art von Blindstellen, die DORA beseitigen soll.

Annahme, dass TLPT nur ein größerer Penetration Test ist

Wir haben es schon gesagt, aber es ist es wert, es zu wiederholen. TLPT ist eine grundlegend andere Aktivität als Penetration Testing. Es ist intelligence-gesteuert, wird auf Live-Produktionssystemen durchgeführt, wird im Geheimen vor Ihren Abwehrteams ausgeführt, wird über Monate statt Wochen ausgeführt, erfordert obligatorisches Purple Teaming und wird von Ihrer zuständigen Behörde validiert und bescheinigt. TLPT mit einer Penetration Testing-Mentalität anzugehen – begrenzter Umfang, kurzer Zeitrahmen, rein technischer Fokus – wird zu einem Test führen, der die regulatorischen Anforderungen nicht erfüllt und keine aussagekräftigen Resilienz-Erkenntnisse liefert.

Warten auf Benachrichtigung

Wenn Sie ein systemisch wichtiges Institut sind, ist es ein strategischer Fehler, auf die formelle Benachrichtigung durch Ihre zuständige Behörde zu warten, bevor Sie sich auf TLPT vorbereiten. Das Fenster von der Benachrichtigung bis zur Festlegung des Umfangs beträgt etwa sechs Monate, und die erforderliche Vorbereitung – Funktionszuordnung, Anbieterauswahl, Vertragsverhandlungen, Bildung des Kontrollteams, Beschaffung von Bedrohungsinformationen – ist erheblich. Organisationen, die frühzeitig beginnen, werden reibungslosere Tests durchführen, bessere Ergebnisse erzielen und ihren Aufsichtsbehörden demonstrieren, dass sie die operationelle Resilienz ernst nehmen.