Alle Vergleiche

Cyber Resilience Act (CRA)

VS

Digital Operational Resilience Act (DORA)

CRA vs. DORA

Produktsicherheit trifft digitale Finanzresilienz

Produktregulierung

Gilt für den Hersteller: Wie sicher ist das Produkt gebaut und gewartet?

Finanzaufsichtsrecht

Gilt für das Finanzunternehmen: Wie resilient ist die Organisation gegenüber ICT-Risiken?

CRA und DORA sind komplementar, nicht austauschbar. Softwarehersteller für den Finanzsektor können beiden Regelwerken gleichzeitig unterliegen.

0 Abgedeckt3 Teilweise6 Nicht abgedeckt

Sie erfüllen DORA — was fehlt noch für Ihre Produkte?

DORA stärkt die operationale Resilienz Ihres Unternehmens im Finanzsektor. Der CRA adressiert jedoch die Sicherheit Ihrer Produkte — eine fundamentale Perspektivverschiebung von der Organisation zum Produkt.

036
CRA-AnforderungAbdeckung durch Digital Operational Resilience Act
ICT-Risikomanagement-Awareness
Teilweise

DORA Art. 5–16 etablieren ein umfassendes ICT-Risikomanagement auf Unternehmensebene. Der CRA fordert zusätzlich eine produktspezifische Cyberrisikobewertung gemäß Art. 13 Abs. 2.

Vorfallmeldeprozesse
Teilweise

DORA-Meldeprozesse an Finanzaufsichtsbehörden bestehen. Der CRA fordert die Meldung an ENISA — andere Auslöser (Produktschwachstellen vs. operationale Vorfälle), andere Plattform.

Drittanbieter-Risikobewertung
Teilweise

DORA Art. 28–30 regeln ICT-Drittanbieterrisiken auf Vertragsebene. Der CRA fordert produktseitige Sorgfaltspflichten für Drittkomponenten und SBOM-Transparenz.

Produktsicherheitsanforderungen
Nicht abgedeckt

DORA ist organisationsbezogen. Der CRA fordert konkrete technische Sicherheitseigenschaften im Produkt selbst: Security by Design, Zugriffskontrolle, Datenintegrität gemäß Anhang I.

Produkt-SBOM
Nicht abgedeckt

DORA kennt keine SBOM-Pflicht. Der CRA verlangt eine maschinenlesbare Software Bill of Materials für jedes Produkt mit digitalen Elementen.

Produktschwachstellenbehandlung
Nicht abgedeckt

DORA regelt organisatorisches ICT-Risikomanagement. Der CRA fordert eine dokumentierte Schwachstellenbehandlung für jedes Produkt über den gesamten Supportzeitraum.

CE-Kennzeichnung
Nicht abgedeckt

DORA kennt keine Produktkennzeichnung. Der CRA verlangt die CE-Kennzeichnung als Marktzugangsvoraussetzung nach erfolgreicher Konformitätsbewertung.

Produkttechnische Dokumentation
Nicht abgedeckt

DORA fokussiert auf ICT-Governance-Dokumentation. Der CRA fordert umfassende produktspezifische technische Dokumentation gemäß Anhang VII.

Produkt-Supportzeitraum
Nicht abgedeckt

DORA kennt keine Produktsupportpflicht. Der CRA verpflichtet Hersteller, einen Supportzeitraum festzulegen und kostenlose Sicherheitsupdates bereitzustellen.

01

Komplementäre Regulierungsansätze

CRA reguliert die Angebotsseite (sichere Produkte), DORA die Nachfrageseite im Finanzsektor (resiliente ICT-Systeme). Diese Komplementarität ist beabsichtigt.

  • CRA: Hersteller müssen sichere Produkte auf den Markt bringen (Security by Design, SBOM, Schwachstellenbehandlung)
  • DORA: Finanzinstitute müssen ICT-Systeme resilient betreiben (Art. 5–16)
  • Brücke: CRA-konforme Produkte dienen als Nachweis der Lieferkettensicherheit gemäß DORA Art. 28
02

Überschneidungsbereich: ICT-Drittanbieter

ICT-Drittanbieter für Finanzinstitute können beiden Regelwerken gleichzeitig unterliegen: als Hersteller dem CRA und als ICT-Drittanbieter DORA.

  • CRA-Pflichten: Anhang-I-Anforderungen, SBOM, ENISA-Meldung (24h)
  • DORA-Pflichten (Art. 28–30): Vertragliche Anforderungen, Audit-Zugangsrechte, Vorfallsberichterstattung, Exit-Strategien
  • Effizienz: CRA-Dokumentation (SBOMs, Risikobewertungen) direkt für DORA-Vertragsanforderungen nutzbar
03

Vorfallsberichterstattung im Vergleich

Beide Verordnungen fordern Vorfallsmeldungen, aber mit unterschiedlichen Auslösern und Adressaten. Ein einzelner Vorfall kann beide Meldepflichten auslösen.

  • CRA (Art. 14): Hersteller meldet Produktschwachstellen an ENISA — 24h Frühwarnung, 72h Vollmeldung
  • DORA (Art. 19): Finanzunternehmen meldet ICT-Vorfälle an Aufsichtsbehörde — Erstmeldung, Zwischenmeldung, Abschlussbericht
  • Doppelte Meldung: Hersteller an ENISA + Finanzinstitut an Aufsichtsbehörde bei demselben Vorfall
04

Strategische Empfehlungen für Unternehmen

CRA-Compliance bildet das Fundament, auf dem DORA-relevante Nachweise aufbauen. Die Strategie hängt von der Rolle ab.

  • Softwarehersteller: CRA-Compliance als Basis — SBOM, Schwachstellenbehandlung und Security by Design dokumentieren, sodass sie für DORA-Due-Diligence nutzbar sind
  • Finanzinstitute: CRA-Konformität als Beschaffungskriterium — CE-Kennzeichnung und SBOM vereinfachen DORA-Drittanbieter-Risikomanagement
  • ICT-Drittanbieter: Frühzeitig prüfen, ob CRA und DORA Art. 31 (kritische Einstufung durch ESAs) anwendbar sind

Synergien zwischen CRA und DORA

CRA und DORA ergänzen sich als komplementäre Regulierungen — eine integrierte Umsetzung bietet erhebliche Effizienzvorteile.

Dokumentation als Brücke

CRA-Dokumentation (SBOMs, Risikobewertungen, Schwachstellenberichte) kann direkt für DORA-Due-Diligence-Prüfungen genutzt werden.

Lieferkettensicherheit

CRA-konforme Produkte erleichtern Finanzinstituten die Erfüllung ihrer DORA-Anforderungen an ICT-Drittanbieter-Risikomanagement.

Koordinierte Meldeprozesse

Bei Sicherheitsvorfällen können CRA-Meldung an ENISA und DORA-Meldung an Aufsichtsbehörden parallel ausgelöst werden.

Ihre nächsten Schritte

1Hohe Priorität

Perspektive von Organisation auf Produkt verschieben

Ergänzen Sie Ihr DORA-ICT-Risikomanagement um produktspezifische Sicherheitsanforderungen. Definieren Sie für jedes Produkt die CRA-Anhang-I-Anforderungen.

2Hohe Priorität

Produktsicherheitsmaßnahmen implementieren

Implementieren Sie Security by Design, Zugriffskontrolle und sichere Standardkonfiguration in Ihren Softwareprodukten — nicht nur in Ihrer IT-Infrastruktur.

3Hohe Priorität

SBOM erstellen

Integrieren Sie automatisierte SBOM-Generierung in Ihren Entwicklungsprozess. Die SBOM-Transparenz unterstützt gleichzeitig Ihre DORA-Drittanbieter-Nachweise.

4Mittlere Priorität

CRA-Konformitätsdokumentation aufbauen

Erstellen Sie die produktspezifische technische Dokumentation gemäß CRA Anhang VII — Sicherheitsarchitektur, Risikobewertung, Testberichte.

Häufig gestellte Fragen

Fallen Softwareanbieter für Finanzinstitute unter DORA oder den CRA?
Potenziell unter beide Verordnungen. Als Hersteller eines Produkts mit digitalen Elementen unterliegen sie dem CRA für die Produktsicherheit. Gleichzeitig können sie als ICT-Drittanbieter gemäß DORA Art. 28–30 vertraglichen Anforderungen ihrer Finanzkunden unterliegen. Werden sie als kritischer ICT-Drittanbieter eingestuft (DORA Art. 31), gelten zusätzlich direkte Aufsichtsanforderungen durch die ESAs.
Wie erleichtert CRA-Compliance die DORA-Umsetzung für Finanzinstitute?
CRA-konforme Produkte bieten dokumentierte Sicherheitseigenschaften, die direkt für DORA-relevante Nachweise genutzt werden können: SBOMs ermöglichen Transparenz über die Softwarelieferkette (relevant für DORA Art. 28 Drittanbieter-Risikomanagement), die CRA-Konformitätserklärung belegt Security by Design, und die laufende Schwachstellenbehandlung durch den Hersteller entlastet das ICT-Risikomanagement des Finanzinstituts. Die EU-Kommission bestätigt in den CRA-FAQ diesen unterstützenden Zusammenhang.
Was ist ein kritischer ICT-Drittanbieter unter DORA und wie unterscheidet sich das vom CRA?
DORA Art. 31 ermächtigt die europäischen Aufsichtsbehörden (ESAs), ICT-Drittanbieter als "kritisch" einzustufen, wenn deren Ausfall systemische Auswirkungen auf den Finanzsektor hätte. Kritische ICT-Drittanbieter unterliegen dann einem direkten Aufsichtsrahmen. Der CRA kennt keine vergleichbare Einstufung — er unterscheidet stattdessen nach Produktkategorien (Standard, Klasse I, Klasse II) gemäß CRA Anhang III und IV, die den Konformitätsbewertungspfad bestimmen.
Müssen DORA-Resilienztests für alle verwendeten Softwareprodukte durchgeführt werden?
DORA Art. 24–27 fordert grundlegende und erweiterte Resilienztests für ICT-Systeme von Finanzunternehmen. Für bedeutende Finanzinstitute kommen Threat-Led Penetration Tests (TLPT) gemäß Art. 26 hinzu. Diese Tests betreffen die Betriebsumgebung des Finanzinstituts — nicht das Produkt isoliert. CRA-konforme Produkte mit dokumentierter Sicherheitsarchitektur und bekanntem Schwachstellenstatus erleichtern jedoch die Planung und Durchführung dieser Tests erheblich.
Welche Fristen gelten für die Vorfallsmeldung unter CRA und DORA?
Die Meldefristen unterscheiden sich: Unter dem CRA muss ein Hersteller eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden als Frühwarnung an ENISA melden (CRA Art. 14), gefolgt von einer vollständigen Meldung innerhalb von 72 Stunden. Unter DORA müssen Finanzunternehmen schwerwiegende ICT-Vorfälle ihrer Aufsichtsbehörde gemäß dem dreistufigen Verfahren in Art. 19 melden — die genauen Fristen sind in den Regulatory Technical Standards (RTS) der ESAs konkretisiert.
Kann ein einheitliches Risikomanagement-Framework beide Verordnungen abdecken?
Ja, ein integrierter Ansatz ist empfehlenswert. Das CRA-Risikomanagement auf Produktebene (Anhang I, Abschnitt 1) und das DORA-ICT-Risikomanagement auf Unternehmensebene (Art. 5–16) lassen sich in einem übergreifenden Framework verbinden. Zentrale Berührungspunkte sind das Asset-Management (SBOM-Integration), die Schwachstellenbehandlung (gemeinsame Prozesse für Entdeckung, Bewertung und Behebung), die Vorfallsberichterstattung (koordinierte Meldeketten) und das Lieferkettenmanagement (CRA-Konformität als DORA-Beschaffungskriterium).
Welche Produkte sind vom CRA ausgenommen?
Nicht alle Produkte mit digitalen Elementen fallen unter den CRA. Explizit ausgenommen sind: Medizinprodukte und In-vitro-Diagnostika (MDR/IVDR), Kraftfahrzeuge und deren Typgenehmigung (UN ECE R155/R156), Luftfahrtprodukte, Produkte für die nationale Sicherheit oder Verteidigung sowie bestimmte Open-Source-Software, die nicht im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird. Falls Ihr Produkt unter eine dieser Ausnahmen fällt, gelten die jeweiligen sektorspezifischen Cybersicherheitsanforderungen statt des CRA.

Weiterführende Links

Offizielle Quellen

CRA — Verordnung (EU) 2024/2847 im Volltext

Offizieller Verordnungstext des Cyber Resilience Act im EUR-Lex-Portal

DORA — Verordnung (EU) 2022/2554 im Volltext

Offizieller Verordnungstext des Digital Operational Resilience Act

ESMA — DORA-Seite

Übersicht der Europäischen Wertpapier- und Marktaufsichtsbehörde zu DORA, einschließlich technischer Regulierungsstandards

Mehr auf Kunnus

CRA-Wissensportal

Vollständiger Verordnungstext und Kommentierungen zum CRA

CRA verständlich erklärt

Übersicht über den Cyber Resilience Act für Entscheidungsträger

Kunnus für Software & SaaS

CRA-Compliance-Lösung speziell für Software- und SaaS-Hersteller im Finanzsektor

CRA-Compliance-Check

Kostenlose Ersteinschätzung Ihres CRA-Compliance-Status

CRA vs. NIS-2 — EU-Cybersicherheitsstrategie

Produktsicherheit vs. organisatorische Sicherheit: Die zwei Säulen der EU-Cybersicherheit

CRA vs. ISO 27001 — Standard vs. Verordnung

Wie sich der freiwillige ISO-Standard und die verbindliche EU-Verordnung ergänzen

CRA- und DORA-Compliance vereinen

Kunnus unterstützt Softwarehersteller im Finanzsektor dabei, CRA-Anforderungen effizient umzusetzen — und gleichzeitig DORA-relevante Dokumentation für ihre Finanzkunden bereitzustellen.

Mehr erfahren