deenx-default

DORA: Digitale Betriebsstabilität im Finanzsektor

Seit dem 17. Januar 2025 gilt die EU-Verordnung 2022/2554 - der Digital Operational Resilience Act. DORA verpflichtet Finanzunternehmen, ihre gesamte IKT-Landschaft gegen Cyberrisiken abzusichern. Das schließt Open-Source-Komponenten ausdrücklich ein: Art. 25 Abs. 1 DORA nennt "Open-Source-Analysen" ausdrücklich als Testmethode.

Für Vorstände und Geschäftsführungen bedeutet das: Sie tragen die persönliche Letztverantwortung für das IKT-Risikomanagement (Art. 5 Abs. 2a). Diese Verantwortung lässt sich nicht delegieren - DORA verpflichtet Sie sogar ausdrücklich, sich fortzubilden, die Risiken zu verstehen und die Maßnahmen zu überwachen. Wer bekannte Sicherheitspflichten bewusst übergeht, riskiert neben persönlicher Haftung auch seinen D&O-Versicherungsschutz. OTTRIA sichert Ihre Open-Source-Abhängigkeiten ab und dokumentiert jede Maßnahme so, dass Sie Ihre Sorgfalt gegenüber Aufsicht, Prüfern und Versicherern belegen können.

Wer ist betroffen? #

DORA erfasst 21 Unternehmenskategorien, die sich in sechs Gruppen gliedern (Art. 2 Abs. 1):

Banken und Zahlungsverkehr #

Kapitalmärkte und Wertpapierhandel #

Fonds und Vermögensverwaltung #

Versicherung und Altersvorsorge #

Finanz-Infrastruktur und Spezialanbieter #

IKT-Drittdienstleister -indirekt betroffen #

Alle IT-, Software-, Cloud- und Open-Source-Zulieferer (lit. u). Wenn Sie Software oder Infrastruktur für Finanzunternehmen bereitstellen, betreffen Sie die DORA-Anforderungen an die Lieferkette unmittelbar. Ihre Kunden aus dem Finanzsektor werden die Einhaltung von Sicherheitsstandards vertraglich einfordern -oder müssen (Art. 28 Abs. 5).

Was fordert DORA? #

IKT-Risikomanagement unter Vorstandsverantwortung #

Das Leitungsorgan trägt die letztendliche Verantwortung für das Management der IKT-Risiken (Art. 5 Abs. 2a). Es muss ausreichende Kenntnisse und Fähigkeiten aktiv auf dem neuesten Stand halten (Art. 5 Abs. 4) und einen umfassenden IKT-Risikomanagementrahmen einrichten (Art. 6 Abs. 1), der unter anderem Strategien, Leitlinien, Verfahren und Werkzeuge umfasst (Art. 6 Abs. 2).

Vollständiges IKT-Asset-Inventar #

Sie müssen ein Inventar aller IKT-Assets führen, einschließlich Konfiguration und Interdependenzen (Art. 8 Abs. 4). Das umfasst die Ermittlung aller Prozesse, die von IKT-Drittdienstleistern abhängen (Art. 8 Abs. 5), eine regelmäßige Aktualisierung bei jeder wesentlichen Änderung (Art. 8 Abs. 6) und die Bewertung von IKT-Altsystemen mindestens jährlich (Art. 8 Abs. 7). Für Open-Source-Abhängigkeiten heißt das in der Praxis: Ohne vollständige, aktuelle SBOM können Sie dieses Inventar nicht führen.

Schwachstellenmanagement #

DORA verlangt Mechanismen zur Ermittlung potenzieller wesentlicher Schwachstellen (Art. 10 Abs. 1), Kapazitäten und Personal für Schwachstellen-Intelligence (Art. 13 Abs. 1), dokumentierte Richtlinien für Patches und Updates (Art. 9 Abs. 4f) und Kommunikationspläne für die verantwortungsbewusste Offenlegung von Schwachstellen (Art. 14 Abs. 1).

Verbindliches Sicherheitstestprogramm einschließlich Open-Source-Sicherheit #

DORA verpflichtet Sie zu einem angemessenen Sicherheitstestprogramm. Art. 25 Abs. 1 benennt dafür ausdrücklich Open-Source-Analysen, Quellcodeprüfungen (soweit durchführbar), Schwachstellenbewertungen und -scans sowie Penetrationstests. In welcher Tiefe Sie diese Methoden einsetzen, richtet sich nach Größe, Geschäftstätigkeit und Risikoprofil Ihres Hauses.

Dafür gibt es einen festen Takt: Jedes Finanzunternehmen außer Kleinstunternehmen muss alle IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, mindestens einmal jährlich angemessen testen (Art. 24 Abs. 6). Wählt die Aufsicht Ihr Haus für bedrohungsorientierte Penetrationstests (TLPT) aus, kommen diese mindestens alle drei Jahre hinzu - und beziehen Ihre IKT-Drittdienstleister mit ein (Art. 26).

Zentralverwahrer und zentrale Gegenparteien prüfen zusätzlich jede Anwendung, Infrastrukturkomponente und IKT-Dienstleistung für kritische oder wichtige Funktionen vor jedem Einsatz und Wiedereinsatz auf Schwachstellen (Art. 25 Abs. 2).

Für Ihre Open-Source-Komponenten heißt das: Der jährliche Test muss sie erfassen, und das Ergebnis muss prüffähig dokumentiert sein. Diesen Teil übernimmt OTTRIA für Sie.

Management der IKT-Drittparteienrisiken #

Finanzunternehmen bleiben jederzeit voll verantwortlich für die Einhaltung der IKT-Anforderungen -auch wenn sie Funktionen an Dritte auslagern (Art. 28 Abs. 1). Das Leitungsorgan muss die Strategie für IKT-Drittparteienrisiken regelmäßig überprüfen (Art. 28 Abs. 2). Ein Informationsregister über alle IKT-Drittvereinbarungen ist zu führen (Art. 28 Abs. 3). Vor Vertragsschluss mit IKT-Drittdienstleistern gilt eine Due-Diligence-Pflicht (Art. 28 Abs. 4). Bei kritischen Funktionen werden höchste Qualitätsstandards verlangt (Art. 28 Abs. 5). Für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, müssen Ausstiegsstrategien vorliegen (Art. 28 Abs. 8).

Meldepflichten #

Bei schwerwiegenden IKT-Vorfällen gilt: Erstmeldung innerhalb von 4 Stunden (Art. 19 Abs. 4a) und Zwischenmeldung innerhalb von 72 Stunden (Art. 19 Abs. 4b). Diese Fristen gelten auch am Wochenende und an Feiertagen.

Konsequenzen bei Verstößen #

Persönliche Geschäftsführerhaftung #

Bußgelder #

DORA-Verstöße können Ihr Institut Millionen kosten. In Deutschland drohen Banken für bestimmte Verstöße Bußgelder bis zu 5 Millionen Euro — etwa bei fehlenden, fehlerhaften oder verspäteten Vorfallmeldungen oder vorgeschriebenen bedrohungsorientierten Penetrationstests (TLPT). Weitere ausdrücklich erfasste Verstöße können mit bis zu 500.000 Euro geahndet werden (§ 56 Abs. 5e und 6 KWG). Hinzu kommen aufsichtsrechtliche Maßnahmen zur Beseitigung der Mängel (Art. 50 Abs. 2-4 DORA). Für andere Finanzunternehmen richten sich die Bußgeldrahmen nach dem jeweiligen nationalen Aufsichtsgesetz.

Öffentliche Sichtbarkeit #

Nicht mehr anfechtbare Sanktionsentscheidungen werden grundsätzlich auf den Websites der Aufsichtsbehörden veröffentlicht - nur so lange wie erforderlich, höchstens fünf Jahre lang (Art. 54 Abs. 1-2, Abs. 6). Eine anonymisierte oder aufgeschobene Bekanntmachung ist nur ausnahmsweise vorgesehen - planen Sie nicht damit. Hinzu kommt die inhärent öffentliche Natur von Open Source: CVEs, Issues, Commits und offene Bugs sind für jeden einsehbar -für Auditoren ebenso wie für Angreifer.

Weitere Konsequenzen #

Was OTTRIA übernimmt #

DORA-PflichtOTTRIA-Leistung
IKT-Asset-Inventar (Art. 8 Abs. 4-7)SBOM-Auswertung und laufende Überwachung aller Open-Source-Abhängigkeiten
Schwachstellenerkennung (Art. 10 Abs. 1)CVE-Scanning und Silent-Fix-Detection für alle SBOM-Komponenten
Schwachstellen-Intelligence (Art. 13 Abs. 1)Laufende Überwachung, Frühwarnungen durch Steward-Einbindung
Jährliche Tests kritischer Systeme (Art. 24 Abs. 6)Prüffähige Testnachweise für alle Open-Source-Komponenten
Open-Source-Analysen (Art. 25 Abs. 1)Systematische Analyse aller OSS-Abhängigkeiten, Quellcodeprüfungen
Schwachstellenbewertung vor Einsatz (Art. 25 Abs. 2)Risikobewertung pro Komponente vor Integration
Patch-Management (Art. 9 Abs. 4f)Upstream-Fixes koordinieren oder selbst erstellen, auch in verwaisten Projekten
Verantwortungsbewusste Offenlegung (Art. 14 Abs. 1)Disclosure-Management als Teil der Steward-Rolle
Due Diligence bei Drittdienstleistern (Art. 28 Abs. 4)Dokumentierte Bewertung der OSS-Projekte als "Lieferanten"
Ausstiegsstrategien (Art. 28 Abs. 8)Bewertung von Alternativprojekten, Forks, Mirrors

Was OTTRIA nicht übernimmt #

Was legen Sie dem Prüfer vor? #

OTTRIA liefert Ihnen #

Sie ergänzen #

Zusammen ergibt das ein prüffähiges Nachweispaket, das Ihre Aufsichtsbehörde erwartet.

Umsetzung in Deutschland #

BaFin als Aufsichtsbehörde #

In Deutschland überwacht die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) die Einhaltung von DORA. Die BaFin baut auf bestehender Regulierung auf: MaRisk (Mindestanforderungen an das Risikomanagement) und BAIT (Bankaufsichtliche Anforderungen an die IT) werden durch DORA nicht ersetzt, sondern ergänzt. Unternehmen, die MaRisk und BAIT bereits umsetzen, haben eine Grundlage -müssen aber die DORA-spezifischen Anforderungen zusätzlich erfüllen, insbesondere bei Open-Source-Analysen (Art. 25 Abs. 1) und dem Management von IKT-Drittparteienrisiken (Art. 28).

DORA und NIS2 #

Für die in Paragraph 28 Abs. 6 BSIG genannten Finanzunternehmen geht DORA bei bestimmten Pflichten vor: Ausgenommen sind §§ 30, 31, 32, 35, 36, 38 und 39 BSIG - nicht das gesamte Gesetz. Behandeln Sie DORA und BSIG deshalb als ein Programm. Wer seine DORA-Pflichten sauber erfüllt, deckt den ausgenommenen Teil ab; alles Übrige bleibt eine eigenständige BSIG-Pflicht, die Sie nachweisen müssen.

Nationale Durchführung #

Da DORA eine EU-Verordnung ist, gilt sie direkt in allen Mitgliedstaaten. Die nationale Ausgestaltung betrifft vor allem die Sanktionsregime (Art. 50 Abs. 3-4) und die konkrete Aufsichtspraxis. In anderen EU-Ländern können abweichende Aufsichtsstrukturen und Sanktionshöhen gelten.

Sie möchten wissen, wie Ihre Open-Source-Abhängigkeiten unter DORA stehen? Fordern Sie eine kostenlose DORA-Erstanalyse Ihrer SBOM an.

Termin vereinbaren

Kostenloser Info-Abend zu DORA in Ihrer Region

DORA-Factsheet herunterladen (PDF)

Weiterlesen