01Ein Vorfall, mehrere Meldeketten
Ein Ereignis wie Log4Shell (CVE-2021-44228) würde unter heutigem Recht drei Ketten zugleich auslösen. Der Hersteller, dessen Produkt die betroffene Bibliothek einbindet, meldet nach Art. 14 des Cyber Resilience Act an CSIRT und ENISA. Wird dieselbe Schwachstelle im eigenen Netz ausgenutzt, greift § 32 BSIG gegenüber dem BSI. Fließen dabei personenbezogene Daten ab, tritt Art. 33 DSGVO gegenüber der Datenschutzaufsicht daneben. Die Fristen überschneiden sich, die Auslöser und die Empfänger nicht.
Ein einziges Vorfallsticket mit Feldern für alle Regime hält die Fristen zusammen. Es erzwingt zu Beginn die Angaben, von denen abhängt, welche Kette anläuft: in welchen Mitgliedstaaten das betroffene Produkt bereitgestellt wurde und ob personenbezogene Daten im Spiel sind. Eine benannte Rufbereitschaft mit Vertretung trägt die 24-Stunden-Frist über ein Wochenende, und wer die Kette einmal ohne Anlass durchspielt, findet die Lücke im Kalender statt im Ernstfall.
02Die Lieferkette als gemeinsamer Nenner
Drei Anforderungen laufen auf dieselbe Datengrundlage zu: die Lieferkettensicherheit nach § 30 BSIG, die Sorgfaltspflicht des Herstellers für integrierte Komponenten Dritter nach Art. 13 des Cyber Resilience Act und der Nachweis über die Software-Stückliste. Wer eine belastbare Stückliste pflegt, bedient alle drei aus einer Quelle.
Die Pflicht endet dabei nicht am eigenen Quellcode. Den Zulieferer erreicht sie nur über den Vertrag: Zusagen zum Unterstützungszeitraum, Meldung von Schwachstellen nach oben, Lieferung einer Stückliste in einem gängigen maschinenlesbaren Format. Fehlen diese Klauseln, steht der Hersteller im Ernstfall mit einer Pflicht da, die er tatsächlich nicht erfüllen kann.
Für Open-Source-Komponenten gibt es diesen Vertragspartner nicht. Hier liegt die Brücke zu unserem Kompetenzbereich FOSS-Compliance. Eine Stückliste, die Open-Source-Komponenten und ihre Lizenzen sauber ausweist, beantwortet Sicherheits- und Lizenzfragen in einem Zug.
03Data Act und CRA am selben Produkt
Ein vernetztes Produkt ist regelmäßig zugleich Produkt mit digitalen Elementen und Gegenstand von Datenzugangsrechten. Datenzugang, Sicherheitsanforderungen und der Schutz von Geschäftsgeheimnissen sind gemeinsam zu entwerfen, nicht nacheinander.
Ein Zugangsdesign, das die Anforderungen des Data Act erfüllt und dabei die Sicherheitsanforderungen des Cyber Resilience Act unterläuft, ist kein Fortschritt. Es verlagert das Problem nur von der einen Behörde zur anderen.
04Abgrenzung zum Datenschutz
Weder der Cyber Resilience Act noch der Data Act sind Datenschutzrecht. Wo personenbezogene Daten betroffen sind, gilt die Datenschutz-Grundverordnung daneben, mit eigenen Rechtsgrundlagen, eigenen Meldewegen und eigener Aufsicht.
Innerhalb der Kanzlei ist das eine arbeitsteilige Zuordnung. Für Fragen der Verarbeitung personenbezogener Daten führt der Weg zu unserem Kompetenzbereich Datenschutz & Datenrecht, für Vertragsfragen rund um Software, Cloud und Beschaffung zu IT-Vertragsrecht.
05Sonderfall Finanzsektor: DORA
Finanzunternehmen im Anwendungsbereich der DORA-Verordnung sind von den Pflichten der §§ 30, 31, 32, 35, 36, 38 und 39 BSIG ausgenommen. DORA geht insoweit als spezielleres Recht vor.
Die Registrierungspflicht nach § 33 BSIG bleibt davon unberührt. Wer die Ausnahme als vollständige Bereichsausnahme liest, übersieht sie.
06Wenn nicht das BSI zuständig ist
Fällt ein Produkt zugleich als Hochrisiko-KI-System unter die KI-Verordnung (EU) 2024/1689, liegt die Marktüberwachung nach Art. 52 Abs. 14 des Cyber Resilience Act nicht beim BSI, sondern bei der für die KI-Aufsicht benannten Behörde.
Für vernetzte Produkte mit KI-Komponente ist diese Zuordnung vorab zu klären. Für Fragen der KI-Regulierung führt der Weg zu unserem Kompetenzbereich KI & Legal Tech.
