Von ISO 27001:2022 zur CRA-Compliance: Systematische Gap-Analyse und Implementierungsroadmap

Executive Summary

Organisationen mit bestehender ISO 27001:2022-Zertifizierung verfügen bereits über ein solides Fundament für die CRA-Compliance. Diese Analyse quantifiziert die bestehende Coverage, identifiziert systematisch alle Gaps und definiert konkrete Maßnahmen zur CRA-Erfüllung.

Kurz: ISO 27001:2022 deckt circa 67%/48% (je nach Sektion) der CRA-Anforderungen ab. Die verbleibenden 33%/52% erfordern gezielte produktspezifische Ergänzungen in den Bereichen SBOM, CVD-Programme, automatische Updates und erweiterte Incident-Reporting-Prozesse.

1. Ausgangssituation: ISO 27001:2022 als Fundament

1.1 Was Sie bereits haben

Mit einer ISO 27001:2022-Zertifizierung haben Sie bereits implementiert:

Governance & Management:

• Strukturiertes ISMS mit definierten Rollen und Verantwortlichkeiten
• Dokumentiertes Risikomanagement-Framework
• Management-Reviews und kontinuierliche Verbesserungsprozesse
• Internal Audit-Programme

Sicherheitskontrollen:

• 93 Annex A Controls (vollständig oder selektiv basierend auf Statement of Applicability)
• Incident Management-Prozesse
• Vulnerability Management
• Zugriffskontroll-Mechanismen
• Kryptographie-Standards
• Security Awareness Training

Dokumentation:

• ISMS-Policies und Procedures
• Risk Assessment und Treatment Plan
• Statement of Applicability (SoA)
• Audit-Nachweise und Records

1.2 Was der CRA zusätzlich verlangt

Der CRA (Verordnung (EU) 2024/2847, in Kraft seit 10. Dezember 2024) adressiert produktspezifische Cybersicherheit und verlangt:

Produktfokus statt Organisationsfokus:

• Einzelne Produkte mit digitalen Elementen (PDEs) müssen CRA-konform sein
• CE-Kennzeichnung als Konformitätsnachweis
• Produktlebenszyklus-Verantwortung

Spezifische technische Anforderungen:

• Software Bill of Materials (SBOM) für jedes Produkt
• Automatische Sicherheitsupdates (standardmäßig aktiviert)
• Coordinated Vulnerability Disclosure (CVD) Programme
• 24-Stunden-Meldefrist bei aktiv ausgenutzten Schwachstellen

Rechtliche Verbindlichkeit:

• Obligatorisch für EU-Marktzugang
• Sanktionen bis €15 Millionen oder 2,5% des Jahresumsatzes
• Nicht freiwillig wie ISO 27001

2. Vollständige Mapping-Tabelle: ISO 27001:2022 → CRA Essential Requirements

Die folgende Tabelle mappt alle CRA Essential Requirements (Annex I) auf ISO 27001:2022 Controls und identifiziert Gaps.

2.1 Annex I, Section 1: Produktsicherheitsanforderungen

Zusammenfassung Section 1:

• Durchschnittliche Coverage: 67%
• Kritischste Gaps: Automatische Updates (1.5), Exploitation-Schutz (1.4), Attack Surface (2.4)

2.2 Annex I, Section 2: Schwachstellenmanagement-Prozesse

Zusammenfassung Section 2:

• Durchschnittliche Coverage: 48%
• Kritischste Gaps: CVD-Programm (2.3), 24h-Meldepflicht (2.5, 2.6), Support Period (2.8)

3. Die 10 kritischen Gaps und wie Sie sie schließen

Basierend auf der Mapping-Analyse sind dies die 10 kritischsten Gaps, die ISO 27001-zertifizierte Organisationen schließen müssen:

Gap 1: Software Bill of Materials (SBOM)

CRA-Anforderung: Jedes Produkt muss eine maschinenlesbare SBOM enthalten, die alle Komponenten und Abhängigkeiten dokumentiert.

ISO 27001 Status: Keine direkte Anforderung für SBOM.

Was Sie tun müssen:

1. Tool-Auswahl & Integration:
   • Implementierung von SBOM-Generierungs-Tools (CycloneDX, SPDX, Syft)
   • Integration in CI/CD-Pipeline für automatische SBOM-Generierung
   • Format: Bevorzugt CycloneDX 1.5+ oder SPDX 2.3+
2. SBOM-Inhalt:
   • Alle direkten und transitiven Abhängigkeiten
   • Versionsnummern
   • Lizenzen
   • Known Vulnerabilities (CVEs)
   • Component Hashes
3. Governance:
   • SBOM-Review als Release-Kriterium
   • Quarterly SBOM-Audits
   • SBOM-Archivierung (10 Jahre)

Prozess-Etablierung:

Code Commit → Build → SBOM Generation → SBOM Signing → 
SBOM Storage → SBOM Distribution (mit Produkt)

Zeitrahmen: 2-3 Monate

Gap 2: Coordinated Vulnerability Disclosure (CVD) Programm

CRA-Anforderung: Etablierung eines CVD-Programms gemäß ISO/IEC 29147 mit öffentlichem Disclosure-Prozess.

ISO 27001 Status: Incident Management vorhanden, aber kein formales CVD.

Was Sie tun müssen:

1. Vulnerability Disclosure Policy (VDP) erstellen:Beispiel-Struktur:
   • Scope: Welche Produkte/Systeme sind im Scope?
   • Reporting Channel: security@ihreorganisation.com
   • Response Times: Acknowledgment <72h, Triage <7 days
   • Disclosure Timeline: 90 days coordinated disclosure
   • Safe Harbor: Legal protection für Researcher
   • Recognition: Hall of Fame, Bug Bounty (optional)
2. Security Contact etablieren:
   • Registrierung von security.txt gemäß RFC 9116
   • Veröffentlichung auf Website und in Produktdokumentation
   • CSAF-Provider-Metadaten (für strukturierte Advisories)
3. Tooling:
   • Ticketsystem mit Security-Triage (Jira Security, HackerOne)
   • Schwachstellen-Datenbank intern
   • Advisory-Management (CSAF Format)

CVD-Workflow implementieren:

Report Received → Triage (Severity Scoring) → 
Validation (Reproduktion) → Fix Development →
Researcher Notification → Coordinated Disclosure (90d) →
Public Advisory → CVE Assignment

Zeitrahmen: 2-4 Monate

Gap 3: Automatische Sicherheitsupdates

CRA-Anforderung: Automatische Updates standardmäßig aktiviert (Opt-out für Nutzer), getrennt von Feature-Updates.

ISO 27001 Status: Update-Management vorhanden, aber keine Automatic-Update-Requirement.

Was Sie tun müssen:

1. Update-Architektur:
   • Secure Update Server Infrastruktur
   • Code Signing (Signatur aller Updates)
   • Update Verification (Client-seitige Signature-Checks)
   • Rollback-Mechanismus bei fehlgeschlagenen Updates
2. Update-Delivery:
   • Delta-Updates (Bandbreiten-Optimierung)
   • Staged Rollouts (Canary → Beta → Production)
   • Update-Priorisierung basierend auf Severity
3. User Experience:
   • Clear UI für Update-Status
   • Update-Historie
   • Opt-out-Option mit Warnhinweis
   • Emergency Update Notifications

Update-Typen trennen:

Zeitrahmen: 3-6 Monate

Gap 4: 24-Stunden-Incident-Reporting

CRA-Anforderung: Aktiv ausgenutzte Schwachstellen und schwere Incidents binnen 24 Stunden an CSIRT melden.

ISO 27001 Status: Incident Response vorhanden, aber keine 24h-Meldefrist.

Was Sie tun müssen:

1. Incident-Classification verschärfen:CRA-Reportable Incidents:Classification: Critical → 24h Reporting
   • Aktiv ausgenutzte Schwachstellen (confirmed exploitation)
   • Schwere Cybersecurity-Incidents (data breach, DoS, etc.)
   • Incidents mit signifikanter Nutzerauswirkung
2. Single Reporting Platform (SRP) Integration:
   • EU entwickelt zentrale Meldeplattform
   • API-Integration vorbereiten
   • Automatisierte Meldung wo möglich
3. 24/7 On-Call:
   • Security On-Call Rotation
   • Eskalations-Matrix
   • Runbooks für CRA-Reporting

Reporting-Workflow:

Incident Detection → Severity Assessment (<2h) →
[IF CRITICAL] → CSIRT Notification (<24h) →
Follow-up Reports (Updates every 72h) →
Final Report (nach Remediation)

Zeitrahmen: 1-2 Monate

Gap 5: Produktspezifische Risikobewertung

CRA-Anforderung: Cybersecurity-Risikobewertung für jedes einzelne Produkt vor Markteinführung.

ISO 27001 Status: Organisatorisches Risk Assessment vorhanden, aber nicht produktspezifisch.

Was Sie tun müssen:

1. Produkt Risk Assessment Template:Für jedes Produkt dokumentieren:
   • Threat Model (STRIDE, PASTA)
   • Attack Vectors und Attack Surface
   • Datenflüsse (DFDs)
   • Trust Boundaries
   • Risiko-Register mit Mitigations
   • Residual Risks
2. Threat Modeling Integration:
   • Threat Modeling in Design Phase
   • Tool-Support (Microsoft Threat Modeling Tool, OWASP Threat Dragon)
   • Peer-Review von Threat Models
   • Update bei Major Product Changes
3. Risk Treatment Plan pro Produkt:
   • Linked zu organisatorischem ISMS Risk Treatment
   • Produkt-spezifische Security Controls
   • Acceptance Criteria für Release
4. Documentation:
   • Risk Assessment Report (10 Jahre Aufbewahrung)
   • Security Architecture Documents
   • Design Security Review Sign-offs

Zeitrahmen: 2-3 Monate (Framework), dann ongoing

Gap 6: Support Period Definition & Communication

CRA-Anforderung: Klare Kommunikation des Support-Zeitraums, während dem Sicherheitsupdates bereitgestellt werden.

ISO 27001 Status: Keine Anforderung für Support-Period-Definition.

Was Sie tun müssen:

1. Support Policy definieren:Beispiel-Policy:
   • Standard Products: 5 Jahre ab Markteinführung
   • Critical Products: 10 Jahre + Extended Support Option
   • End-of-Life: 12 Monate Notice vor Support-Ende
   • Extended Support: Kostenpflichtige Option verfügbar
2. Kommunikationskanäle:
   • Support Period in Produktdokumentation
   • Auf Website veröffentlicht
   • In SBOM enthalten (versionedExternalReference)
   • End-of-Life-Notifications an registrierte Nutzer
3. Post-Support-Handling:
   • Migration Guides zu neueren Versionen
   • Critical Security-Only Updates (optional, kostenpflichtig)
   • Deaktivierung von Update-Servern nach EOL + Grace Period

Support-Matrix:

Zeitrahmen: 1-2 Monate

Gap 7: Pre-Release Vulnerability Scanning

CRA-Anforderung: Keine bekannten exploitbaren Schwachstellen bei Markteinführung.

ISO 27001 Status: Security Testing vorhanden (A.8.29), aber keine explizite "Zero Known Vulnerabilities"-Anforderung.

Was Sie tun müssen:

1. Vulnerability Remediation SLAs:
   • Critical: Fix within 7 days
   • High: Fix within 30 days
   • Medium: Fix within 90 days
   • Low: Fix within 180 days or next major release
2. Continuous Monitoring:
   • Subscribe zu Security Advisories aller Dependencies
   • Automated Alerts bei neuen CVEs in verwendeten Komponenten
   • Rapid Response Process für Zero-Days

Release Gates:

Multi-Layer Scanning:

Zeitrahmen: 3-4 Monate (Tool Integration + Process)

Gap 8: Secure Coding Standards & Training

CRA-Anforderung: Sichere Programmierpraktiken während des gesamten Entwicklungszyklus.

ISO 27001 Status: A.8.28 (Secure Coding) vorhanden, aber oft nicht detailliert genug für CRA.

Was Sie tun müssen:

1. Secure Coding Guidelines entwickeln:Basis: OWASP Secure Coding PracticesPlus: Language-specific Guidelines (Java, C++, Python, etc.)Plus: Framework-specific (React, Angular, Spring, etc.)Mandatory Topics:
   • Input Validation & Sanitization
   • Output Encoding
   • Authentication & Session Management
   • Cryptography (welche Algorithmen, Key Lengths)
   • Error Handling & Logging
   • Memory Safety (für C/C++)
   • SQL Injection Prevention
   • XSS Prevention
   • CSRF Protection
2. Developer Training:
   • Mandatory Secure Coding Training (16h) für alle Developer
   • Annual Refresher (4h)
   • Specialized Training (Web Security, Mobile Security, IoT Security)
   • Hands-on Labs (WebGoat, Juice Shop, etc.)
3. Secure Code Review Process:
   • Peer Code Reviews mit Security Checklist
   • Automated Code Review (SAST Integration in PR-Process)
   • Security Champion Program (trained Security-minded Developers)
4. Knowledge Base:
   • Internal Secure Coding Wiki
   • Code Snippets & Patterns
   • Common Vulnerability Examples & Fixes
   • Post-Incident Learnings

Zeitrahmen: 3-6 Monate (rollout across teams)

Gap 9: CE-Kennzeichnung & Technical Documentation

CRA-Anforderung: CE-Kennzeichnung als Konformitätsnachweis, umfassende technische Dokumentation (10 Jahre).

ISO 27001 Status: ISMS-Dokumentation vorhanden, aber nicht CRA-spezifisch.

Was Sie tun müssen:

1. Technical Documentation Package erstellen:Required Documents pro Produkt:
   • ✓ EU Declaration of Conformity
   • ✓ Cybersecurity Risk Assessment
   • ✓ Security Architecture Description
   • ✓ SBOM (alle Versionen)
   • ✓ Vulnerability Handling Documentation
   • ✓ Test Reports (Security Testing Results)
   • ✓ User Security Documentation
   • ✓ Support Period Declaration
   • ✓ Change History (alle Security-relevanten Changes)
2. Dokumenten-Management:
   • Zentrales Repository für Technical Documentation
   • Versionskontrolle
   • Zugriffskontrollen (nur autorisiertes Personal)
   • 10-Jahres-Archivierung (von Markteinführung oder Support-Ende)
3. CE-Kennzeichnung:
   • CE-Mark auf Produkt anbringen (Verpackung oder digital)
   • Format gemäß Regulation (EU) 765/2008
   • Notified Body Number (falls relevant)

Konformitätsbewertung durchführen:

Zeitrahmen: 2-4 Monate/Produkt

Gap 10: Supply Chain Security & Component Tracking

CRA-Anforderung: Verantwortung für gesamte Supply Chain, einschließlich Drittkomponenten.

ISO 27001 Status: A.5.19-5.22 (Supplier Relationships) vorhanden, aber nicht produktspezifisch.

Was Sie tun müssen:

1. Supplier Security Assessment erweitern:Für Software-/Hardware-Suppliers zusätzlich prüfen:
   • ✓ Haben sie eigenes SBOM-Management?
   • ✓ CVD-Programm vorhanden?
   • ✓ Security Patch SLAs?
   • ✓ End-of-Life-Policy?
   • ✓ Werden sie CRA-compliant sein?
2. Dependency Management:
   • Dependency-Tracking-Tool (Dependency-Track, Sonatype Nexus)
   • Automatisierte Vulnerability Scanning aller Dependencies
   • License Compliance Checking
   • Policy: Nur approved Dependencies verwenden
3. Software Supply Chain Security:
   • SLSA (Supply-chain Levels for Software Artifacts) Level implementieren
   • Build Provenance (Sigstore, in-toto)
   • Artifact Verification (Checksum, Signatures)
   • Reproducible Builds wo möglich
4. Contractual Requirements:Update Supplier Contracts mit CRA-relevanten Klauseln:
   • Vulnerability Notification Obligations
   • Patch Delivery SLAs
   • SBOM Provision
   • Right to Audit

Zeitrahmen: 4-6 Monate

4. Priorisierte Implementierungs-Roadmap

Zeitrahmen: November 2025 - November 2027 (764 Tage)

Phase 1: Foundation (November 2025 - März 2026, 4 Monate)

Ziel: Kritischste Gaps schließen, Quick Wins realisieren

Phase 2: Scale (April - September 2026, 6 Monate)

Ziel: Alle Produkte erfassen, Prozesse standardisieren, Reporting-Fähigkeit aufbauen

Phase 3: Finalization (Oktober 2026 - September 2027, 12 Monate)

Ziel: 100% Compliance, Zertifizierungen, Kontinuierliche Verbesserung

5. Quick-Check: Ist Ihre Organisation bereit?

5.1 CRA Readiness Assessment

Bewerten Sie Ihre Organisation (je 0-5 Punkte):

Governance & Prozesse:

• [ ] Etablierte ISMS-Governance mit Management-Commitment (ISO 27001) (0-5)
• [ ] Produkt-Security ist in Produktentwicklung integriert (0-5)
• [ ] Incident Response mit <24h-Capability vorhanden (0-5)
• [ ] Supply Chain Management mit Security-Fokus (0-5)

Technische Fähigkeiten:

• [ ] CI/CD-Pipeline etabliert und sicher (0-5)
• [ ] Vulnerability Scanning (SAST/DAST) im Einsatz (0-5)
• [ ] Secure Coding Practices dokumentiert und trainiert (0-5)
• [ ] Update-Mechanismen in Produkten vorhanden (0-5)

Dokumentation & Compliance:

• [ ] Technische Dokumentation systematisch gepflegt (0-5)
• [ ] Risikomanagement-Prozesse dokumentiert (0-5)
• [ ] Audit-Readiness (Internal Audits regelmäßig) (0-5)
• [ ] Regulatorische Anforderungen werden getrackt (0-5)

Produkt-spezifisch:

• [ ] SBOM-Fähigkeit vorhanden oder einfach implementierbar (0-5)
• [ ] Produktarchitektur erlaubt automatische Updates (0-5)
• [ ] Security by Design in Produktdesign-Prozessen (0-5)
• [ ] Support Lifecycle für Produkte definiert (0-5)

Scoring:

6. Zusammenfassung und nächste Schritte

6.1 Key Takeaways

1. ISO 27001:2022 ist ein exzellentes Fundament für CRA-Compliance, deckt aber nur einen Teil der Anforderungen ab.
2. Die 10 kritischen Gaps müssen systematisch geschlossen werden:
   • SBOM (Priorität 1)
   • CVD-Programm (Priorität 1)
   • Automatische Updates (Priorität 2)
   • 24h-Reporting (Priorität 1)
   • Produktspezifische Risk Assessments (Priorität 2)
   • Support Period Definition (Priorität 3)
   • Pre-Release Vulnerability Scanning (Priorität 2)
   • Secure Coding Standards (Priorität 2)
   • CE-Kennzeichnung & Dokumentation (Priorität 3)
   • Supply Chain Security (Priorität 2)
3. Zeitrahmen: 18-24 Monate für vollständige Compliance
4. Priorisierung: Die Gaps müssen nach Kritikalität und Abhängigkeiten angegangen werden (siehe Roadmap in Abschnitt 4)

6.2 Ihre nächsten Schritte (nächste 4 Wochen)

Woche 1: Assessment & Planning

• [ ] Führen Sie das CRA Readiness Assessment durch (Abschnitt 5.1)
• [ ] Erstellen Sie vollständiges Produktinventar mit CRA-Klassifizierung
• [ ] Identifizieren Sie interne Stakeholder und etablieren Sie Steering Committee

Woche 2: Gap-Analyse

• [ ] Nutzen Sie die Mapping-Tabelle (Abschnitt 2) für detaillierte Gap-Analyse
• [ ] Priorisieren Sie Gaps nach Kritikalität und Aufwand
• [ ] Erstellen Sie groben Projektplan

Woche 3: Ressourcen-Planung

• [ ] Definieren Sie Team (intern + externe Unterstützung falls benötigt)
• [ ] Identifizieren Sie notwendige Tools und Budget
• [ ] Erstellen Sie erste Roadmap-Version

Woche 4: Projektstart

• [ ] Erstellen Sie detaillierte Implementierungs-Roadmap basierend auf Abschnitt 4
• [ ] Starten Sie Quick Wins (z.B. CVD-Policy-Draft, security.txt)
• [ ] Beginnen Sie Tool-Evaluierung (SBOM, Scanning)

6.3 Empfohlene Ressourcen

Offizielle EU-Ressourcen:

• CRA Full Text: https://eur-lex.europa.eu/eli/reg/2024/2847
• ENISA CRA Hub: https://www.enisa.europa.eu/topics/cyber-resilience-act

Standards & Guidelines:

• ISO/IEC 29147:2018 (Vulnerability Disclosure)
• ISO/IEC 30111:2019 (Vulnerability Handling)
• NIST SP 800-218 (Secure Software Development Framework)
• OWASP SAMM (Software Assurance Maturity Model)

Community & Support:

• Linux Foundation: CRA Guidance for Open Source
• DIGITAL Europe: Industry Working Groups
• National Cybersecurity Agencies: BSI (DE), ANSSI (FR), NCSC (NL, UK)

Anhang: Checkliste für ISO 27001-zertifizierte Organisationen

Monatliche CRA-Compliance-Checkliste

Organisatorisch:

• [ ] Steering Committee Meeting durchgeführt
• [ ] Progress gegen Roadmap getrackt
• [ ] Risiken und Blockers identifiziert
• [ ] Budget-Status überprüft

SBOM:

• [ ] SBOM für alle neuen/geänderten Produkte generiert
• [ ] SBOM-Qualitätschecks (Vollständigkeit) durchgeführt
• [ ] Neue Komponenten auf Vulnerabilities gescannt

Vulnerability Management:

• [ ] Alle neuen CVEs in verwendeten Komponenten überprüft
• [ ] Kritische Vulnerabilities binnen SLA gefixt
• [ ] CVD-Reports bearbeitet und beantwortet (wenn vorhanden)

Incident Response:

• [ ] Incidents auf CRA-Reportierungspflicht geprüft
• [ ] 24h-Reporting-SLA eingehalten (falls relevant)
• [ ] Post-Incident Reviews durchgeführt

Security Testing:

• [ ] SAST/DAST/SCA Scans durchgeführt
• [ ] Scan-Ergebnisse triaged
• [ ] Release Gates enforced

Dokumentation:

• [ ] Technical Documentation für neue Releases aktualisiert
• [ ] Änderungen in Support Periods kommuniziert
• [ ] Audit-Trail gepflegt

Training:

• [ ] Neue Mitarbeiter in Secure Coding trainiert
• [ ] Security Awareness Kampagne durchgeführt

Disclaimer: Dieses Dokument dient Informationszwecken und stellt keine Rechtsberatung dar.