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