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" als Pflichttest.

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 - und eine D&O-Versicherung deckt Gesetzesverstöße typischerweise nicht ab.

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 internationale Normen berücksichtigt (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 bedeutet das: eine vollständige, aktuelle SBOM.

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).

Pflicht zu Open-Source-Analysen und Quellcodeprüfungen #

Art. 25 Abs. 1 nennt ausdrücklich als Testmethoden: Open-Source-Analysen, Quellcodeprüfungen (soweit durchführbar), Schwachstellenbewertungen und -scans sowie Penetrationstests. Alle kritischen Systeme müssen mindestens jährlich getestet werden (Art. 24 Abs. 6). Vor dem Einsatz und Wiedereinsatz von Komponenten ist eine Schwachstellenbewertung durchzuführen (Art. 25 Abs. 2). Alle drei Jahre sind bedrohungsorientierte Penetrationstests (TLPT) vorgeschrieben, die auch IKT-Drittdienstleister einbeziehen (Art. 26).

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 alle IKT-Drittdienstleister 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 #

Für Finanzunternehmen sieht DORA keine konkreten Prozentsätze vor -die Ausgestaltung obliegt den Mitgliedstaaten (Art. 50 Abs. 3-4). Art. 50 erlaubt ausdrücklich "jede Art von Maßnahme, auch finanzieller Art". Für kritische IKT-Drittdienstleister gilt: 1 % des weltweiten Tagesumsatzes als Zwangsgeld, täglich, für bis zu sechs Monate (Art. 35 Abs. 8).

Öffentliche Sichtbarkeit #

Alle Sanktionsentscheidungen werden auf den Websites der Aufsichtsbehörden veröffentlicht -bis zu fünf Jahre lang (Art. 54 Abs. 1-2, Abs. 6). Zwangsgelder gegen IKT-Drittdienstleister werden ebenfalls veröffentlicht (Art. 35 Abs. 10). 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
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 #

DORA-Unternehmen sind von der deutschen NIS2-Umsetzung (NIS2UmsuCG) ausgenommen (Paragraph 28 Abs. 6 NIS2UmsuCG). DORA geht als sektorspezifische Regulierung vor.

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