Ein Penetrationstest für Finanzdienstleister muss mehr leisten. Das bloße Aufdecken isolierter technischer Lücken reicht nicht aus. Er muss aufzeigen, wie sich konkrete Angriffspfade auf kritische Geschäftsprozesse auswirken, ob definierte Schutzmaßnahmen unter realen Bedingungen standhalten und wie belastbar die Evidenzen für Governance, Risikomanagement sowie aufsichtsrechtliche Audits ausfallen.

Für einen DORA-orientierten Penetrationstest sollten mindestens die externe Angriffsfläche, Webanwendungen, APIs, interne Netzwerke, Cloud- und ICT-Infrastrukturen, mobile Anwendungen, Social-Engineering-Risiken sowie kritische Geschäftsprozesse und Wiederanlaufverfahren berücksichtigt werden. DORA schreibt dabei keine offizielle Einteilung in genau acht Prüffelder vor. Die folgende Struktur bietet jedoch eine praxisorientierte Grundlage für Scope, Durchführung und Nachweisführung.

DORA – die Verordnung über die digitale operationale Resilienz im Finanzsektor – bildet den europäischen Regulierungsrahmen für das Management von ICT-Risiken. Finanzunternehmen müssen ihre digitale Widerstandsfähigkeit kontinuierlich überprüfen und strukturierte Testprogramme etablieren. Dazu gehören je nach Risikoprofil Schwachstellenanalysen, Penetrationstests und weitergehende Resilienzprüfungen.

Die Anforderungen verpflichten IT-Leitungen und Informationssicherheitsverantwortliche dazu, Sicherheitstests aus dem Silo der reinen IT-Sicherheit herauszuholen. Entscheidend ist die verknüpfte Betrachtung von kritischen Geschäftsprozessen, unterstützenden ICT-Services, externen Abhängigkeiten und den messbaren operativen Folgen einer Systemkompromittierung.

Aufsichtsbehörden beziehen die Resultate von Tests, einschließlich der Findings aus Threat-Led Penetration Tests (TLPT), gezielt in die regulatorische Bewertung des ICT-Risikomanagements und der operationalen Stabilität ein.

Penetrationstests als Bestandteil des ICT-Risikomanagements

Ein Penetrationstest prüft, ob sich identifizierte Schwachstellen unter kontrollierten, aber realistischen Bedingungen tatsächlich ausnutzen lassen. Dabei geht es nicht um theoretische Risikoannahmen, sondern um den Nachweis konkreter Effekte: den unbefugten Zugriff auf Kunden- oder Vertragsdaten, die unberechtigte Ausführung von Zahlungsverkehrstransaktionen, die Übernahme privilegierter Administrationskonten oder die gezielte Störung einer kritischen Kernfunktion.

Ein automatisierter Schwachstellenscan liefert eine breite Bestandsaufnahme bekannter Sicherheitslücken in Systemen und Softwarekomponenten. Er kann jedoch weder komplexe Angriffsketten abbilden noch die tatsächliche Auswirkung auf geschäftliche Abläufe bewerten. Der Penetrationstest ergänzt diese Basisanalyse durch eine simulierte, zielgerichtete Ausnutzung. Die Ergebnisse müssen lückenlos aufbereitet werden, um direkt in das Risikoregister, das Schwachstellenmanagement und das Management-Reporting einzufließen. Dafür sind strukturierte Angaben zu Scope, Methodik, Testzeitraum, Findings, Risikobewertung und Nachtests erforderlich.

Penetrationstest, TLPT und Schwachstellenscan im Vergleich

Ein DORA TLPT geht über einen regulären Penetrationstest hinaus. Er basiert auf spezifischen Threat-Intelligence-Erkenntnissen und prüft die Abwehr- und Reaktionsfähigkeit gegen hochentwickelte Angriffsszenarien direkt an kritischen oder wichtigen Funktionen.

Die technischen Regulierungsstandards zum TLPT sind auf EU-Ebene in der Delegierten Verordnung (EU) 2025/119 verankert. Ob eine Einrichtung einen vollwertigen TLPT durchführen muss oder ein risikobasierter Penetrationstest ausreicht, hängt von der jeweiligen aufsichtsrechtlichen Einstufung, den betriebenen Systemen und den aktuellen behördlichen Vorgaben ab.

Was DORA nicht vorgibt

DORA schreibt weder eine starre Struktur von genau acht Prüffeldern vor noch existiert ein universelles Testschema für jedes Institut. Jedes Finanzunternehmen ist verpflichtet, eine individuelle, risikobasierte Auswahl der Testgegenstände zu treffen.

Maßgeblich für die Festlegung sind die Identifikation kritischer Funktionen, die zugehörigen Datenflüsse, die aktuelle Bedrohungslage sowie die Abhängigkeit von externen ICT-Drittdienstleistern. Ein Penetrationstest stellt zudem keinen Ersatz für das Gesamtsystem der DORA-Compliance dar. Governance-Strukturen, Incident Management, Business Continuity Plans und das Drittparteien-Risikomanagement erfordern eigenständige Prozesse. Je nach Geschäftsmodell sind ergänzende Vorgaben wie PCI DSS, NIS-2 oder KRITIS-Bestimmungen abzugrenzen und in die Prüfplanung zu integrieren.

Die nachfolgenden Abschnitte gliedern die technische und organisatorische Prüfpraxis für einen Penetrationstest Finanzdienstleister. Welches Feld mit welcher Intensität untersucht wird, leitet sich direkt aus der Risikoanalyse der jeweiligen Organisation ab.

1. Externe Angriffsfläche und Perimeter

Die Analyse der externen Angriffsfläche erfasst sämtliche aus dem Internet erreichbaren Systeme, IP-Bereiche, VPN-Gateways, Webserver und Schnittstellen. Geprüft werden fehlerhafte Dienste-Konfigurationen, veraltete Softwarestände, unsichere TLS-Implementierungen und exponierte Verwaltungsschnittstellen. Da vergessene Testsysteme oder unvollständige Asset-Inventare häufig als Einfallstor dienen, gleicht der Test den Ist-Zustand direkt mit dem zentralen Asset-Register ab.

2. Webanwendungen und Kundenportale

Kunden- und Partnerportale im Banken- und Versicherungsumfeld verarbeiten hochsensible Informationen. Der Penetrationstest untersucht hierbei die Robustheit der Authentifizierung, die Durchsetzung der Mandantentrennung, das Session-Management sowie die Absicherung der Geschäftslogik gegen Eingabemanipulationen. Ziel ist es festzustellen, ob Angreifer Berechtigungsprüfungen umgehen, fremde Datensätze einsehen oder nicht autorisierte Transaktionen ausführen können.

3. APIs und Systemintegrationen

Programmierschnittstellen verbinden Kundenanwendungen mit Kernbanksystemen, Zahlungsdienstleistern und externen ICT-Partnern. Bei der Überprüfung stehen die Token-Validierung, Berechtigungskonzepte, Rate-Limiting-Mechanismen sowie der Schutz vor Request-Manipulationen im Mittelpunkt. Ein API-Test deckt auf, ob über technische Schnittstellen unzulässiger Datenzugriff möglich ist oder administrative Befehle abgesetzt werden können.

4. Interne Netzwerke und Active Directory

Nach einem potenziellen Erstzugriff versuchen Angreifende, sich intern weiterzubewegen und ihre Rechte auszuweiten. Die Überprüfung konzentriert sich auf die wirksame Segmentierung des Netzwerks, das Identitätsmanagement im Active Directory, die Absicherung privilegierter Konten sowie den Schutz von Servern mit Zugriff auf Kernbank- oder Versicherungssysteme. Die Analyse zeigt, ob ein kompromittierter Standard-Arbeitsplatz zur vollständigen Übernahme der Domäne führen kann.

5. Cloud- und ICT-Infrastrukturen

Hybride und Cloud-basierte Betriebsumgebungen erfordern eine genaue Prüfung von Identitäts- und Zugriffskonzepten, Container-Sicherheiten, virtuellen Netzwerken und der Verwaltung von Secret-Keys. Neben rein technischen Schwachstellen wird die Abgrenzung der Verantwortlichkeiten zwischen dem Finanzunternehmen und dem Cloud-Provider bewertet, um Konfigurationsfehler an den Schnittstellen zu verhindern.

6. Mobile Anwendungen und Endgeräte

Mobile Banking- oder Versicherungs-Apps werden auf lokalen Speichermechanismen, Verschlüsselungsstandards, API-Kommunikation und den Widerstand gegen Reverse Engineering geprüft. Ergänzend fließen Endgeräte wie Unternehmens-Laptops und Mobile-Device-Management-Lösungen in den Test ein, um Risiken durch verloren gegangene oder manipulierte Hardware einzudämmen.

7. Social Engineering und physische Sicherheitskontrollen

Menschliche und physische Faktoren bilden oft das schwächste Glied der Sicherheitskette. Durch kontrollierte Phishing-Simulationen, Vishing-Tests oder Prüfungen der Zutrittskontrollen vor Ort wird bewertet, wie effektiv Sicherheitsrichtlinien gelebt werden. Solche Tests erfordern vorab präzise definierte Abbruchkriterien, Freigabeprozesse und den vollen Schutz der Mitarbeitenden.

8. Kritische Geschäftsprozesse, Resilienz und Wiederanlauf

Dieser Prüfbereich bewertet die Auswirkung technischer Ausfälle auf den laufenden Betrieb. Es wird analysiert, wie sich der Ausfall einer Anwendung oder Datenbank auf die Gesamtwiderstandsfähigkeit auswirkt und ob etablierte Notfall-, Backup- und Wiederanlaufverfahren unter Last wie vorgesehen funktionieren. Die Ergebnisse stellen die direkte Verbindung zwischen technischem Pentest und dem Business Continuity Management her.

Die Festlegung des Testumfangs beginnt mit der Identifikation der kritischen Geschäftsprozesse. Ausgehend von den Geschäftsprozessen werden die unterstützenden ICT-Systeme, Datenbanken und Schnittstellen kartiert, um den effektiven Scope festzulegen. Begründete Ausschlüsse von Systemen müssen nachvollziehbar dokumentiert werden, um bei regulatorischen Überprüfungen zu bestehen.

Die Verhaltensregeln, die sogenannten Rules of Engagement, definieren den zeitlichen Rahmen, die erlaubten Angriffsformen, Kommunikationskanäle für Notfälle und klare Abbruchkriterien. Je nach Zielsetzung kommen Black-Box-, Grey-Box- oder White-Box-Ansätze zum Einsatz. Der Schutz von Live-Daten und die unterbrechungsfreie Verfügbarkeit des Geschäftsbetriebs haben während der gesamten Testphase höchste Priorität.

Nach dem Test erfordert jedes Finding eine geschäftliche Risikobewertung, die über reine Schwachstellen-Scores hinausgeht. Der abschließende Bericht muss neben detaillierten technischen Angaben eine adressatengerechte Zusammenfassung für Management und Revision enthalten.

Die nachfolgende Übersicht fasst die zentralen Einzelschritte von der Vorbereitung bis zum Audit-Nachweis zusammen:

• Scope-Definition: Zuordnung von Systemen und Schnittstellen zu den kritischen Geschäftsprozessen sowie Dokumentation vertraglicher Freigaben von ICT-Drittdienstleistern.
   
• Rules of Engagement: Festlegung von Testmethodik, Zeitfenstern, Notfallkontakten und Schutzmaßnahmen für produktive Datenbestände.
   
• Risikobasierte Bewertung: Einstufung der Findings nach technischer Schwere und konkreter geschäftlicher Auswirkung auf das Institut.
   
• Remediation & Nachtest: Verbindliche Zuweisung von Behebungsverantwortlichen, Definition von Fristen und Durchführung technischer Nachtests zur Nachweisführung.
   
• Auditfeste Dokumentation: Erstellung von Management Summaries, Aktualisierung des Risikoregisters und Aufbereitung der Nachweise für die Aufsicht.

Ein qualifizierter Testanbieter für den Finanzsektor muss fundierte Kenntnisse der Branchenprozesse, der regulatorischen Vorgaben nach DORA sowie praktisches Know-how zu Kernbanksystemen, Finanz-APIs und komplexen Multi-Cloud-Architekturen nachweisen. Entscheidend ist die nachweisbare Fachexpertise des eingesetzten Testteams.

Um Interessenkonflikte auszuschließen, ist eine strikte organisatorische Trennung zwischen der Sicherheitsberatung, der technischen Implementierung und der eigentlichen Prüfinstanz erforderlich. Verträge mit Dienstleistern müssen den Scope, den Umgang mit vertraulichen Daten, Löschpflichten, Nachbesserungsfristen für Nachtests sowie die Einbindung von Subunternehmern eindeutig regeln.

Jedes identifizierte Risiko erfordert eine eindeutige Zuweisung an eine verantwortliche Person innerhalb der IT- oder Fachorganisation inklusive verbindlicher Fertigstellungsfrist. Kann eine Schwachstelle kurzfristig nicht behoben werden, müssen kompensierende Sicherheitskontrollen eingerichtet und im Risikoregister formal dokumentiert werden.

Die Behebung einer Schwachstelle ist erst dann abgeschlossen, wenn ein technischer Nachtest das Schließen des spezifischen Angriffswegs bestätigt hat. Die gewonnenen Erkenntnisse fließen direkt in die Weiterentwicklung interner Architekturvorgaben, Patch-Management-Prozesse und Sicherheitsstandards ein.

Durch die Definition klarer Kennzahlen, wie der durchschnittlichen Behebungsdauer kritischer Findings oder der Wiederholungsquote von Konfigurationsfehlern, lässt sich der Fortschritt der digitalen Resilienz dauerhaft messen und gegenüber Aufsichtsbehörden belegen.

Ein strukturierter Penetrationstest für Finanzdienstleister schlägt die Brücke zwischen technischer Detailprüfung und strategischem Risikomanagement. Die acht Prüffelder bieten IT-Leitungen und Sicherheitsverantwortlichen eine klare Orientierung, um den Scope präzise abzugrenzen, gesetzliche Nachweispflichten zu erfüllen und den Betrieb nachhaltig abzusichern.

audius steht Finanzinstituten als erfahrener Partner bei der Konzeption, Durchführung und auditfesten Aufbereitung DORA-orientierter Sicherheitstests zur Seite. Gemeinsam mit der Tochtergesellschaft Ergonomics in Zürich, die auf hochsichere Softwareentwicklung, Cyber Security und Compliance im europäischen Finanzsektor spezialisiert ist, unterstützt audius Organisationen dabei, technische Prüfergebnisse in wirksame Schutzmaßnahmen und wiederholbare Governance-Prozesse zu überführen. So wird die Erfüllung regulatorischer Vorgaben mit einer echten Steigerung der operationalen Resilienz verbunden.