Die CRA-Risikobewertung (Art. 13): das Dokument, das festlegt, welche Anforderungen gelten

Problem

Viele sehen die Risikobewertung als Pflichtübung am Rand. Im CRA (Cyber Resilience Act, die EU-Verordnung zur Cybersicherheit von Produkten mit digitalen Elementen) ist sie das Gegenteil: Artikel 13 macht die dokumentierte Cybersicherheits-Risikobewertung zum Dreh- und Angelpunkt. Sie entscheidet, ob und wie die einzelnen Sicherheitsvorgaben aus Anhang I Teil I Nr. 2 (Buchstaben a bis m) - die Liste der wesentlichen Produktanforderungen des Gesetzes - für ein konkretes Produkt gelten. Lassen Sie eine Anforderung weg, ist das in der technischen Dokumentation zu begründen. Ohne saubere Bewertung lässt sich später nicht belegen, warum - eine Lücke genau dort, wo die Marktaufsicht zuerst hinschaut.

Für wen ist das? Für Hersteller, die ihre CRA-Risikobewertung dokumentieren müssen.

Kurze Antwort

Dernium CRA führt die Risikobewertung strukturiert statt formlos. Im Kern:

• Sie pflegen den vom Gesetz geforderten Mindestinhalt: Verwendungszweck, vernünftigerweise vorhersehbare Nutzung und Fehlgebrauch, Einsatzbedingungen und erwartete Lebensdauer.
• Sie entscheiden je Anforderung aus Teil I Nr. 2 über die Anwendbarkeit (mit Umsetzungshinweis oder, bei "nicht anwendbar", erzwungener Begründung).
• Sie führen ein Risiko-Register, also eine Liste aller Risiken mit Eintrittswahrscheinlichkeit, Auswirkung, Maßnahme und Restrisiko.
• Das Ergebnis fließt automatisch in die technische Dokumentation (Anhang VII Nr. 3) - keine Doppelpflege.
• Eine Methodik schreibt der CRA nicht vor; verpflichtend ist der Inhalt. Dernium gibt keine Bewertung ab; Inhalt und Verantwortung bleiben bei Ihnen.

Tiefgang

Die Bewertung steuert die Anwendbarkeit. Artikel 13 Abs. 3 sagt es deutlich: die Risikobewertung gibt an, ob und wie die Anforderungen aus Anhang I Teil I Nr. 2 gelten und umgesetzt werden. Das Werkzeug bildet das als Tabelle der dreizehn Anforderungen (a bis m) ab - je mit Häkchen "anwendbar" und Feld für Umsetzung oder Begründung.

"Nicht anwendbar" ohne Begründung gibt es nicht. Artikel 13 Abs. 4 verlangt für jede weggelassene Anforderung eine klare Begründung in der technischen Dokumentation. Das Werkzeug erzwingt sie: ohne Begründungstext lässt sich eine als nicht anwendbar markierte Anforderung nicht speichern. So entsteht die Lücke gar nicht erst.

Was nicht abwählbar ist, ist auch nicht abwählbar. Nur die Produkteigenschaften aus Teil I Nr. 2 sind risikoabhängig. Die allgemeine Sicherheitsanforderung (Teil I Nr. 1) und die gesamte Schwachstellenbehandlung (Teil II) gelten immer - sie erscheinen daher nicht als abwählbare Punkte, sondern als Felder für Ihre Umsetzung (mit Verweis auf SBOM, also die Software-Stückliste mit allen verbauten Bausteinen, Offenlegungs-Richtlinie und Update-Mechanismus).

Ein Risiko-Register, das den Namen verdient. Je Risiko: Angriffsweg, betroffene Anforderung, Eintrittswahrscheinlichkeit und Auswirkung (woraus sich die Einstufung ergibt), Maßnahme, Restrisiko und Status - die wiedererkennbare Form einer Risikoanalyse, bewusst ohne erzwungene Methodik, weil der CRA keine vorschreibt.

Eine Quelle, ein Dokument. Sobald die Bewertung ausgefüllt ist, übernimmt der Generator der technischen Dokumentation sie als Abschnitt "Cybersicherheits-Risikobewertung" (Anhang VII Nr. 3) - keine Doppelpflege. Ohne strukturierte Bewertung bleibt das Freitextfeld als Rückfallebene.

Abgelehnte Alternativen

• Freitext-Risikobewertung. Erfüllt den Inhalt vielleicht, erzwingt aber weder die Begründung nicht anwendbarer Anforderungen noch die Verbindung zu den Anhang-I-Punkten.
• Eine Methodik vorschreiben. Der CRA tut es nicht; eine erzwungene ISO- oder IEC-Schablone (Normen-Vorlagen internationaler Standardisierungsgremien) wäre Mehraufwand ohne Rechtsgrund. Wir führen den Pflichtinhalt, die Methodik bleibt offen.
• Teil II abwählbar machen. Rechtlich falsch - die Schwachstellenbehandlung ist nicht risikoabhängig wegzulassen.
• Bewertung getrennt von der technischen Doku halten. Doppelpflege driftet; deshalb fließt sie direkt in Anhang VII Nr. 3.

Was Sie jetzt tun sollten

1. Legen Sie je Produkt den Mindestinhalt fest: Verwendungszweck, vorhersehbare Nutzung und Fehlgebrauch, Einsatzbedingungen, erwartete Lebensdauer. Das ist die Grundlage jeder weiteren Entscheidung.
2. Gehen Sie die dreizehn Anforderungen aus Anhang I Teil I Nr. 2 (a bis m) einzeln durch und entscheiden Sie je: anwendbar mit Umsetzungshinweis oder nicht anwendbar mit dokumentierter Begründung.
3. Behandeln Sie die allgemeine Sicherheitsanforderung (Teil I Nr. 1) und die Schwachstellenbehandlung (Teil II) als gesetzt - hier ist nicht das Ob, sondern nur das Wie zu beschreiben.
4. Bauen Sie ein Risiko-Register auf: je Risiko Angriffsweg, betroffene Anforderung, Eintrittswahrscheinlichkeit, Auswirkung, Maßnahme, Restrisiko und Status.
5. Lassen Sie das Ergebnis in die technische Dokumentation (Anhang VII Nr. 3) übernehmen und schreiben Sie die Bewertung bei Produktänderungen oder neuen Bedrohungen fort.

Wie Dernium hilft

Sie führen die Risikobewertung an einer Stelle und sehen je Anforderung sofort, was zu begründen ist. Eine Erklärschicht benennt den gesetzlichen Mindestinhalt und trennt, was wir strukturieren und übernehmen, von dem, was Sie als Hersteller inhaltlich verantworten. So wird aus der Pflichtübung ein geführter, nachweisbarer Schritt.

Offene Punkte

• Die Risikobewertung ist laufend zu aktualisieren (Art. 13 Abs. 3: dokumentiert und während des Support-Zeitraums fortzuschreiben). Das Werkzeug hält den Stand; die inhaltliche Aktualität bei Produktänderungen oder neuen Bedrohungen bleibt Ihre Aufgabe.
• Die inhaltliche Richtigkeit der Bewertung und Begründungen verantworten Sie. Das Werkzeug strukturiert und erinnert; es bewertet nicht und ist keine Rechtsberatung.

Häufige Fragen

Schreibt der CRA eine bestimmte Methodik für die Risikobewertung vor?

Nein. Der CRA verpflichtet zum Inhalt, nicht zu einer bestimmten Methode. Sie dürfen eine etablierte Schablone (etwa eine ISO- oder IEC-Norm) nutzen, müssen es aber nicht. Verpflichtend sind der Mindestinhalt, die Entscheidung über die Anwendbarkeit je Anforderung und die Begründung weggelassener Anforderungen.

Welche Anforderungen darf ich überhaupt als nicht anwendbar einstufen?

Nur die risikoabhängigen Produkteigenschaften aus Anhang I Teil I Nr. 2 (Buchstaben a bis m). Die allgemeine Sicherheitsanforderung aus Teil I Nr. 1 und die gesamte Schwachstellenbehandlung aus Teil II gelten immer und lassen sich nicht abwählen - hier beschreiben Sie nur die Umsetzung.

Was passiert, wenn ich eine Anforderung ohne Begründung weglasse?

Dann fehlt genau der Nachweis, den Artikel 13 Abs. 4 in der technischen Dokumentation verlangt - und das ist die Stelle, an der die Marktaufsicht zuerst nachsieht. Im Werkzeug entsteht diese Lücke gar nicht erst: Eine als nicht anwendbar markierte Anforderung lässt sich ohne Begründungstext nicht speichern.

Muss ich die Risikobewertung nach der ersten Erstellung weiter pflegen?

Ja. Artikel 13 Abs. 3 verlangt, dass die Bewertung dokumentiert und während des Support-Zeitraums fortgeschrieben wird. Bei Produktänderungen oder neuen Bedrohungen ist sie zu aktualisieren. Das Werkzeug hält den jeweiligen Stand fest, die inhaltliche Aktualität bleibt aber Ihre Aufgabe als Hersteller.

Übernimmt Dernium die Risikobewertung oder eine rechtliche Einschätzung für mich?

Nein. Dernium strukturiert den Vorgang, erinnert an Pflichtinhalte und übernimmt das Ergebnis in die technische Dokumentation. Die inhaltliche Bewertung, die Begründungen und deren Richtigkeit verantworten Sie als Hersteller. Das Werkzeug bewertet nicht und ersetzt keine Rechtsberatung.

Verifikation

Die Pflicht zur Risikobewertung steht in Artikel 13 (Abs. 2 bis 4): sie ist zu dokumentieren und fortzuschreiben, bestimmt die Anwendbarkeit der Anforderungen aus Anhang I Teil I Nr. 2 und verlangt eine Begründung für nicht anwendbare Anforderungen. Anhang VII Nr. 3 schreibt die Aufnahme in die technische Dokumentation vor.

Mehr aus unserer CRA-Reihe

• Cyber Resilience Act: Überblick für Softwarehersteller
• SBOM und Sigstore: Herkunftsnachweis für Software-Artefakte
• CRA-Meldepflicht: Schwachstellen und Vorfälle an CSIRT und ENISA (ab 2026)
• CRA-Konformitätsnachweise: Anhang V/VII und CE (ab 2027)
• Coordinated Vulnerability Disclosure: Policy, security.txt und CSAF
• DoC- und Tech-Doc-Generator: Anhang V/VII als PDF
• Schwachstellen über den Support-Zeitraum behandeln: Fristen-Uhr und Behebungs-Lebenslauf
• Konformitätsbewertung nach CRA: welcher Pfad für welches Produkt (Art. 32)
• CRA Anhang II: Nutzerinformationen und Anleitungen als PDF
• Drittkomponenten nach CRA: Sorgfaltspflicht für Fremd- und Open-Source-Bausteine (Art. 13 Abs. 5)
• CRA-Readiness auf einen Blick: das Dashboard über alle Bausteine
• Wesentliche Veränderung nach CRA: wann eine neue Version neu bewertet werden muss (Art. 3 Nr. 30)
• Die notifizierte Stelle nach CRA: wann eine Dritt-Prüfung nötig ist und was sie braucht (Art. 32)
• Dernium CRA: ein Werkzeug für den gesamten Cyber Resilience Act