CRA-Cybersicherheits-Risikobewertung: Leitfaden und Vorlage

Jeder Hersteller eines Produkts mit digitalen Elementen im Anwendungsbereich des CRA muss eine Cybersicherheits-Risikobewertung durchführen und schriftlich festhalten. Diese Risikoanalyse entscheidet, welche CRA-Sicherheitsanforderungen für Ihr konkretes Produkt gelten und wie Sie sie erfüllen. Marktüberwachungsbehörden können sie anfordern. Ohne sie ist Ihre technische Dokumentation unvollständig, und Ihre Konformitätsaussage steht auf keinem Fundament.

Dieser Leitfaden erklärt, wie Sie die Bewertung durchführen, dokumentieren und aktuell halten. Er enthält eine vollständige Zuordnung der Sicherheitsanforderungen, ein durchgerechnetes Beispiel und eine kopierbare Dokumentvorlage.

Was ist die CRA-Cybersicherheits-Risikobewertung?

Die Cybersicherheits-Risikobewertung ist eine dokumentierte Analyse der Risiken, denen Ihr Produkt ausgesetzt ist, ausgehend von seiner Zweckbestimmung und der Art, wie Nutzer es vernünftigerweise verwenden. Sie deckt die Einsatzbedingungen ab, etwa die Betriebsumgebung und die Werte, die das Produkt schützen muss, und berücksichtigt, wie lange das Produkt voraussichtlich im Einsatz bleibt.

Die Bewertung hat ein zentrales Ergebnis, von dem alles andere abhängt. Sie legt für jede CRA-Produktsicherheitsanforderung fest, ob diese für Ihr Produkt gilt, und wenn ja, wie Ihr Design und Ihre Prozesse sie umsetzen. Zusätzlich hält sie fest, wie Sie das Secure-by-Design-Grundniveau erfüllen und wie Ihre Prozesse zur Schwachstellenbehandlung das Produkt abdecken.

Drei Eigenschaften unterscheiden sie von einem allgemeinen unternehmensweiten Risikoregister:

• Sie ist produktspezifisch. Verankert in der Architektur, den Schnittstellen und den Nutzern genau dieses Produkts. Ein unternehmensweites ISMS-Risikoregister genügt dafür nicht. Unser ISO-27001-Vergleich geht auf diese Lücke im Detail ein.
• Sie ist ein Lebenszyklus-Dokument. Sie nutzen sie während Planung und Konzeption, nicht erst zur Veröffentlichung, und aktualisieren sie über den gesamten Supportzeitraum.
• Sie ist Nachweis. Die dokumentierte Bewertung gehört in Ihre technische Dokumentation, wo Behörden sie anfordern können.

Wer braucht sie, und wann

Jeder Hersteller, der ein Produkt mit digitalen Elementen auf dem Unionsmarkt in Verkehr bringt, braucht eine Risikobewertung, es sei denn, das Produkt liegt vollständig außerhalb des CRA. Im Anwendungsbereich: Hardware mit Firmware, eigenständige Software und Produkte, bei denen Datenfernverarbeitung Teil des Angebots ist. Die Pflicht gilt für ein Ein-Personen-Softwareunternehmen genauso wie für einen Konzern. Vom CRA ausgenommene Produkte, etwa erfasste Medizinprodukte, bestimmte Fahrzeuge und zertifizierte Luftfahrtausrüstung, folgen stattdessen ihren eigenen Sektorregeln. Sind Sie unsicher, ob der CRA Ihr Produkt überhaupt erfasst, beginnen Sie mit dem Leitfaden zum Anwendungsbereich.

Das Timing zählt mehr, als die meisten Teams erwarten:

• In der Planungsphase beginnen. Die Bewertung soll Designentscheidungen lenken. Führen Sie einen ersten Durchlauf durch, solange sich die Architektur noch günstig ändern lässt.
• Vor dem Inverkehrbringen abschließen und dokumentieren. Die schriftliche Bewertung muss in der technischen Dokumentation liegen, wenn das Produkt ausgeliefert wird.
• Über den Supportzeitraum pflegen. Die Bewertung ist nie abgeschlossen. Sie begleitet das Produkt, solange Sie Sicherheitsupdates schulden.

Es gibt eine eng begrenzte Vereinfachung. Sie betrifft nur Produkte, die der CRA als Hochrisiko-KI-Systeme einstuft und die zugleich anderen EU-Vorschriften unterliegen, die eine Risikobewertung verlangen. Für diese darf die Cybersicherheitsbewertung Teil jener anderen Risikobewertung werden, statt ein eigenständiges Dokument zu bleiben. Die inhaltlichen Pflichten bleiben gleich. Wie das in der Praxis funktioniert, zeigt der Leitfaden zur Überschneidung mit dem AI Act.

Was die Bewertung enthalten muss

Der CRA legt ein inhaltliches Minimum fest. Ihre Bewertung muss drei Dinge abdecken:

• Das Produkt im Kontext. Wozu das Produkt dient, wie Nutzer es vernünftigerweise verwenden, in welcher Umgebung es läuft, welche Werte es schützen muss und wie lange es voraussichtlich im Einsatz bleibt.
• Anwendbarkeitsentscheidungen. Für jede der 13 Produktsicherheitsanforderungen: Gilt sie für dieses Produkt, und wie wird sie umgesetzt. Trifft eine nicht zu, eine klare schriftliche Begründung.
• Prozessabdeckung. Wie das Secure-by-Design-Grundniveau erfüllt wird und wie Ihre Prozesse zur Schwachstellenbehandlung das Produkt abdecken.

Die Begründungspflicht verdient besondere Aufmerksamkeit. „Nicht anwendbar“ ohne Grund ist ein Mangel. Benennen Sie die Produkteigenschaften, die die Anforderung entfallen lassen, und halten Sie sie schriftlich fest. Die schriftliche Begründung gehört zusammen mit dem Rest der Bewertung in die technische Dokumentation.

Über dieses gesetzliche Minimum hinaus lohnen sich Kontrollen, die das Dokument belastbar machen: Behandlungsentscheidungen mit dem verbleibenden Risiko, Akzeptanzkriterien, eine namentliche Freigabe mit Datum und eine Versionshistorie. Der CRA schreibt keine davon vor. Sie zeigen, dass die Bewertung aktuell geblieben ist und dass jemand Verantwortliches das Restrisiko akzeptiert hat.

Methode wählen

Der CRA schreibt keine Bewertungsmethodik, Bewertungsskala oder Vorlage vor. Verlangt wird ein dokumentiertes Ergebnis, das die Anwendbarkeitsentscheidungen stützt. Wählen Sie eine Methode, die Ihr Team wiederholen kann, und beschreiben Sie sie in der Bewertung, damit eine prüfende Person Ihre Argumentation nachvollziehen kann.

Eine Regel gilt unabhängig von der gewählten Methode. Drücken Sie jedes Risiko als Kombination aus seiner Wahrscheinlichkeit und dem Ausmaß des Verlusts oder der Störung aus, die es verursachen könnte. Der CRA fasst Cybersicherheitsrisiko genau in diesen zwei Dimensionen. Eine Bedrohungsliste, die keine von beiden bewertet, ist noch keine Bewertung.

Gängige, praxistaugliche Optionen:

Methode	Was sie liefert	Passt am besten zu
Wahrscheinlichkeit-mal-Auswirkung-Matrix	Einfache numerische Risikobewertungen und ein priorisiertes Register	Kleine Teams, erste Bewertungen
STRIDE-Bedrohungsmodellierung	Systematische Bedrohungsidentifikation pro Komponente und Datenfluss	Softwarelastige Produkte mit klaren Architekturdiagrammen
Verfahren nach ISO/IEC 27005	Ein vollständiger Risikomanagementzyklus mit Kontext, Analyse und Behandlung	Organisationen, die bereits ein ISMS betreiben
IEC-62443-Bedrohungs-Risiko-Ansatz	Zonen- und Kanal-Analyse für industrielle Kontexte	Industrie- und OT-Produkte, siehe den Leitfaden zur industriellen Automatisierung

Die kommenden harmonisierten Normen ändern nichts an der freien Methodenwahl. Die Entwurfsnorm für den europäischen Rahmen zum CRA-Risikomanagement ist selbst methodenneutral: Sie baut auf dem Risikoprozess nach ISO 31000 auf, ohne ein Bewertungsmodell vorzuschreiben. Unser Tracker für harmonisierte Normen verfolgt ihren Fortschritt. Und Normen ersetzen die Bewertung nie: Selbst ein Produkt, das harmonisierte Normen vollständig anwendet, braucht eine eigene dokumentierte Bewertung, und Sie müssen prüfen, ob die Normen die Risiken abdecken, die Sie tatsächlich identifiziert haben.

Für welche Methode Sie sich auch entscheiden, halten Sie zwei Regeln ein:

1. Die Methode muss Anwendbarkeitsantworten liefern. Ein Stapel bewerteter Risiken reicht nicht. Das Ergebnis muss sich den 13 Sicherheitsanforderungen unten zuordnen lassen.
2. Die Methode schriftlich festhalten. Skalendefinitionen, Formel, Akzeptanzschwellen. Eine Bewertung „12 (Hoch)“ bedeutet nichts, wenn die Skala nicht dokumentiert ist. Die Aufzeichnung sollte es einer Marktüberwachungsbehörde ermöglichen, nachzuvollziehen, wie jedes Risiko identifiziert, bewertet und behandelt wurde.

Die Bewertung, Schritt für Schritt

Ein praxistaugliches Verfahren in sieben Schritten. Passen Sie die Tiefe an Komplexität und Risiko Ihres Produkts an.

Schritt 1: Anwendungsbereich und Kontext festlegen

Halten Sie Produktname und -version, die Zweckbestimmung, die Einsatzumgebungen und die Nutzer fest. Legen Sie fest, was im Anwendungsbereich liegt, einschließlich Begleit-Apps, Cloud-Backends, die Teil des Angebots sind, und mitgelieferter Komponenten. Legen Sie außerdem fest, was außerhalb liegt und warum.

Schritt 2: Werte identifizieren

Listen Sie auf, was das Produkt schützen muss. Typische Werte sind Nutzerdaten, Zugangsdaten und Schlüssel, die Integrität von Firmware und Konfiguration, die Verfügbarkeit der Produktfunktion und das umgebende Netz. Vermerken Sie, wo jeder Wert liegt und wie er sich bewegt.

Schritt 3: Bedrohungen identifizieren

Arbeiten Sie Ihre Architektur Fläche für Fläche durch. Zuerst die externen Schnittstellen, denn dort setzen Angreifer an. Fragen Sie sich für jede Schnittstelle und jeden Datenfluss, was ein Angreifer tun könnte: abfangen, fälschen, manipulieren, überlasten, extrahieren. Beziehen Sie vorhersehbaren Fehlgebrauch des Produkts mit ein, nicht nur vorsätzliche Angriffe. Halten Sie jede plausible Bedrohung mit der Schwachstelle fest, die sie ausnutzen würde.

Schritt 4: Risiken bewerten

Bewerten Sie Wahrscheinlichkeit und Auswirkung für jede Bedrohung anhand Ihrer dokumentierten Skala. Wo ein Sicherheitsvorfall körperliche Schäden verursachen könnte, beziehen Sie die Auswirkung auf Gesundheit und Sicherheit der Nutzer in die Auswirkungsbewertung ein. Ordnen Sie die Ergebnisse nach Rang. Der Sinn der Bewertung ist Priorisierung, nicht Präzision. Eine belastbare Rangfolge, die Designentscheidungen antreibt, schlägt eine präzise wirkende Tabelle, die niemand nutzt.

Schritt 5: Anwendbarkeit der Sicherheitsanforderungen entscheiden

Gehen Sie die 13 Produktsicherheitsanforderungen einzeln durch. Legen Sie für jede fest, ob sie für dieses Produkt gilt, welche der von Ihnen identifizierten Risiken sie abdeckt und wie Sie sie umsetzen. Trifft eine wirklich nicht zu, schreiben Sie die Begründung auf. Die vollständige Zuordnungstabelle weiter unten ist Ihr Arbeitsblatt.

Schritt 6: Risiken behandeln und Restrisiken festhalten

Halten Sie für jedes wesentliche Risiko die gewählte Kontrolle, ihren Umsetzungsort und das nach der Kontrolle verbleibende Risiko fest. Definieren Sie Akzeptanzkriterien und dokumentieren Sie, wer das verbleibende Risiko akzeptiert hat. Risiken ohne Kontrolle brauchen eine ausdrückliche, verantwortete Akzeptanzentscheidung.

Schritt 7: Freigeben und Pflegeauslöser festlegen

Lassen Sie die Bewertung von einer namentlich benannten verantwortlichen Person mit Datum freigeben. Legen Sie dann die Ereignisse fest, die sie erneut öffnen: neue Schwachstelleninformationen, neue Funktionen, Komponenten- oder Lieferantenänderungen, Erkenntnisse aus Sicherheitsvorfällen. Fügen Sie eine Versionshistorien-Tabelle hinzu, damit Behörden sehen, dass das Dokument gelebt hat.

Zuordnung der 13 Sicherheitsanforderungen

Das ist das Herzstück der Bewertung. Der CRA listet 13 Produktsicherheitsanforderungen auf, und Ihr Dokument muss für jede zwei Fragen beantworten: Gilt sie, und wie setzen Sie sie um. Die folgende Tabelle übersetzt jede Anforderung in Prüffragen und typische Nachweise.

Die Spalte Anforderung bleibt nah am Gesetzeswortlaut. Die Spalte Kontrollen ist nicht Teil des Gesetzestexts, sie listet die Maßnahmen und Nachweise, mit denen Teams die Erfüllung typischerweise zeigen.

Zwei praktische Hinweise zur Nutzung der Tabelle:

• „Soweit anwendbar“ ist eine Entscheidung je Produkt, die Sie begründen müssen. Die Anforderungen gelten auf Grundlage Ihrer Risikobewertung. Ein eigenständiges Software-Tool ohne gespeicherte Daten und Einstellungen kann den Ausschluss der Datenentfernungs-Anforderung begründen. Kein Produkt kann die Update-Fähigkeit ausschließen, nur weil Updates unbequem sind.
• Die Zuordnung dient zugleich als Index Ihrer Konformitätsnachweise. Die Kontrollen-Spalte jeder Zeile zeigt, was in die technische Dokumentation gehört, und genau dieses Material prüft eine Konformitätsbewertung.

Die Prozesse zur Schwachstellenbehandlung abdecken

Die Bewertung muss außerdem festhalten, wie Ihre laufenden Prozesse das Produkt abdecken. Die Prozessanforderungen des CRA sind die operative Seite derselben Medaille. Ihre Bewertung sollte kurz und mit Verweisen auf die jeweils zuständigen Dokumente bestätigen, dass Sie für dieses Produkt:

• Schwachstellen und Komponenten identifizieren und dokumentieren, einschließlich einer SBOM, die mindestens die obersten Abhängigkeiten abdeckt
• Schwachstellen ohne Verzögerung angehen und beheben, wobei Sicherheitsupdates getrennt von Funktionsupdates ausgeliefert werden, soweit technisch machbar
• wirksame und regelmäßige Tests und Überprüfungen der Produktsicherheit durchführen
• sobald ein Update verfügbar ist, die behobene Schwachstelle öffentlich offenlegen, mit Beschreibung, betroffenen Produkten, Auswirkungen, Schweregrad und Hilfestellung zur Behebung. Eine begründete Verzögerung ist zulässig, wenn die Sicherheitsrisiken der Veröffentlichung den Nutzen überwiegen, und nur so lange, bis Nutzer die Möglichkeit hatten, den Patch anzuwenden
• eine Richtlinie zur koordinierten Offenlegung von Schwachstellen betreiben
• eine Kontaktadresse für Schwachstellenmeldungen bereitstellen und dafür sorgen, dass Informationen zu möglichen Schwachstellen fließen, auch für Komponenten Dritter
• Updates über sichere Mechanismen verteilen, damit Fixes zeitnah ankommen, automatisch, soweit das für Sicherheitsupdates zutrifft
• Sicherheitsupdates ohne Verzögerung und kostenlos verbreiten, mit Advisory-Mitteilungen, die Nutzern sagen, was zu tun ist. Bei einem maßgeschneiderten Produkt kann ein gewerblicher Kunde nur beim Punkt der Kostenlosigkeit anders vereinbaren

Diese Punkte sind Arbeitszusammenfassungen, nicht der vollständige Gesetzeswortlaut. Halten Sie diesen Abschnitt in Ihrer Bewertung kurz, verlinken Sie auf die zuständigen Prozessdokumente, und prüfen Sie die vollständigen Anforderungen in unserem Leitfaden zur Schwachstellenbehandlung.

Durchgerechnetes Beispiel

Die folgenden Auszüge zeigen den Detailgrad, der sich in der Praxis bewährt. Das Produkt ist ein fiktiver vernetzter Umweltsensor mit Begleit-App und Cloud-Dashboard.

Auszug aus dem Risikoregister

CYBERSICHERHEITS-RISIKOBEWERTUNG

Produkt: SmartSense Pro (SSP-3000)
Version: 2.4.1
Datum der Bewertung: Januar 2027
Verantwortlich: [Name, Security-Team]

METHODE:
Wahrscheinlichkeit x Auswirkung, Skalen definiert in Abschnitt 1.
Risiko = Wahrscheinlichkeit (1-5) x Auswirkung (1-5)
Stufen: Niedrig (1-4), Mittel (5-9), Hoch (10-16), Kritisch (17-25)

-------------------------------------------------------------
RISIKO-ID: R-001
BEDROHUNG: Unbefugte Änderung der Firmware
SCHWACHSTELLE: Unsignierte Firmware könnte installiert werden
AUSWIRKUNG: 5 - Kompromittierung des Geräts, Datenschutzverletzung
WAHRSCHEINLICHKEIT: 3 - Erfordert physischen oder lokalen Netzzugriff
INHÄRENTES RISIKO: 15 (Hoch)

KONTROLLE: Verifikation der Firmware-Signatur
UMSETZUNG: ECDSA-P-256-Signatur wird vor der Installation geprüft
RESTRISIKO: 3 (Niedrig) - Kryptografischer Angriff unwahrscheinlich
STATUS: Mitigiert
-------------------------------------------------------------
RISIKO-ID: R-002
BEDROHUNG: Abfangen der Cloud-Kommunikation
SCHWACHSTELLE: Netzwerkverkehr bei der Übertragung lesbar
AUSWIRKUNG: 4 - Offenlegung von Daten, Befehlsinjektion
WAHRSCHEINLICHKEIT: 3 - Gemeinsam genutzte und öffentliche Netze zu erwarten
INHÄRENTES RISIKO: 12 (Hoch)

KONTROLLE: TLS 1.3 mit Certificate Pinning
UMSETZUNG: Fest hinterlegtes CA-Zertifikat, kein Fallback
RESTRISIKO: 2 (Niedrig) - Kompromittierung des Zertifikats unwahrscheinlich
STATUS: Mitigiert
-------------------------------------------------------------
[Fortsetzung für alle identifizierten Risiken...]

RISIKOÜBERSICHT:
Identifizierte Risiken insgesamt: 23
Kritisch: 0
Hoch: 3 (alle auf Niedrig oder Mittel mitigiert)
Mittel: 8 (alle auf Niedrig mitigiert)
Niedrig: 12 (akzeptiert oder mitigiert)

AKZEPTANZ DES RESTRISIKOS:
Alle Restrisiken innerhalb der in Abschnitt 1 definierten Toleranz.
Akzeptiert von: [Security Lead], [Datum]

Auszug aus der Anwendbarkeitsaufzeichnung

ANWENDBARKEIT DER SICHERHEITSANFORDERUNGEN

ANF. 3 - SICHERHEITSUPDATES
Gilt: JA
Abgedeckte Risiken: R-004, R-011
Umsetzung: Signierte OTA-Updates. Automatische Sicherheitsupdates
standardmäßig aktiviert, Opt-out und Aufschiebung in den App-Einstellungen.
Nutzer werden in der App und per E-Mail benachrichtigt.
Nachweis: Update-Mechanismus-Design UMD-002

ANF. 12 - LOGGING UND ÜBERWACHUNG
Gilt: JA
Abgedeckte Risiken: R-009
Umsetzung: Sicherheitsrelevante Ereignisse (Anmeldefehler, Konfigurationsänderungen,
Update-Ereignisse) werden auf dem Gerät erfasst und an die Cloud weitergeleitet.
Opt-out für das Logging in den Datenschutzeinstellungen verfügbar.
Nachweis: Logging-Design LD-001, Ereigniskatalog

ANF. 13 - SICHERE DATENENTFERNUNG
Gilt: JA
Abgedeckte Risiken: R-015
Umsetzung: Der Werksreset löscht dauerhaft alle gespeicherten
Daten und Einstellungen, einschließlich Netzwerk-Zugangsdaten. Das Gerät
hält keine übertragbaren Nutzerdaten, daher besteht kein Übertragungspfad.
Nachweis: Reset- und Löschdesign RD-001

[Fortsetzung für alle 13 Anforderungen...]

Beachten Sie den Eintrag zur Datenentfernung: Die Anforderung deckt alle Daten und Einstellungen ab, gespeicherte Netzwerk-Zugangsdaten zählen dazu. Trifft eine Anforderung tatsächlich nicht zu, behält der Eintrag dieselbe Form, benennt aber die Produkteigenschaften, die sie entfallen lassen. Ein eigenständiges Software-Tool ohne gespeicherte Daten und Einstellungen könnte festhalten: „Nicht anwendbar. Das Produkt hält keine Daten und keine Einstellungen. Es gibt nichts zu entfernen.“ Genau dieser Tatsachensatz ist das, was eine Behörde bewerten kann.

Dokumentvorlage

Eine Struktur, die Sie für die schriftliche Bewertung übernehmen können:

CYBERSICHERHEITS-RISIKOBEWERTUNG - [Produkt, Version]

1. METHODE
   Skalen, Formel, Risikostufen, Akzeptanzschwellen

2. PRODUKTKONTEXT
   Zweckbestimmung / Vorhersehbare Nutzung und Fehlgebrauch
   Betriebsumgebung / Nutzer
   Zu schützende Werte
   Erwartete Nutzungsdauer
   Anwendungsbereich: enthaltene Komponenten, Ausschlüsse mit Begründung

3. ARCHITEKTUR UND ANGRIFFSFLÄCHE
   Schnittstellen, Datenflüsse, Vertrauensgrenzen
   (Diagrammverweis)

4. RISIKOREGISTER
   Ein Eintrag je plausible Bedrohung, bewertet, mit Kontrolle,
   Restrisiko und Status

5. ANWENDBARKEIT DER SICHERHEITSANFORDERUNGEN
   Ein Eintrag je Anforderung (alle 13), gilt ja/nein,
   Umsetzung, Nachweisverweis, Begründung bei
   Nichtanwendbarkeit

6. SECURE-BY-DESIGN-GRUNDNIVEAU UND PROZESSABDECKUNG
   Wie das Gesamtsicherheitsniveau des Produkts zu seinen
   Risiken passt, Verweise auf Prozesse zur Schwachstellenbehandlung

7. RESTRISIKO UND AKZEPTANZ
   Zusammenfassung, Akzeptanzkriterien, namentliche Akzeptanz

8. FREIGABE UND PFLEGE
   Verantwortlich, Freigabedatum
   Aktualisierungsauslöser
   Versionshistorien-Tabelle

Aktuell halten

Die Bewertung ist ein lebendes Dokument für den gesamten Supportzeitraum. Öffnen Sie sie erneut, wenn:

• neue Schwachstelleninformationen eintreffen, für das Produkt oder seine Komponenten, aus eigener Überwachung, Forschungsmeldungen oder Lieferanten-Advisories
• sich das Produkt ändert, und immer, wenn eine Änderung wesentlich genug ist, um eine neue Konformitätsbewertung zu erfordern
• sich Komponenten ändern, einschließlich neuer Lieferanten und Versionen von Komponenten Dritter oder Open-Source-Komponenten
• ein Sicherheitsvorfall etwas zeigt, das Ihre Bewertungen nicht vorhergesehen haben

Erfassen Sie jede Überarbeitung in der Historientabelle, mit dem, was sich geändert hat und warum. Eine Bewertung, die einmal vor drei Jahren datiert wurde, signalisiert einer Marktüberwachungsbehörde, dass das Dokument dekorativ ist.

Eine Konsistenzpflicht wird leicht übersehen. Ihre Bewertung berücksichtigt, wie lange das Produkt voraussichtlich im Einsatz ist. Der von Ihnen erklärte Supportzeitraum muss diese erwartete Nutzungsdauer widerspiegeln, abgewogen gegen seine eigenen gesetzlichen Faktoren. Beide Aufzeichnungen müssen also zusammenpassen. Erwartet Ihre Bewertung acht Jahre im Feld und Ihr erklärter Supportzeitraum beträgt fünf, überprüfen Sie die Festlegung anhand dieser Faktoren erneut. Das übliche Ergebnis ist ein längerer Supportzeitraum, keine Fußnote, die die Lücke erklärt.

Wer sie verantwortet, und wo sie in Ihren Arbeitsablauf passt

Der CRA macht den Hersteller verantwortlich. Er weist keine internen Rollen zu und schreibt weder eine Risikobewertungsmethodik noch einen Team-Arbeitsablauf vor. Eine Bewertung, die niemand verantwortet, veraltet jedoch, deshalb teilen arbeitende Teams sie in der Praxis ungefähr so auf:

• Product Owner. Verantwortet den Kontext: Zweckbestimmung, vorhersehbare Nutzung, erwartete Nutzungsdauer. Entscheidet, was das Produkt verspricht, und gibt daher frei, wenn sich das Versprechen ändert.
• Entwickler und Architekten. Verantworten das Bedrohungsbild: Schnittstellen, Datenflüsse, die Kontrollen, die jedes Risiko behandeln, und den Nachweis, dass die Kontrollen existieren.
• Security Lead, oder wer diese Rolle innehat. Verantwortet die Methode, das Register, die Anwendbarkeitsaufzeichnung und die Freigabe. In einem kleinen Team trägt eine Person alle drei Hüte, und das funktioniert.

Verankern Sie die Aktualisierungsauslöser dann in den Momenten, in denen ohnehin schon gearbeitet wird, damit die Bewertung nie davon abhängt, dass sich jemand daran erinnert:

Die Pipeline-Nachweise stammen aus dem Tooling, das Sie ohnehin betreiben: SBOM-Erstellung in CI/CD speist die Komponentenaufzeichnung, und Ihr Prozess zur Schwachstellenbehandlung ist es, der die Einträge in Schritt 4 erneut öffnet. Der CRA schreibt das Ergebnis vor, eine dokumentierte, aktuell gehaltene Bewertung, nicht den Zyklus. Der Zyklus macht diese Pflicht neben echtem Liefertempo überlebbar.

Komponenten Dritter

Das Risiko Ihres Produkts umfasst auch die Komponenten darin. Integrieren Sie Komponenten Dritter, einschließlich Open-Source-Komponenten, müssen Sie Sorgfaltspflicht walten lassen, damit diese die Produktsicherheit nicht gefährden. In der Bewertung bedeutet das:

• Komponentenrisiken erscheinen dort im Register, wo sie wesentlich sind, mit der SBOM als Inventar-Rückgrat
• Ihr Ansatz zur Auswahl und Überwachung von Komponenten ist festgehalten, mit Verweisen auf Lieferantennachweise
• Update-Pfade für Komponenten sind Teil der Analyse der Update-Fähigkeit

Die praktische Umsetzung, einschließlich eines Lieferantenfragebogens, finden Sie im Leitfaden zur Lieferanten-Due-Diligence.

Wo die Bewertung abgelegt wird

Die schriftliche Bewertung ist Teil Ihrer technischen Dokumentation, neben der Designdokumentation, den Testnachweisen und der Entscheidungsaufzeichnung zum Supportzeitraum. Halten Sie die freigegebene Version, ihre Versionshistorie und die Nachweise, auf die sie verweist, so lange abrufbar, wie die Datei aufbewahrt werden muss. Der Leitfaden zur technischen Dokumentation zeigt die Aktenstruktur und wo jedes Artefakt liegt.

Häufige Fehler

• Nachträglich erstellt. Eine Bewertung, die in der Woche vor der Auslieferung entsteht, kann das Design nicht beeinflusst haben. Prüfer bemerken das.
• Keine Anwendbarkeitsentscheidungen. Ein Risikoregister allein beantwortet nicht die Frage, die der CRA stellt. Jede der 13 Anforderungen braucht eine ausdrückliche Antwort.
• „Nicht anwendbar“ ohne Begründung. Jeder Ausschluss braucht eine schriftliche Begründung in der Akte.
• Undokumentierte Methode. Bewertungen ohne Skalen, Formeln ohne Definitionen.
• Unternehmensebene statt Produktebene. Ein ISMS-Risikoregister deckt Ihre Organisation ab. Der CRA will dieses Produkt.
• Zum Release eingefroren. Keine Versionshistorie, keine Aktualisierungsauslöser, keine Verbindung zur Schwachstellenüberwachung.
• Widersprüchlich zum Supportzeitraum. Annahmen zur erwarteten Nutzung, die dem erklärten Supportzeitraum widersprechen.
• Keine namentliche Verantwortung. Niemand hat sie freigegeben, niemand akzeptiert das Restrisiko, niemand verantwortet Aktualisierungen.