Die CRA Technische Dokumentation: Was in jeden Abschnitt gehört (Anhang VII Aufschlüsselung)

Die Technische Dokumentation ist Ihr Nachweispaket für die CRA-Compliance. Marktüberwachungsbehörden werden sie anfordern. Benannte Stellen werden sie prüfen. Ohne vollständige Technische Dokumentation dürfen Sie Ihr Produkt nicht legal auf den EU-Markt bringen.

Dieser Leitfaden schlüsselt Anhang VII Abschnitt für Abschnitt auf und erklärt, was jeder erfordert und wie Sie ihn vorbereiten.

Was ist die Technische Dokumentation?

Die Technische Dokumentation ist das vollständige Nachweispaket, das demonstriert, dass Ihr Produkt die CRA-Anforderungen erfüllt.

Sie ist nicht:

• Marketing-Dokumentation
• Nur Benutzerhandbücher
• Eine Abhak-Übung

Sie ist:

• Umfassender technischer Nachweis
• Lebende Dokumentation (aktualisiert während des Produktlebenszyklus)
• Ihre Verteidigung bei Marktüberwachungsuntersuchungen
• Erforderlich für die Konformitätsbewertung

Anhang VII Strukturübersicht

Der CRA-Anhang VII spezifiziert die Anforderungen an die Technische Dokumentation:

STRUKTUR DER TECHNISCHEN DOKUMENTATION (Anhang VII)

1. ALLGEMEINE BESCHREIBUNG
   └── Produktidentifikation und Verwendungszweck

2. DESIGN UND ENTWICKLUNG
   └── Wie Sicherheit eingebaut wurde

3. CYBERSICHERHEITS-RISIKOBEWERTUNG
   └── Identifizierte und behandelte Risiken

4. GRUNDLEGENDE ANFORDERUNGEN
   └── Wie Anhang I-Anforderungen erfüllt werden

5. ANGEWANDTE NORMEN
   └── Verwendete Normen und Abweichungen

6. SOFTWARE-STÜCKLISTE
   └── Komponenten und Abhängigkeiten

7. TESTERGEBNISSE
   └── Verifizierungsnachweise

8. EU-KONFORMITÄTSERKLÄRUNG
   └── Oder Kopie davon

9. SCHWACHSTELLENBEHANDLUNG
   └── Sicherheitsprozesse nach Inverkehrbringen

Abschnitt 1: Allgemeine Beschreibung

Zweck: Festlegen, was das Produkt ist und wofür es gedacht ist.

Erforderlicher Inhalt

CHECKLISTE ALLGEMEINE BESCHREIBUNG

Produktidentifikation:
[ ] Produktname und Modellnummer
[ ] Hardware-Version(en)
[ ] Software-/Firmware-Version(en)
[ ] Seriennummernformat oder -bereich
[ ] Eindeutiger Produktidentifikator

Verwendungszweck:
[ ] Beschreibung der Hauptfunktion
[ ] Zielnutzer/-umgebung
[ ] Vorgesehene Anwendungsfälle
[ ] Nicht vorgesehene Verwendungen (Ausschlüsse)

Produktkategorie:
[ ] CRA-Klassifizierung (Standard/Wichtig/Kritisch)
[ ] Begründung der Klassifizierung
[ ] Verwandte Produktvorschriften (falls vorhanden)

Marktinformationen:
[ ] Datum des ersten EU-Inverkehrbringens
[ ] Ziel-Mitgliedstaaten
[ ] Vertriebskanäle

Beispiel

ALLGEMEINE BESCHREIBUNG

Produktname: SmartSense Pro Industriesensor
Modellnummer: SSP-3000
Hardware-Version: Rev C (PCB v3.2)
Firmware-Version: 2.4.1

VERWENDUNGSZWECK:
Der SmartSense Pro ist ein industrieller Umgebungssensor,
der für die Überwachung von Fertigungsanlagen konzipiert ist.
Er misst Temperatur, Luftfeuchtigkeit und Luftqualität und
überträgt Daten per WiFi an Cloud- oder lokale Server.

ZIELNUTZER:
- Facility Manager
- Industrieautomatisierungs-Integratoren
- Umwelt-Compliance-Beauftragte

VORGESEHENE UMGEBUNG:
- Industrielle Innenräume
- Betriebstemperatur: -10°C bis +60°C
- Netzwerk: WiFi 802.11 b/g/n

NICHT VORGESEHEN FÜR:
- Medizinische oder lebensrettende Anwendungen
- Außeninstallation
- Explosionsgefährdete Bereiche
- Verbraucher-/Wohnanwendungen

CRA-KLASSIFIZIERUNG:
Standardprodukt. Nicht in Anhang III oder IV gelistet.
Begründung: Allzwecksensor ohne Sicherheitsfunktionen
oder kritische Infrastrukturanwendung.

EU-INVERKEHRBRINGEN:
Erstmals auf den Markt gebracht: 15. März 2027
Zielmärkte: Alle EU-Mitgliedstaaten
Vertrieb: Direktverkauf und autorisierte Distributoren

Abschnitt 2: Design und Entwicklung

Zweck: Dokumentieren, wie Sicherheit in das Produktdesign integriert wurde.

Erforderlicher Inhalt

CHECKLISTE DESIGN-DOKUMENTATION

Architektur:
[ ] Systemarchitekturdiagramm
[ ] Komponenteninteraktionsdiagramm
[ ] Datenflussdiagramm
[ ] Vertrauensgrenzen identifiziert

Sicherheitsdesign:
[ ] Beschreibung der Sicherheitsarchitektur
[ ] Kryptografische Implementierungen
[ ] Authentifizierungsmechanismen
[ ] Autorisierungsmodell
[ ] Sichere Kommunikationsprotokolle
[ ] Datenschutzmaßnahmen

Entwicklungsprozess:
[ ] Beschreibung des sicheren Entwicklungslebenszyklus
[ ] Rückverfolgbarkeit der Sicherheitsanforderungen
[ ] Code-Review-Verfahren
[ ] Sicherheitstests in der Entwicklung
[ ] Konfigurationsmanagement

Änderungsmanagement:
[ ] Versionskontrollverfahren
[ ] Änderungsauswirkungsbewertung
[ ] Sicherheitsüberprüfung bei Änderungen

Wie "Secure by Design"-Dokumentation aussieht

SICHERHEITSARCHITEKTUR-ÜBERSICHT

1. VERTRAUENSGRENZEN
   ┌─────────────────────────────────────────┐
   │            Cloud-Backend                 │
   │  (Authentifizierung, Datenspeicherung)  │
   └───────────────┬─────────────────────────┘
                   │ TLS 1.3
   ┌───────────────┴─────────────────────────┐
   │         Geräte-Firmware                  │
   │  ┌─────────────────────────────────┐    │
   │  │    Anwendungsschicht            │    │
   │  ├─────────────────────────────────┤    │
   │  │    Sicherheitsdienste           │    │
   │  │  (Krypto, Auth, Secure Boot)    │    │
   │  ├─────────────────────────────────┤    │
   │  │    Hardware-Sicherheit          │    │
   │  │  (Secure Element, RNG)          │    │
   │  └─────────────────────────────────┘    │
   └─────────────────────────────────────────┘

2. AUTHENTIFIZIERUNG
   - Gerät-zu-Cloud: Mutual TLS mit Gerätezertifikaten
   - Nutzer-zu-Gerät: Lokale API erfordert Auth-Token
   - Zertifikatbereitstellung: Werkseitig, einzigartig pro Gerät

3. DATENSCHUTZ
   - Ruhende Daten: AES-256-GCM-Verschlüsselung
   - Daten in Übertragung: TLS 1.3 mit Certificate Pinning
   - Sensible Daten: Im Secure Element gespeichert

4. UPDATE-MECHANISMUS
   - Signierte Firmware-Updates (ECDSA P-256)
   - Signaturverifizierung vor Installation
   - Rollback-Schutz über Versionszähler
   - Automatische Update-Prüfungen (nutzerkonfigurierbar)

Abschnitt 3: Cybersicherheits-Risikobewertung

Zweck: Identifizierte Risiken und deren Behandlung dokumentieren.

Erforderlicher Inhalt

CHECKLISTE RISIKOBEWERTUNG

Methodik:
[ ] Risikobewertungsmethodik beschrieben
[ ] Scope-Definition
[ ] Asset-Identifikation
[ ] Ansatz zur Bedrohungsidentifikation

Risikoanalyse:
[ ] Bedrohungen aufgezählt
[ ] Schwachstellen berücksichtigt
[ ] Auswirkungsbewertung
[ ] Wahrscheinlichkeitsbewertung
[ ] Risikoeinstufungen

Risikobehandlung:
[ ] Behandlungsentscheidungen für jedes Risiko
[ ] Sicherheitskontrollen auf Risiken abgebildet
[ ] Restrisikobewertung
[ ] Risikoakzeptanzkriterien

Format der Risikobewertung

CYBERSICHERHEITS-RISIKOBEWERTUNG

Produkt: SmartSense Pro (SSP-3000)
Version: 2.4.1
Bewertungsdatum: Januar 2027
Bewerter: [Name, Sicherheitsteam]

METHODIK:
Basierend auf ISO 27005, angepasst für Produktsicherheit.
Risiko = Wahrscheinlichkeit × Auswirkung
Skala: Niedrig (1-4), Mittel (5-9), Hoch (10-16), Kritisch (17-25)

─────────────────────────────────────────────────────────────
RISIKO-ID: R-001
BEDROHUNG: Unbefugte Firmware-Modifikation
SCHWACHSTELLE: Unsignierte Firmware könnte installiert werden
AUSWIRKUNG: Hoch (5) - Gerätekompromittierung, Datenleck
WAHRSCHEINLICHKEIT: Mittel (3) - Erfordert physischen Zugang
INHÄRENTES RISIKO: 15 (Hoch)

KONTROLLE: Firmware-Signaturverifizierung
IMPLEMENTIERUNG: ECDSA P-256 Signatur vor Installation geprüft
RESTRISIKO: 3 (Niedrig) - Kryptografischer Angriff unwahrscheinlich

STATUS: Mitigiert
─────────────────────────────────────────────────────────────
RISIKO-ID: R-002
BEDROHUNG: Man-in-the-Middle-Angriff auf Cloud-Kommunikation
SCHWACHSTELLE: Abfangen von Netzwerkverkehr
AUSWIRKUNG: Hoch (4) - Datenexposition, Command Injection
WAHRSCHEINLICHKEIT: Mittel (3) - Öffentliche Netzwerke möglich
INHÄRENTES RISIKO: 12 (Hoch)

KONTROLLE: TLS 1.3 mit Certificate Pinning
IMPLEMENTIERUNG: Festcodiertes CA-Zertifikat, kein Fallback
RESTRISIKO: 2 (Niedrig) - Zertifikatskompromittierung unwahrscheinlich

STATUS: Mitigiert
─────────────────────────────────────────────────────────────
[Fortsetzung für alle identifizierten Risiken...]

RISIKOZUSAMMENFASSUNG:
Identifizierte Risiken gesamt: 23
Kritisch: 0
Hoch: 3 (alle auf Niedrig/Mittel mitigiert)
Mittel: 8 (alle auf Niedrig mitigiert)
Niedrig: 12 (akzeptiert oder mitigiert)

RESTRISIKO-AKZEPTANZ:
Alle Restrisiken liegen innerhalb akzeptabler Toleranz.
Unterzeichnet: [Sicherheitsleiter], [Datum]

Abschnitt 4: Zuordnung Grundlegender Anforderungen

Zweck: Nachweisen, wie jede Anhang I-Anforderung erfüllt wird.

Anhang I, Teil I Anforderungen

Ordnen Sie jede Anforderung Ihrer Implementierung zu:

COMPLIANCE-MATRIX GRUNDLEGENDE ANFORDERUNGEN

ANHANG I, TEIL I - SICHERHEITSANFORDERUNGEN
═══════════════════════════════════════════════════════════

1. OHNE BEKANNTE AUSNUTZBARE SCHWACHSTELLEN ENTWICKELT
   Status: KONFORM
   Nachweise:
   - Schwachstellen-Scanbericht (Trivy): 0 kritisch/hoch
   - Abhängigkeitsanalyse: Alle Komponenten auf aktuellen sicheren Versionen
   - Penetrationstestbericht: Keine ausnutzbaren Schwachstellen gefunden
   Referenz: Testbericht TR-2027-001, Seiten 15-23

2. STANDARDMÄSSIG SICHERE KONFIGURATION
   Status: KONFORM
   Nachweise:
   - Dokument zur Prüfung der Standardkonfiguration
   - Keine Standardpasswörter (eindeutige Credentials bei Setup erforderlich)
   - Unnötige Dienste standardmäßig deaktiviert
   - Sichere Protokolle standardmäßig aktiviert (TLS, nicht HTTP)
   Referenz: Designdokument DD-004, Abschnitt 3.2

3. SCHUTZ VOR UNBEFUGTEM ZUGRIFF
   Status: KONFORM
   Nachweise:
   - Dokument zur Authentifizierungsarchitektur
   - Implementierung der Zugriffskontrolle
   - Session-Management-Design
   - Mechanismus zur Sperrung bei fehlgeschlagener Anmeldung
   Referenz: Sicherheitsarchitektur SA-001, Kapitel 4

4. VERTRAULICHKEIT DER DATEN
   Status: KONFORM
   Nachweise:
   - Verschlüsselungsspezifikationen (AES-256-GCM)
   - Schlüsselverwaltungsverfahren
   - Datenklassifizierung und -handhabung
   Referenz: Designdokument DD-005

5. INTEGRITÄT VON DATEN UND BEFEHLEN
   Status: KONFORM
   Nachweise:
   - Nachrichtenauthentifizierung (HMAC)
   - Befehlsvalidierungslogik
   - Eingabevalidierungsverfahren
   Referenz: Sicherheitsarchitektur SA-001, Kapitel 5

6. DATENMINIMIERUNG
   Status: KONFORM
   Nachweise:
   - Dateninventardokument
   - Begründung für jeden erhobenen Datentyp
   - Aufbewahrungsrichtlinie (automatische Löschung nach 90 Tagen)
   Referenz: Datenschutz-Folgenabschätzung PIA-001

[Fortsetzung für alle Anhang I-Anforderungen...]

Abschnitt 5: Angewandte Normen

Zweck: Dokumentieren, welche Normen verwendet wurden und wie.

Format der Normendokumentation

ANGEWANDTE NORMEN

HARMONISIERTE NORMEN (Konformitätsvermutung):
─────────────────────────────────────────────────────────────
Norm: EN 303 645 (wenn für CRA harmonisiert)
Titel: Cybersicherheit für Verbraucher-IoT
Status: Vollständig angewandt
Veröffentlichung: ABl. EU [Referenz bei Veröffentlichung]
Nachweis: Normenkonformitätsbericht SCR-001
─────────────────────────────────────────────────────────────

WEITERE ANGEWANDTE NORMEN:
─────────────────────────────────────────────────────────────
Norm: IEC 62443-4-1:2018
Titel: Sicherheit für Industrieautomation - Sichere Entwicklung
Status: Angewandt (ausgewählte Anforderungen)
Angewandte Abschnitte: 5, 6, 7, 8, 10
Nachweis: SDL-Dokumentation SLD-001
─────────────────────────────────────────────────────────────
Norm: ISO/IEC 27001:2022
Titel: Informationssicherheitsmanagement
Status: Organisation zertifiziert (Zertifikat #12345)
Relevanz: ISMS deckt Produktentwicklungsprozesse ab
─────────────────────────────────────────────────────────────

ABWEICHUNGEN:
─────────────────────────────────────────────────────────────
Norm: EN 303 645
Abschnitt: 5.3-2 (Eindeutige Credentials pro Gerät)
Abweichung: Credentials eindeutig pro Gerät, aber nicht vorprovisioniert
Begründung: Gerät erfordert Nutzer-Setup; Credentials werden
            bei Erstkonfiguration erstellt
Alternative Maßnahme: Starke Passwortanforderungen durchgesetzt,
                     Kontosperrung bei fehlgeschlagenen Versuchen
Risikobewertung: Restrisiko akzeptabel (siehe R-015)
─────────────────────────────────────────────────────────────

Abschnitt 6: Software-Stückliste

Zweck: Komponententransparenz für Schwachstellenverfolgung bereitstellen.

SBOM-Dokumentation

SOFTWARE-STÜCKLISTE

Produkt: SmartSense Pro (SSP-3000)
Firmware-Version: 2.4.1
SBOM-Format: CycloneDX 1.5
Erstellt: 15.01.2027
Tool: Trivy + syft

SBOM-DATEI:
sbom-ssp3000-v2.4.1.json (angehängt)

KOMPONENTENZUSAMMENFASSUNG:
─────────────────────────────────────────────────────────────
Komponenten gesamt: 127
  Direkte Abhängigkeiten: 23
  Transitive Abhängigkeiten: 104

Nach Typ:
  Bibliotheken: 98
  Frameworks: 12
  Betriebssystem: 1 (FreeRTOS)
  Firmware-Module: 16

Nach Lizenz:
  MIT: 45
  Apache 2.0: 38
  BSD: 15
  LGPL: 8
  Proprietär: 21 (interne Komponenten)
─────────────────────────────────────────────────────────────

SCHWACHSTELLENSTATUS BEI BEWERTUNG:
─────────────────────────────────────────────────────────────
Scan-Datum: 15.01.2027
Scanner: Trivy v0.48.0

Kritisch: 0
Hoch: 0
Mittel: 2 (akzeptiert - siehe unten)
Niedrig: 5 (akzeptiert)

AKZEPTIERTE SCHWACHSTELLEN:
CVE-2026-XXXXX (Mittel): Komponente xyz v1.2.3
  Status: In unserer Konfiguration nicht ausnutzbar
  Begründung: Funktion nicht aktiviert, Codepfad nicht erreichbar
  Überprüfungsdatum: 15.04.2027
─────────────────────────────────────────────────────────────

SBOM-UPDATE-VERPFLICHTUNG:
SBOM wird mit jeder Firmware-Version aktualisiert und
Kunden auf Anfrage zur Verfügung gestellt.

Abschnitt 7: Testergebnisse

Zweck: Nachweis erbringen, dass Anforderungen tatsächlich erfüllt werden.

Format der Testergebnisse

ZUSAMMENFASSUNG TESTERGEBNISSE

Produkt: SmartSense Pro (SSP-3000) v2.4.1
Testperiode: Dezember 2026 - Januar 2027
Testleiter: [Name]

═══════════════════════════════════════════════════════════
TESTKAMPAGNE: TC-2027-001
═══════════════════════════════════════════════════════════

1. FUNKTIONALE SICHERHEITSTESTS
   Umfang: Authentifizierung, Autorisierung, Verschlüsselung, Secure Boot
   Testfälle: 85
   Bestanden: 85
   Fehlgeschlagen: 0
   Referenz: Testbericht TR-FUNC-001

2. SCHWACHSTELLEN-SCANNING
   Tool: Trivy v0.48.0 + Nessus Professional
   Umfang: Firmware, Netzwerkdienste, Web-Oberfläche
   Ergebnisse:
     Kritisch: 0
     Hoch: 0
     Mittel: 2 (mit Begründung akzeptiert)
     Niedrig: 5 (akzeptiert)
   Referenz: Scan-Bericht SR-VULN-001

3. PENETRATIONSTESTS
   Anbieter: [Name der Drittfirma]
   Umfang: Black-Box-Tests des bereitgestellten Geräts
   Dauer: 5 Tage
   Ergebnisse:
     Kritisch: 0
     Hoch: 0
     Mittel: 1 (vor Release behoben)
     Niedrig: 3 (akzeptiert)
   Referenz: Pentest-Bericht PT-2027-001

4. FIRMWARE-ANALYSE
   Tool: EMBA v1.3
   Umfang: Binäranalyse, hartcodierte Credentials, Krypto-Probleme
   Ergebnisse:
     Kritisch: 0
     Hoch: 0
     Informativ: 4
   Referenz: Firmware-Analysebericht FA-001

═══════════════════════════════════════════════════════════
GESAMTBEWERTUNG: BESTANDEN
Alle kritischen und hohen Befunde behoben.
Mittlere/niedrige Befunde mit dokumentierter Begründung akzeptiert.
═══════════════════════════════════════════════════════════

Abschnitt 8: EU-Konformitätserklärung

Zweck: Die formelle Erklärung oder einen Verweis darauf einschließen.

Erforderlicher Inhalt

Die Technische Dokumentation muss eine Kopie der EU-Konformitätserklärung oder einen Verweis enthalten, wo sie erhältlich ist.

EU-KONFORMITÄTSERKLÄRUNG

(Siehe separates DoC-Dokument oder Kopie in Technischer Dokumentation)

Referenz: DoC-SSP3000-2027-001
Datum: 1. März 2027
Ort: Technische Dokumentation, Anhang A

Die EU-Konformitätserklärung begleitet jedes Produkt
und ist zum Download verfügbar unter:
https://firma.de/support/ssp3000/doc

Abschnitt 9: Verfahren zur Schwachstellenbehandlung

Zweck: Sicherheitsprozesse nach dem Inverkehrbringen dokumentieren.

Dokumentation der Schwachstellenbehandlung

VERFAHREN ZUR SCHWACHSTELLENBEHANDLUNG

1. KONTAKTMETHODEN
   Primär: security@firma.de
   Webformular: https://firma.de/security/melden
   security.txt: https://firma.de/.well-known/security.txt
   CVD-Richtlinie: https://firma.de/security/offenlegungsrichtlinie

2. ANTWORTVERPFLICHTUNGEN
   Bestätigung: Innerhalb von 3 Werktagen
   Erste Bewertung: Innerhalb von 10 Werktagen
   Statusupdates: Alle 14 Tage
   Lösungsziel: 90 Tage (kritisch: 7 Tage)

3. INTERNER PROZESS
   [Flussdiagramm oder Prozessbeschreibung]
   Siehe: Prozessdokument PD-VULN-003

4. PATCH-VERTEILUNG
   Mechanismus: OTA-Updates über Cloud-Infrastruktur
   Benachrichtigung: In-App-Benachrichtigung + E-Mail an registrierte Nutzer
   Verifizierung: Signierte Updates mit Rollback-Fähigkeit

5. ENISA-MELDUNG
   Auslöser: Aktive Ausnutzung erkannt
   Zeitplan: 24h Frühwarnung, 72h detaillierter Bericht
   Verantwortlich: Sicherheitsteamleiter
   Prozess: Siehe PD-ENISA-001

6. HISTORISCHE AUFZEICHNUNG
   Behandelte Schwachstellen (letzte 24 Monate): 3
   Durchschnittliche Lösungszeit: 45 Tage
   ENISA-Meldungen eingereicht: 0

Wartung der Technischen Dokumentation

Lebende Dokumentation

Die Technische Dokumentation ist nicht statisch:

AUSLÖSER FÜR AKTUALISIERUNG DER TECHNISCHEN DOKUMENTATION

VERPFLICHTENDE UPDATES:
- Neue Firmware-/Software-Version
- Sicherheitspatch-Release
- Schwachstelle entdeckt und behandelt
- Designänderung, die Sicherheit betrifft
- Normenaktualisierung (wenn angewandte Normen sich ändern)
- SBOM-Änderungen (neue/aktualisierte Komponenten)

PERIODISCHE ÜBERPRÜFUNGEN:
- Vierteljährlich: SBOM und Schwachstellenstatus
- Jährlich: Vollständige Überprüfung der Technischen Dokumentation
- Vor Ende des Unterstützungszeitraums: Endgültige Dokumentationsfestschreibung

VERSIONSKONTROLLE:
- Alle Dokumente versionskontrolliert
- Änderungshistorie gepflegt
- Frühere Versionen archiviert

Aufbewahrungsanforderungen

DOKUMENTATIONSAUFBEWAHRUNG

Aufbewahrungsfrist: 10 Jahre ab letzter auf den Markt gebrachter Einheit

Beispiel-Zeitachse:
- Produkt erstmals auf den Markt gebracht: März 2027
- Letzte Einheit auf den Markt gebracht: Dezember 2030
- Dokumentationsaufbewahrung bis: Dezember 2040

Speicheranforderungen:
- Sichere, zugängliche Speicherung
- Backup-Verfahren
- Integritätsschutz
- Verfügbar innerhalb von [48 Stunden] auf Behördenanfrage

Häufige Fehler

Unvollständige Risikobewertung

Problem: Risikobewertung, die nicht alle Bedrohungen abdeckt oder Behandlungsdetails fehlen.

Lösung: Strukturierte Methodik verwenden. Jedes identifizierte Risiko einer Kontrolle oder Akzeptanzentscheidung zuordnen.

Fehlende SBOM

Problem: Keine SBOM oder SBOM ohne transitive Abhängigkeiten.

Lösung: SBOM mit geeignetem Tooling erstellen. Vollständigen Abhängigkeitsbaum einschließen.

Veraltete Dokumentation

Problem: Technische Dokumentation beschreibt Version 1.0, aber Produkt ist bei Version 2.3.

Lösung: Dokumentation mit jeder Version aktualisieren. Versionen explizit verfolgen.

Keine Anforderungsrückverfolgbarkeit

Problem: Behauptet Compliance, zeigt aber nicht, wie jede Anforderung erfüllt wird.

Lösung: Explizite Zuordnung von jeder Anhang I-Anforderung zu Nachweisen erstellen.

Tests ohne Nachweise

Problem: Behauptet, Tests wurden durchgeführt, aber keine Berichte verfügbar.

Lösung: Alle Testberichte aufbewahren. In Technische Dokumentation einschließen oder klar referenzieren.

Checkliste Technische Dokumentation

VOLLSTÄNDIGKEITS-CHECKLISTE TECHNISCHE DOKUMENTATION

ABSCHNITT 1 - ALLGEMEINE BESCHREIBUNG:
[ ] Produktidentifikation vollständig
[ ] Verwendungszweck dokumentiert
[ ] CRA-Klassifizierung mit Begründung angegeben
[ ] Inverkehrbringungs-Informationen

ABSCHNITT 2 - DESIGN:
[ ] Architekturdiagramme
[ ] Sicherheitsdesign-Dokumentation
[ ] Entwicklungsprozess-Beschreibung
[ ] Änderungsmanagement-Verfahren

ABSCHNITT 3 - RISIKOBEWERTUNG:
[ ] Methodik dokumentiert
[ ] Alle Risiken identifiziert
[ ] Behandlungsentscheidungen für jedes Risiko
[ ] Restrisikobewertung

ABSCHNITT 4 - GRUNDLEGENDE ANFORDERUNGEN:
[ ] Anhang I Teil I Zuordnung vollständig
[ ] Anhang I Teil II Zuordnung vollständig
[ ] Nachweise für jede Anforderung referenziert

ABSCHNITT 5 - NORMEN:
[ ] Alle angewandten Normen aufgelistet
[ ] Anwendungsnachweise erbracht
[ ] Abweichungen dokumentiert und begründet

ABSCHNITT 6 - SBOM:
[ ] Maschinenlesbare SBOM angehängt
[ ] Alle Komponenten enthalten
[ ] Schwachstellenstatus dokumentiert

ABSCHNITT 7 - TESTERGEBNISSE:
[ ] Testplan dokumentiert
[ ] Testberichte angehängt
[ ] Alle Befunde behandelt

ABSCHNITT 8 - KONFORMITÄTSERKLÄRUNG:
[ ] Konformitätserklärung enthalten/referenziert

ABSCHNITT 9 - SCHWACHSTELLENBEHANDLUNG:
[ ] Kontaktmethoden dokumentiert
[ ] Prozess dokumentiert
[ ] ENISA-Verfahren vorhanden

WARTUNG:
[ ] Versionskontrolle eingerichtet
[ ] Update-Verfahren dokumentiert
[ ] Aufbewahrungsplan vorhanden

Wie CRA Evidence hilft

CRA Evidence vereinfacht die Erstellung der Technischen Dokumentation:

• Strukturierte Vorlagen: Abschnitt-für-Abschnitt-Builder für Technische Dokumentation
• Anforderungszuordnung: Anhang I Compliance-Nachweise verfolgen
• SBOM-Management: SBOMs speichern, analysieren und aktualisieren
• Dokumenten-Repository: Zentralisierte Speicherung für alle Nachweise
• Versionsverfolgung: Dokumentation über Produktversionen hinweg pflegen
• Export-Fähigkeit: Vollständige Technische Dokumentation-Pakete erstellen

Erstellen Sie Ihre Technische Dokumentation unter app.craevidence.com.

Verwandte Leitfäden

SBOM: Vertiefen Sie sich in die SBOM-Anforderungen in unserem SBOM-Leitfaden.

Bewertung: Wählen Sie Ihren Konformitätsbewertungsweg mit unserem Modul-Entscheidungsleitfaden.

Erklärung: Erfahren Sie, wie Sie Ihre EU-Konformitätserklärung vorbereiten.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung konsultieren Sie qualifizierte Rechtsberater.