Der Cyber Resilience Act: Ein Leitfaden für Finanzunternehmen
Erste Pflichten greifen schon bald: Was Banken und Versicherungen jetzt wissen müssen
Keyfacts:
- Nach dem Digital Operational Resilience Act (DORA) kommt auf Finanzinstitute jetzt der Cyber Resilience Act (CRA) zu.
- Der Cyber Resilience Act reguliert Produkte „mit digitalen Elementen“ – also auch Software und Hardware von Banken und Versicherungen.
- Erste Fristen gelten schon von Herbst 2026 an, daher ist jetzt der Zeitpunkt für einen Umsetzungsfahrplan.
Das regelt der Cyber Resilience Act der Europäischen Union
Der Cyber Resilience Act ist eine EU-Verordnung, die für alle Produkte „mit digitalen Elementen“ gilt. Die Verordnung nimmt also nicht bestimmte Branchen in den Blick, sondern die Produkte – und macht somit für Hardware oder Software, die auf dem Markt in der EU angeboten werden, Vorgaben in Sachen Cybersicherheit.
Jedes Produkt, das direkt oder indirekt mit Geräten oder Netzen kommunizieren kann und auf dem EU-Binnenmarkt bereitgestellt wird, muss künftig über seinen gesamten Lebenszyklus hinweg angemessen sicher sein – von der Planung und dem Design über die Entwicklung und die Lieferung bis hin zur Wartung und der Außerbetriebnahme. Dazu formuliert die Verordnung unter anderem Anforderungen an die Produktentwicklung, an ein wirksames Schwachstellenmanagement und an regelmäßige Sicherheitsupdates.
Deshalb ist der Cyber Resilience Act für Banken und Versicherer wichtig
Für Banken und Versicherer ist der Cyber Resilience Act (CRA) relevant, weil sie besonders digitale und technologiegetriebene Unternehmen sind, die viele sensible Kundendaten verarbeiten und schützen müssen. Ob Banking-App, Identitäts- und Authentifizierungssoftware oder Zahlungskarten mit Chip: Banken müssen nach dem CRA künftig dafür Sorge tragen, dass die von ihnen eingesetzten Lösungen von der Designphase bis zum Ende des Betriebs sicher sind.
Vom Design bis zur Wartung und Dokumentation: Die Anforderungen des CRA
Für die betroffenen Produkte müssen Banken, Versicherungen und Co. vor allem die folgenden Anforderungen umsetzen:
- Security by Design: Cybersicherheit muss von Anfang an in Entwicklung und Architektur verankert sein.
- Secure by Default: Produkte müssen schon in der Standardkonfiguration sicher nutzbar sein. Ein Beispiel: Eine Banking-App muss von Beginn an ein starkes Authentifizierungsverfahren haben.
- Schwachstellenmanagement: Sicherheitslücken müssen erkannt, priorisiert, behoben und kommuniziert werden.
- Sicherheitsupdates: Updates und Patches müssen über den ganzen Produktlebenszyklus verlässlich bereitgestellt werden.
- Meldepflichten: Ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle sind innerhalb kurzer Fristen von wenigen Tagen zu melden.
- Dokumentation und Nachweise: Eine technische Dokumentation (inklusive der Software Bill of Materials, SBOM – eine Inventarliste einer Software), Nutzerinformationen und Konformitätsnachweise müssen vorliegen.
Das bedeutet der CRA für Banken, Versicherungen und ihre Zulieferer
Banken und Versicherungen müssen künftig zum Beispiel beim Einkauf von Software sicherstellen, dass sie zertifiziert ist. Auf Hersteller kommen umfangreiche technische Dokumentationsanforderungen zu. All das hat Auswirkungen auf die IT-Beschaffung in den Instituten. Außerdem müssen die Prozesse zur Meldung und Behebung von Schwachstellen mit denen der Drittanbieter verzahnt und Update- und Support-Zeiträume noch genauer geprüft werden.
Ein wichtiger Punkt: Ein Hersteller ist gemäß dem CRA nicht nur ein Unternehmen, das selbst Produkte entwickelt. Ein Hersteller ist auch, wer ein Produkt entwickeln lässt und es unter eigenem Namen oder eigener Marke auf den Markt bringt – unabhängig davon, ob es bezahlt, monetarisiert oder unentgeltlich angeboten wird.
Das ist im Finanzsektor praxisrelevant: Wird eine Banking‑App durch einen Dienstleister entwickelt, aber unter der Marke der Bank vertrieben, trägt die Bank die Herstellerpflichten. Damit verschiebt sich der Blick von der reinen Lieferantensteuerung hin zu klaren Produktverantwortlichkeiten im eigenen Haus.
Produkt‑Owner, Informationssicherheit, Rechtsabteilung und Compliance und Procurement müssen gemeinsam sicherstellen, dass CRA‑Pflichten in Spezifikation, Vertrag, Entwicklung, Testing, Release und Betrieb durchgängig abgebildet sind.
Resilienz als Ziel – aber das unterscheidet den Cyber Resilience Act und DORA
Grundsätzlich gelten der Digital Operational Resilience Act (DORA) und der Cyber Resilience Act parallel und zielen beide auf digitale Resilienz. Sie setzen aber unterschiedliche Schwerpunkte: DORA adressiert die digitale operationelle Resilienz des Unternehmens. DORA wirkt also institutionsbezogen und ist auf den Betrieb und die Prozesse sowie auf Fragen der Governance ausgerichtet.
Der CRA dagegen nimmt die Cybersicherheit des einzelnen Produkts in den Blick, wirkt also produktbezogen. Dabei werden mehrere Produktklassen unterschieden. Viele Anforderungen zum Beispiel an das Risikomanagement oder im Schwachstellen‑ und Patch‑Management überlappen sich. Dennoch gibt es derzeit keine ausdrückliche Ausnahme für Produkte von DORA‑regulierten Unternehmen im CRA – Finanzinstitute müssen neben den Anforderungen aus DORA also auch die des CRA umsetzen.
Eine aktuelle KPMG-Umfrage zum Stand der DORA-Umsetzung markiert die Dringlichkeit, beide Vorhaben miteinander zu verzahnen: Nur 12 Prozent der befragten Banken, Versicherungen und IKT-Dienstleister halten ihren eigenen Reifegrad für sehr hoch, und nur etwa ein Drittel hat bereits Cyber-Resilienz-Stresstests durchgeführt.
DORA-Umsetzung bei Finanzunternehmen: Exklusiver Brancheneinblick
Gemeinsam mit dem Marktforschungsinstitut Lünendonk haben wir die Branche mit Hilfe einer Umfrage um Selbsteinschätzungen zu DORA gebeten.
Studie herunterladenZwar enthält der CRA eine Öffnungsklausel (Artikel 2 Absatz 5), die Ausnahmen ermöglichen kann, wenn andere EU‑Vorschriften ein gleichwertiges oder höheres Schutzniveau bieten. Ob und in welchem Umfang DORA künftig als Grundlage für Ausnahmen oder Erleichterungen dient, müsste aber explizit durch die EU-Kommission entschieden werden.
Das ist derzeit nicht abzusehen. Deshalb sollten Banken und Versicherer die CRA‑Compliance unabhängig von ausstehenden Auslegungsfragen vorbereiten.
Zeitplan und Pflichten: Nahendes Fristende, lange Vorläufe
Der CRA ist bereits am 10.12.2024 in Kraft getreten. Für Finanzunternehmen sind zwei Meilensteine besonders wichtig: Ab dem 11.09.2026 greifen Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle.
In diesem Zuge ist eine zentrale Kontaktstelle für Schwachstellenmeldungen zu benennen, an die sich Nutzer wenden können, um Schwachstellen in den Produkten zu melden. Diese produktbezogenen Pflichten erfordern häufig Anpassungen in Entwicklungs‑ und Release‑Prozessen sowie in der technischen Dokumentation – und brauchen damit Vorlauf.
Vom 11.12.2027 an gelten alle Pflichten des CRA. Erwähnenswert ist dabei eine Übergangsbestimmung, die in Artikel 69 Absatz 2 des CRA formuliert ist: Produkte, die bereits vor dem 11.12.2027 in Verkehr gebracht wurden, unterliegen den CRA-Anforderungen grundsätzlich erst dann, wenn sie ab diesem Zeitpunkt wesentlich verändert werden.
Das schafft für Bestandsprodukte zwar eine gewisse Entlastung. Aber sobald Änderungen am Produkt die Konformität mit den grundlegenden Sicherheitsanforderungen beeinflussen oder den vorgesehenen Verwendungszweck verändern, greift die Übergangsbestimmung nicht und die Produkte fallen unter die CRA-Regulierung. Finanzunternehmen sollten also jetzt mit der Umsetzung beginnen.
Sanktionen und Bußgelder: Abwarten ist riskant
Denn bei Verstößen drohen empfindliche Bußgelder – je nach Verstoß bis zu 2,5 Prozent des weltweiten Jahresumsatzes oder bis zu 15 Millionen Euro. Es ist also auch für das Top-Management hochrelevant, das Institut jetzt bereit für die Anforderungen des CRA zu machen: Abwarten ist riskant.
Unser Fahrplan: Von der Bestandsaufnahme zur CRA‑Konformität
Ein praktikabler Weg hin zur CRA-Konformität ist ein vierstufiges Vorgehen, das CRA‑Pflichten effizient mit bestehenden DORA‑Strukturen verbindet:
- Bestandsaufnahme der betroffenen Produkte: Erfassen Sie alle Produkte mit digitalen Elementen, die Sie auf dem EU‑Markt bereitstellen (einschließlich kostenloser Apps und Portale). Klären Sie Ihre Rolle (der CRA unterscheidet zwischen Hersteller, Einführer und Händler des Produkts) und ordnen Sie Produktverantwortliche zu.
- Produktspezifische Gap‑Analyse: Gleichen Sie CRA‑Anforderungen je Produkt gegen den Status quo ab. Schauen Sie dabei genau auf grundlegende Cybersicherheitsanforderungen, das Vulnerability Handling, die Update‑Pflichten, die technische Dokumentation, die Konformitätsbewertung und Reporting‑Prozesse.
- Maßnahmenplanung: Übersetzen Sie die identifizierten Lücken in konkrete Arbeitspakete – zum Beispiel zu Anpassungen im Software-Lebenszyklus, Security‑by‑Design‑Anforderungen, Test‑ und Release‑Gates, Lieferantenanforderungen, Dokumentations‑ und Nachweisführung.
- Priorisierte Umsetzung: Priorisieren Sie nach Fristen und Risiko. Starten Sie früh mit Vulnerability‑ und Incident‑Meldeprozessen (Artikel 14 des CRA) für das Umsetzungsdatum 11.09.2026 und planen Sie parallel dazu Konformitätsbewertungen und CE‑Kennzeichnung sowie die Dokumentation für den Stichtag 11.12.2027.
Wichtig ist dabei die Integration: Nutzen Sie DORA‑Prozesse (zum Beispiel IKT-Risikokontrollen, Supplier‑Governance und IKT-Vorfallsmanagement) als Fundament, definieren Sie aber pro Produkt klare CRA‑Nachweise und Verantwortlichkeiten.
Cyber Resilience Act umsetzen und Anforderungen in die DORA-Governance integrieren
Der CRA verschiebt den Blick von der Resilienz des ganzen Unternehmens auf die Cyber‑Robustheit einzelner Produkte. Für Banken und Versicherer heißt das: Die entscheidende und möglichst schnell zu klärende Frage lautet daher, welche konkreten Produkte betroffen sind – und welche Rolle das Unternehmen in der Lieferkette einnimmt.
Wer jetzt startet, kann die Meldepflichten 2026 kontrolliert aufsetzen und bis 2027 eine belastbare Produkt‑Compliance erreichen – idealerweise integriert in die bestehende DORA‑Governance und die Produkt‑ und IT‑Prozesse.
