DORA-Pentest-Anforderungen: Was BaFin und das BSI 2026 fordern

Was DORA für IKT-Tests vorschreibt

Die Digital Operational Resilience Act (Verordnung (EU) 2022/2554) bindet alle in der EU regulierten Finanzunternehmen sowie ihre kritischen IKT-Drittanbieter. Pentests sind in zwei Säulen geregelt:

• Artikel 24 — Standard-IKT-Sicherheitstests. Mindestens jährlich. Gilt für alle DORA-Adressaten. Methodisches Spektrum: Schwachstellenscans, Netzwerksicherheitsanalysen, Open-Source-Tests, Penetrationstests, szenariobasierte Tests, Quellcode-Reviews. Anforderung: dokumentierte Mängelbehebung im Verhältnis zum Risiko.
• Artikel 26–27 — TLPT (Threat-Led Penetration Testing). Alle drei Jahre. Gilt nur für signifikante Finanzunternehmen (die EZB-/EBA-Kriterien greifen hier). Anmeldepflicht bei der zuständigen Behörde, Test-Manager-Vorgabe, Closed-Box-Methodik, strenge Vertraulichkeit. Praktisch: TIBER-EU-Framework als Referenz.

Wichtige Klarstellung: SQUR adressiert Artikel 24, nicht TLPT. Wer unter Artikel 26 fällt, braucht einen akkreditierten TLPT-Anbieter und eine eigene Test-Manager-Organisation. Die nachfolgende Diskussion bezieht sich auf den 95-%-Fall: das jährliche Artikel-24-Mandat.

BaFin-Aufsichtspraxis 2025/2026 — was tatsächlich gefordert wird

Die Bundesanstalt für Finanzdienstleistungsaufsicht hat 2025 ihre IKT-Aufsicht erheblich ausgebaut. Drei Muster sind erkennbar:

1. „Angemessen und verhältnismäßig" wird konkret operationalisiert

DORA Artikel 24 verlangt Tests „im Verhältnis zum Risikoprofil." BaFin liest das im Lichte der MaRisk-Tradition: Risikoprofil ergibt sich aus IKT-Komplexität, kritischen Funktionen, Datenklassifikation und Bedrohungslage. Wer ein nicht-triviales Online-Banking-Frontend, eine API für Drittanbieter oder ein Kunden-Self-Service-Portal betreibt, bekommt im Audit-Gespräch sehr konkrete Erwartungen genannt — und sie sind höher als ein generischer Schwachstellenscan einmal im Jahr.

2. Nachweis der Mängelbehebung — nicht nur der Identifizierung

Die zweite Aufsichts-Verschärfung betrifft das, was bisher oft als „Findings sind dokumentiert" durchging. BaFin verlangt zunehmend die geschlossene Beweiskette: Identifizierung → Risikoeinschätzung → Mängelbehebungsplan → Behebung → Retest mit Bestätigung. Ohne Retest-Spalte im Bericht ist die Beweiskette unvollständig.

3. Dritt-Komponenten als eigenständige Risikoquelle

Artikel 28–30 (Risiko durch IKT-Drittanbieter) wird ernst genommen. Ein Pentest, der Drittkomponenten — externe SaaS-Integrationen, Open-Source-Bibliotheken mit bekannten CVEs, externe APIs — als Befunde sauber separiert und der jeweiligen Drittpartei zuordnet, hilft beim Lieferantenregister-Nachweis nach Artikel 28(3).

BSI-Bezug — IT-Grundschutz und C5

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) ist nicht direkt DORA-Aufsicht, aber zwei BSI-Referenzen tauchen in praktisch jedem deutschen DORA-Audit-Bericht auf:

• IT-Grundschutz-Bausteine OPS.1.1.6 und CON.10: Schwachstellenmanagement und Penetrationstests — sie liefern die operative Sprache, in der deutsche IT-Auditoren über Testkadenz, Umfang und Berichtsformat sprechen.
• BSI C5 (Cloud Computing Compliance Criteria Catalogue): Für Finanzunternehmen mit Cloud-Anteil (also: praktisch alle) ist C5 der De-facto-Standard für die Risikobewertung des Cloud-Anbieters. C5-Pentests von Cloud-Workloads werden im DORA-Audit als „angemessen" akzeptiert, wenn die C5-Anforderungen abgedeckt sind.

Wer fällt unter DORA?

• Kreditinstitute — alle Banken, einschließlich Sparkassen und Volksbanken.
• Zahlungsinstitute und E-Geld-Institute.
• Wertpapierfirmen und Investmentdienstleister.
• Versicherungs- und Rückversicherungsunternehmen.
• Krypto-Dienstleister unter MiCAR.
• Marktinfrastruktur-Betreiber (Handelsplätze, zentrale Gegenparteien).
• Kritische IKT-Drittanbieter — die EU-Kommission designiert „critical TPPs" jährlich; diese fallen direkt unter DORA-Aufsicht.

Ausnahmen: Versicherungsvermittler unter dem 5-Mitarbeiter-Schwellenwert sowie Einrichtungen der betrieblichen Altersvorsorge mit weniger als 15 Mitgliedern.

Was ein DORA-konformer Pentest-Bericht enthalten muss

Aus 16 Monaten Aufsichtspraxis ergibt sich folgende Mindestliste — alle Punkte werden in deutschen DORA-Audits aktiv geprüft:

1. Geltungsbereich — getestete Systeme, ausgeschlossene Komponenten, Testzeitraum, eingesetzte Werkzeuge und Methodik.
2. Risikoprofil-Begründung — warum dieser Umfang dem IKT-Risikoprofil entspricht (Bezug zu Artikel 6 IKT-Risikomanagement-Rahmen).
3. Befunde mit CVSS-Bewertung — pro Befund: Beschreibung, Reproduktionsschritte, Auswirkung, betroffenes Asset, Beweisartefakt (Screenshot, Request/Response).
4. Empfohlene Maßnahmen — pro Befund: konkrete Behebungsempfehlung, Aufwandsschätzung, abgeleitete kompensierende Kontrollen.
5. Mängelbehebungs-Tracking — Status (offen / in Behebung / behoben), Behebungs-Owner, geplantes Datum, tatsächliches Datum.
6. Retest-Belege — pro behobenem Befund: Bestätigung durch erneuten Test, Datum, Ergebnis.
7. Drittkomponenten-Befunde separiert — pro betroffener Drittpartei: Lieferanten-ID aus dem Lieferantenregister, Disclosure-Status.
8. Executive Summary — eine Seite, für die Geschäftsleitung. Schwerpunkt: Risiko-Trend gegenüber letztem Test.

Wie autonomes Pentesting DORA Artikel 24 entlastet

Klassisches Pentesting ist teuer, langsam und nicht skalierbar — was im Konflikt zur DORA-Anforderung nach jährlicher Wiederholung steht. Autonome Pentest-Plattformen wie SQUR adressieren das durch drei Eigenschaften:

• Festpreis, definierte Laufzeit. €1.995 pro Pentest, 24 Stunden bis zum Bericht. Damit passt der Pentest in das Jahresbudget jedes mittleren Finanzunternehmens — nicht nur in das Budget der DAX-Adressaten.
• Bericht im DORA-Format. Jeder Befund kommt mit CVSS, Beweisartefakt, betroffenem Asset und Behebungsempfehlung. Die NIS2-Artikel-21-Evidence-Package-Variante (für Mehrfach-Compliance-Adressaten) ist optional verfügbar.
• EU-Datenresidenz. SQUR-Tests laufen in GCP Brüssel. Test-Artefakte verlassen die EU nicht. Das ist nicht nur DORA-relevant, sondern auch BaFin-konform unter den ausländischen Cloud-Anbieter-Regelungen.

Häufige Fragen

Reicht ein Schwachstellenscan für DORA?

Nein — Artikel 24 verlangt explizit Penetrationstests zusätzlich zu Schwachstellenscans. Ein Schwachstellenscan identifiziert bekannte CVE-Einträge; ein Pentest demonstriert, ob die Schwachstelle in der konkreten Konfiguration tatsächlich ausnutzbar ist. BaFin liest „Penetrationstests" als eigenständige Anforderung neben „Schwachstellenanalysen".

Wie oft muss getestet werden?

Mindestens jährlich. Faktisch: nach jeder wesentlichen Änderung kritischer IKT-Systeme. „Wesentlich" wird im IKT-Risikomanagement-Rahmen (Artikel 6) definiert — typischerweise: neuer öffentlich zugänglicher Endpunkt, Architekturänderung, Drittanbieter-Wechsel.

Was passiert bei Verstößen?

DORA Artikel 50 sieht Verwaltungssanktionen vor: bis zu 10 Mio. EUR oder 5 % des weltweiten Jahresumsatzes — der höhere Wert. Die nationalen Aufsichtsbehörden setzen das um; BaFin hat 2026 erstmals zweistellige Millionenstrafen für DORA-Verstöße angekündigt.

Wie unterscheidet sich DORA von NIS2?

DORA gilt für Finanzunternehmen, NIS2 für „wesentliche" und „wichtige" Einrichtungen quer durch alle Branchen (Energie, Verkehr, Gesundheit, digitale Anbieter). Ein Finanzunternehmen kann unter beiden Regimes fallen — DORA ist dann die spezielle Vorschrift (lex specialis), NIS2 die Generalklausel. Der SQUR-NIS2-Artikel-21-Evidence-Package konvertiert einen Pentest-Bericht in beide Formate.