Compliance-Checkliste zum Cyber Resilience Act (kostenloses Excel)

Diese Compliance-Checkliste zum Cyber Resilience Act verwandelt die Verordnung (EU) 2024/2847 in 24 konkrete Prüfpunkte, die Sie gegen ein einzelnes Produkt laufen lassen können. Es ist eine kostenlose Excel-Datei für Product-Security-Leads, CISOs und Compliance-Manager, die zeigen müssen, dass ihre Produkte mit digitalen Elementen den CRA erfüllen, bevor dessen Pflichten greifen. Sie arbeiten eine Liste ab, die auf die grundlegenden Anforderungen aus Anhang I, die Pflicht zur Software-Stückliste, den koordinierten Prozess zur Behandlung von Schwachstellen und die Meldefristen an die ENISA abbildet, und ersparen sich das erneute Durchlesen der gesamten Verordnung. Jede Zeile beschreibt, wie ein guter Zustand aussieht und wo der Nachweis liegt. Laden Sie die Datei unten herunter, teilen Sie sie mit dem Engineering und nutzen Sie sie als Rückgrat Ihrer CRA-Readiness-Prüfung.

Was die Compliance-Checkliste zum Cyber Resilience Act abdeckt

Die Datei ist ein einzelnes Arbeitsblatt mit 24 Punkten, gruppiert nach den Bereichen, um die es dem CRA tatsächlich geht. Jede Zeile trägt dieselben Spalten: die Anforderung in Klartext, wie ein guter Zustand aussieht, der Nachweis, der ihn belegt, ein Verantwortlicher und ein Statusfeld, das Sie auf Erfüllt, Teilweise oder Lücke setzen können. Diese Struktur macht die Checkliste zugleich zur lebenden Arbeitsliste.

Die 24 Punkte verteilen sich auf fünf Blöcke:

• Grundlegende Cybersicherheitsanforderungen. Die Produkteigenschaften aus Anhang I, von der Secure-by-Default-Konfiguration bis zum Schutz der Vertraulichkeit und Integrität der Daten, die das Produkt verarbeitet.
• Software-Stückliste. Erstellung und Pflege einer maschinenlesbaren SBOM, damit Sie und Ihre Kunden wissen, welche Komponenten im Produkt stecken.
• Behandlung von Schwachstellen. Ein koordinierter Prozess, um Schwachstellen über den gesamten Supportzeitraum zu identifizieren, zu dokumentieren und zu beheben.
• Sicherheitsupdates. Bereitstellung von Updates über den definierten Supportzeitraum, damit bekannte Schwachstellen für die Nutzer tatsächlich behoben werden.
• Meldung. Benachrichtigung der ENISA über aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle innerhalb der vorgegebenen Fristen.

Der EU Cyber Resilience Act ehrlich betrachtet: worauf es wirklich ankommt

Der CRA (Verordnung (EU) 2024/2847) ist ein eigenständiges Produktrecht. Er stellt Cybersicherheitsanforderungen an Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, und seine Pflichten haften am Produkt selbst; die Unterlagen Ihres Unternehmens sind dabei eine getrennte Baustelle. Genau diese Unterscheidung geht in Teams am häufigsten schief: CRA-Kontrollen sind Produkteigenschaften und verlangen deshalb eine eigene Betrachtung neben dem ISMS, das organisatorische Prozesse abdeckt. Ein zertifizierter ISO-27001-Bestand macht ein vernetztes Gerät für sich genommen noch lange nicht konform.

Genau deshalb sollten Sie jedem Mapping gegenüber skeptisch sein, das behauptet, Ihre bestehenden Managementsystem-Kontrollen deckten bereits den Großteil des CRA ab. Diese Abdeckung zu leihen fühlt sich effizient an und erzeugt ein Readiness-Bild, das schlicht falsch ist. Die echte Überlappung sitzt rund um die Behandlung von Schwachstellen und die Meldung von Vorfällen, und überall sonst ist sie dünn.

Fünf Pflichten tragen das Gewicht:

1. Grundlegende Anforderungen. Jedes Produkt muss die grundlegenden Cybersicherheitsanforderungen aus Anhang I erfüllen, also die Basis-Sicherheitseigenschaften, mit denen das Produkt ausgeliefert wird.
2. Sicherheitsupdates. Hersteller müssen über einen definierten Supportzeitraum Sicherheitsupdates bereitstellen, damit Schwachstellen so lange behoben werden, wie das Produkt im Einsatz ist. Das ist die Pflicht mit dem Preisschild. Einen Supportzeitraum festzulegen ist eine kaufmännische Entscheidung im selben Maß wie eine Sicherheitsentscheidung, also gehören die Verantwortlichen für Roadmap und Marge zusammen mit dem Sicherheitsteam in diese Diskussion.
3. SBOM. Sie müssen eine Software-Stückliste erstellen und pflegen, damit die Komponenten im Produkt bekannt und nachverfolgbar sind.
4. Behandlung von Schwachstellen. Ein koordinierter Prozess zur Behandlung von Schwachstellen muss Probleme über denselben Supportzeitraum identifizieren, dokumentieren und beheben.
5. Meldung. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle müssen an die ENISA gemeldet werden.

Nach Schwierigkeit geordnet sind die fünf ungleich verteilt. Die SBOM ist überwiegend ein Tooling-Problem, und eine ordentliche Build-Pipeline bringt Sie in Wochen fast ans Ziel. Die grundlegenden Anforderungen sind ein Engineering-Programm, denn sichere Voreinstellungen und ein funktionierender Update-Mechanismus müssen von Anfang an eingebaut sein, und bei einigen Ihrer Produkte wird das kaum der Fall gewesen sein. Der Prozess zur Behandlung von Schwachstellen ist der Schläfer: leicht aufzuschreiben, schwer über Jahre tatsächlich zu betreiben, über jede unterstützte Version hinweg und mit einem echten Menschen am anderen Ende des Meldekanals.

Der Kalender ist der Teil, den die meisten Pläne unterschätzen. Die Meldepflichten beginnen am 11. September 2026, die Hauptpflichten für Hersteller gelten ab dem 11. Dezember 2027. Rechnen Sie von diesen beiden Terminen zurück, statt den CRA als fernes Problem zu behandeln. Der Meldetermin ist in der Praxis der engere von beiden, weil er zuerst greift und weil der Aufbau von koordinierter Offenlegung, einem überwachten Meldekanal und einer abgestimmten Regel dafür, was als aktiv ausgenutzt zählt, Organisationsarbeit ist, für die mehrere Teams ihr Verhalten ändern müssen. Das dauert länger als das Entwerfen einer Richtlinie. Wenn Sie Tooling abwägen, das diese Arbeit dauerhaft trägt, führt unser Überblick über CRA-Compliance-Software durch die Optionen; alles Weitere auf dieser Seite geht davon aus, dass Sie die Readiness-Arbeit zunächst selbst erledigen.

So verwenden Sie die Compliance-Checkliste zum Cyber Resilience Act

1. Wählen Sie ein Produkt. Der CRA arbeitet Produkt für Produkt, begrenzen Sie die Checkliste also auf ein einzelnes Produkt mit digitalen Elementen, bevor Sie beginnen. Nehmen Sie das Produkt, das einem Release am nächsten steht, statt des scheinbar einfachsten. Sie lernen mehr, wenn Sie die Checkliste gegen etwas mit einer echten Deadline dahinter laufen lassen, und die Lücken, die Sie aufdecken, sind die, die Sie tatsächlich Geld kosten.
2. Benennen Sie Verantwortliche. Geben Sie jeder der 24 Zeilen einen namentlich benannten Verantwortlichen in Engineering, Security oder Produkt. Ohne eine zugeordnete Person bewegt sich nichts.
3. Bewerten Sie jeden Punkt. Markieren Sie jede Zeile als Erfüllt, Teilweise oder Lücke und verlinken Sie den Nachweis daneben: eine Konfigurations-Baseline, die SBOM-Datei, die Richtlinie zur Behandlung von Schwachstellen, den Update-Plan.
4. Schließen Sie die Lücken entlang der Termine. Sequenzieren Sie die Behebung so, dass die Meldung von Schwachstellen und Vorfällen vor dem 11. September 2026 steht und die vollen Herstellerpflichten vor dem 11. Dezember 2027.
5. Wiederholen Sie die Prüfung vor jedem Release. Behandeln Sie die Checkliste als festes Release-Gate und prüfen Sie sie erneut, wann immer sich das Produkt wesentlich ändert.

Automatisieren Sie das in Venvera

Die Excel-Datei ist ein starker Ausgangspunkt, aber ein Spreadsheet veraltet in dem Moment, in dem sich das Produkt ändert. In Venvera leben dieselben 24 Prüfpunkte im CRA-Framework als nachverfolgte Kontrollen mit Verantwortlichen, Fälligkeiten und Nachweisen an jeder einzelnen. Wird Ihre SBOM oder Ihre Richtlinie zur Behandlung von Schwachstellen aktualisiert, spiegelt der Kontrollstatus das wider, während eine Datei, die niemand wieder öffnet, still veraltet. Weil CRA-Produkteigenschaften neben Ihren anderen Pflichten sitzen, lassen sich bereits gesammelte Nachweise dort wiederverwenden, wo sie wirklich zutreffen. Venvera beginnt bei 399 EUR/Monat. Die manuelle Checkliste unten orientiert Sie heute; die Plattform hält die Arbeit danach aktuell.

Häufig gestellte Fragen

Ab wann gilt der EU Cyber Resilience Act?

Der CRA greift gestaffelt zu zwei Schlüsselterminen. Die Meldepflichten beginnen am 11. September 2026, die Hauptpflichten für Hersteller gelten ab dem 11. Dezember 2027. Planen Sie die Bereitschaft für die Meldung von Schwachstellen und Vorfällen gegen den früheren Termin, denn ab dann werden Benachrichtigungen an die ENISA fällig.

Ersetzt der CRA ISO 27001 oder mein ISMS?

Nein. CRA-Kontrollen sind Produkteigenschaften und verlangen eine eigene Betrachtung neben dem ISMS, das organisatorische Prozesse steuert. Ein ISO-27001-Zertifikat beschreibt, wie Ihre Organisation Sicherheit managt; der CRA fragt, ob ein konkretes Produkt die grundlegenden Anforderungen aus Anhang I erfüllt, eine SBOM mitliefert und einen funktionierenden Prozess zur Behandlung von Schwachstellen hat.

Was ist eine SBOM und warum verlangt der CRA eine?

Eine Software-Stückliste ist ein maschinenlesbares Inventar der Komponenten in Ihrem Produkt. Der CRA verpflichtet Hersteller, eine zu erstellen und zu pflegen, damit Schwachstellen in Drittkomponenten über den Supportzeitraum gefunden und behoben werden können, statt unsichtbar zu bleiben, bis sie ausgenutzt werden.

Wer muss den Cyber Resilience Act einhalten?

Hersteller, die Produkte mit digitalen Elementen auf dem EU-Markt bereitstellen. Sie müssen die grundlegenden Anforderungen aus Anhang I erfüllen, über einen Supportzeitraum Sicherheitsupdates bereitstellen, eine SBOM erstellen und pflegen, einen koordinierten Prozess zur Behandlung von Schwachstellen betreiben und aktiv ausgenutzte Schwachstellen sowie schwerwiegende Vorfälle an die ENISA melden.