DORA Pentest: Penetrationstest-Pflichten nach Art. 24 und Art. 26

Seit dem 17. Januar 2025 gilt der Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) unmittelbar in allen EU-Mitgliedstaaten. Artikel 24 verpflichtet Finanzunternehmen zu regelmäßigen Penetrationstests ihrer IKT-Systeme; Artikel 26 schreibt für systemrelevante Institute zusätzlich Threat-Led Penetration Tests (TLPT) vor. Dieser Leitfaden erklärt, welche Unternehmen in-scope sind, was die Verordnung konkret fordert und welcher Pentest-Ansatz die Anforderungen erfüllt.

DORA-Pentest starten

Geschrieben von Malte Wagenbach

Gründer von Matproof Security. Spezialisiert auf KI-gestützte Penetrationstests und EU-Compliance (DORA, NIS2, BSI Grundschutz, ISO 27001).

Zuletzt überprüft: 17. Mai 2026

Warum DORA den Pentest zur regulatorischen Pflicht macht

DORA ist kein Leitfaden, sondern unmittelbar anwendbares EU-Recht. Anders als die frühere EBA-Leitlinie zu IKT-Risiken (EBA/GL/2019/04) hat DORA bindende Kraft: BaFin und EZB können bei Verstößen Bußgelder bis zu 1 % des globalen Tagesumsatzes verhängen und die Geschäftsleitung persönlich belangen. Art. 24 Abs. 1 DORA verlangt, dass Finanzunternehmen ihre IKT-Systeme, -Anwendungen und -Infrastrukturen durch ein 'Programm für die Prüfung der digitalen operationalen Resilienz' regelmäßig auf Schwachstellen prüfen. Art. 24 Abs. 2 listet explizit 'Penetrationstests, einschließlich auf Bedrohungen ausgerichteter Penetrationstests' auf. Die BaFin hat in ihrem DORA-Merkblatt (Januar 2025) klargestellt, dass ein einfacher Schwachstellenscan (Vulnerability Scan) diese Anforderung nicht erfüllt — es bedarf eines vollständigen Penetrationstests mit dokumentiertem Scope, Methodik und Proof-of-Exploit. Für bedeutende und systemrelevante Institute (gem. Art. 26 DORA) kommt zusätzlich der TLPT-Standard (Threat-Led Penetration Testing nach TIBER-EU-Rahmenwerk) zum Tragen, der nur von EZB-akkreditierten Red-Team-Anbietern durchgeführt werden darf.

DORA Art. 24 Abs. 1 und 2: Pflicht zu regelmäßigen IKT-Sicherheitstests inkl. Penetrationstests für alle Finanzunternehmen nach Art. 2 DORA — Banken, Versicherer, Zahlungsdienstleister, Wertpapierfirmen, Krypto-Assetdienstleister, Ratingagenturen, Datenbereitstellungsdienste.
DORA Art. 26 Abs. 1: TLPT-Pflicht für systemrelevante Institute — mindestens alle drei Jahre vollständiger Threat-Led Penetration Test durch akkreditierten Anbieter, koordiniert mit der zuständigen Behörde (BaFin / EZB).
DORA Art. 24 Abs. 7 und 8: Tests müssen durch unabhängige Parteien durchgeführt werden (intern oder extern); bei kritischen IKT-Dienstleistungen durch externe Tester; vollständige Dokumentation inkl. 'Abschlussbericht mit Angabe der durchgeführten Tests, der verwendeten Methoden und der festgestellten Schwachstellen'.
DORA RTS (Delegierte Verordnung (EU) 2024/1774): Technische Regulierungsstandards präzisieren die Anforderungen an IKT-Sicherheitstests — Mindestabdeckung, Frequenz, Berichtspflichten.
BaFin-Merkblatt DORA (Januar 2025): Vulnerability Scans ersetzen keinen Penetrationstest; Auditor muss dokumentierten Nachweis über Scope, Tester-Qualifikation (OSCP/CREST oder gleichwertig) und Ergebnis-Handling verlangen können.
Persönliche Haftung der Geschäftsleitung (Art. 5 DORA): Vorstand und Aufsichtsrat sind direkt verantwortlich für die IKT-Resilienz — ein fehlender Pentest-Nachweis ist ein direktes Governance-Risiko.
Cross-Border-Koordination (Art. 26 Abs. 8 DORA): Bei grenzüberschreitend tätigen Instituten koordiniert die EZB gemeinsame TLPT-Tests — die TIBER-EU-Richtlinie definiert das Rahmenwerk.

Was ein DORA-konformer Penetrationstest abdecken muss

IKT-Systeme der Kernfunktionen (Art. 24 Abs. 3 DORA): Banking-Systeme, Zahlungsverkehrs-APIs, Trading-Plattformen, Kundendaten-Repositories — vollständige Asset-Inventarisierung als Voraussetzung.
Authentifizierungs- und Zugangssteuerung: MFA-Implementierungen (PSD2 SCA-Anforderungen), OAuth2/OIDC-Flows, Privileged-Access-Management (PAM), Service-Account-Berechtigungen.
API-Sicherheit nach OWASP API Top 10 (2023): API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Property Level Authorization — besonders kritisch bei Open-Banking-APIs (PSD2, Berlin Group NextGenPSD2).
Netzwerksegmentierung und Firewall-Konfiguration: Separation der IKT-Umgebungen (Produktion / Staging / Entwicklung), laterale Bewegung zwischen Segmenten, SWIFT-Netzwerk-Isolation (SWIFT CSP CSCF v2024).
Verschlüsselung ruhender und übertragener Daten: TLS 1.3 (RFC 8446), HSM-Integration für Schlüsselmaterial, veralte Cipher-Suites (kein RC4, 3DES, MD5), CVE-2023-0215 (OpenSSL) und CVE-2022-0778 (OpenSSL infinite loop) als Referenzpunkte.
Drittanbieter-IKT-Abhängigkeiten (Art. 28 DORA): SaaS-Komponenten, Cloud-Infrastruktur-Provider, Zahlungsabwickler — Supply-Chain-Risiken, bekannte CVEs in Drittanbieter-Bibliotheken.
Business Continuity & Disaster Recovery: Test ob Angreifer Backup-Prozesse kompromittieren können; Ransomware-Simulation gegen Backup-Systeme; Wiederherstellungszeit-Verifikation.
Social Engineering und Phishing-Simulationen (für umfangreichere TLPT-Engagements): Mitarbeiter-Awareness, technische Phishing-Erkennungs-Controls, Reaktionszeit des Incident-Response-Teams.
Cloud-Infrastruktur (Art. 28 DORA Drittparteienrisiken): IAM-Fehlkonfigurationen in AWS/Azure/GCP, S3-Bucket-Berechtigungen, exponierte Storage-Accounts, unsichere Serverless-Funktionen.
Logging und Monitoring (Art. 10 DORA): Verifikation dass Angriffs-Aktivitäten in SIEM/SOAR detektiert werden — 'detect what we do'-Prinzip als DORA-Nachweis.

Beispiel-Befund

Kritisch

Unsicherer OAuth2-Flow im Open-Banking-API-Gateway (FAPI-Verstoß)

Das Open-Banking-API-Gateway implementiert OAuth2 Authorization Code Flow ohne PKCE (Proof Key for Code Exchange, RFC 7636). Ein Man-in-the-Middle-Angreifer kann den Authorization Code aus einer Browser-Redirect-URL abfangen und ohne Besitz des Code-Verifiers gegen ein Access-Token eintauschen. Zusätzlich akzeptiert der Token-Endpoint den 'state'-Parameter nicht, was Cross-Site-Request-Forgery bei der OAuth-Initiierung ermöglicht. Das Gateway verarbeitet täglich >50.000 PSD2-Transaktionen; ein kompromittiertes Token ermöglicht vollständigen Lesezugriff auf Kontodaten und initiierten Zahlungsverkehr.

Behebung: Implementierung von PKCE (RFC 7636) als Pflichtanforderung für alle OAuth2-Flows (auch serverseitig, als Defense-in-Depth). Validierung des 'state'-Parameters bei jeder Autorisierungsanfrage. Migration zu Financial-grade API Security Profile (FAPI 2.0, OpenID Foundation) als Best Practice für Open-Banking. Token-Rotation nach jedem Gebrauch, kurze Access-Token-Laufzeit (max. 5 Minuten), Refresh-Token nur mit Rotation. Penetrationstest-Protokoll gemäß DORA Art. 24 Abs. 7 dokumentieren.

Referenz: CVE-2022-21449 (ECDSA Psychic Signatures, Java) · OWASP API2:2023 Broken Authentication · RFC 7636 PKCE · DORA Art. 24 Abs. 2 · PSD2 RTS on SCA (EU) 2018/389 Art. 9

DORA-Pentest: Optionen im Vergleich

—	Kostenloser Scan	Matproof Sentinel	Klassische Beratung
Automatisierte Scan-Engine	✓ (3-min Vorschau)	✓ Vollständiger Scan	✗ Nur manuell
OWASP Top 10 Abdeckung	Partiell	✓ Vollständig	✓ Vollständig
Proof-of-Exploit-Evidenz	✗	✓ Pro Befund	✓ Pro Befund
Regulatorisches Mapping (DORA/NIS2/ISO 27001)	✗	✓ Automatisiert	✓ Manuell
Audit-tauglicher PDF-Bericht	✗	✓ Sofort	✓ 2–4 Wochen Lieferzeit
Kontinuierliche / wiederkehrende Scans	✗	✓ Pro Deploy	✗ Jährliches Engagement
Zeit bis zum ersten Ergebnis	~3 Min.	~30 Min. Vollscan	2–4 Wochen
Preis	€0	Ab €149	€8.000–€25.000
Quellcode-Review (SAST)	✗	✓ Im Growth-Plan	✓ Im Scope
API-Testing (REST/GraphQL)	✗	✓ Automatisiert	✓ Manuell

DORA-konforme Pentest-Pakete

Einzel-Scan

€149 einmalig

1 vollständiger Pentest-Scan
KI-priorisierte Befunde mit CVSS 3.1
Proof-of-Exploit für jedes Finding
PDF-Bericht (audit-tauglich)
Regulatorisches Mapping (DORA, NIS2, BSI)

Einzel-Scan kaufen →

Häufige Fragen zum DORA Penetrationstest

Wer ist von DORA Art. 24 Penetrationstest-Pflicht betroffen?

Art. 2 DORA definiert den Anwendungsbereich: Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, Versicherungsunternehmen, Ratingagenturen, Transaktionsregister, Handelsplätze, Krypto-Assetdienstleister (nach MiCA), Datenbereitstellungsdienste und kritische IKT-Drittdienstleister. Nicht explizit ausgenommen sind auch Software-Anbieter, die als 'kritische IKT-Drittdienstleister' eingestuft werden können. Kleine und mittlere Unternehmen (Art. 3 DORA) unterliegen vereinfachten Anforderungen, aber auch hier gilt der Grundsatz regelmäßiger technischer Tests.

Was ist der Unterschied zwischen dem DORA Art. 24 Pentest und dem TLPT nach Art. 26?

Art. 24 schreibt allgemeine Penetrationstests für alle betroffenen Finanzunternehmen vor — Frequenz, Scope und Tiefe sind risikobasiert, aber es muss ein dokumentierter Pentest-Bericht vorliegen. Art. 26 TLPT (Threat-Led Penetration Testing) ist eine weitergehende Anforderung nur für 'bedeutende' Institute (systemrelevante Banken, bedeutende Versicherer): Mindestens alle drei Jahre ein vollständiger Red-Team-Test, bei dem ein akkreditierter Anbieter die Methodik aus echter Threat Intelligence ableitet und unangekündigt angreift. TLPT kostet typischerweise €80.000–€250.000; ein Standard-DORA-Pentest ist mit einer KI-Pentest-Plattform wie Matproof Sentinel oder einem Boutique-Anbieter (€8.000–€25.000) erfüllbar.

Wie oft muss ein DORA-Pentest durchgeführt werden?

DORA selbst nennt keine feste Frequenz — Art. 24 Abs. 1 spricht von 'regelmäßig'. Die BaFin-Auslegung und die EBA-Richtlinien gehen typischerweise von mindestens jährlichen Tests für kritische Systeme und nach wesentlichen Änderungen aus. Art. 26 TLPT schreibt für betroffene Institute explizit mindestens alle drei Jahre vor. Empfehlung: jährlicher vollständiger Pentest + kontinuierliches Scanning (z.B. via Matproof Sentinel) nach jedem Major-Release.

Was muss der DORA-Pentest-Bericht enthalten?

Art. 24 Abs. 7 DORA verlangt: dokumentierten Scope (welche Systeme wurden getestet), verwendete Methodik, festgestellte Schwachstellen mit Schweregrad, Behebungsempfehlungen und Status (behoben / in Behebung / akzeptiert). Die BaFin empfiehlt zusätzlich: Tester-Qualifikation (OSCP/CREST oder gleichwertig), verwendetes Test-Framework (PTES, OWASP Testing Guide), Proof-of-Exploit für kritische und hohe Befunde. Matproof Sentinel liefert alle diese Elemente im PDF-Bericht.

Kann Matproof Sentinel den DORA Art. 26 TLPT-Test ersetzen?

Nein — DORA Art. 26 TLPT erfordert für systemrelevante Institute einen EZB-akkreditierten Red-Team-Anbieter. Matproof Sentinel ist eine KI-gestützte Pentest-Plattform und eignet sich hervorragend für den regulären DORA Art. 24-Pentest, die Vorbereitung auf TLPT (Gap-Analyse, Schwachstellen-Baseline) und kontinuierliche Sicherheitstests zwischen TLPT-Zyklen. Für TLPT vermitteln wir gerne an akkreditierte Partner.

Was passiert, wenn ein Finanzunternehmen keinen DORA-Pentest nachweisen kann?

BaFin und EZB können bei Verstößen gegen DORA-Anforderungen Geldbußen bis zu 1 % des globalen Tagesumsatzes verhängen (Art. 50 DORA). Bei wiederholten oder schwerwiegenden Verstößen ist auch die Aussetzung der Geschäftstätigkeit möglich. Darüber hinaus haftet die Geschäftsleitung persönlich (Art. 5 DORA). In der Praxis werden fehlende Pentest-Nachweise bei aufsichtlichen Prüfungen (Jahresabschlussprüfung, Sonderprüfungen) als wesentlicher Mangel eingestuft, der Nachbesserungs- und Nachweispflichten auslöst.

Müssen IKT-Drittdienstleister (Cloud, SaaS) ebenfalls DORA-Pentests durchführen?

Direkt: Ja, wenn sie als 'kritische IKT-Drittdienstleister' nach Art. 31 DORA eingestuft werden (Einstufung durch EBA/ESMA/EIOPA). Diese unterliegen dann direkt der DORA-Aufsicht. Indirekt: Alle anderen IKT-Drittdienstleister müssen über Vertragsklauseln (Art. 30 DORA) Mindest-Sicherheitsanforderungen erfüllen, die Penetrationstests einschließen können. Das Finanzunternehmen muss nach Art. 28 DORA sicherstellen, dass seine kritischen Drittdienstleister angemessene Sicherheitstests durchführen.

Wie hängen DORA und NIS2 zusammen — welches Gesetz gilt für wen?

DORA ist ein sektorielles Spezialgesetz für Finanzunternehmen und hat als lex specialis Vorrang vor NIS2, soweit Finanzunternehmen betroffen sind. NIS2 gilt allgemein für essenzielle und wichtige Einrichtungen in kritischen Sektoren (Art. 3 NIS2-RL), aber Art. 4 NIS2-RL stellt klar, dass branchenspezifisches EU-Recht (wie DORA) vorgeht. Unternehmen, die sowohl unter DORA als auch unter NIS2 fallen würden, müssen nur DORA erfüllen — der Regulator geht davon aus, dass DORA-Compliance NIS2 vollständig abdeckt.

Vertiefen — verwandte Artikel aus unserem Blog

DORA-konformen Pentest jetzt starten

Erhalten Sie in 3 Minuten eine erste Einschätzung Ihrer IKT-Sicherheitslage — ohne Login, ohne Vertrag. Der vollständige Matproof Sentinel Pentest liefert einen audit-bereiten Bericht, der die Anforderungen von DORA Art. 24 Abs. 7 erfüllt. Für TLPT nach Art. 26 vermitteln wir akkreditierte Partner.