Skip to content

Digital Operational Resilience Act (DORA)

Das Gesetz über die digitale operative Widerstandsfähigkeit (Digital Operational Resilience Act, DORA) ist ein umfassender Rechtsrahmen, der von der Europäischen Union (EU) eingeführt wurde, um die operative Widerstandsfähigkeit von Finanzinstituten und kritischen Drittanbietern zu verbessern. DORA soll sicherstellen, dass Finanzinstitute und ihre Dienstleister allen Arten von Störungen und Bedrohungen im Zusammenhang mit der Informations- und Kommunikationstechnologie (IKT) standhalten, darauf reagieren und sich davon erholen können.

[!NOTE]

Alle Artikelverweise beziehen sich, sofern nicht anders angegeben, auf die Verordnung (EU) 2022/2554 und führen direkt zum jeweiligen Artikel. Die Quellen der Durchführungs- und Delegationsrechtsakte stehen im Abschnitt Quellen.

Überblick

  • Segment: IT Sicherheit / Financial Services

  • Verabschiedet / Veröffentlicht:

    • Verordnung (EU) 2022/2554 vom 14.12.2022, veröffentlicht im Amtsblatt der EU (L 333) am 27.12.2022
    • Begleitend: Richtlinie (EU) 2022/2556 vom 14.12.2022, die u. a. die Richtlinien 2009/138/EG (Solvency II), 2013/36/EU (CRD), 2014/65/EU (MiFID II) und (EU) 2015/2366 (PSD2) hinsichtlich der digitalen operationalen Resilienz anpasst

  • Gültig ab (Art. 64):

    • In Kraft getreten: 16.01.2023 (20. Tag nach Veröffentlichung)
    • Anwendbar: 17.01.2025 (Verordnung, in allen Teilen verbindlich und unmittelbar in jedem Mitgliedstaat gültig)

  • Gültig für (Art. 2 Abs. 1):

    DORA gilt für 20 Typen von Finanzunternehmen (Buchstaben a bis t), darunter Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Krypto-Dienstleister, Handelsplätze, zentrale Gegenparteien, Versicherungs- und Rückversicherungsunternehmen sowie Ratingagenturen. Zusätzlich erfasst die Verordnung IKT-Drittdienstleister (Buchstabe u; Legaldefinition in Art. 3 Nr. 19), die diese Unternehmen beliefern. Für kritische Anbieter (CTPP) gilt ein eigener Aufsichtsrahmen.

  • Nicht gültig für (Art. 2 Abs. 3):

    • Verwalter alternativer Investmentfonds nach Art. 3 Abs. 2 der Richtlinie 2011/61/EU
    • Versicherungs- und Rückversicherungsunternehmen nach Art. 4 der Richtlinie 2009/138/EG (kleine Versicherer unterhalb der Solvency-II-Schwellen)
    • Einrichtungen der betrieblichen Altersversorgung mit insgesamt weniger als 15 Versorgungsanwärtern
    • Nach Art. 2 und 3 der Richtlinie 2014/65/EU (MiFID II) ausgenommene Personen
    • Versicherungsvermittler, die Kleinst-, kleine oder mittlere Unternehmen sind
    • Postgiroämter im Sinne der Richtlinie 2013/36/EU
    • Nicht-Finanzunternehmen, es sei denn, sie erbringen IKT-Dienstleistungen für Finanzunternehmen (dann mittelbar über Vertragspflichten, ggf. direkt als CTPP)

  • Verhältnismäßigkeit (Art. 4, Art. 16):

    • Die Anforderungen sind nach Größe, Risikoprofil sowie Art, Umfang und Komplexität der Tätigkeiten anzuwenden.
    • Für eine abschließend aufgezählte Gruppe (u. a. kleine, nicht verflochtene Wertpapierfirmen, ausgenommene Zahlungs- und E-Geld-Institute, kleine Einrichtungen der betrieblichen Altersversorgung) gilt anstelle der Art. 5–15 ein vereinfachter IKT-Risikomanagementrahmen.
    • Kleinstunternehmen sind von einzelnen Pflichten ausgenommen oder erhalten Erleichterungen (z. B. Art. 6 Abs. 4, Art. 24, Art. 26).

  • Grauzone:

    • Abgrenzung, ob und wann klassische Software-Lizenzierung oder On-Premise-Software als „IKT-Dienstleistung" gilt. Art. 3 Nr. 21 definiert diese als digitale Dienste und Datendienste, die über IKT-Systeme dauerhaft bereitgestellt werden, einschließlich Hardware als Dienstleistung und Software- oder Firmware-Updates durch den Hardwareanbieter. Der Wortlaut lässt die Einordnung von reinem Lizenzkauf offen.
    • Verhältnis zu NIS2: Für Finanzunternehmen, die nach NIS2 als wesentliche oder wichtige Einrichtungen gelten, ist DORA ein sektorspezifischer Rechtsakt im Sinne von Art. 4 der Richtlinie (EU) 2022/2555 (Art. 1 Abs. 2). Die Abgrenzung für Konzerne mit gemischten Tätigkeiten ist im Einzelfall zu prüfen.
    • Nationale Ausgestaltung der Sanktionen (Art. 50 Abs. 3) und der Aufsicht. In Deutschland erfolgt die Anpassung über das Finanzmarktdigitalisierungsgesetz (FinmadiG). Die BaFin hat KAIT, VAIT und ZAIT mit Ablauf des 16.01.2025 aufgehoben, die BAIT gelten nur noch für Institute außerhalb des DORA-Anwendungsbereichs fort (BaFin-Meldung vom 09.01.2025).

  • Ziel: Die Verordnung betont die Bedeutung der operativen Widerstandsfähigkeit und verpflichtet Finanzinstitute zur Einführung robuster Rahmenwerke für das IKT-Risikomanagement. Dazu gehören die Identifizierung, Bewertung und Minderung von IKT-Risiken, um die Kontinuität kritischer Betriebsabläufe sicherzustellen. Gleichzeitig vereinheitlicht DORA die bis dahin national und sektoral zersplitterten IKT-Anforderungen in einem EU-Rahmen (Art. 1).

  • Neuerungen / Anforderungen:

    • Einheitlicher IKT-Risikomanagementrahmen mit Letztverantwortung des Leitungsorgans (Art. 5–16)
    • Standardisierte Klassifizierung und Meldung schwerwiegender IKT-Vorfälle (Art. 17–23)
    • Verpflichtende Resilienztests, für von der Aufsicht bestimmte Finanzunternehmen inklusive bedrohungsorientierter Penetrationstests (TLPT, Art. 24–27)
    • Strukturiertes Management von IKT-Drittparteirisiken mit Informationsregister und Mindestvertragsinhalten (Art. 28–30)
    • Direkte EU-Aufsicht über kritische IKT-Drittdienstleister (CTPP) durch EBA, ESMA und EIOPA (Art. 31–44)
    • Freiwilliger Austausch von Informationen zu Cyberbedrohungen (Art. 45)

Zentrale Forderungen

Finanzinstitute müssen umfassende Rahmenwerke für das IKT-Risikomanagement einrichten, die Richtlinien, Verfahren und Kontrollen zur Bewältigung von IKT-Risiken umfassen. Dazu gehören regelmäßige Risikobewertungen, die Planung von Maßnahmen zur Reaktion auf Vorfälle und das Business Continuity Management. DORA gliedert die Anforderungen in fünf Säulen (Kapitel II bis VI).

  • Governance und Rechenschaftspflicht (Art. 5):

    Das Leitungsorgan definiert, genehmigt, überwacht und verantwortet den IKT-Risikomanagementrahmen und trägt die letztendliche Verantwortung für das Management der IKT-Risiken (Abs. 2 lit. a). Es legt klare Aufgaben und Verantwortlichkeiten fest (Abs. 2 lit. c), genehmigt die Strategie für digitale operationale Resilienz einschließlich der Toleranzschwelle für IKT-Risiken (lit. d), weist Budget zu (lit. g) und überprüft die Leitlinie zur Nutzung von IKT-Drittdienstleistern (lit. h). Seine Mitglieder müssen ihre Kenntnisse zu IKT-Risiken durch regelmäßige Schulungen aktuell halten (Abs. 4).

  • IKT-Risikomanagement (Art. 6–16):

    • Dokumentierter Rahmen, mindestens jährlich überprüft, und Strategie für digitale operationale Resilienz (Art. 6 Abs. 5 und 8)
    • Aktuelle Inventare der IKT-Assets, Informationsbestände und Abhängigkeiten inkl. Konfiguration und Interdependenzen (Art. 8 Abs. 1, 4, 6), laufende Bewertung von Cyberbedrohungen und IKT-Schwachstellen (Abs. 2)
    • Schutz und Prävention (Art. 9 Abs. 4): Zugriffsbeschränkung (lit. c), starke Authentifizierung und Verschlüsselung (lit. d), IKT-Änderungsmanagement einschließlich Software (lit. e) sowie dokumentierte Patch- und Update-Richtlinien (lit. f)
    • Erkennung anomaler Aktivitäten (Art. 10), Geschäftsfortführung, Reaktion und Wiederherstellung (Art. 11), Backup (Art. 12)
    • Lernen aus Vorfällen (Art. 13) und Krisenkommunikation (Art. 14)
    • Konkretisierung durch die Delegierte Verordnung (EU) 2024/1774 (Tools, Methoden, Prozesse und Richtlinien, vereinfachter Rahmen). Besonders relevant für Software:
      • Art. 10: Schwachstellen- und Patch-Management. Zu verfolgen ist u. a. die Nutzung von Bibliotheken Dritter, einschließlich Open-Source-Bibliotheken, die kritische oder wichtige Funktionen unterstützen. Das Finanzunternehmen hat außerdem zu prüfen, ob IKT-Drittdienstleister Schwachstellen angehen und zumindest kritische Schwachstellen zeitnah melden.
      • Art. 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen, u. a. Quellcodeprüfungen mit statischen und dynamischen Tests (Abs. 3), Integritätsschutz des Quellcodes (Abs. 7) sowie Analyse und Test von proprietärer Software und, nach Möglichkeit, Open-Source-Quellcode vor dem Produktiveinsatz (Abs. 8)

  • Meldung von Vorfällen (Art. 17–23):

    Die Verordnung schreibt Prozesse zur Erkennung, Klassifizierung und Meldung schwerwiegender IKT-bezogener Vorfälle an die zuständigen Behörden vor (Art. 17, Art. 19 Abs. 1). Art. 19 Abs. 4 sieht eine Erst-, Zwischen- und Abschlussmeldung vor. Die konkreten Fristen regelt die Delegierte Verordnung (EU) 2025/301, Art. 5, auf Grundlage von Art. 20 DORA. Sie laufen ab der Einstufung als schwerwiegend:

    Meldung Frist
    Erstmeldung so früh wie möglich, innerhalb von 4 Stunden nach Einstufung als schwerwiegend, spätestens 24 Stunden nach Kenntnis des Vorfalls
    Zwischenmeldung spätestens 72 Stunden nach Übermittlung der Erstmeldung
    Abschlussmeldung spätestens einen Monat nach der (letzten aktualisierten) Zwischenmeldung

    Die Kriterien zur Einstufung als schwerwiegend enthält die Delegierte Verordnung (EU) 2024/1772. Erhebliche Cyberbedrohungen können freiwillig gemeldet werden (Art. 19 Abs. 2). Haben Vorfälle Auswirkungen auf die finanziellen Interessen von Kunden, sind diese unverzüglich zu informieren (Art. 19 Abs. 3).

  • Tests der digitalen Betriebsresilienz (Art. 24–27):

    Finanzunternehmen, die keine Kleinstunternehmen sind, unterhalten ein Testprogramm (Art. 24 Abs. 1) und testen alle IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, mindestens einmal jährlich (Abs. 6). Die Tests müssen von unabhängigen Parteien durchgeführt werden (Abs. 4). Zu den vorgesehenen Testarten zählen u. a. Schwachstellenbewertungen und -scans, Open-Source-Analysen, Scans von Softwarelösungen und Quellcodeprüfungen, soweit durchführbar (Art. 25 Abs. 1). Von den Behörden bestimmte Finanzunternehmen führen mindestens alle drei Jahre bedrohungsorientierte Penetrationstests (TLPT) an Live-Produktivsystemen durch (Art. 26 Abs. 1 und 2), ausgerichtet am TIBER-EU-Rahmen (Abs. 11). Details regelt die Delegierte Verordnung (EU) 2025/1190.

  • Risikomanagement bei Dritten (Art. 28–30):

    DORA legt großen Wert auf das Management von Risiken, die mit Drittanbietern verbunden sind. Finanzunternehmen bleiben jederzeit voll für die Einhaltung der Verordnung verantwortlich (Art. 28 Abs. 1 lit. a) und müssen vor Vertragsabschluss Risiken, auch Konzentrationsrisiken, bewerten (Art. 28 Abs. 4, Art. 29).

    • Führung eines Informationsregisters aller vertraglichen Vereinbarungen über IKT-Dienstleistungen, mit jährlicher Berichterstattung an die Aufsicht (Art. 28 Abs. 3); Standardvorlagen in der Durchführungsverordnung (EU) 2024/2956
    • Mindestvertragsinhalte für alle IKT-Dienste (Art. 30 Abs. 2): Beschreibung der Leistungen und Unterauftragsvergabe, Datenverarbeitungsstandorte, Schutz von Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit, Datenzugang und -rückgabe bei Insolvenz oder Vertragsende, Unterstützung bei IKT-Vorfällen, Zusammenarbeit mit Behörden, Kündigungsrechte
    • Zusätzliche Inhalte bei kritischen oder wichtigen Funktionen (Art. 30 Abs. 3): präzise Leistungsziele, Notfallpläne und IKT-Sicherheitsmaßnahmen des Dienstleisters, Teilnahme an TLPT, uneingeschränkte Zugangs-, Inspektions- und Auditrechte, Ausstiegsstrategien mit verbindlichem Übergangszeitraum
    • Verpflichtende Exit-Strategien für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen (Art. 28 Abs. 8)
    • Konkretisierung der Vertragspolitik in der Delegierten Verordnung (EU) 2024/1773

  • Aufsicht über kritische IKT-Drittdienstleister (Art. 31–44):

    Die Europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA) stufen kritische IKT-Drittdienstleister (CTPP) anhand der Kriterien in Art. 31 Abs. 2 ein (u. a. systemische Auswirkungen, Abhängigkeit, Substituierbarkeit) und benennen je CTPP eine federführende Überwachungsbehörde (Lead Overseer). Diese darf Informationen anfordern, Untersuchungen und Inspektionen durchführen und Empfehlungen aussprechen (Art. 35 Abs. 1).

  • Aufsicht und Durchsetzung (Art. 46–50):

    Die zuständigen Behörden verfügen über alle Aufsichts-, Untersuchungs- und Sanktionsbefugnisse (Art. 50 Abs. 1 und 2). Die Mitgliedstaaten legen angemessene verwaltungsrechtliche Sanktionen und Abhilfemaßnahmen selbst fest; diese müssen wirksam, verhältnismäßig und abschreckend sein (Abs. 3). Mindestens müssen Unterlassungsanordnungen, die Einstellung von Praktiken und öffentliche Bekanntmachungen möglich sein (Abs. 4). Gegenüber CTPP kann der Lead Overseer ein Zwangsgeld von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes verhängen, täglich und für höchstens sechs Monate (Art. 35 Abs. 6 bis 8).

  • Informationsaustausch (Art. 45):

    Finanzunternehmen können Informationen und Erkenntnisse über Cyberbedrohungen (u. a. Kompromittierungsindikatoren, Taktiken, Techniken und Verfahren) in vertrauenswürdigen Gemeinschaften austauschen und melden dies den Behörden.

Relevanz für Software-Hersteller und Open Source

Software- und Cloud-Anbieter, die Finanzunternehmen beliefern, sind in der Regel IKT-Drittdienstleister (sofern ihre Leistung die Definition in Art. 3 Nr. 21 erfüllt, siehe Grauzone) und müssen die Anforderungen aus Art. 30 vertraglich zusichern. Praktisch bedeutet das:

  • Nachweis von Schwachstellen- und Patch-Prozessen sowie von Vorfallsunterstützung (Art. 30 Abs. 2 lit. f; Art. 30 Abs. 3 lit. c)
  • Transparenz über die Software-Lieferkette, einschließlich eingesetzter Open-Source-Komponenten: Der Kunde muss Bibliotheken Dritter nachverfolgen und Schwachstellen prüfen (Delegierte VO 2024/1774, Art. 10) und seine IKT-Assets samt Interdependenzen inventarisieren (Art. 8 Abs. 4)
  • Nachvollziehbare Entwicklungs- und Wartungsprozesse: Der Kunde muss gelieferte Software und nach Möglichkeit Open-Source-Quellcode vor dem Produktiveinsatz analysieren und testen (Delegierte VO 2024/1774, Art. 16 Abs. 3, 7, 8)
  • Prüf- und Auditrechte sowie Exit- und Migrationsunterstützung (Art. 30 Abs. 3 lit. e und f)
  • Offenlegung und Steuerung von Unterauftragsketten (Art. 29 Abs. 2, Art. 30 Abs. 2 lit. a)

Für Format und Mindestinhalte einer SBOM bietet die BSI TR-03183 Teil 2 eine Orientierung (siehe CRA); sie hat keinen DORA-Bezug. DORA enthält keine ausdrückliche SBOM-Pflicht. Ohne belastbare Komponentenkenntnis lassen sich die oben genannten Anforderungen aber kaum nachweisbar erfüllen, eine SBOM ist daher ein naheliegendes Mittel. Die Anforderungen ergänzen sich mit dem Cyber Resilience Act für Produkte mit digitalen Elementen und mit NIS2, das für Finanzunternehmen durch DORA als Spezialregelung verdrängt wird.

Wechselwirkungen mit anderen EU-Regularien

DORA trifft Finanzunternehmen als Betreiber und Nutzer von IKT, während CRA und PLD die Hersteller von Software und Produkten adressieren. Für Software-Anbieter im Finanzsektor greifen daher häufig mehrere Regelwerke gleichzeitig:

Aspekt DORA NIS2 CRA AI Act PLD
Adressat Finanzunternehmen, IKT-Drittdienstleister (Vertragspflichten), CTPP wesentliche und wichtige Einrichtungen Hersteller, Importeure, Händler von Produkten mit digitalen Elementen Anbieter und Betreiber von KI-Systemen Hersteller (inkl. Software)
Lieferkette Art. 28–30 (Register, Verträge) Art. 21 Abs. 2 lit. d Art. 13 Abs. 5 (Sorgfalt bei Drittkomponenten, auch FOSS) Art. 25 (Wertschöpfungskette) —
Incident Reporting Art. 19 + Del. VO 2025/301: 4 h / 72 h / 1 Monat Art. 23 Abs. 4: 24 h / 72 h / 1 Monat Art. 14: 24 h / 72 h / Abschlussbericht 14 Tage nach Korrekturmaßnahme (Schwachstelle) bzw. 1 Monat (Vorfall) Art. 73: 15 Tage, in Sonderfällen 10 bzw. 2 Tage —
Aufsicht national zuständige Finanzaufsicht (DE: BaFin/Bundesbank), ESAs für CTPP nationale Behörden (DE: BSI) Marktüberwachung Marktüberwachung; bei Finanzinstituten die Finanzaufsicht (Art. 74 Abs. 6) Zivilgerichte

[!NOTE]

Die Meldepflichten nach CRA Art. 14 gelten bereits seit dem 11.09.2026, die übrigen CRA-Pflichten erst ab dem 11.12.2027 (CRA Art. 71). Die Meldepflichten gelten auch für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden (Art. 69 Abs. 3).

DORA ↔ NIS2: DORA ist für Finanzunternehmen ein sektorspezifischer Rechtsakt im Sinne von Art. 4 NIS2 (DORA Art. 1 Abs. 2). Für die von DORA geregelten Sachverhalte (IKT-Risikomanagement, Meldewesen) gelten somit die DORA-Vorgaben. Sektorfremde Geschäftsbereiche eines Konzerns können weiterhin unter NIS2 fallen. Eine Einbindung der NIS2-Behörden (CSIRT) in die Meldekette kann der Mitgliedstaat zusätzlich vorsehen (Art. 19 Abs. 1).

DORA ↔ CRA: Die Kundenseite (Finanzunternehmen) fordert über Art. 28–30 Sicherheit und Transparenz vertraglich ein, die Herstellerseite wird durch den CRA gesetzlich geregelt. Wer Software an Banken oder Versicherer liefert, kann beides mit denselben Mitteln bedienen: SBOM, Secure-Development-Lifecycle und ein Vulnerability-Disclosure-Prozess. Ein CRA-konformer Hersteller erfüllt damit wesentliche Vorarbeiten für die DORA-Vertragsverhandlung, ersetzt sie aber nicht (z. B. Audit- und Exit-Rechte nach Art. 30 Abs. 3).

DORA ↔ AI Act: Setzt ein Finanzunternehmen KI-Systeme ein (Kreditwürdigkeitsprüfung, Betrugserkennung, Risikomodelle), sind diese Teil der IKT-Assets und unterliegen DORA. Hochrisiko-KI nach AI Act braucht zusätzlich Risikomanagement (Art. 9), Dokumentation und Logging. Der AI Act berücksichtigt bestehende interne Governance-Pflichten des Finanzsektors, etwa beim Qualitätsmanagementsystem (Art. 17 Abs. 4), bei der Dokumentation (Art. 18 Abs. 3) und bei Protokollen (Art. 19 Abs. 2). Bei Vorfällen laufen zwei Meldewege (DORA und AI Act) mit unterschiedlichen Fristen.

DORA ↔ PLD: Die Produkthaftungsrichtlinie (EU) 2024/2853 erfasst ausdrücklich auch Software als Produkt (Art. 4 Nr. 1) und gewährt Schadensersatzansprüche natürlichen Personen (Art. 5 Abs. 1). DORA regelt dagegen die Aufsicht und die Vertragsbeziehung zwischen Finanzunternehmen und IKT-Anbietern. Vertragliche Regelungen nach Art. 30 DORA ersetzen die gesetzliche Haftung nach PLD nicht.

[!NOTE]

Die Tabelle ist eine Orientierung und ersetzt keine Rechtsberatung. Fristen und Auslöser (Kenntnis, Einstufung, Eintritt) unterscheiden sich je Regelwerk. Bei Mehrfachbetroffenheit sollten die Meldeprozesse parallel und mit einheitlicher Faktenbasis aufgesetzt werden.

Zeitplan und Konkretisierungen (Level 2)

Datum Meilenstein
27.12.2022 Veröffentlichung der Verordnung (EU) 2022/2554 im Amtsblatt der EU
16.01.2023 Inkrafttreten
25.06.2024 Veröffentlichung der Delegierten Verordnungen (EU) 2024/1774 (Risikomanagement-Tools und -Methoden, vereinfachter Rahmen), (EU) 2024/1772 (Klassifizierung von Vorfällen) und (EU) 2024/1773 (Vertragspolitik für IKT-Dienstleistungen)
02.12.2024 Veröffentlichung der Durchführungsverordnung (EU) 2024/2956 (Standardvorlagen für das Informationsregister)
17.01.2025 Anwendbarkeit der Verordnung (Art. 64)
20.02.2025 Veröffentlichung der Delegierten Verordnung (EU) 2025/301 (Inhalt und Fristen der Vorfallsmeldungen)
18.06.2025 Veröffentlichung der Delegierten Verordnung (EU) 2025/1190 (TLPT)
18.11.2025 Die ESAs veröffentlichen die erste Liste der benannten kritischen IKT-Drittdienstleister (Pressemitteilung); die Liste ist nach Art. 31 Abs. 9 jährlich zu aktualisieren

Lösungsansätze & Hilfestellungen

  • Verordnung (EU) 2022/2554 im Volltext (EUR-Lex)
  • EBA, ESMA und EIOPA haben gemeinsame Regulatory Technical Standards (RTS) und Implementing Technical Standards (ITS) zu DORA veröffentlicht, die konkrete technische Anforderungen spezifizieren: ESAs DORA RTS
  • Die BaFin hat Umsetzungshinweise zu DORA veröffentlicht
  • ENISA bietet Orientierungshilfen für ICT-Risikomanagement im Finanzsektor
  • Für TLPT bietet das Rahmenwerk TIBER-EU der EZB eine etablierte methodische Grundlage (Art. 26 Abs. 11)

Tools & Werkzeuge

ICT-Risikomanagement & GRC

Tool Lizenz Problem / Zweck Regulatorische Relevanz
Eramba Open Source (AGPL, Community Edition) GRC-Plattform: Risikoregister, Controls, Policy-Management, Audit-Trails DORA Art. 5–14: ICT-Risikomanagement-Rahmenwerk
OpenRMF Open Source (GPL-3.0) RMF-Dokumentation, STIG-Checklisten, Control-Tracking ICT-Risikodokumentation

SBOM & Lieferkettensicherheit

Tool Lizenz Problem / Zweck Regulatorische Relevanz
TrustSource ts-scan Open Source Universeller SCA-Scanner: analysiert Abhängigkeiten aus Build-Systemen und Paketmanagern, erzeugt SBOMs und lädt Ergebnisse in die TrustSource-Plattform hoch DORA Art. 8 Abs. 4 und 6: Inventar der IKT-Assets; Del. VO 2024/1774 Art. 10: Nachverfolgung von Bibliotheken Dritter
TrustSource CE AGPL (Community Edition) Vollständige SCA-Plattform: SBOM-Versionierung, Vulnerability Management und CSAF-Kommunikation DORA Art. 9 Abs. 4 lit. e, f: Änderungs- und Patch-Management; Del. VO 2024/1774 Art. 10: Schwachstellenmanagement
OWASP Dependency-Track Apache-2.0 Kontinuierliche SBOM-Analyse: nimmt SBOMs entgegen, überwacht fortlaufend gegen NVD, OSV und weitere Datenbanken DORA Art. 8 Abs. 2, Art. 10: Bewertung von IKT-Schwachstellen und Erkennung; Del. VO 2024/1774 Art. 10

Incident Management & Reporting

Tool Lizenz Problem / Zweck Regulatorische Relevanz
TheHive Open Source (AGPL) Security Incident Response; strukturiertes Case Management und Dokumentation DORA Art. 17–23: ICT-Incident Management und Meldepflichten
Deming Open Source (GPL) Web-basiertes IT-Sicherheits-Audit-Management nach ISO 27001; Maßnahmen-Tracking und Audit-Dokumentation DORA Art. 17–19: Nachweisführung zu ICT-Incident-Management-Prozessen

Resilience Testing

Tool Lizenz Problem / Zweck Regulatorische Relevanz
Chaos Monkey / Chaos Engineering Tools Open Source (Apache-2.0) Resilience Testing durch gezieltes Einbringen von Fehlern in Produktivsysteme DORA Art. 24–27: Testen der digitalen Betriebsresilienz

Quellen

Alle Rechtstexte in der deutschen Fassung im Amtsblatt der EU (ELI-Links):