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.
DORA erfasst 21 Unternehmenskategorien, die sich in sechs Gruppen gliedern (Art. 2 Abs. 1):
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).
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).
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.
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).
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).
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).
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.
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).
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.
| DORA-Pflicht | OTTRIA-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 |
Zusammen ergibt das ein prüffähiges Nachweispaket, das Ihre Aufsichtsbehörde erwartet.
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-Unternehmen sind von der deutschen NIS2-Umsetzung (NIS2UmsuCG) ausgenommen (Paragraph 28 Abs. 6 NIS2UmsuCG). DORA geht als sektorspezifische Regulierung vor.
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.
DORA-Factsheet herunterladen (PDF)
Weiterlesen