Cyber Resilience Act
Sicherheitsvorfall
Legaldefinition Art. 3 Nr. 43 CRA
„einen Sicherheitsvorfall gemäß der Begriffsbestimmung in Artikel 6 Nummer 6 der Richtlinie (EU) 2022/2555“
Der Cyber Resilience Act (CRA) definiert den Sicherheitsvorfall nicht selbst, sondern verweist auf die NIS-2-Richtlinie. Dort heißt es: ein Ereignis, das die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit gespeicherter, übermittelter oder verarbeiteter Daten oder der über Netz- und Informationssysteme angebotenen oder zugänglichen Dienste beeinträchtigt.
Diese Verweistechnik ist Absicht: Sie hält die Begriffe der beiden Rechtsakte deckungsgleich. Wer bereits NIS-2-Prozesse betreibt, arbeitet mit derselben Definition.
Vier Eigenschaften, ein Vorfall
Entscheidend ist, dass die Definition ohne Angreifer auskommt. Beeinträchtigt ist beeinträchtigt. Ob ein Angriff, ein Konfigurationsfehler oder ein Hardwaredefekt dahintersteckt, spielt für die Einordnung keine Rolle.
Das überrascht viele, die „Sicherheitsvorfall“ mit „Angriff“ gleichsetzen. Ein fehlgeschlagenes Update, das ein Gerät unbrauchbar macht, beeinträchtigt die Verfügbarkeit und ist damit begrifflich ein Sicherheitsvorfall.
Die Meldeschwelle liegt höher
Aus der Definition allein folgt noch keine Meldepflicht. Der CRA knüpft die Meldung an einen engeren Begriff: den schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit des Produkts mit digitalen Elementen auswirkt. Damit wirken zwei Filter, nämlich die Schwere und der Produktbezug.
Damit fallen zwei häufige Fälle heraus: der kleine, folgenlose Vorfall und der Vorfall in der eigenen Unternehmens-IT, der das ausgelieferte Produkt nicht berührt. Beide sind zu behandeln, aber nicht nach Artikel 14 zu melden.
Verhältnis zur aktiv ausgenutzten Schwachstelle
Die beiden Meldetatbestände des CRA überschneiden sich, ersetzen einander aber nicht:
- Eine Aktiv ausgenutzte Schwachstelle beschreibt eine Eigenschaft des Produkts, die nachweislich ausgenutzt wurde.
- Ein Sicherheitsvorfall beschreibt ein Ereignis mit Auswirkung auf Daten oder Dienste.
Ein erfolgreicher Angriff über eine Schwachstelle ist beides zugleich. In diesem Fall sind beide Meldewege zu bedienen. Für den Abschlussbericht gelten dabei unterschiedliche Fristen: 14 Tage nach Verfügbarkeit einer Abhilfe bei der Schwachstelle, ein Monat nach der 72-Stunden-Meldung beim Vorfall.
Was das für die Praxis heißt
Weil die Einordnung über Fristen entscheidet, gehört sie vorab geklärt und nicht in den Ernstfall verschoben. Sinnvoll ist eine kurze, schriftliche Entscheidungshilfe: Betrifft es ein ausgeliefertes Produkt? Ist eine der vier Eigenschaften beeinträchtigt? Ist der Vorfall schwerwiegend? Und wer entscheidet das außerhalb der Geschäftszeiten?
Diese vier Fragen im Voraus zu beantworten, kostet eine Stunde. Sie im Ernstfall zu beantworten, kostet einen erheblichen Teil der 24 Stunden.
Fragen aus der Praxis
-
Nur, wenn eine der vier geschützten Eigenschaften betroffen ist. Ein Ausfall beeinträchtigt die Verfügbarkeit und ist damit erfasst, unabhängig davon, ob ein Angriff dahintersteckt. Ein Hardwaredefekt oder ein Fehler beim Einspielen eines Updates kann also ein Sicherheitsvorfall sein. Ob er auch meldepflichtig ist, entscheidet erst die zusätzliche Schwelle.
-
Nein. Meldepflichtig sind nur schwerwiegende Sicherheitsvorfälle, die sich auf die Sicherheit des Produkts mit digitalen Elementen auswirken. Ein Vorfall in Ihrer Büro-IT ohne Bezug zum Produkt löst keine Pflicht nach dem CRA aus. Andere Vorschriften können dennoch greifen, etwa die Datenschutz-Grundverordnung oder NIS 2.
-
Der CRA definiert auch diesen Begriff: ein Ereignis, das einen Sicherheitsvorfall hätte auslösen können, aber erfolgreich verhindert wurde oder nicht eingetreten ist. Beinahe-Vorfälle sind nicht meldepflichtig. Für die eigene Risikobewertung sind sie trotzdem wertvoll, weil sie zeigen, wo Schutzmechanismen gerade noch gegriffen haben.
Dieses Glossar dient der Orientierung und ersetzt keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847.