DORA - Relevante Artikel

Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die digitale operationale Resilienz im Finanzsektor (Digital Operational Resilience Act - DORA). Die Verordnung ist in allen EU-Mitgliedstaaten unmittelbar und direkt anwendbar. Nachfolgend sind nur diejenigen Artikel im originalen deutschen Wortlaut wiedergegeben, die für die Bewertung von Open-Source-Software-Risiken im Finanzsektor besonders relevant sind.

Die Auswahl konzentriert sich auf die Artikel, die das IKT-Risikomanagement, die Identifizierung von Abhängigkeiten, die Testpflichten (einschließlich der explizit geforderten Open-Source-Analysen in Art. 25 Abs. 1), das Management von IKT-Drittparteienrisiken sowie die Sanktionsregelungen betreffen. Jeder Abschnitt ist thematisch gegliedert und mit einer kurzen Einordnung versehen.

Governance und Organisation (Art. 5) #

Art. 5 legt die Verantwortung des Leitungsorgans für das gesamte IKT-Risikomanagement fest. Die Geschäftsleitung muss IKT-Risiken nicht nur delegieren, sondern selbst verstehen, genehmigen und überwachen. Das schließt ausdrücklich die Strategie für die digitale operationale Resilienz, Budgetmittel und die Überwachung von IKT-Drittdienstleistern ein.

Art. 5 Abs. 2 #

Art. 5 Abs. 4 #

IKT-Risikomanagementrahmen (Art. 6) #

Der IKT-Risikomanagementrahmen bildet die strukturelle Grundlage für alle weiteren DORA-Pflichten. Er muss Strategien, Verfahren und Tools umfassen, die alle IKT-Assets schützen, einschließlich Open-Source-Softwarekomponenten.

Art. 6 Abs. 2 #

Identifizierung (Art. 8) #

Art. 8 verpflichtet zur vollständigen Inventarisierung aller IKT-Assets und deren Abhängigkeiten. Für Open-Source-Komponenten bedeutet dies: Jede Abhängigkeit muss erfasst, ihre Konfiguration dokumentiert und ihre Verbindungen zu anderen Assets nachvollzogen werden. Regelmäßige Risikobewertungen, insbesondere für Altsysteme, sind Pflicht.

Art. 8 Abs. 4 #

Art. 8 Abs. 5 #

Art. 8 Abs. 6 #

Art. 8 Abs. 7 #

Schutz und Prävention (Art. 9) #

Art. 9 Abs. 4 fordert dokumentierte Richtlinien für das Änderungsmanagement und Patch-Management. Für Open-Source-Komponenten bedeutet das: Jede Aktualisierung einer Abhängigkeit muss kontrolliert erfasst, getestet und genehmigt werden. Dokumentierte Patch-Richtlinien sind ausdrücklich vorgeschrieben.

Art. 9 Abs. 4 #

Erkennung (Art. 10) #

Die Erkennungspflicht geht über reines CVE-Scanning hinaus: Finanzunternehmen müssen anomale Aktivitäten und wesentliche Schwachstellen umgehend erkennen. Die Erkennungsmechanismen müssen regelmäßig getestet werden, was den Bezug zu den Testpflichten in Art. 25 herstellt.

Art. 10 Abs. 1 #

Lernprozesse und Weiterentwicklung (Art. 13) #

Art. 13 fordert aktive Kapazitäten zur Sammlung und Bewertung von Schwachstelleninformationen. Für die Open-Source-Lieferkette heißt das: nicht nur scannen, sondern die Ergebnisse analysieren, Auswirkungen bewerten und daraus lernen. Die jährliche Berichtspflicht an das Leitungsorgan stellt sicher, dass Erkenntnisse auf Führungsebene ankommen.

Art. 13 Abs. 1 #

Art. 13 Abs. 5 #

Kommunikation (Art. 14) #

Die Kommunikationspflicht umfasst die verantwortungsbewusste Offenlegung von Schwachstellen gegenüber Kunden und der Öffentlichkeit. Dies korrespondiert mit dem Responsible-Disclosure-Prozess der Open-Source-Welt.

Art. 14 Abs. 1 #

Meldung IKT-bezogener Vorfälle (Art. 19) #

Art. 19 verpflichtet Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle der zuständigen Behörde zu melden - mit Erst-, Zwischen- und Abschlussmeldung innerhalb fester Fristen.

Art. 19 Abs. 1 #

---

Art. 19 Abs. 4 #

Testen der digitalen operationalen Resilienz (Art. 24, 25) #

Art. 24 und 25 bilden den Kern der DORA-Testpflichten. Art. 25 Abs. 1 nennt ausdrücklich Open-Source-Analysen als eine der vorgeschriebenen Testmethoden. Dies ist die expliziteste gesetzliche Forderung nach einer systematischen Bewertung von Open-Source-Komponenten in der gesamten EU-Regulierung.

Art. 24 Abs. 6 #

---

Art. 25 Abs. 1 #

Art. 25 Abs. 2 #

IKT-Drittparteienrisiko (Art. 28) #

Art. 28 regelt umfassend das Management von Risiken durch IKT-Drittdienstleister. Für Open-Source-Abhängigkeiten ist das besonders relevant: Jede Open-Source-Komponente kann als IKT-Drittparteienrisiko gelten. Die Artikel fordern Sorgfaltspflichten bei der Auswahl, laufende Überwachung, Ausstiegsstrategien und dokumentierte Informationsregister.

Art. 28 Abs. 1 #

Art. 28 Abs. 2 #

Art. 28 Abs. 3 #

Art. 28 Abs. 4 #

Art. 28 Abs. 5 #

Art. 28 Abs. 7 #

Art. 28 Abs. 8 #

Befugnisse der federführenden Überwachungsbehörde (Art. 35) #

Die Überwachungsbehörde kann bei Nichteinhaltung Zwangsgelder von bis zu 1 % des weltweiten Tagesumsatzes verhängen. Verhängte Zwangsgelder werden grundsätzlich öffentlich gemacht.

Art. 35 Abs. 8 #

Art. 35 Abs. 10 #

Verwaltungsrechtliche Sanktionen und Abhilfemaßnahmen (Art. 50) #

Art. 50 definiert das Sanktionsinstrumentarium der Behörden. Die Maßnahmen reichen von Unterlassungsanweisungen über finanzielle Maßnahmen bis zu öffentlichen Bekanntmachungen. Auch persönliche Haftung von Leitungsorganen ist vorgesehen.

Art. 50 Abs. 3 #

Art. 50 Abs. 4 #

Art. 50 Abs. 5 #

Öffentliche Bekanntmachung verwaltungsrechtlicher Sanktionen (Art. 54) #

Sanktionsentscheidungen werden auf den amtlichen Websites der Behörden veröffentlicht, einschließlich der Identität der verantwortlichen Personen. Die Veröffentlichung bleibt bis zu fünf Jahre bestehen.

Art. 54 Abs. 1 #

Art. 54 Abs. 2 #

Art. 54 Abs. 6 #

Vollständiger Gesetzestext #

Der vollständige Wortlaut der Verordnung (EU) 2022/2554 ist im Amtsblatt der Europäischen Union (ABl. L 333 vom 27.12.2022) veröffentlicht und kann über EUR-Lex abgerufen werden:

DORA-Factsheet