breakpilot-compliance/backend-compliance/migrations/059_wiki_cra_annex_i_detail.sql

-- Migration 059: CRA Annex I — Detaillierte Essential Cybersecurity Requirements
-- Erweitert den bestehenden Wiki-Artikel 'cra-security-controls' um Part 1 + Part 2,
-- Produktklassifizierung und ISO 27001 Mapping.
-- Zusaetzlich: Neuer Artikel fuer CRA-Produktklassifizierung und Konformitaetsbewertung.

-- ============================================================================
-- 1) Update: CRA Security Controls (Annex I) — Vollstaendige 8-Kategorien-Struktur
-- ============================================================================
UPDATE compliance_wiki_articles
SET
    title   = 'CRA Annex I — Essential Cybersecurity Requirements (Vollstaendig)',
    summary = 'Annex I des CRA definiert die wesentlichen Cybersicherheitsanforderungen in zwei Teilen: Teil 1 (Produktsicherheit, 11 Anforderungen) und Teil 2 (Schwachstellenbehandlung, 8 Anforderungen). Daraus ergeben sich rund 35 konkrete Security-Controls in 8 Kategorien.',
    content = '## Ueberblick

Der **EU Cyber Resilience Act (CRA)**, Verordnung (EU) 2024/2847, legt in **Annex I** die **Essential Cybersecurity Requirements** fest, die alle Produkte mit digitalen Elementen erfuellen muessen. Annex I besteht aus zwei Teilen:

- **Teil 1 — Sicherheitsanforderungen an Produkte** (11 Kernanforderungen)
- **Teil 2 — Anforderungen an die Schwachstellenbehandlung** (8 Prozessanforderungen)

Daraus lassen sich etwa **35 konkrete Security-Controls** in **8 thematischen Kategorien** ableiten. Diese Controls bilden die Grundlage fuer eine Cybersecurity-Compliance-Strategie.

---

## Teil 1: Sicherheitsanforderungen an Produkte

### Kategorie 1 — Secure-by-Design und Architektur

Diese Controls stellen sicher, dass Sicherheit von Anfang an in die Produktarchitektur integriert wird.

| # | Control | CRA-Referenz | Beschreibung | ISO 27001 Mapping |
|---|---------|-------------|-------------|-------------------|
| 1 | **Secure-by-Default-Konfiguration** | Annex I, 1(1) | Produkte muessen mit sicheren Standardeinstellungen ausgeliefert werden. Keine offenen Ports, keine aktivierten Debug-Schnittstellen, keine unnoetig laufenden Dienste. | A.8.9 |
| 2 | **Minimale Angriffsflaeche** | Annex I, 1(2) | Nur notwendige Schnittstellen, Dienste und Protokolle aktivieren. Jede zusaetzliche Funktionalitaet vergroessert die Angriffsflaeche und muss einzeln gerechtfertigt werden. | A.8.9, A.8.20 |
| 3 | **Sichere Systemarchitektur** | Annex I, 1(3) | Sicherheitskritische Komponenten muessen isoliert werden (Sandboxing, Containerisierung, Privilege Separation). Defense-in-Depth-Prinzip anwenden. | A.8.27 |
| 4 | **Least-Privilege-Prinzip** | Annex I, 1(3)(d) | Jede Komponente, jeder Prozess und jeder Benutzer erhaelt nur die minimal notwendigen Berechtigungen. Privilegien-Eskalation muss verhindert werden. | A.8.2, A.8.3 |
| 5 | **Manipulationsschutz** | Annex I, 1(3)(c) | Schutz vor unautorisierter Aenderung von Software und Konfiguration durch Integritaetsmechanismen (Code Signing, Secure Boot, TPM). | A.8.24 |
| 6 | **Integritaetspruefung** | Annex I, 1(3)(c) | Automatische Ueberpruefung der Integritaet von Software, Firmware und Konfigurationsdaten bei Start und Laufzeit. Hash-basierte Validierung und digitale Signaturen. | A.8.24 |

### Kategorie 2 — Authentifizierung und Zugriffskontrolle

Controls zur Sicherstellung, dass nur autorisierte Personen und Systeme Zugriff erhalten.

| # | Control | CRA-Referenz | Beschreibung | ISO 27001 Mapping |
|---|---------|-------------|-------------|-------------------|
| 7 | **Starke Authentifizierung** | Annex I, 1(3)(d) | Implementierung sicherer Authentifizierungsmechanismen. Multi-Faktor-Authentifizierung fuer administrative Zugriffe. Unterstuetzung moderner Standards (FIDO2, WebAuthn). | A.8.5 |
| 8 | **Keine Default-Passwoerter** | Annex I, 1(3)(d) | Produkte duerfen keine universellen Standardpasswoerter verwenden. Jedes Geraet muss ein individuelles Passwort erhalten oder den Benutzer zur Aenderung bei Ersteinrichtung zwingen. | A.8.5 |
| 9 | **Sicheres Credential-Management** | Annex I, 1(3)(d) | Zugangsdaten muessen verschluesselt gespeichert werden (bcrypt, Argon2id). Keine Klartextspeicherung. API-Keys und Tokens regelmaessig rotieren. | A.8.5 |
| 10 | **Sitzungsmanagement** | Annex I, 1(3)(d) | Sichere Session-Verwaltung mit Timeout, Token-Binding und Session-Invalidierung bei Logout oder Passwortwechsel. CSRF-Schutz implementieren. | A.8.5 |
| 11 | **Brute-Force-Schutz** | Annex I, 1(3)(d) | Schutz vor Brute-Force- und Credential-Stuffing-Angriffen durch Rate Limiting, Account Lockout und CAPTCHA-Mechanismen. | A.8.5, A.8.16 |
| 12 | **Rollenbasierte Autorisierung** | Annex I, 1(3)(d) | Implementierung von RBAC (Role-Based Access Control). Trennung von administrativen und Nutzerfunktionen. Prinzip der geringsten Privilegien durchsetzen. | A.8.2, A.8.3 |

### Kategorie 3 — Kryptografie und Datenschutz

Controls zum Schutz von Daten durch kryptografische Verfahren.

| # | Control | CRA-Referenz | Beschreibung | ISO 27001 Mapping |
|---|---------|-------------|-------------|-------------------|
| 13 | **Verschluesselung sensibler Daten** | Annex I, 1(3)(e) | Alle sensiblen Daten muessen verschluesselt werden — sowohl bei der Speicherung (at rest, AES-256) als auch bei der Uebertragung (in transit, TLS 1.2+). | A.8.24 |
| 14 | **Speicher-Schutz (Data at Rest)** | Annex I, 1(3)(e) | Verschluesselung gespeicherter Daten auf Festplatten, in Datenbanken und Backups. Schluessel getrennt von Daten speichern. | A.8.24 |
| 15 | **Transport-Schutz (Data in Transit)** | Annex I, 1(3)(e) | Alle Netzwerkkommunikation ueber TLS 1.2 oder hoeher. Veraltete Protokolle (SSL, TLS 1.0/1.1) deaktivieren. Certificate Pinning fuer kritische Verbindungen. | A.8.24 |
| 16 | **Sicheres Schluesselmanagement** | Annex I, 1(3)(e) | Kryptografische Schluessel in HSM oder Vault speichern. Regelmaessige Rotation (mind. jaehrlich). Dokumentation der Schluessel-Lebenszyklen. Sofortige Rotation bei Kompromittierungsverdacht. | A.8.24 |
| 17 | **Datenminimierung** | Annex I, 1(3)(f) | Nur Daten erfassen und verarbeiten, die fuer die Produktfunktion erforderlich sind. Personenbezogene Daten gemaess DSGVO-Grundsaetzen behandeln. | A.8.10, A.8.11 |

### Kategorie 4 — Secure Software Development Lifecycle

Controls fuer sichere Softwareentwicklung ueber den gesamten Lebenszyklus.

| # | Control | CRA-Referenz | Beschreibung | ISO 27001 Mapping |
|---|---------|-------------|-------------|-------------------|
| 18 | **Strukturierter SSDLC** | Annex I, 1(1) | Implementierung eines formalen Secure Software Development Lifecycle mit definierten Security Gates in jeder Phase (Requirements, Design, Implementation, Test, Release). | A.8.25, A.8.26 |
| 19 | **Systematische Code Reviews** | Annex I, 1(1) | Peer Reviews mit Security-Fokus fuer jeden Code-Commit. Einsatz von Checklisten fuer OWASP Top 10 und CWE Top 25. Security Champions in jedem Entwicklerteam. | A.8.25 |
| 20 | **Automatisierte Sicherheitstests** | Annex I, 1(1) | Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST) und Software Composition Analysis (SCA) in der CI/CD-Pipeline. Secrets Detection fuer eingebettete Zugangsdaten. | A.8.25 |
| 21 | **Supply-Chain-Security** | Annex I, 1(5) | Systematische Pruefung aller Drittanbieter-Komponenten auf Schwachstellen und Lizenz-Compliance. Vertrauenswuerdigkeit von Lieferanten bewerten. | A.5.19, A.5.21 |
| 22 | **Dependency-Monitoring** | Annex I, 1(5) | Kontinuierliche Ueberwachung aller Abhaengigkeiten auf bekannte Schwachstellen (CVE). Automatische Benachrichtigung bei neuen CVEs in verwendeten Bibliotheken. | A.8.8, A.8.25 |
| 23 | **Software Bill of Materials (SBOM)** | Annex I, 1(5) | Fuer jedes Produkt ein maschinenlesbares SBOM fuehren (CycloneDX oder SPDX). Mindestens Top-Level-Abhaengigkeiten mit Name, Version und Lizenz dokumentieren. SBOM bei jedem Release aktualisieren. | A.8.25 |

### Kategorie 5 — Logging, Monitoring und Anomalie-Erkennung

Controls zur Erkennung und Nachverfolgung von Sicherheitsereignissen.

| # | Control | CRA-Referenz | Beschreibung | ISO 27001 Mapping |
|---|---------|-------------|-------------|-------------------|
| 24 | **Security-Logging** | Annex I, 1(3)(g) | Protokollierung aller sicherheitsrelevanten Ereignisse: Login-Versuche, Berechtigungsaenderungen, administrative Aktionen, API-Zugriffe, Fehler und Ausnahmen. Logs muessen Zeitstempel, Akteur, Aktion und Ergebnis enthalten. | A.8.15 |
| 25 | **Ereignis-Monitoring** | Annex I, 1(3)(g) | Zentrale Sammlung und Echtzeit-Ueberwachung sicherheitsrelevanter Events. Einsatz eines SIEM-Systems oder vergleichbarer Loesung. Korrelation von Events aus verschiedenen Quellen. | A.8.16 |
| 26 | **Anomalie-Erkennung** | Annex I, 1(3)(g) | Automatische Erkennung von Angriffsmustern und ungewoehnlichem Verhalten. Alarmierung bei Abweichungen von Baseline-Verhalten. Integration von Threat Intelligence Feeds. | A.8.16 |
| 27 | **Log-Integritaet und -Aufbewahrung** | Annex I, 1(3)(g) | Logs muessen manipulationssicher gespeichert werden (append-only, signiert oder WORM). Aufbewahrung mindestens 12 Monate. Zugriff auf Logs nur fuer autorisiertes Security-Personal. | A.8.15 |

### Kategorie 6 — Update- und Patch-Management

Controls fuer die sichere Bereitstellung und Installation von Updates.

| # | Control | CRA-Referenz | Beschreibung | ISO 27001 Mapping |
|---|---------|-------------|-------------|-------------------|
| 28 | **Sichere Update-Mechanismen** | Annex I, 1(4) | Updates muessen ueber sichere Kanaele verteilt werden (HTTPS, signierte Pakete). Automatische oder einfach zugaengliche Update-Moeglichkeit fuer Endnutzer. Rollback-Faehigkeit bei fehlerhaften Updates. | A.8.8, A.8.19 |
| 29 | **Update-Authentizitaet** | Annex I, 1(4) | Alle Updates muessen digital signiert sein. Signaturpruefung vor Installation erzwingen. Verwendung vertrauenswuerdiger Signaturschluessel mit dokumentierter Key Ceremony. | A.8.24 |
| 30 | **Update-Integritaet** | Annex I, 1(4) | Integritaetspruefung jedes Update-Pakets vor und nach Installation (Hash-Vergleich, Signatur-Verifikation). Manipulation waehrend der Uebertragung erkennen und ablehnen. | A.8.24 |
| 31 | **Lifecycle-Support** | Annex I, 1(4) | Security-Updates waehrend des gesamten erwarteten Produktlebenszyklus bereitstellen — mindestens **5 Jahre** ab Inverkehrbringen oder die erwartete Nutzungsdauer, je nachdem welcher Zeitraum laenger ist. End-of-Life klar kommunizieren. | A.8.8 |

---

## Teil 2: Anforderungen an die Schwachstellenbehandlung

### Kategorie 7 — Vulnerability Management

Controls fuer die systematische Identifikation, Bewertung und Behebung von Schwachstellen.

| # | Control | CRA-Referenz | Beschreibung | ISO 27001 Mapping |
|---|---------|-------------|-------------|-------------------|
| 32 | **Schwachstellen-Identifikation** | Annex I, 2(1) | Kontinuierliches CVE-Monitoring aller eingesetzten Komponenten. Regelmaessige Vulnerability Scans (woechentlich automatisiert). Bug-Bounty-Programme oder Responsible-Disclosure-Kanaele einrichten. | A.8.8 |
| 33 | **SBOM-Pflege und Analyse** | Annex I, 2(1) | SBOM aktuell halten und kontinuierlich gegen CVE-Datenbanken pruefen. Automatische Alarmierung bei neu entdeckten Schwachstellen in verwendeten Komponenten. | A.8.8, A.8.25 |
| 34 | **Risikobasierte Priorisierung** | Annex I, 2(2) | Schwachstellen nach CVSS-Score und tatsaechlichem Risiko priorisieren. Reaktionszeiten nach Schweregrad: Kritisch (24–72h), Hoch (7 Tage), Mittel (30 Tage), Niedrig (naechster Zyklus). | A.8.8 |
| 35 | **Coordinated Vulnerability Disclosure** | Annex I, 2(5) | Veroeffentlichung einer CVD-Policy mit klarem Meldeprozess. Kontaktadresse fuer Sicherheitsforscher bereitstellen. Eingangsbestaetigung innerhalb von 5 Werktagen. Koordinierte Veroeffentlichung nach Patch-Verfuegbarkeit. | A.5.5, A.5.6 |

### Kategorie 8 — Incident Response und Meldepflichten

Controls fuer die Erkennung, Behandlung und Meldung von Sicherheitsvorfaellen.

| # | Control | CRA-Referenz | Beschreibung | ISO 27001 Mapping |
|---|---------|-------------|-------------|-------------------|
| 36 | **Incident-Response-Prozess** | Annex I, 2(5) | Dokumentierter Prozess mit definierten Phasen: Detection → Classification → Containment → Investigation → Recovery → Reporting → Lessons Learned. Regelmaessige Uebungen (Tabletop Exercises). | A.5.24, A.5.25, A.5.26 |
| 37 | **Fruehwarnung (24h)** | Annex I, 2(7) + Art. 14(2)(a) | Bei aktiv ausgenutzten Schwachstellen oder schweren Vorfaellen: Fruehwarnung an ENISA und/oder zustaendige nationale Behoerde innerhalb von **24 Stunden** nach Kenntniserlangung. | A.5.24, A.5.26 |
| 38 | **Detaillierter Vorfallsbericht (72h)** | Annex I, 2(7) + Art. 14(2)(b) | Innerhalb von **72 Stunden**: Detaillierter Bericht mit Umfang, Auswirkung, Ursachenanalyse und eingeleiteten Gegenmassnahmen. Bei personenbezogenen Daten zusaetzlich Art. 33/34 DSGVO beachten. | A.5.24, A.5.26 |
| 39 | **Patch-Bereitstellung** | Annex I, 2(3) | Patches fuer gemeldete und bestaetigte Schwachstellen so schnell wie moeglich bereitstellen. Sicherheitshinweise (Security Advisories) an Kunden veroeffentlichen. CSAF-Format fuer maschinenlesbare Advisories empfohlen. | A.8.8 |
| 40 | **Dokumentation und Nachbereitung** | Annex I, 2(6) | Alle Schwachstellen und Vorfaelle lueckenlos dokumentieren und fuer mindestens 10 Jahre aufbewahren. Lessons-Learned-Prozess nach jedem bedeutenden Vorfall. Ergebnisse in Risikobewertung einfliessen lassen. | A.5.27 |

---

## Produktklassifizierung nach CRA

Der CRA unterscheidet drei Produktkategorien mit unterschiedlichen Konformitaetsanforderungen:

### Standardprodukte (Default)

**Beispiele:** einfache Apps, Desktop-Software, Spiele, Foto-Editoren

- **Konformitaetsbewertung:** Selbstbewertung (Modul A)
- **Anforderungen:** Alle Annex-I-Anforderungen, aber einfachster Nachweis
- **Betrifft:** ca. 90% aller Produkte

### Wichtige Produkte (Annex III) — Klasse I

**Beispiele:** Passwort-Manager, VPN-Software, Firewalls, Router, Smart-Home-Systeme, IoT-Geraete mit Sensorfunktion, SIEM-Systeme

- **Konformitaetsbewertung:** Harmonisierte Standards oder Drittanbieter-Bewertung
- **Anforderungen:** Alle Annex-I-Anforderungen + erhoehte Nachweispflichten
- **Betrifft:** ca. 8% aller Produkte

### Wichtige Produkte — Klasse II

**Beispiele:** Betriebssysteme, Hypervisoren, Container-Runtimes, Public-Key-Infrastruktur, industrielle Steuerungssysteme (ICS/SCADA)

- **Konformitaetsbewertung:** Verpflichtende Drittanbieter-Bewertung durch benannte Stelle
- **Anforderungen:** Alle Annex-I-Anforderungen + strengste Nachweispflichten
- **Betrifft:** ca. 2% aller Produkte

### Kritische Produkte (Annex IV)

**Beispiele:** Hardware-Security-Module (HSM), Smartcard-Chips, Secure Elements, Smart-Meter-Gateways

- **Konformitaetsbewertung:** Europaeisches Cybersicherheitszertifikat erforderlich (EUCC)
- **Anforderungen:** Hoechste Stufe — europaeische Zertifizierung obligatorisch

---

## Zuordnung der Controls zu Dokumenten

Diese 40 Controls koennen automatisiert zu folgenden Compliance-Dokumenten fuehren:

| Dokument | Controls | Beschreibung |
|----------|----------|-------------|
| **Cybersecurity Policy** | 1–40 | Uebergreifendes Grundsatzdokument fuer Cybersicherheit |
| **Secure Development Policy** | 18–23 | Richtlinie fuer den sicheren Entwicklungsprozess (SSDLC) |
| **Vulnerability Management Policy** | 32–35, 39 | CVD, Patching, SBOM-Analyse |
| **Incident Response Plan** | 36–38, 40 | 24h/72h Meldung, Eskalation, Nachbereitung |
| **Access Control Policy** | 7–12 | Authentifizierung, Autorisierung, Passwort-Richtlinie |
| **Cryptographic Policy** | 13–17 | Verschluesselung, Schluesselmanagement, Datenschutz |
| **Update/Patch Policy** | 28–31 | Update-Mechanismen, Signierung, Lifecycle-Support |
| **Logging & Monitoring Policy** | 24–27 | Security-Logging, SIEM, Anomalie-Erkennung |

---

## Zeitplan fuer die Umsetzung

| Datum | Meilenstein |
|-------|------------|
| 10.12.2024 | CRA in Kraft getreten |
| 11.06.2026 | Konformitaetsbewertungsstellen muessen benannt sein |
| 11.09.2026 | **Meldepflichten aktiv** (Controls 37, 38) |
| 11.12.2027 | **Volle Anwendung** — alle 40 Controls muessen umgesetzt sein, CE-Kennzeichnung erforderlich |

---

## Sanktionen bei Nicht-Einhaltung

| Verstoss | Maximales Bussgeld |
|----------|-------------------|
| Wesentliche Anforderungen (Annex I) | 15 Mio. EUR oder 2,5% des weltweiten Jahresumsatzes |
| Sonstige Pflichten | 10 Mio. EUR oder 2% des weltweiten Jahresumsatzes |
| Falsche/unvollstaendige Informationen | 5 Mio. EUR oder 1% des weltweiten Jahresumsatzes |',
    legal_refs = ARRAY['Annex I CRA', 'Annex III CRA', 'Annex IV CRA', 'Art. 13 CRA', 'Art. 14 CRA', 'Art. 15 CRA', 'Art. 64 CRA', '(EU) 2024/2847'],
    tags = ARRAY['security-controls', 'annex-i', 'secure-by-design', 'authentifizierung', 'kryptografie', 'sbom', 'vulnerability', 'patching', 'incident-response', 'produktklassifizierung', 'iso-27001', 'ssdlc'],
    relevance = 'critical',
    updated_at = NOW()
WHERE id = 'cra-security-controls';

-- ============================================================================
-- 2) Neuer Artikel: CRA-Konformitaetsbewertung — Praktischer Leitfaden
-- ============================================================================
INSERT INTO compliance_wiki_articles (id, category_id, title, summary, content, legal_refs, tags, relevance, source_urls) VALUES
('cra-konformitaet', 'cra',
 'CRA-Konformitaetsbewertung — Praktischer Leitfaden',
 'Schritt-fuer-Schritt-Anleitung zur CRA-Konformitaetsbewertung: Produktklassifizierung, Dokumentation, Self-Assessment vs. Drittanbieter-Pruefung, CE-Kennzeichnung.',
 '## Ueberblick

Jeder Hersteller muss vor dem Inverkehrbringen eine **Konformitaetsbewertung** durchfuehren, um nachzuweisen, dass sein Produkt die Essential Cybersecurity Requirements (Annex I) erfuellt. Der Aufwand haengt von der Produktkategorie ab.

## Schritt 1: Produkt klassifizieren

Bestimmen Sie, ob Ihr Produkt unter eine der Sonderkategorien faellt:

### Entscheidungsbaum

```
Ist das Produkt in Annex IV gelistet?
  → Ja: Kritisches Produkt → Europaeische Zertifizierung (EUCC)
  → Nein: Weiter

Ist das Produkt in Annex III, Klasse II gelistet?
  → Ja: Wichtig Klasse II → Drittanbieter-Bewertung (Pflicht)
  → Nein: Weiter

Ist das Produkt in Annex III, Klasse I gelistet?
  → Ja: Wichtig Klasse I → Harmonisierte Standards ODER Drittanbieter
  → Nein: Standardprodukt → Selbstbewertung (Modul A)
```

## Schritt 2: Cybersecurity-Risikobewertung

Fuehren Sie eine systematische Risikoanalyse durch:

1. **Assets identifizieren** — Welche Daten verarbeitet das Produkt? Welche Schnittstellen hat es?
2. **Bedrohungen analysieren** — STRIDE-Methodik oder vergleichbar anwenden
3. **Schwachstellen bewerten** — Bekannte CVEs, Design-Schwaechen, Konfigurationsfehler
4. **Risiken priorisieren** — Eintrittswahrscheinlichkeit × Auswirkung
5. **Massnahmen definieren** — Welche Controls aus Annex I adressieren welches Risiko?

## Schritt 3: Controls implementieren

Setzen Sie die relevanten Controls aus den 8 Kategorien um (siehe Artikel „CRA Annex I — Essential Cybersecurity Requirements"). Dokumentieren Sie fuer jeden Control:

- **Status**: Implementiert / In Bearbeitung / Nicht anwendbar
- **Nachweis**: Wie wird die Umsetzung belegt? (Code, Konfiguration, Test, Policy)
- **Verantwortlich**: Wer ist zustaendig?

## Schritt 4: Technische Dokumentation

Die technische Dokumentation muss enthalten:

- Beschreibung des Produkts und seiner Funktionen
- Cybersecurity-Risikobewertung
- Angewandte harmonisierte Normen
- Nachweis der Einhaltung jeder Annex-I-Anforderung
- SBOM (Software Bill of Materials)
- Informationen zum Support-Zeitraum

## Schritt 5: Konformitaetserklaerung und CE-Kennzeichnung

Nach erfolgreicher Bewertung:

1. **EU-Konformitaetserklaerung** ausstellen
2. **CE-Kennzeichnung** anbringen
3. **Dokumentation** mindestens 10 Jahre aufbewahren
4. Produkt darf in der EU vertrieben werden

## Haeufige Fehler

| Fehler | Konsequenz |
|--------|-----------|
| Default-Passwoerter nicht entfernt | Verstoss gegen Annex I, 1(3)(d) |
| Kein SBOM erstellt | Verstoss gegen Annex I, 1(5) |
| Kein Update-Mechanismus | Verstoss gegen Annex I, 1(4) |
| Keine CVD-Policy | Verstoss gegen Annex I, 2(5) |
| Support-Zeitraum nicht definiert | Verstoss gegen Art. 13(8) |

## Empfehlung

Nutzen Sie die **BreakPilot Compliance SDK Control Library**, um den Umsetzungsstand Ihrer CRA-Controls systematisch zu tracken und automatisiert Nachweise zu generieren.',
 ARRAY['Annex I CRA', 'Annex II CRA', 'Annex III CRA', 'Annex IV CRA', 'Annex V CRA', 'Art. 13 CRA', 'Art. 24 CRA', 'Art. 25 CRA', 'Art. 26 CRA', 'Art. 27 CRA'],
 ARRAY['konformitaet', 'ce-kennzeichnung', 'self-assessment', 'technische-dokumentation', 'sbom', 'risikobewertung'],
 'important',
 ARRAY['https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng'])
ON CONFLICT (id) DO NOTHING;