Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Das Informationsregister von DORA listet Verträge für technologische Dienstleistungen auf, die auf fortlaufender Basis erbracht werden; daher ist eine Bibliothek, die Sie ohne Vertrag herunterladen, in der Regel nicht darin enthalten.
- Verbindliche technische Standards schreiben vor, dass Open-Source-Bibliotheken, die von Diensten genutzt werden, welche kritische oder wichtige Funktionen unterstützen, nachverfolgt werden müssen.
- Software, die in den Systemen eines Finanzinstituts zum Einsatz kommt, unterliegt den Vorschriften zum Risikomanagement, unabhängig davon, ob ein Lieferantenvertrag vorliegt oder nicht.
Die DORA-Konformitätsanforderungen gelten auch für Open-Source-Bibliotheken, selbst wenn diese nicht in Ihrem Informationsverzeichnis aufgeführt sind. Der „Digital Operational Resilience Act“ (DORA) der EU nennt sie in seinen technischen Standards zum Risikomanagement im Bereich der Informations- und Kommunikationstechnologie (IKT), die unabhängig von den Bestimmungen in Lieferantenverträgen gelten.
Das Informationsregister ist die Liste, die ein Finanzunternehmen über seine Verträge für laufende IKT-Dienstleistungen führt. Ob eine Bibliothek darin aufgeführt wird, hängt davon ab, ob ein Vertrag, beispielsweise für kostenpflichtigen Support, dahintersteht. Die Risikomanagementvorschriften gelten für die Bibliothek in jedem Fall, solange sie in Ihren Systemen läuft. Sie gehört also zum Bestand der von Ihnen genutzten Software, auch wenn sie im Register nicht aufgeführt ist. Eine Bibliothek, die in diesem Bestand fehlt, stellt eine Lücke in einer von DORA geforderten Aufzeichnung dar. Vorgesetzte können Sie anweisen, dies zu beheben, und jeder Mitgliedstaat legt Sanktionen für Verstöße gegen DORA fest. Die Behörden veröffentlichen endgültige Sanktionsentscheidungen.
Für welche Organisationen gelten die DORA-Compliance-Anforderungen?
DORA gilt für zwanzig Kategorien von Finanzunternehmen, darunter Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherer, Krypto-Asset-Dienstleister, zentrale Gegenparteien und Handelsplätze. Externe IKT-Dienstleister, also Unternehmen, die diesen Einrichtungen Technologiedienstleistungen bereitstellen, werden gesondert aufgeführt und unterliegen nur dann der direkten EU-Aufsicht, wenn sie als systemrelevant eingestuft werden.
Einige Unternehmen fallen nicht in den Anwendungsbereich, darunter bestimmte kleinere Verwalter alternativer Investmentfonds und Versicherer, Rentenversicherungsträger mit bis zu 15 Mitgliedern sowie Postgiroinstitute (Postbanken, die Zahlungskonten führen). Die Mitgliedstaaten können zudem bestimmte Unternehmen ausschließen, die gemäß der EU-Bankenrichtlinie von deren Vorschriften ausgenommen sind.
Kleine und nicht miteinander verbundene Wertpapierfirmen, von der Pflicht befreite Zahlungs- und E-Geld-Institute, kleine Altersversorgungsträger (mit weniger als 100 Mitgliedern) sowie die von der Bankenrichtlinie befreiten Institute, die die Mitgliedstaaten weiterhin in den Anwendungsbereich einbeziehen, erhalten einen vereinfachten Rahmen für das IKT-Risikomanagement mit gesonderten Vorschriften in den technischen Standards. Wenn dies auf Sie zutrifft, beginnen Sie dort. Alle anderen befolgen den vollständigen Rahmen, angepasst an ihre Größe und ihr Risikoprofil – ebenso wie der Rest dieses Artikels.
Das Register basiert auf Verträgen
Der Haupttext von DORA ist die Verordnung (EU) 2022/2554, die im Folgenden als „Verordnung“ bezeichnet wird. In Artikel 3 der Verordnung wird ein IKT-Drittanbieter als ein Unternehmen definiert, das IKT-Dienste erbringt, und IKT-Dienste als digitale und Datendienste, die fortlaufend über IKT-Systeme bereitgestellt werden. Das Register, die Vertragsbedingungen und die Ausstiegsregeln beziehen sich alle auf einen Anbieter, der diese Art von Dienstleistungen erbringt.
Gemäß Artikel 28 Absatz 3 führen Sie ein Verzeichnis mit Angaben zu allen vertraglichen Vereinbarungen für diese Dienste, wobei Sie diejenigen, die kritische oder wichtige Funktionen unterstützen, von den übrigen trennen. Kritische oder wichtige Funktionen sind solche, deren Störung die Finanzen des Unternehmens, seine Dienste oder seine Fähigkeit, die Bedingungen seiner Zulassung zu erfüllen, erheblich beeinträchtigen würde. Mindestens einmal jährlich melden Sie Ihre neuen Verträge Ihrer zuständigen Behörde, einschließlich der Angaben dazu, wer diese Dienste erbringt und welche Dienste und Funktionen sie abdecken. Auf Anfrage legen Sie zudem das vollständige Verzeichnis vor. Die Standardvorlagen für das Verzeichnis stammen aus der Durchführungsverordnung (EU) 2024/2956 der Kommission.
Artikel 30 legt Mindestvertragsbedingungen fest, und Artikel 28 Absatz 8 schreibt Ausstiegsstrategien für Dienste vor, die kritische oder wichtige Funktionen unterstützen. Wenn ein Vertrag über einen solchen Dienst die Vergabe von Unteraufträgen zulässt, sind Sie gemäß Artikel 29 verpflichtet, die Risiken abzuwägen, einschließlich derer, die mit langen oder komplexen Ketten verbunden sind. Ein technischer Regulierungsstandard (RTS), die Delegierte Verordnung (EU) Nr. 2025/532 der Kommission, legt fest, welche Elemente Sie bei der Vergabe von Unteraufträgen für diese Dienste ermitteln und bewerten müssen. In den Vorlagen des Registers werden zudem alle Unterauftragnehmer erfasst, die einen solchen Dienst tatsächlich unterstützen.
Hinweis: Die Europäischen Aufsichtsbehörden (ESAs) veröffentlichen auf der Website der Europäischen Bankenaufsichtsbehörde (EBA) eine von Mitarbeitern erstellte FAQ zur Meldung an das Register. Darin heißt es, dass der einmalige Erwerb einer statischen Lösung ohne laufende Wartung, Support oder Updates keine IKT-Dienstleistung darstellt. Es handelt sich hierbei um eine Leitlinie der Mitarbeiter und nicht um die offizielle Position der ESAs.
Kritische Anbieter unterliegen einer gesonderten Aufsicht durch die ESAs: die EBA, die Europäische Aufsichtsbehörde für das Versicherungswesen und die betriebliche Altersversorgung sowie die Europäische Wertpapier- und Marktaufsichtsbehörde. Diese haben am 18. November 2025 die erste Liste der als kritisch eingestuften IKT-Drittanbieter veröffentlicht und müssen diese jährlich aktualisieren. Die Einstufung gilt für Unternehmen, die IKT-Dienstleistungen erbringen; eine Open-Source-Bibliothek an sich kommt daher nicht in Frage. Eine Bibliothek, die Sie ohne Vertrag herunterladen, fällt nicht unter das Register, die Vertragsregeln und die Aufsicht über kritische Anbieter, da kein Anbieter sie Ihnen als fortlaufenden Dienst bereitstellt. Sie unterliegt jedoch weiterhin den DORA-Vorschriften zum IKT-Risikomanagement, die sie als Software behandeln, die das Unternehmen nutzt.
Wo Open-Source-Bibliotheken im Regelwerk auftauchen
Die DORA-Konformitätsanforderungen, die sich speziell auf Open-Source-Software beziehen, sind in den Standards zum IKT-Risikomanagement enthalten. Die Verordnung definiert ein IKT-Asset als ein Software- oder Hardware-Asset in den Netzwerk- und Informationssystemen, die von der Einrichtung genutzt werden. Artikel 6 schreibt den Schutz von IKT-Assets, einschließlich Computersoftware, vor, und Artikel 8 verpflichtet Sie dazu, diese zu identifizieren, zu klassifizieren und zu dokumentieren, ihre gegenseitigen Abhängigkeiten abzubilden und Bestandsverzeichnisse zu führen.
Die Tabelle enthält die verbindlichen Anforderungen, die für Bibliotheken von unmittelbarster Bedeutung sind. Dabei steht „RTS 2024/1774“ für die Delegierte Verordnung (EU) 2024/1774 der Kommission, die RTS zum IKT-Risikomanagement.
| Thema | Was dafür erforderlich ist | Quelle |
|---|---|---|
| IKT-Bestandsaufnahme | Software-Assets und deren Abhängigkeiten identifizieren, klassifizieren und dokumentieren sowie die Bestandslisten auf dem neuesten Stand halten | Verordnung, Artikel 8 |
| Bibliotheksnachverfolgung | Erfassen Sie die von Diensten, die kritische oder wichtige Funktionen unterstützen, verwendeten Bibliotheken von Drittanbietern und Open-Source-Bibliotheken und überwachen Sie deren Versionen und Aktualisierungen gegebenenfalls gemeinsam mit dem Anbieter. | RTS 2024/1774, § 10 |
| Tests vor der Serienfertigung | Open-Source-Code sollte, soweit möglich, analysiert und getestet werden, bevor er in die Produktion gelangt, und Softwarepakete sollten spätestens in der Integrationsphase einer Sicherheitsprüfung unterzogen werden | RTS 2024/1774, § 16 |
| Schädlicher Code | Ergreifen Sie Sicherheitsmaßnahmen gegen Schadcode und stellen Sie sicher, dass nur autorisierte Software installiert wird | RTS 2024/1774, § 11 |
| Richtlinien für Patches | Führen Sie dokumentierte Richtlinien für Patches und Updates mit Fristen und Eskalationsverfahren für den Fall, dass diese nicht eingehalten werden. | Verordnung, Artikel 9; RTS 2024/1774, Artikel 10 |
| Altsysteme | Führen Sie mindestens einmal jährlich eine spezifische Risikobewertung für ältere IKT-Systeme durch | Verordnung, Artikel 3 und 8 |
Aus der Verordnung: In Artikel 25 Absatz 1 werden „Open-Source-Analysen“ als ein Beispiel für geeignete Tests im Rahmen des Resilienzprüfungsprogramms eines Finanzinstituts aufgeführt, neben Schwachstellenscans, Quellcode-Prüfungen, soweit diese durchführbar sind, und Penetrationstests.
Bei Standardkomponenten, die in Diensten verwendet werden, die keine kritischen oder wichtigen Funktionen unterstützen, sind Sie gemäß RTS 2024/1774, Artikel 10, weiterhin verpflichtet, die darin verwendeten Bibliotheken von Drittanbietern und Open-Source-Bibliotheken so weit wie möglich nachzuverfolgen.
Die Verordnung definiert ein veraltetes IKT-System als ein System, das zwar noch in Gebrauch ist und die Funktionen der Einrichtung unterstützt, dessen Lebensdauer jedoch abgelaufen ist, das aus technologischen oder wirtschaftlichen Gründen nicht für Upgrades oder Fehlerbehebungen geeignet ist oder das vom Hersteller oder einem externen IKT-Dienstleister nicht mehr unterstützt wird. Diese Definition umfasst ganze IKT-Systeme. Jede Einrichtung muss entscheiden und dokumentieren, ob eine nicht mehr unterstützte Bibliothek dazu führt, dass das System, auf dem sie läuft, als veraltetes System gilt. Kleinstunternehmen, d. h. kleinere Finanzunternehmen mit weniger als 10 Mitarbeitern und einem Umsatz oder einer Bilanzsumme von bis zu 2 Millionen Euro, sind von der jährlichen Überprüfung der Altsysteme ausgenommen.
Ob eine Bibliothek im Register eingetragen ist, hängt davon ab, wie sie zu Ihnen gelangt
Jede Bibliothek, die auf Ihren Systemen ausgeführt wird, gilt als von Ihrem Unternehmen genutzte Software, sodass die Risikomanagementvorschriften für sie gelten. Ob auch die Vorschriften für Drittanbieter und die Registrierungspflicht gelten, hängt davon ab, ob die Bibliothek über einen IKT-Dienst zu Ihnen gelangt.
Was als IKT-Dienstleistung gilt, liegt im Ermessen des jeweiligen Unternehmens. In der Frage und Antwort Nr. 2999, einer von der Europäischen Kommission über die europäischen Aufsichtsbehörden (ESAs) veröffentlichten Antwort, wird die Definition bewusst weit gefasst und die Beurteilung dem Finanzunternehmen überlassen. Für eine Bibliothek bedeutet dies, dass Sie selbst entscheiden, ob eine Support- oder Vertriebsvereinbarung als IKT-Dienstleistung gilt und in das Register aufgenommen werden muss.
| Wie die Bibliothek ankommt | IKT-Anlage | Im Informationsregister | Grundlage |
|---|---|---|---|
| Download aus dem öffentlichen Register, keine Support-Vereinbarung | Ja, als Software nutzt das Unternehmen | In der Regel nicht, da kein Vertrag über eine laufende Dienstleistung besteht | Verordnung, Artikel 3 und 28; FAQ für Mitarbeiter (Leitfaden) |
| Kommerzielle Vertriebs- oder Supportvereinbarung | Ja | Ja, wenn das Unternehmen dies als fortlaufende IKT-Dienstleistung einstuft | Verordnung, Artikel 3 und 28; Fragen und Antworten 2999 (Leitfaden) |
| In das Produkt oder den gehosteten Dienst eines Anbieters integriert | Ja, sofern es in den vom Finanzinstitut genutzten Netzwerk- und Informationssystemen läuft | Die Organisation des Anbieters sowie Subunternehmer, die die Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen effektiv absichern | Verordnung, Artikel 28 und 29; Durchführungsverordnung 2024/2956, Artikel 3 |
Wenn eine Bibliothek in das Produkt oder den gehosteten Dienst eines Anbieters eingebettet ist, entspricht der Anbieter, der diese ausliefert, in der Regel der Definition eines Unternehmens, das IKT-Dienstleistungen erbringt, während dies für den Betreuer der Bibliothek selten der Fall ist. Die vertraglichen Bestimmungen gelten dann für den Anbieter, doch eine Bibliothek, die in den von Ihnen genutzten Systemen ausgeführt wird, unterliegt weiterhin Ihren Risikomanagementvorschriften.
Eine kurze Checkliste für die Bibliotheken in Ihren kritischen Funktionen
Jeder Punkt dieser DORA-Konformitätscheckliste verweist auf den zugrunde liegenden verbindlichen Text und geht davon aus, dass Sie dem gesamten Rahmenwerk unterliegen.
- Bestandsaufnahme. Ihre Bestandsaufnahme umfasst die Software, die kritische oder wichtige Funktionen unterstützt, sowie deren Vernetzung (Verordnung, Artikel 8).
- Nachverfolgung. Sie verfolgen die von Diensten, die diese Funktionen unterstützen, verwendeten Bibliotheken von Drittanbietern und Open-Source-Bibliotheken und überwachen deren Versionen und Aktualisierungen, gegebenenfalls in Zusammenarbeit mit dem Anbieter (RTS 2024/1774, Artikel 10).
- Prüfung. Open-Source-Code wird, soweit möglich, vor der Produktionsbereitstellung analysiert und getestet, und Softwarepakete werden spätestens in der Integrationsphase Sicherheitsprüfungen unterzogen (RTS 2024/1774, Artikel 16).
- Schädlicher Code. Ihre Sicherheitsverfahren umfassen Maßnahmen zum Schutz vor schädlichem Code und lassen nur autorisierte Software auf Ihren Systemen zu (RTS 2024/1774, Artikel 11).
- Patches. Eine dokumentierte Richtlinie für Patches und Updates legt Fristen und Eskalationsschritte fest (Verordnung, Artikel 9; RTS 2024/1774, Artikel 10). Wenn die einzige Abhilfe eine neuere Version ist, kann ein Upgrade selbst zu grundlegenden Änderungen führen, wie wir in dem Artikel „Warum ‚Einfach upgraden‘ ein schlechter Sicherheitsratschlag ist“ erläutern.
- Altsysteme. Altsysteme im IKT-Bereich werden mindestens einmal jährlich einer spezifischen Risikobewertung unterzogen, es sei denn, es handelt sich um ein Kleinstunternehmen (Verordnung, Artikel 8).
- Register. In Ihrem Informationsregister sind alle vertraglichen Vereinbarungen über IKT-Dienstleistungen aufgeführt, einschließlich Softwarevereinbarungen, die als laufende Dienstleistungen gelten, und Sie können begründen, warum eine bestimmte Bibliothek darin nicht enthalten ist (Verordnung, Artikel 28).
- Rollen. Das Leitungsgremium legt klare Rollen für IKT-bezogene Funktionen und deren Abstimmung fest (Verordnung, Artikel 5). Sofern es sich nicht um ein Kleinstunternehmen handelt, übernimmt eine Kontrollfunktion die Steuerung und Überwachung von IKT-Risiken, einschließlich Bibliotheksrisiken (Verordnung, Artikel 6). Die Vorschriften legen nicht fest, welches Team für die Nachverfolgung der Bibliotheken zuständig ist. Entscheiden Sie daher, ob Ihr IKT-Risikoteam oder Ihr Team für Risiken durch Dritte diese Aufgabe übernimmt.
Beginnen Sie mit einer entscheidenden Funktion
In Ihrem Register werden keine Bibliotheken angezeigt, die Sie ohne Vertrag heruntergeladen haben; suchen Sie diese daher in Ihren eigenen Systemen. Wählen Sie eine kritische oder wichtige Funktion aus und listen Sie die dazugehörigen Bibliotheken auf, einschließlich derer, die indirekt eingebunden sind. Markieren Sie alle Bibliotheken, für die es keinen aktiven Upstream-Betreuer gibt oder für die es keinen Upstream-Fix für Ihre Version gibt. Legen Sie dann für jede Bibliothek eine Vorgehensweise fest: entweder das Ersetzen der Bibliothek, das Upgrade auf eine korrigierte Version, sofern vorhanden, oder das Patchen der von Ihnen verwendeten Version. Eine Funktion reicht aus, um eine konkrete Liste mit Ergebnissen zu erstellen und den Umfang der übrigen Software einzuschätzen.
Wenn Sie sich für den Weg über Patches entscheiden, ist SecureChain eine Option, die Sie in Betracht ziehen sollten. Das Tool scannt den Quellcode jedes Open-Source-Pakets auf bekannte Malware und verdächtige Codemuster, bevor das Paket bei Ihnen ankommt, und erstellt das Paket anschließend aus derselben Quelle neu. Im Rahmen des SLA behebt es neu veröffentlichte CVEs in diesen Paketen. Jedes Paket enthält eine SBOM für Ihr Inventar sowie VEX-Daten darüber, welche CVEs Ihre Version betreffen. Die Herkunftsangabe auf SLSA-Level 3 belegt, dass es aus der gescannten Quelle neu kompiliert wurde. Wenn Upstream-Betreuer keine Sicherheitspatches mehr bereitstellen, übernimmt der „Endless Lifecycle Support“ (ELS) automatisch diese Pakete. SecureChain und ELS sind für die Ökosysteme von JavaScript, Python, Java, Go und PHP verfügbar.
FAQ
Was versteht man unter DORA-Compliance?
DORA-Konformität bedeutet, dass ein Finanzunternehmen die Anforderungen des EU-Gesetzes über digitale Betriebsresilienz (DORA), der Verordnung (EU) 2022/2554 und der dazugehörigen technischen Standards erfüllt. Ziel ist es, den Betrieb der Dienste auch bei technologischen Störungen aufrechtzuerhalten. Die Vorschriften sind seit dem 17. Januar 2025 in Kraft.
Was sind die Anforderungen zur Einhaltung der DORA-Vorschriften?
DORA, das EU-Gesetz zur digitalen Betriebsresilienz, umfasst fünf Bereiche. Dabei handelt es sich um das Risikomanagement im Bereich der Informations- und Kommunikationstechnologie (IKT), die Meldung schwerwiegender IKT-Vorfälle, Resilienztests, das Risikomanagement bei IKT-Drittanbietern sowie den Austausch von Informationen über Cyberbedrohungen. Technische Standards regeln viele dieser Bereiche im Detail.
Wer muss die DORA-Compliance-Anforderungen erfüllen?
Der „Digital Operational Resilience Act“ (DORA) gilt für zwanzig Kategorien von Finanzunternehmen, darunter Kreditinstitute, Zahlungsinstitute, Wertpapierfirmen, Versicherer und Handelsplätze. Einige Unternehmen sind ausgenommen, und bestimmte kleine Unternehmen unterliegen einem vereinfachten Risikomanagementrahmen. Technologie-Dienstleister unterliegen nur dann einer direkten Aufsicht, wenn sie als systemrelevant eingestuft werden.
Sind Open-Source-Bibliotheken im DORA-Informationsregister erfasst?
Das Informationsregister gemäß dem „Digital Operational Resilience Act“ (DORA) listet Verträge über Informations- und Kommunikationstechnologie-Dienstleistungen (IKT) auf, die auf fortlaufender Basis erbracht werden. Eine Bibliothek aus einem öffentlichen Register verfügt in der Regel nicht über einen solchen Vertrag und ist daher nicht aufgeführt. Ein kostenpflichtiger Support kann dies ändern. In jedem Fall gelten die Risikomanagementvorschriften weiterhin für die Bibliothek als Software, die von der Einrichtung genutzt wird.
Wird Open-Source-Software in DORA erwähnt?
Ja. Eine technische Norm im Rahmen des Digital Operational Resilience Act (DORA), der Delegierten Verordnung (EU) 2024/1774 der Kommission, verpflichtet Finanzunternehmen dazu, die Open-Source-Bibliotheken zu erfassen, die von Informations- und Kommunikationstechnologie-Diensten (IKT) verwendet werden, welche kritische oder wichtige Funktionen unterstützen. Außerdem schreibt sie vor, Open-Source-Code vor der Produktionsfreigabe zu testen, sofern dies machbar ist.
Welche Sanktionen drohen bei Nichteinhaltung der DORA-Vorschriften?
Das Gesetz über die digitale Betriebsresilienz (DORA) überlässt die Festlegung der Strafhöhen für Finanzunternehmen den einzelnen Mitgliedstaaten, die dafür sorgen müssen, dass diese wirksam, verhältnismäßig und abschreckend sind. Die zuständigen Behörden können ein Unternehmen anweisen, einen Verstoß zu beenden und Abhilfemaßnahmen zu ergreifen, und sie veröffentlichen endgültige Sanktionsentscheidungen. Anbieter kritischer Technologien müssen mit einer gesonderten Sanktion auf EU-Ebene in Höhe von bis zu 1 % ihres durchschnittlichen weltweiten Tagesumsatzes rechnen, die täglich für einen Zeitraum von bis zu sechs Monaten berechnet wird.
Wer trägt das Abhängigkeitsrisiko im Rahmen von DORA?
Das Gesetz zur digitalen Betriebsresilienz (Digital Operational Resilience Act, DORA) schreibt vor, dass jedes Finanzunternehmen – mit Ausnahme von Kleinstunternehmen – eine Kontrollfunktion mit der Verantwortung für das Management und die Überwachung von Risiken im Bereich der Informations- und Kommunikationstechnologie (IKT) betrauen muss. Es wird nicht festgelegt, welches Team die Bibliotheken überwacht. Diese Rolle wird vom Leitungsgremium festgelegt, sodass jedes Unternehmen selbst entscheidet, ob die Überwachung durch sein IKT-Risiko- oder sein Drittparteien-Risikoteam erfolgt.
