CRA, NIS2, DORA: drei Vorgaben, ein Cyber-Resilienz-Rahmenwerk

Europa hat seine Cyber-Resilienz in drei Teilen aufgebaut. NIS2 richtet sich an wesentliche und wichtige Einrichtungen aus achtzehn kritischen Sektoren: eine Richtlinie, also eine nationale Umsetzung, deren französische Fassung so lange auf sich warten lässt, dass die Kommission Frankreich am 9. Juli vor den Gerichtshof gebracht hat. DORA richtet sich an Finanzunternehmen, Banken, Versicherer, Vermögensverwalter: eine Verordnung, unmittelbar anwendbar seit dem 17. Januar 2025, in Frankreich beaufsichtigt von der ACPR. Der CRA richtet sich an Produkte: jede Hardware oder Software mit digitalen Elementen, die auf den europäischen Markt gebracht wird, mit einer ersten verbindlichen Frist am 11. September 2026 für die Meldung aktiv ausgenutzter Schwachstellen; die Kommission hat gerade ihre erste Anwendungsleitlinie dazu veröffentlicht.

Aus Brüsseler Sicht drei getrennte Anwendungsbereiche. Aus Sicht eines Konzerns dieselben Personen: der CISO, das Compliance-Team, das Risikomanagement, oft dieselben Dienstleister. Eine Bank, die eigene Anwendungen entwickelt, unterliegt für ihr Rahmenwerk DORA, für ihre Produkte dem CRA, und ihr Konzern kann Tochtergesellschaften haben, die unter NIS2 fallen. Der Text sieht das Zusammenspiel sogar ausdrücklich vor: Für Finanzunternehmen hat DORA als sektorspezifischer Text Vorrang vor NIS2. Nur muss man genau wissen, wer im Konzern wofür zuständig ist.

Befreit von ihrem jeweiligen Fachvokabular, verlangen die drei Texte dieselbe Grundlage. Eine benannte Governance: Die Leitungsorgane sind, bei NIS2 und DORA sogar persönlich, für die Genehmigung und Überwachung des Rahmenwerks verantwortlich. Ein dokumentiertes IKT-Risikomanagement: Vermögenswerte identifizieren, Bedrohungen bewerten, Abweichungen behandeln. Ein Vorfallsprozess: erkennen, einstufen, melden, Lehren ziehen. Und eine Kontrolle der Drittanbieter: die Lieferkette bei NIS2, das Register der IKT-Dienstleister bei DORA, das seit April 2025 an die Aufsichtsbehörden übermittelt wird, die Komponentenkette beim CRA.

Die wirklichen Unterschiede liegen bei Fristen und Meldestellen. Ein schwerwiegender Vorfall wird bei NIS2 an die ANSSI gemeldet (Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden), bei DORA an die zuständige Finanzaufsicht nach deren eigenen harmonisierten Vorlagen, beim CRA an die ENISA für eine aktiv ausgenutzte Produktschwachstelle, ebenfalls innerhalb von 24 Stunden. Drei Formulare, drei Uhren, ein einziger realer Vorfall.

Die isolierte Bearbeitung zeigt hier ihre konkretesten Schäden. Drei Compliance-Projekte erzeugen drei voneinander abweichende Bestandsverzeichnisse, drei Risikokarten mit unvereinbaren Maßstäben, drei Meldeverfahren, bei denen niemand weiß, welches um 2 Uhr morgens gilt, wenn der Vorfall real ist und alle drei Uhren gleichzeitig laufen.

Das ist der Test, der keine Fehler verzeiht: Ein bedeutender Vorfall bei einem Finanzunternehmen, das zugleich Software entwickelt, kann gleichzeitig eine DORA-Meldung an die Aufsichtsbehörde und eine CRA-Meldung an die ENISA auslösen, während sich die Konzerntöchter Fragen zu ihren NIS2-Pflichten stellen. Organisationen, die dieses Szenario mit einem einheitlichen Rahmenwerk geübt haben, meistern es; die anderen erleben es zum ersten Mal in echt.

Die methodische Antwort ist dieselbe, die wir bereits für die regulatorische Häufung allgemein beschrieben haben: die Grundlage, die einmal gemessen wird, von den regulatorischen Sichten trennen, die je nach Text aufgeschlüsselt werden. Eine Cyber-Resilienz-Reifegrad-Analyse bewertet die gemeinsamen Fähigkeiten, Governance, Risiken, Vorfälle, Drittanbieter, Tests, auf einer einheitlichen Skala; jedes Kriterium wird den Vorgaben zugeordnet, denen es dient, und die drei Compliance-Anforderungen lassen sich als drei Projektionen desselben Ist-Zustands lesen.

Diese Überschneidung macht nützliche Kollisionen sichtbar: Ein einheitlicher Vorfallsprozess, mit seinen Einstufungsschwellen und seinem Verzeichnis der Meldestellen, bringt alle drei Vorgaben auf einen Schlag voran. Ein gut aufgebautes Drittanbieterregister dient heute DORA und morgen der NIS2-Lieferkette. Und eine gemeinsame Risikosprache, etwa nach ISO 27005, verhindert, dass jeder Text seine eigene Schweregradskala neu erfindet.

Die CRA-Frist am 11. September ist der richtige Auslöser, weil sie nah, verbindlich und operativ ist. Drei Schritte in dieser Reihenfolge: klären, wer im Konzern welchem Text unterliegt, Einheit für Einheit und Produkt für Produkt. Den Meldeprozess vereinheitlichen: ein einziges internes Verfahren, drei externe Meldestellen, benannte und erreichbare Verantwortliche. Dann den Reifegrad der Grundlage messen und die Lücken in einen datierten Maßnahmenplan übersetzen, mit Priorität für das, was allen drei Vorgaben zugleich dient.

Der Zeitplan wird damit nicht enden: Die zentralen CRA-Pflichten treten im Dezember 2027 in Kraft, das französische Résilience-Gesetz wird irgendwann verabschiedet, DORA erhöht kontinuierlich die Anforderungen an Tests. Organisationen, die dieses Trio aus einer einzigen Analyse heraus steuern, werden jede neue Stufe problemlos nehmen. Die anderen fangen bei jeder Frist wieder von vorn an.