Ein Softwarehaus, das seine Produkte an Banken oder Versicherungen verkauft, hält sich oft für einen reinen Zulieferer, der mit Finanzregulierung nichts zu tun hat. Das stimmt nicht mehr. Sobald ein Produkt digitale Elemente enthält und an ein Finanzunternehmen geliefert wird, greifen zwei EU-Regelwerke gleichzeitig, mit unterschiedlichen Adressaten, aber überlappenden Anforderungen.
Dieser Artikel grenzt ab, wann DORA, wann der Cyber Resilience Act und wann beide gleichzeitig gelten, und was das für die Praxis bedeutet.
Executive Summary
1. Ausgangslage: zwei Regelwerke, zwei Perspektiven
DORA, die Verordnung über die digitale operationale Resilienz im Finanzsektor, richtet sich in erster Linie an Banken, Versicherungen und andere Finanzunternehmen. Sie regelt aber auch, wie diese Unternehmen mit ihren IT-Dienstleistern umgehen müssen, insbesondere bei kritischen ICT-Drittdienstleistern. Der Cyber Resilience Act richtet sich dagegen direkt an Hersteller von Produkten mit digitalen Elementen, unabhängig davon, wer sie kauft.
2. Wer ist betroffen?
- Softwarehersteller, deren Produkte digitale Elemente im Sinne des CRA enthalten
- IT-Dienstleister, die als kritische ICT-Drittdienstleister im Sinne von DORA eingestuft werden
- Finanzunternehmen selbst, die ihre Lieferantenverträge auf beide Regelwerke abstimmen müssen
3. Wie hoch ist die Priorität?
Hoch für betroffene Hersteller. Wer die Überschneidung übersieht, riskiert nicht nur Bußgelder nach beiden Regelwerken, sondern auch vertragliche Nachforderungen von Finanzkunden, die ihrerseits unter DORA nachweisen müssen, dass ihre Zulieferer angemessen geprüft wurden.
4. Warum ist das wichtig?
Finanzunternehmen sind seit DORA verpflichtet, ihre kritischen ICT-Drittdienstleister vertraglich und organisatorisch stärker in die Pflicht zu nehmen, etwa durch Prüfrechte, Exit-Strategien und Meldepflichten. Ein Softwarehersteller, der gleichzeitig CRA-Pflichten erfüllen muss, kann diese Nachweise oft aus denselben Unterlagen ableiten, wenn er die Überschneidung von Anfang an mitdenkt, statt beide Anforderungen getrennt zu bearbeiten.
5. Was muss konkret getan werden?
- ✓ Prüfen, ob eigene Produkte unter die CRA-Definition digitaler Elemente fallen
- ✓ Klären, ob Finanzkunden das eigene Unternehmen als kritischen ICT-Drittdienstleister nach DORA einstufen
- ✓ Bestehende Sicherheitsnachweise so dokumentieren, dass sie für beide Regelwerke verwendbar sind
- ✓ Lieferantenverträge mit Finanzkunden auf DORA-Anforderungen wie Exit-Strategien und Prüfrechte prüfen
BAM Core
DORA und CRA im selben Datenmodell abbilden
Statt getrennter Nachweise: ein Kontrollen-Set, das beide Regelwerke gleichzeitig bedient.
Executable Compliance ansehen →6. Welche Dokumente werden benötigt?
- Einstufung der eigenen Produkte nach CRA-Kategorien
- Vertragsunterlagen mit Finanzkunden, insbesondere zu Prüfrechten und Exit-Strategien
- Sicherheitsnachweise, die sowohl für CRA-Konformitätserklärung als auch für DORA-Drittparteirisiko verwendbar sind
7. BAM-Mapping
| Framework | Kapitel | Kontrolle | Dokument | Priorität |
|---|---|---|---|---|
| DORA | Art. 28–30 | Management von ICT-Drittparteirisiken | Lieferantenvertrag mit Prüfrechten | hoch |
| CRA | Anhang I | Wesentliche Cybersicherheitsanforderungen | CRA-Konformitätserklärung | hoch |
| CRA | Art. 13 | Pflichten des Herstellers | Technische Dokumentation | mittel |
Verknüpfte Frameworks: DORA · Cyber Resilience Act
8. Unsere Empfehlung
Unsere Empfehlung
- Frühzeitig prüfen, ob eigene Produkte unter beide Regelwerke fallen, nicht erst bei Vertragsverhandlung mit Finanzkunden
- Sicherheitsnachweise als gemeinsame Grundlage für CRA und DORA aufbauen, nicht getrennt pflegen
- Lieferantenverträge mit Finanzkunden aktiv auf DORA-Anforderungen prüfen, statt nur zu reagieren
- Bei Unsicherheit zur CRA-Einstufung frühzeitig rechtliche Einschätzung einholen
Quellen
- Verordnung (EU) 2022/2554 (DORA), Art. 28–30 (Management des IKT-Drittparteirisikos)
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), Art. 13 und Anhang I