Zielgruppe: IT-Auditoren, B2B-Einkäufer, ISBs & Compliance-Verantwortliche
Prüfgegenstand: Produkte mit digitalen Elementen (Hardware & Software) sowie deren Datenfernverarbeit1. Geltungsbereich & Produktklassifizierung
- [ ] Produktidentifikation: Ist geklärt, ob das beschaffte oder entwickelte Produkt digitale Elemente enthält und direkt oder indirekt mit Netzwerken verbunden werden kann? (Ausgenommen sind u. a. nicht-kommerzielle Open-Source-Software und gesetzlich geregelte Sonderbereiche wie Medizinprodukte).
- [ ] Einstufung nach Risiko: Wurde das Produkt einer der vier CRA-Kategorien korrekt zugeordnet?
- Standardprodukt (z. B. Smart-Home-Saugroboter, Steuererstattungs-Software)
- Wichtig Klasse 1 (z. B. Passwortmanager, VPN-Clients, SIEM-Systeme)
- Wichtig Klasse 2 (z. B. Firewalls, IDS/IPS, manipulationssichere Mikroprozessoren)
- Kritisch (z. B. Hardware-Sicherheitsmodule, Smartcard-Elemente, Smart-Meter-Gateways)
- [ ] Konformitätsbewertungsweg: Wurde der erforderliche Nachweisweg gemäß New Legislative Framework (NLF) ermittelt?
- Selbsterklärung (Modul A) bei Standardprodukten oder Klasse 1 mit harmonisierten Normen
- Einbindung einer Notifizierten Stelle (Modul B+C oder Modul H) bei Klasse 1 ohne Normen sowie bei Klasse 2
- Zertifizierung nach dem Cybersecurity Act bei kritischen Produkten
2. Security by Design & Security by Default
- [ ] Schutz der Datenintegrität & Vertraulichkeit: Ist nachgewiesen, dass gespeicherte und übertragene Daten nach dem Stand der Technik verschlüsselt werden?
- [ ] Minimierung der Angriffsfläche: Wurden Schnittstellen und Funktionen auf das technisch notwendige Minimum reduziert?
- [ ] Standardkonfigurationen: Sind schwache Standardpasswörter werkseitig unterbunden und automatische Sicherheitsupdates voreingestellt?
- [ ] Authentisierung & Zugriffsschutz: Werden angemessene Mechanismen zur Identitäts- und Zugriffsverwaltung bereitgestellt?
3. Software Bill of Materials (SBOM) & Lieferkettensicherheit
- [ ] Maschinenlesbare SBOM: Liegt für das Softwareprodukt bzw. die Firmware eine detaillierte Software-Stückliste in einem strukturierten, maschinenlesbaren Format vor?
- [ ] Komponenten-Inventar: Werden alle eingebundenen Drittanbieter-Bibliotheken und Open-Source-Komponenten lückenlos nachgehalten?
- [ ] Lieferanten-Due-Diligence: Wurden Verträge mit Komponenten-Lieferanten bezüglich verpflichtender Schwachstellenüberwachung und festgelegter Patch-SLAs geprüft?
4. Support-Zeiträume & Schwachstellenmanagement
- [ ] Transparenz des Support-Endes: Ist das Verbindlichkeitsdatum für kostenlose Sicherheitsupdates gegenüber dem Endanwender klar kommuniziert (in der Regel mindestens 5 Jahre)?
- [ ] Patch-Prozess: Ist sichergestellt, dass Sicherheitsaktualisierungen während der Support-Phase unverzüglich und kostenlos bereitgestellt werden?
- [ ] Coordinated Vulnerability Disclosure (CVD): Existiert ein etablierter Kanal zur Entgegennahme und Verarbeitung extern gemeldeter Schwachstellen?
5. Meldewesen & Schnittstelle zur Single Reporting Platform
- [ ] 24-Stunden-Frühwarnung: Ist ein Prozess definiert, um aktiv ausgenutzte Schwachstellen oder schwere Sicherheitsvorfälle innerhalb von 24 Stunden über die Single Reporting Platform an die ENISA und das zuständige CSIRT zu melden?
- [ ] 72-Stunden-Detailmeldung: Werden vertiefende Informationen zum Vorfall spätestens nach 72 Stunden nachgereicht?
- [ ] Abschlussbericht: Ist die Erstellung eines Abschlussberichts (spätestens 14 Tage nach Patch-Bereitstellung bei Schwachstellen bzw. 1 Monat bei Vorfällen) im Incident-Response-Plan verankert?
- [ ] Abgrenzung NIS2 vs. CRA: Sind die Verantwortlichkeiten für Produkt-Meldungen (CRA an ENISA) und Organisations-Meldungen (NIS2 an die nationale Behörde) eindeutig getrennt?
6. Technische Dokumentation & CE-Kennzeichnung
- [ ] Compliance-Akte: Ist eine vollständige technische Dokumentation vorhanden, die Risikobewertungen, Threat-Modelle, Testberichte und Architekturentscheidungen bündelt?
- [ ] EU-Konformitätserklärung: Wurde die Konformitätserklärung ordnungsgemäß ausgestellt und unterzeichnet?
- [ ] Erweitertes CE-Kennzeichen: Beinhaltet die CE-Kennzeichnung des Produkts den Nachweis über die Erfüllung der CRA-Cybersicherheitsanforderungen?
7. Sanktions- & Haftungsrisiko-Check
- [ ] Marktüberwachung & Bußgeld-Compliance: Ist dem Management bekannt, dass Verstöße gegen die CRA-Pflichten mit Bußgeldern von bis zu 15 Mio. € bzw. 2,5 % des weltweiten Jahresumsatzes geahndet werden können?
- [ ] Marktzugangsrisiko: Ist berücksichtigt, dass Marktüberwachungsbehörden bei Nicht-Konformität Produktrückrufe anordnen oder das CE-Kennzeichen entziehen können?
💡 Tipp für ISO 27001 Lead Implementer: Betreiben Sie bereits ein ISMS, empfiehlt es sich, die produktbezogenen Produktrisiken (CRA) und die organisatorischen Betriebsrisiken (NIS2) in einem gemeinsamen Risikoregister zu führen, deren Behandlungsmaßnahmen jedoch strikt zu trennen.
