CRA vs. ISO 27001: Die Compliance-Lücken, die Ihr ISMS nicht abdeckt
ISO 27001 deckt nicht den CRA ab. Dieser Leitfaden zeigt genau, wo Ihr ISMS hilft, wo es fehlt, und was Sie vor der Frist 2027 noch brauchen.
In diesem Artikel
- Zusammenfassung
- Was deckt ISO 27001 ab – und was verlangt der CRA?
- Wo ISO 27001 beim CRA hilft und wo es nicht ausreicht
- Wie Sie ISO 27001 für den CRA nutzen
- ISO 27001 Annex A-Kontrollen und CRA
- Gilt die ISO 27001-Zertifizierung als CRA-Konformitätsbewertung?
- Drei typische ISO 27001 + CRA-Szenarien
- So integrieren Sie den CRA in Ihr bestehendes ISMS
- Checkliste: ISO 27001-Organisation erweitert um CRA
- Offizielle ISO 27001- und CRA-Ressourcen
- Häufig gestellte Fragen
- Nächste Schritte
Wenn Ihr Unternehmen ISO 27001 zertifiziert ist, könnten Sie annehmen, dass Sie für den Cyber Resilience Act (CRA) gut aufgestellt sind. Das sind Sie nicht. Zumindest nicht ohne erhebliche zusätzliche Arbeit.
ISO 27001 schützt die Informationswerte Ihrer Organisation. Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verlangt, dass jedes Produkt mit digitalen Elementen, das Sie auf dem EU-Markt in Verkehr bringen, von Grund auf sicher ist, mit einem Software Bill of Materials (SBOM) ausgeliefert wird und für seine erwartete Lebensdauer mit Sicherheitsupdates versorgt wird. Das sind produktbezogene Pflichten, keine organisatorischen. Bei Nichteinhaltung drohen Bußgelder von bis zu 15 Millionen EUR oder 2,5 % des weltweiten Jahresumsatzes (Art. 64). Siehe den Leitfaden zu CRA-Strafen und Durchsetzung.
Die Meldepflichten nach Art. 14 beginnen am 11. September 2026. Die vollständige Compliance ist bis zum 11. Dezember 2027 erforderlich. Siehe den vollständigen CRA-Implementierungszeitplan.
Dieser Leitfaden zu ISO 27001 vs. CRA zeigt genau, wo Ihr ISMS hilft, wo es nicht ausreicht, und was Sie ergänzen müssen.
Zusammenfassung
- ISO 27001 = organisatorisches/unternehmensweites Sicherheitsmanagement
- CRA = Produktanforderungen an die Cybersicherheit (Annex I, Verordnung (EU) 2024/2847)
- ISO 27001 entspricht NICHT der CRA-Compliance
- ISO 27001 bildet eine Grundlage für sichere Entwicklungsprozesse
- CRA verlangt produktspezifische Nachweise: SBOM, Schwachstellenbehandlung, CE-Kennzeichnung
- Beide zusammen = starke Gesamtsicherheitslage
Was deckt ISO 27001 ab – und was verlangt der CRA?
Was ISO 27001 abdeckt
ISO 27001 ist ein Standard für Informationssicherheits-Managementsysteme (ISMS), der folgendes umfasst:
Kontrollen auf Organisationsebene:
- Informationssicherheitsrichtlinien
- Asset-Management
- Zugangskontrolle (zu Systemen und Daten)
- Kryptografieeinsatz
- Physische Sicherheit
- Betriebssicherheit
- Kommunikationssicherheit
- Lieferantenbeziehungen
- Vorfallsmanagement
- Geschäftskontinuität
- Compliance-Management
Fokus: Schutz der Informationswerte Ihrer Organisation
Was CRA abdeckt
CRA ist eine Produktverordnung, die folgendes abdeckt (Annex I):
Anforderungen auf Produktebene:
- Security-by-Design bei Produkten
- Keine bekannten ausnutzbaren Schwachstellen
- Sichere Standardkonfiguration
- Schutz vor unbefugtem Zugriff (im Produkt)
- Datenschutz (durch das Produkt)
- Update-Fähigkeit (des Produkts)
- Schwachstellenbehandlung und ENISA-Meldung (für das Produkt)
- SBOM für Produktkomponenten (Art. 13(5))
- Richtlinie zur koordinierten Offenlegung von Schwachstellen (Art. 13(6))
- Öffentlicher Kontakt für Schwachstellen (Art. 13(7))
- CE-Kennzeichnung und Konformitätsbewertung
Fokus: Sicherstellung, dass die von Ihnen verkauften Produkte sicher sind
Der CRA klassifiziert Produkte in Kategorien: Standard, Wichtige Klasse I, Wichtige Klasse II und Kritisch (Annex III und IV). Jede Kategorie hat unterschiedliche Anforderungen an die Konformitätsbewertung. Ein Produkt der Wichtigen Klasse II erfordert eine obligatorische Drittparteiprüfung durch eine notifizierte Stelle, unabhängig von Ihrem ISO 27001-Zertifizierungsstatus. Siehe den Leitfaden zur CRA-Produktklassifizierung.
Der grundlegende Unterschied
ISO 27001 vs. CRA GELTUNGSBEREICH
ISO 27001:
"Wie verwaltet Ihre ORGANISATION die Sicherheit?"
┌─────────────────────────────────────────────┐
│ Ihr Unternehmen │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Systeme │ │ Daten │ │ Personal│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Prozesse │ │ Netzwerk│ │ Gebäude │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────┘
CRA:
"Wie sicher sind die PRODUKTE, die Sie verkaufen?"
┌─────────────────────────────────────────────┐
│ Ihre Produkte (an Kunden verkauft) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Produkt A│ │Produkt B│ │Produkt C│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ Jedes Produkt muss CRA-Anforderungen │
│ erfüllen │
└─────────────────────────────────────────────┘
Wo ISO 27001 beim CRA hilft und wo es nicht ausreicht
Wo ISO 27001 beim CRA hilft
| CRA-Anforderung | ISO 27001-Unterstützung | Wie es hilft |
|---|---|---|
| Sichere Entwicklung | A.8.25-28 (Sichere Entwicklung) | Prozessgrundlage |
| Schwachstellenbehandlung | A.8.8 (Technische Schwachstellen) | Organisatorischer Prozess |
| Vorfallsreaktion | A.5.24-26 (Vorfallsmanagement) | Reaktionsfähigkeit |
| Lieferantenmanagement | A.5.19-22 (Lieferantenbeziehungen) | Lieferkettensicherheit |
| Zugangskontrolle | A.5.15-18, A.8.2-5 | Sicherheit der Entwicklungsumgebung |
| Kryptografie | A.8.24 (Kryptografie) | Grundlage der Kryptografierichtlinie |
| Dokumentation | A.5.1 (Richtlinien), 7.5 (Dokumentierte Informationen) | Dokumentationskultur |
| Risikobewertung | 6.1 (Risikobewertung) | Risikomethodik |
Wo ISO 27001 nicht ausreicht
| CRA-Anforderung | ISO 27001-Lücke | Was fehlt |
|---|---|---|
| SBOM | Teilweise: A.8.26/A.8.28 decken Komponentenbewusstsein ab, nicht das maschinenlesbare SBOM-Format | Standardisiertes SBOM (SPDX/CycloneDX) gemäß Art. 13(5) |
| CE-Kennzeichnung | Nicht abgedeckt | Konformitätsbewertungsprozess |
| Produktsicherheitstests | Begrenzt | Produktspezifische Testnachweise für technische Unterlagen |
| Secure by Default | Kein Produktfokus | Produktkonfigurationsanforderungen |
| Supportzeitraum | Nicht abgedeckt | Mindestens 5 Jahre oder erwartete Produktlebensdauer, falls kürzer (Art. 13(8)) |
| ENISA-Meldung | Nicht abgedeckt | 24h/72h-Benachrichtigung + Abschlussbericht an nationales CSIRT über Single Reporting Platform (Art. 14) |
| CVD-Richtlinie | Nicht abgedeckt | Dokumentierte Richtlinie zur koordinierten Offenlegung von Schwachstellen (Art. 13(6)) |
| Öffentlicher Schwachstellenkontakt | Nicht abgedeckt | Einzige Anlaufstelle für Schwachstellenmeldungen, z. B. security.txt (Art. 13(7)) |
| Benutzerdokumentation | Begrenzt | Sicherheitsanweisungen für das Produkt |
| Technische Unterlagen | Nicht abgedeckt | CRA-Dokumentationsformat gemäß Annex VII |
Zusammenfassung der Lückenanalyse
Starke Grundlage (ISO 27001 hilft erheblich):
- Sicherheitskultur und -bewusstsein
- Risikomanagementsystematik
- Vorfallsreaktionsfähigkeit
- Lieferantensicherheitsmanagement
- Richtlinien für den sicheren Entwicklungszyklus
- Zugangskontrollrahmen
- Dokumentationspraktiken
Teilweise Abdeckung (ISO 27001 hilft, reicht aber nicht aus):
- Schwachstellenmanagement (Organisationsbereich vs. Produktbereich)
- Kryptografie (Richtlinie vs. Produktimplementierung)
- Sicherheitstests (Unternehmenssysteme vs. Produkttests)
- Änderungsmanagement (IT-Änderung vs. Produktmodifikation)
- SBOM (Komponentenbewusstsein in A.8.26/A.8.28 vs. maschinenlesbares SBOM-Format)
Lücken (CRA-spezifisch, nicht durch ISO 27001 abgedeckt):
- SBOM-Generierung und -Pflege in einem standardisierten Format
- Produktkonformitätsbewertung
- CE-Kennzeichnungsprozess
- Schwachstellenmeldung an nationales CSIRT über Single Reporting Platform (Art. 14)
- Produktspezifische technische Unterlagen (Annex VII)
- Supportzeitraum-Zusage (Art. 13(8))
- Überprüfung der sicheren Standardkonfiguration
- Anforderungen an den Produktaktualisierungsmechanismus
- Richtlinie zur koordinierten Offenlegung von Schwachstellen (Art. 13(6))
- Öffentlicher Kontakt für Schwachstellenmeldungen (Art. 13(7))
Wie Sie ISO 27001 für den CRA nutzen
Ihr ISMS als Grundlage verwenden
Wenn Sie ISO 27001 zertifiziert sind, haben Sie eine starke Basis, auf der Sie aufbauen können. Der Schlüssel liegt darin, bestehende Prozesse auf Produktpflichten auszuweiten, statt von vorne anzufangen.
Bestehende Prozesse erweitern:
| ISO 27001-Prozess | CRA-Erweiterung |
|---|---|
| Risikobewertung (6.1) | Produktrisikobewertung |
| Schwachstellenmgmt. (A.8.8) | Produktschwachstellenbehandlung + CSIRT-Meldung |
| Lieferantenmgmt. (A.5.19-22) | SBOM-Erfassung von Lieferanten |
| Vorfallsmgmt. (A.5.24-26) | CSIRT-Meldung gemäß Art. 14 |
| Sichere Entwicklung (A.8.25-28) | Produktsicherheitstests und technische Unterlagen |
Neue Prozesse hinzufügen:
| Neuer Prozess | Zweck |
|---|---|
| SBOM-Generierung | Komponentenverfolgung gemäß Art. 13(5) |
| Konformitätsbewertung | CE-Kennzeichnung |
| Produkttechnische Unterlagen | Regulatorische Dokumentation gemäß Annex VII |
| Supportzeitraum-Management | Zusage gemäß Art. 13(8) |
| ENISA-Meldeverfahren | Schwachstellenbenachrichtigung über nationales CSIRT |
| CVD-Richtlinie | Koordinierte Offenlegung gemäß Art. 13(6) |
Praktische Integrationsschritte
Schritt 1: Bereichserweiterung
- Produktsicherheit zum ISMS-Geltungsbereich hinzufügen
- Produktentwicklung in die Risikobewertung einbeziehen
- Asset-Inventar auf Produktkomponenten ausweiten
Schritt 2: Prozessaktualisierungen
- Schwachstellenverfahren für die Produktmeldung an das nationale CSIRT über die Single Reporting Platform aktualisieren
- SBOM zum Änderungsmanagement hinzufügen
- Den 24h-Frühwarnung-, 72h-Erstmeldungs- und Abschlussberichts-Rhythmus in den Vorfallsreaktionsprozess einbinden
Schritt 3: Dokumentationsergänzungen
- Produkttechnische Unterlagen
- SBOM-Nachweise
- Konformitätsbewertungsnachweise
- Dokumentation zum Supportzeitraum
Schritt 4: Rollen und Verantwortlichkeiten
- Produktsicherheitsverantwortung zuweisen
- CSIRT-Meldeverantwortung definieren
- SBOM-Pflegeverantwortung festlegen
- CVD-Richtlinienverantwortung zuweisen
ISO 27001 Annex A-Kontrollen und CRA
Relevanteste Kontrollen
A.8.25 Sicherer Entwicklungszyklus
- ISO 27001: Richtlinien für die sichere Entwicklung
- CRA-Verwendung: Grundlage für Produktsicherheitsanforderungen (Annex I, Teil I)
A.8.26 Anwendungssicherheitsanforderungen
- ISO 27001: Sicherheitsanforderungen in der Entwicklung
- CRA-Verwendung: Basis für grundlegende Produktanforderungen; teilweise Grundlage für das SBOM-Komponenteninventar
A.8.27 Sichere Systemarchitektur
- ISO 27001: Prinzipien sicherer Architektur
- CRA-Verwendung: Produktsicherheitsarchitektur
A.8.28 Sicheres Coden
- ISO 27001: Sichere Programmierpraktiken einschließlich Abhängigkeitsverfolgung
- CRA-Verwendung: Produktcodesicherheit; teilweise Grundlage für SBOM-Komponentenbewusstsein
A.8.8 Management technischer Schwachstellen
- ISO 27001: Organisatorische Schwachstellenbehandlung
- CRA-Verwendung: Auf Produktschwachstellen + Meldung an nationales CSIRT über Single Reporting Platform ausweiten (Art. 14)
A.5.19-22 Lieferantenbeziehungen
- ISO 27001: Lieferantensicherheitsmanagement
- CRA-Verwendung: SBOM-Erfassung von Lieferanten, Lieferkettensicherheit
Kontrollimplementierung für CRA
ERWEITERUNG DER ISO 27001-KONTROLLEN FÜR CRA
A.8.8 ERWEITERUNG DES SCHWACHSTELLENMANAGEMENTS:
ISO 27001-Anforderung:
"Informationen über technische Schwachstellen der
verwendeten Informationssysteme sollen eingeholt werden..."
CRA-Erweiterung (Art. 14):
- Schwachstellen in IHREN PRODUKTEN überwachen
- Prozess für Kundenbenachrichtigung pflegen
- An nationales CSIRT über Single Reporting Platform melden:
24h Frühwarnung, 72h Erstmeldung,
14-tägiger Abschlussbericht (aktiver Exploit) oder
1-monatiger Abschlussbericht (schwerwiegender Vorfall)
- Schwachstellenstatus pro Produkt verfolgen
- VEX-Dokumente erstellen
A.8.25-28 ERWEITERUNG DER SICHEREN ENTWICKLUNG:
ISO 27001-Anforderung:
"Regeln für die Entwicklung von Software und Systemen
sollen festgelegt und angewendet werden..."
CRA-Erweiterung:
- SBOM-Generierung in den Build-Prozess einbinden (Art. 13(5))
- "Secure by Default"-Konfiguration überprüfen
- Produktsicherheitsanforderungen testen
- Für technische Unterlagen dokumentieren (Annex VII)
- Nachweise für die Konformitätsbewertung pflegen
Gilt die ISO 27001-Zertifizierung als CRA-Konformitätsbewertung?
Deckt die ISO 27001-Zertifizierung die CRA-Compliance ab?
Wichtiges Verständnis:
- ISO 27001-Zertifizierung zeigt organisatorische Sicherheitsreife
- CRA-Compliance ist eine produktbezogene regulatorische Anforderung
- Eine ISO 27001-Zertifizierung befreit nicht vom CRA
- ISO 27001-Auditoren beurteilen keine CRA-Compliance
Die Meldepflichten nach Art. 14 beginnen am 11. September 2026. Die vollständige Compliance ist bis zum 11. Dezember 2027 erforderlich. Bei Nichteinhaltung drohen Bußgelder von bis zu 15 Millionen EUR oder 2,5 % des weltweiten Jahresumsatzes (Art. 64).
ISO 27001 im CRA-Kontext verwenden
WIE MAN ISO 27001 IN DER CRA-DOKUMENTATION REFERENZIERT
IN TECHNISCHEN UNTERLAGEN:
"[Unternehmen] unterhält ein nach ISO/IEC 27001:2022 zertifiziertes
Informationssicherheits-Managementsystem (Zertifikat
Nr. XXX, ausgestellt von [Zertifizierungsstelle]).
Das ISMS bildet die organisatorische Grundlage für
die Produktsicherheit, einschließlich:
- Sicherer Entwicklungszyklus (A.8.25-28)
- Schwachstellenmanagementprozess (A.8.8)
- Lieferantensicherheitsanforderungen (A.5.19-22)
Die produktspezifische CRA-Compliance ist in diesen
technischen Unterlagen dokumentiert und baut auf
diesen ISMS-Kontrollen auf."
WAS DAS ZEIGT:
- Reife des Sicherheitsmanagements
- Prozessgrundlage vorhanden
- Kein Ersatz für Produktnachweise
Audit-Synergien
ISO 27001-Überwachungsaudit:
- Jährliche Bewertung des ISMS
- Kann den Produktsicherheitsbereich einschließen
- Nachweise für CRA wiederverwendbar
CRA-Konformitätsbewertung:
- Produktspezifische Bewertung
- Verweist auf ISMS für Prozessnachweise
- Benötigt zusätzliche Produktnachweise
Synergiemöglichkeiten:
- Audit-Zeitpläne abstimmen
- Nachweise wo möglich wiederverwenden
- Integrierter Managementsystemansatz
- Einziges Dokumentationsrepository
Drei typische ISO 27001 + CRA-Szenarien
Szenario 1: ISO 27001 zertifiziert, CRA-Einstieg
Vorteile, die Sie bereits haben:
- Risikomethodik vorhanden
- Sicherheitskultur etabliert
- Dokumentationspraktiken vorhanden
- Lieferantenmanagement vorhanden
- Vorfallsreaktionsfähigkeit
Was Sie noch hinzufügen müssen:
- [ ] Produktklassifizierung gemäß CRA (Annex III/IV)
- [ ] SBOM-Generierungsfähigkeit (Art. 13(5))
- [ ] CSIRT-Meldeprozess (Art. 14)
- [ ] Produkttechnische Unterlagen (Annex VII)
- [ ] Konformitätsbewertungsprozess
- [ ] Supportzeitraum-Management (Art. 13(8))
- [ ] Produktspezifische Sicherheitstests
- [ ] CVD-Richtlinie (Art. 13(6))
- [ ] Öffentlicher Schwachstellenkontakt (Art. 13(7))
Vorgehensweise:
- Lückenanalyse gegenüber CRA-Anforderungen
- ISMS-Geltungsbereich auf Produkte ausweiten
- CRA-spezifische Prozesse hinzufügen
- Dokumentation aktualisieren
- Relevante Teams schulen
Szenario 2: Kein ISO 27001, CRA-Annäherung
Option A: Nur CRA
- CRA-Anforderungen direkt umsetzen
- Produktfokussierter Ansatz
- Möglicherweise keine organisatorischen Sicherheitsvorteile
- Schnellerer Weg zur CRA-Compliance
Option B: ISO 27001 + CRA
- Beide Rahmenwerke umsetzen
- Stärkere Gesamtsicherheitslage
- Mehr Aufwand im Voraus
- Bessere langfristige Position
Empfehlung: Für Produkthersteller empfiehlt es sich, mit den CRA-Anforderungen zu beginnen (die regulatorische Frist ist festgelegt) und ISO 27001 schrittweise anzustreben. Die Ansätze von Anfang an aufeinander abstimmen, damit keine doppelte Arbeit entsteht. Siehe den CRA-Leitfaden für Startups für einen Pfad mit minimalem Aufwand.
Szenario 3: Mehrere Produkte, zentrales ISMS
Zentralisiert (ISMS):
- Risikomethodik
- Schwachstellenbehandlungsprozess
- Lieferantenmanagement
- Vorfallsreaktion
- Entwicklungsstandards
Pro Produkt (CRA):
- Technische Unterlagen
- SBOM
- Konformitätsbewertung
- Produktdokumentation
- Supportzeitraum
Vorteile:
- Effiziente Prozesswiederverwendung
- Einheitlicher Sicherheitsansatz
- Zentralisiertes Fachwissen
- Produktspezifische Compliance
So integrieren Sie den CRA in Ihr bestehendes ISMS
Governance-Modell
INTEGRIERTES GOVERNANCE-MODELL
ORGANISATIONSEBENE (ISO 27001):
┌─────────────────────────────────────────────┐
│ Informationssicherheits-Managementsystem │
│ │
│ - Sicherheitsrichtlinien │
│ - Risikomanagementrahmen │
│ - Sicherheitsorganisation │
│ - Bewusstsein und Schulung │
└─────────────────────────────────────────────┘
│
▼
PRODUKTEBENE (CRA):
┌─────────────────────────────────────────────┐
│ Produktsicherheits-Compliance │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Produkt A│ │Produkt B│ │Produkt C│ │
│ │- Techn. │ │- Techn. │ │- Techn. │ │
│ │ Unter- │ │ Unter- │ │ Unter- │ │
│ │ lagen │ │ lagen │ │ lagen │ │
│ │- SBOM │ │- SBOM │ │- SBOM │ │
│ │- DoC │ │- DoC │ │- DoC │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────┘
Dokumentationsstruktur
INTEGRIERTE DOKUMENTATION
ISMS-DOKUMENTATION (ISO 27001):
├── Informationssicherheitsrichtlinie
├── Risikobewertungsverfahren
├── Anwendbarkeitserklärung
├── Richtlinie für sichere Entwicklung
├── Schwachstellenmanagementverfahren
├── Vorfallsreaktionsverfahren
└── Lieferantensicherheitsrichtlinie
CRA-DOKUMENTATION (Pro Produkt):
├── Produkttechnische Unterlagen (Annex VII)
│ ├── Produktbeschreibung
│ ├── Risikobewertung
│ ├── Sicherheitsarchitektur
│ ├── Testberichte
│ └── SBOM
├── EU-Konformitätserklärung
├── Benutzerdokumentation
└── Supportzeitraum-Erklärung
QUERVERWEISE:
- Technische Unterlagen verweisen auf ISMS-Verfahren
- ISMS-Verfahren beinhalten CRA-Anforderungen
- Aufzeichnungen werden 10 Jahre oder den Supportzeitraum
aufbewahrt, je nachdem was länger ist (Art. 23(2))
Checkliste: ISO 27001-Organisation erweitert um CRA
Bewertung:
- [ ] Aktuellen ISMS-Geltungsbereich prüfen
- [ ] Produkte mit digitalen Elementen identifizieren
- [ ] Produkte gemäß CRA-Kategorien klassifizieren (Annex III/IV)
- [ ] Lückenanalyse: ISMS vs. CRA-Anforderungen
Bereichserweiterung:
- [ ] Produktsicherheit zum ISMS-Geltungsbereich hinzufügen
- [ ] Risikobewertung auf Produkte ausweiten
- [ ] Anwendbarkeitserklärung aktualisieren
Prozessergänzungen:
- [ ] SBOM-Generierungsprozess (Art. 13(5))
- [ ] CSIRT-Meldeverfahren (Art. 14)
- [ ] Konformitätsbewertungsprozess
- [ ] Supportzeitraum-Management (Art. 13(8))
- [ ] Verfahren für produkttechnische Unterlagen (Annex VII)
- [ ] CVD-Richtlinie (Art. 13(6))
- [ ] Einrichtung eines öffentlichen Schwachstellenkontakts (Art. 13(7))
Dokumentation:
- [ ] Vorlagen für technische Unterlagen
- [ ] Vorlage für Produktrisikobewertung
- [ ] SBOM-Format und -Speicherung
- [ ] Vorlage für Konformitätserklärung
Kontrollerweiterungen:
- [ ] A.8.8: Produktschwachstellen und CSIRT-Meldung hinzufügen
- [ ] A.8.25-28: Produktsicherheitstests hinzufügen
- [ ] A.5.19-22: SBOM von Lieferanten hinzufügen
Rollen:
- [ ] Produktsicherheitsverantwortlichen zuweisen
- [ ] CSIRT-Meldeverantwortung definieren
- [ ] Rolle für Konformitätsbewertung festlegen
- [ ] CVD-Richtlinienverantwortlichen zuweisen
Schulungen:
- [ ] CRA-Bewusstsein für Entwicklungsteams
- [ ] Schulung zu SBOM-Tools
- [ ] Schulung zur Konformitätsbewertung
Offizielle ISO 27001- und CRA-Ressourcen
ISO 27001:
- ISO/IEC 27001:2022: Informationssicherheitsmanagement
- ISO/IEC 27002:2022: Informationssicherheitskontrollen
CRA:
- Verordnung (EU) 2024/2847: Cyber Resilience Act
- ENISA CRA-Anforderungen: Standards-Mapping (November 2024)
Ergänzende Standards:
- ISO/IEC 27034: Anwendungssicherheit (verbindet ISMS und Produktsicherheit)
- IEC 62443: Industrielle Sicherheit (gut geeignet für OT/IoT-Hersteller; starker Kandidat für harmonisierten CRA-Standard)
- ISO/SAE 21434: Fahrzeugsicherheit
Wichtig: ISO 27001-Zertifizierung entspricht NICHT der CRA-Compliance. ISO 27001 deckt die organisatorische Informationssicherheit ab; CRA erfordert eine produktspezifische Konformitätsbewertung.
Tipp: Ordnen Sie Ihre bestehenden Annex-A-Kontrollen den CRA-Annex-I-Anforderungen zu, um Lücken zu identifizieren. Beginnen Sie mit A.8.8, A.8.25-28 und A.5.19-22.
Häufig gestellte Fragen
Befreit eine ISO 27001-Zertifizierung ein Unternehmen von der CRA-Konformitätsbewertung?
Nein. Die ISO 27001-Zertifizierung belegt die organisatorische Reife im Bereich Informationssicherheit, ersetzt jedoch nicht die CRA-Konformitätsbewertung. Der CRA verlangt produktbezogene Nachweise: SBOM, technische Unterlagen, Konformitätserklärung und bei Bedarf eine Bewertung durch eine notifizierte Stelle. Ein Zertifizierer, der Ihr ISMS prüft, beurteilt keine CRA-Konformität. Siehe CRA-Konformitätsbewertungsrouten.
Welche ISO 27001 Annex-A-Kontrollen sind am direktesten für CRA Annex I relevant?
Die Kontrollen mit den meisten Überschneidungen sind A.8.25-28 (sicherer Entwicklungszyklus), A.8.8 (Management technischer Schwachstellen) und A.5.19-22 (Lieferantenbeziehungen). Diese decken CRA-Anforderungen zu Secure-by-Design, Schwachstellenbehandlung und SBOM-Lieferkettenvorgaben ab. A.8.8 muss erweitert werden, um die Meldepflicht für Produktschwachstellen an das nationale CSIRT über die ENISA Single Reporting Platform abzudecken (Art. 14).
Können ISO 27001-Auditnachweise in CRA-technischen Unterlagen wiederverwendet werden?
Ja, selektiv. Nachweise aus Ihrem ISMS zu sicherer Entwicklung (A.8.25-28), Schwachstellenmanagement (A.8.8) und Lieferantenkontrollen (A.5.19-22) können in den technischen Unterlagen referenziert werden. Die technischen Unterlagen erfordern jedoch auch produktspezifische Nachweise, einschließlich Sicherheitsarchitektur, Testberichte, SBOM und Supportzeitraum-Dokumentation, die ISO 27001-Audits nicht erzeugen.
Ist ISO 27001:2022 besser auf den CRA abgestimmt als ISO 27001:2013?
Ja. ISO 27001:2022 hat Kontrollen hinzugefügt, die für den CRA relevanter sind, insbesondere A.8.25-28 (sicherer Entwicklungszyklus, Anwendungssicherheitsanforderungen, sichere Architektur, sicheres Coding). Die 2013er Version wies in diesen Bereichen eine schwächere Abdeckung auf. Wer noch die 2013er Version verwendet, sollte speziell für CRA-Zwecke eine Lückenanalyse gegenüber den 2022er Kontrollen durchführen.
Deckt ISO 27001 die CRA-SBOM-Anforderung ab?
Teilweise. A.8.26 (Anwendungssicherheitsanforderungen) und A.8.28 (sicheres Coding) enthalten Konzepte zur Komponentenbewusstheit und Abhängigkeitsverfolgung. ISO 27001 verlangt jedoch kein maschinenlesbares SBOM im Format CycloneDX oder SPDX mit den NTIA-Mindestelementen, wie es CRA Art. 13(5) fordert. Das organisatorische Bewusstsein ist eine Grundlage, kein Ersatz.
Lässt sich die CRA-Compliance-Arbeit in ein laufendes ISO 27001-Programm integrieren?
Ja, und das ist der empfohlene Ansatz für bereits zertifizierte Unternehmen. Erweitern Sie den ISMS-Geltungsbereich um Produktsicherheit, fügen Sie produktspezifische Verfahren für SBOM und CSIRT-Meldungen hinzu und referenzieren Sie ISMS-Nachweise in Ihren CRA-technischen Unterlagen. Der Schlüssel liegt im Ergänzen statt Duplizieren: CRA-Nachweise gehören in die technischen Unterlagen, nicht in die Anwendbarkeitserklärung des ISMS.
Nächste Schritte
- Führen Sie eine Lückenanalyse Ihrer Annex-A-Kontrollen gegenüber CRA Annex I durch. Beginnen Sie mit A.8.8, A.8.25-28 und A.5.19-22. Diese tragen den Großteil der Last.
- Klassifizieren Sie jedes Produkt nach Annex III und IV. Der Konformitätsbewertungspfad hängt davon ab, nicht von Ihrem ISO 27001-Zertifizierungsstatus.
- Erweitern Sie die Geltungsbereichserklärung Ihres ISMS um die Produktsicherheit. Aktualisieren Sie die Anwendbarkeitserklärung, damit Produktpflichten für Auditoren sichtbar sind.
- Nehmen Sie die SBOM-Generierung (Art. 13(5)) in Ihr Änderungsmanagement auf. CycloneDX oder SPDX, maschinenlesbar, an jeden Release gekoppelt.
- Erstellen oder aktualisieren Sie das CSIRT-Meldeverfahren für Art. 14: 24h-Frühwarnung, 72h-Erstmeldung, Abschlussbericht innerhalb von 14 Tagen oder 1 Monat je nach Vorfallstyp.
- Benennen Sie eine verantwortliche Person für Produktsicherheit und eine für die CVD-Richtlinie (Art. 13(6)/(7)). Das darf nicht im diffusen „Security-Team“ hängen bleiben.
- Planen Sie ein kombiniertes internes Audit, das sowohl die ISO 27001-Überwachung als auch die Bereitschaft der technischen Unterlagen nach CRA abdeckt. Nutzen Sie Nachweise dort, wo sie passen, mehrfach.
Prüfen Sie die CRA-Konformitätsbewertungsrouten, um festzustellen, welches Modul für jedes Produkt gilt. Den CRA-Implementierungszeitplan finden Sie mit den Fristen September 2026 und Dezember 2027.
Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung wenden Sie sich bitte an qualifizierte Rechtsexperten.
Verwandte Artikel
Gilt der CRA für Ihr Produkt?
Beantworten Sie 6 einfache Fragen, um herauszufinden, ob Ihr Produkt unter den EU Cyber Resilience Act fällt. Erhalten Sie Ihr Ergebnis in unter 2 Minuten.
Bereit für CRA-Konformität?
Beginnen Sie mit der Verwaltung Ihrer SBOMs und Compliance-Dokumentation mit CRA Evidence.