Die meisten Compliance-Texte behandeln Meldepflichten eine Verordnung nach der anderen. Das geht gut, bis ein echter Vorfall eintrifft, denn ein einzelnes Ereignis respektiert diese Grenzen selten. Ein aktiv ausgenutzter Fehler in einem vernetzten Produkt kann am selben Nachmittag eine Frühwarnung nach dem Cyber Resilience Act, eine NIS2-Meldung über einen erheblichen Vorfall und eine DSGVO-Meldung über eine Verletzung des Schutzes personenbezogener Daten auslösen. Drei Uhren, drei Empfänger, drei Formate, alle durch ein einziges Ereignis gestartet.
Dieser Beitrag stellt die Pflichten einander gegenüber, damit Sie sehen, wo sie sich überschneiden, wo sie sich unterscheiden und warum es der Weg zu verpassten Fristen ist, sie aus drei getrennten Postfächern zu betreiben.
Drei Regelwerke, drei Uhren
CRA-Artikel 14
Der Cyber Resilience Act bindet Hersteller, die Produkte mit digitalen Elementen auf den EU-Markt bringen. Artikel 14 setzt zwei Auslöser und für jeden einen gestuften Zeitplan.
Für eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt:
- Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung
- Vollständige Meldung innerhalb von 72 Stunden
- Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme
Für einen schwerwiegenden Vorfall, der die Sicherheit des Produkts beeinträchtigt:
- Frühwarnung innerhalb von 24 Stunden
- Meldung innerhalb von 72 Stunden
- Abschlussbericht innerhalb von einem Monat
Die Berichte gehen an das als Koordinator benannte CSIRT und an ENISA, über die zentrale Meldeplattform, sobald sie live ist.
NIS2-Artikel 23
Ist Ihre Organisation eine wesentliche oder wichtige Einrichtung nach NIS2, trägt ein erheblicher Vorfall seine eigene gestufte Pflicht, geschuldet von Ihnen als Betreiber, nicht als Produkthersteller.
- Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung
- Vorfallmeldung innerhalb von 72 Stunden, mit einer ersten Bewertung, Schweregrad, Auswirkungen und etwaigen Kompromittierungsindikatoren
- Zwischenbericht auf Anfrage der Behörde
- Abschlussbericht innerhalb von einem Monat nach der Meldung
Die Berichte gehen an das CSIRT oder die zuständige Behörde Ihres Mitgliedstaats. Dasselbe Ereignis, das eine CRA-Produktmeldung auslöst, kann daher eine separate NIS2-Betreibermeldung auslösen, auf einem parallelen 24- und 72-Stunden-Gleis, an einen Empfänger, der dieselbe Stelle sein kann oder auch nicht.
DSGVO-Artikel 33
Hat der Vorfall personenbezogene Daten offengelegt, fügt die Datenschutz-Grundverordnung eine dritte Uhr hinzu.
- Benachrichtigen Sie die Aufsichtsbehörde unverzüglich und, wo machbar, innerhalb von 72 Stunden nach Kenntniserlangung
- Ist die Verletzung voraussichtlich mit einem hohen Risiko für Personen verbunden, verlangt Artikel 34, dass Sie auch die betroffenen Personen unverzüglich informieren
Diese Uhr verantwortet sich gegenüber Ihrer Datenschutzbehörde, die wiederum eine andere Stelle ist, und der Inhalt, den sie verlangt, betrifft die betroffenen Personen und den Schaden, nicht den Produktfehler.
Wo sie sich überschneiden und wo sie auseinandergehen
Die Fristen sehen auf dem Papier ähnlich aus, und genau das ist die Falle. Die Werte von 24 und 72 Stunden wiederholen sich, aber der Moment, in dem die Uhr beginnt, der Empfänger und der erforderliche Inhalt unterscheiden sich alle.
| Auslöser | Erste Frist | Empfänger | Fokus | |
|---|---|---|---|---|
| CRA Art. 14 | Ausgenutzte Schwachstelle oder schwerwiegender Vorfall im Produkt | 24-h-Frühwarnung | Koordinator-CSIRT und ENISA | Der Produktfehler |
| NIS2 Art. 23 | Erheblicher Vorfall bei der Einrichtung | 24-h-Frühwarnung | Nationales CSIRT oder zuständige Behörde | Operative Auswirkung |
| DSGVO Art. 33 | Verletzung des Schutzes personenbezogener Daten | 72-h-Meldung | Datenschutzbehörde | Risiko für Personen |
Ein paar Punkte sind festzuhalten.
Der Startschuss unterscheidet sich. CRA und NIS2 laufen ab dem Zeitpunkt, an dem Sie von dem Vorfall oder der Ausnutzung Kenntnis erlangen. Die DSGVO läuft ab der Kenntnis der Verletzung. In einem unübersichtlichen realen Vorfall können diese Momente Stunden oder Tage auseinanderliegen, sodass die drei Uhren selten gemeinsam starten, selbst wenn ein Ereignis sie alle verursacht.
Die Empfänger unterscheiden sich. Ein Koordinator-CSIRT, eine nationale zuständige Behörde und eine Datenschutzbehörde sind drei Stellen mit drei Eingangskanälen. Keine davon akzeptiert eine Kopie des Berichts, den Sie an eine andere geschickt haben.
Der Inhalt unterscheidet sich. ENISA will die Schwachstelle und die Korrekturmaßnahme. Die NIS2-Behörde will den operativen Schweregrad und Kompromittierungsindikatoren. Die Datenschutzbehörde will die Datenkategorien, die Zahl der betroffenen Personen und die wahrscheinlichen Folgen für sie.
Was sich überschneidet, ist der 24-Stunden-Reflex. Über CRA und NIS2 hinweg erwartet das Gesetz nun, dass Sie innerhalb eines Tages etwas Sinnvolles sagen, bevor Sie ein vollständiges Bild haben. Diese Frühwarnung ist keine Formalität. Es ist die Pflicht, die am ehesten verpasst wird, weil sie in die ersten chaotischen Stunden fällt, in denen das Team noch herausfindet, was passiert ist.
Das praktische Problem
Die Gefahr ist nicht die Unkenntnis einer einzelnen Regel. Die meisten Teams können die 72-Stunden-DSGVO-Frist aufsagen. Die Gefahr ist die Kollision. Wenn ein Ereignis drei Uhren startet, zersplittert die Arbeit über Rechtsabteilung, Sicherheit und den Datenschutzbeauftragten, jeder beobachtet seine eigene Verordnung, jeder nimmt an, jemand anderes habe die anderen im Griff. Die Frühwarnung, die zu Stunde 23 hinaus musste, rutscht durch, weil alle den Bericht entwarfen, der zu Stunde 72 fällig war.
Ein funktionsfähiger Prozess behandelt diese als einen einzigen Arbeitsablauf mit drei Ergebnissen, nicht als drei Arbeitsabläufe.
- Eine Erfassung, ein Zeitstempel. Halten Sie den Moment der Kenntnis einmal fest, denn jede Uhr wird ab einer Version davon gemessen. Streiten Sie später darüber, welche Version für welches Regelwerk gilt. Verlieren Sie nicht den Zeitstempel.
- Eine Triage, die alle drei Fragen zugleich stellt. Ist das eine ausgenutzte Schwachstelle oder ein schwerwiegender Produktvorfall? Ist es ein erheblicher Vorfall bei uns als Betreiber? Hat es personenbezogene Daten berührt? Die Antworten schließen einander nicht aus.
- Parallele Entwürfe, nicht sequenzielle. Die 24-Stunden-Warnungen für CRA und NIS2 sollten gemeinsam vorbereitet werden, während die DSGVO-Bewertung daneben läuft, nicht danach.
- Ein Prüfpfad. Wenn eine Behörde fragt, warum ein Bericht ankam, als er ankam, wollen Sie eine einzige Aufzeichnung, die zeigt, was Sie wann wussten, über alle drei Pflichten hinweg.
Über die großen drei hinaus
Dasselbe Muster wiederholt sich in benachbarten Regelwerken. Finanzeinrichtungen unter DORA stehen vor der Meldung schwerwiegender IKT-Vorfälle auf ihrem eigenen gestuften Zeitplan. Telekommunikationsanbieter tragen Meldepflichten unter den ePrivacy-Regeln. Sektorregulierer für Medizinprodukte und Maschinen fügen ihre eigene Produktmeldung hinzu. Die Namen ändern sich, die Struktur nicht. Ein Auslöser, eine kurze Zündschnur für das erste Signal, ein vollständigerer Bericht später, geschuldet einer bestimmten Behörde in einem bestimmten Format.
Wenn Sie die Disziplin einmal aufbauen, rund um eine einzige Quelle der Wahrheit dafür, was passiert ist und wann Sie es wussten, wird jedes neue Regelwerk zu einem weiteren Ergebnis desselben Prozesses statt zu einem weiteren Silo, das zu besetzen ist.
Wo CVD Portal hineinpasst
CVD Portal betreibt bereits den vorderen Teil dieser Pipeline. Eine Schwachstelle trifft über Ihr Portal zur koordinierten Offenlegung ein, wird triagiert und speist den CRA-Artikel-14-Meldeablauf, mit Fristen, die gegen den Moment der Kenntnis verfolgt werden. Die obigen Pflichten sind die natürliche Erweiterung desselben Rückgrats. Ein Ereignis, ein Zeitstempel, eine Triage und ein klarer Blick auf jede Uhr, die es gestartet hat.
Wenn Sie Ihre eigenen Meldepflichten kartieren und sehen wollen, wie der CRA-Teil heute funktioniert, ist das der Teil des Portals, den Sie schon jetzt nutzen können.