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.
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: Bei Verstößen kann die BaFin Sanktionen und Abhilfemaßnahmen nach Art. 50 DORA und deutschem Recht verhängen und die Geschäftsleitung in die Pflicht nehmen. Art. 24 Abs. 1 DORA verlangt ein solides und umfassendes Programm für Tests der digitalen operationalen Resilienz. Art. 25 nennt die Testarten, darunter Schwachstellenscans und Penetrationstests. Art. 24 Abs. 6 verlangt mindestens jährlich angemessene Tests aller IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen. Für ausgewählte Institute kommt nach Art. 26 DORA zusätzlich TLPT hinzu (Threat-Led Penetration Testing nach dem TIBER-EU-Rahmenwerk). Die Anforderungen an TLPT-Tester regelt Art. 27.
- DORA Art. 24 und 25: Pflicht zu einem Programm für IKT-Sicherheitstests, zu dem je nach Risiko auch Penetrationstests gehören, für 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. 4 und 5: Die Tests führen unabhängige Parteien durch, intern oder extern. Interne Tester brauchen ausreichende Ressourcen und dürfen keinen Interessenkonflikt haben. Das Unternehmen braucht Verfahren, um alle gefundenen Probleme zu priorisieren, zu klassifizieren und zu beheben, und prüft intern, dass alle Schwachstellen vollständig behoben sind.
- 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. 6 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
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. Behebung gemäß DORA Art. 24 Abs. 5 dokumentieren und intern validieren.
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 | ✗ | ✓ Bestätigte Befunde (Request/Response) | ✓ 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
- 1 vollständiger Pentest-Scan
- KI-priorisierte Befunde mit CVSS 3.1
- Erneut geprüfte Findings mit Request/Response-Nachweis
- PDF-Bericht (audit-tauglich)
- Regulatorisches Mapping (DORA, NIS2, BSI)
- 3 vollständige Sentinel-Pentests pro Monat
- Kontinuierliches Monitoring
- CI/CD-Integration (GitHub, GitLab)
- Alle Regulierungs-Mappings
- Prioritäts-Support
- 10 Sentinel-Pentests pro Monat
- Weitere Scans für je €149
- Alle 10 Agenten, inkl. Cloud (Prowler) und Mobile (MobSF)
- Laufende Zeitpläne: stündlich, täglich oder wöchentlich
- Authentifizierte Scans (Session-Cookies, Bearer-Token)
- Webhook-Zustellung und Prioritäts-Support
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; einen Standard-DORA-Pentest übernimmt oft ein spezialisierter Anbieter (€8.000–€25.000); eine KI-Pentest-Plattform wie Matproof Sentinel unterstützt das Testprogramm zwischen diesen Pentests.
Wie oft muss ein DORA-Pentest durchgeführt werden?
Art. 24 Abs. 6 DORA verlangt mindestens jährlich angemessene Tests aller IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen. Nach wesentlichen Änderungen ist ein neuer Test üblich. TLPT nach Art. 26 gilt nur für ausgewählte Institute, in der Regel mindestens alle drei Jahre. 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. 5 DORA verlangt Verfahren, um alle gefundenen Probleme zu priorisieren, zu klassifizieren und zu beheben, und eine interne Prüfung, dass alle Schwachstellen vollständig behoben sind. Ein Pentest-Bericht unterstützt das in der Praxis mit diesen Angaben: Scope (welche Systeme getestet wurden), Methodik, Schwachstellen mit Schweregrad, Behebungsempfehlungen und Status (behoben / in Behebung / akzeptiert). Prüfer fragen oft auch nach der Qualifikation des Testers und dem Test-Framework (PTES, OWASP Testing Guide). Der Matproof-Sentinel-Bericht (PDF) enthält Scope, Methodik, Schwachstellen mit Schweregrad, Behebungsempfehlungen und Status. Jedes Finding wird erneut geprüft. Bestätigte Findings enthalten Request und Response als Nachweis. Nicht bestätigte Findings werden markiert.
Kann Matproof Sentinel den DORA Art. 26 TLPT-Test ersetzen?
Nein. TLPT nach DORA Art. 26 führen spezialisierte Red-Team-Tester durch, die die Anforderungen von Art. 27 erfüllen. Matproof Sentinel ist eine KI-gestützte Pentest-Plattform. Sie unterstützt Ihr Testprogramm nach Art. 24 und 25, die Vorbereitung auf TLPT (Gap-Analyse, Schwachstellen-Baseline) und kontinuierliche Sicherheitstests zwischen TLPT-Zyklen. Für TLPT selbst brauchen Sie einen spezialisierten Anbieter.
Was passiert, wenn ein Finanzunternehmen keinen DORA-Pentest nachweisen kann?
DORA selbst legt für Finanzunternehmen keine Bußgeldhöhe fest. Art. 50 DORA verpflichtet die Mitgliedstaaten, Verwaltungssanktionen und Abhilfemaßnahmen im nationalen Recht zu regeln. In Deutschland verhängt die BaFin diese Maßnahmen. Die Grenze von 1 % des durchschnittlichen weltweiten Tagesumsatzes in Art. 35 DORA gilt nur für kritische IKT-Drittdienstleister, als Zwangsgeld der federführenden Überwachungsbehörde. 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 Pentest-Nachweise für Ihr Audit und unterstützt Ihr Programm für Tests der digitalen operationalen Resilienz nach DORA Art. 24-25. Er ist kein TLPT. Für TLPT nach Art. 26 brauchen Sie einen spezialisierten Red-Team-Anbieter, der die Anforderungen von Art. 27 erfüllt.
DORA-Pentest starten