Dieser Leitfaden zeigt jeden Bestandteil, die Regeln für Aufbewahrung und Sprache und einen Aufbau, der ohne Dateichaos auskommt. Art. 13 und Art. 31 gelten ab dem 11. Dezember 2027 (Art. 71 Abs. 2 CRA).
Die acht Bestandteile nach Anhang VII
Die Dokumentation enthält diese Angaben, soweit sie für das Produkt von Bedeutung sind.
| Nr. | Bestandteil | Was konkret hineingehört |
|---|---|---|
| 1 | Allgemeine Beschreibung | Zweckbestimmung, relevante Softwareversionen, bei Hardware Fotos oder Abbildungen, Nutzerinformationen nach Anhang II |
| 2 | Konzeption, Entwicklung, Herstellung, Schwachstellenverfahren | Systemarchitektur, SBOM, Konzept für die koordinierte Offenlegung, Nachweis der Kontaktadresse, sichere Verbreitung von Updates, Herstellungs- und Überwachungsprozesse |
| 3 | Bewertung der Cybersicherheitsrisiken | Nach Art. 13, auch die Frage, wie weit die Anforderungen aus Anhang I Teil I gelten |
| 4 | Unterstützungszeitraum | Informationen, die bei seiner Festlegung berücksichtigt wurden |
| 5 | Angewandte Normen | Harmonisierte Normen, gemeinsame Spezifikationen oder Zertifizierungsschemata, sonst Beschreibung der Lösungen |
| 6 | Test- und Prüfberichte | Nachweis der Konformität von Produkt und Schwachstellenverfahren |
| 7 | EU-Konformitätserklärung | Ein Exemplar |
| 8 | SBOM auf Verlangen | Gegebenenfalls auf begründetes Verlangen der Marktüberwachungsbehörde |
Gilt eine Anforderung nicht für Ihr Produkt, nehmen Sie eine klare Begründung auf (Art. 13 Abs. 4 CRA).
Die Regeln rund um die Dokumentation
- Zeitpunkt: Vor dem Inverkehrbringen erstellen (Art. 13 Abs. 12, Art. 31 Abs. 2 CRA).
- Pflege: Bei Bedarf laufend aktualisieren, zumindest während des Unterstützungszeitraums (Art. 31 Abs. 2 CRA).
- Aufbewahrung: Mindestens zehn Jahre nach dem Inverkehrbringen oder für den Unterstützungszeitraum, je nachdem, was länger ist (Art. 13 Abs. 13 CRA).
- Behörden: Auf begründetes Verlangen übermitteln Sie der Marktüberwachungsbehörde die Unterlagen in einer für sie leicht verständlichen Sprache (Art. 13 Abs. 22 CRA).
- Notifizierte Stelle: Dokumentation und Korrespondenz stehen in einer Amtssprache ihres Mitgliedstaats oder in einer von ihr zugelassenen Sprache (Art. 31 Abs. 4 CRA).
- Hochrisiko-KI: Für Produkte nach Art. 12, die auch anderen Rechtsakten mit technischer Dokumentation unterliegen, erstellen Sie eine einzige Dokumentation (Art. 31 Abs. 3 CRA). Die Verordnung (EU) 2025/327 zum Europäischen Gesundheitsdatenraum ändert diese Vorschrift mit Wirkung ab dem 26. März 2027.
- Kleine Unternehmen: Kleinst- und Kleinunternehmen können ein vereinfachtes Format nutzen. Das Formular legt die Kommission per Durchführungsrechtsakt fest (Art. 33 Abs. 5 CRA); Stand November 2026 ist es noch nicht veröffentlicht.
Der Aufbau in sechs Schritten
- Produkt und Rolle klären. Halten Sie fest, ob das Produkt unter den CRA fällt, in welche Klasse es gehört und welche Rolle Sie haben.
- Akte je Version anlegen. Die Dokumentation hängt an einer Version. Eine neue Version übernimmt, was weiter gilt.
- Risikobewertung erstellen. Sie ist das Herzstück: Aus ihr folgt, welche Anforderungen wie umgesetzt sind.
- Anforderungen belegen. Ordnen Sie jeder Anforderung aus Anhang I Status, Begründung und Nachweis zu.
- Testen und zusammenführen. Ergänzen Sie Testberichte, SBOM und Nutzerinformationen.
- Freigeben und pflegen. Geben Sie den Stand frei. Änderungen an Produkt, Risiken oder Normen lösen eine Aktualisierung aus.
Was eine Änderung auslöst
| Ereignis | Was Sie aktualisieren |
|---|---|
| Neue Softwareversion | Beschreibung, SBOM, gegebenenfalls Tests und Risikobewertung |
| Neue Schwachstelle | Risikobewertung und Dokumentation der Schwachstelle (Art. 13 Abs. 7 CRA) |
| Neue Komponente eines Dritten | SBOM, Sorgfalt nach Art. 13 Abs. 5 CRA |
| Neue harmonisierte Norm | Aufstellung der Normen, gegebenenfalls Bewertung |
| Geändertes Update-Verfahren | Beschreibung der technischen Lösung |
Häufige Lücken
- Risikobewertung ohne Bezug: Sie steht für sich und erklärt nicht, wie die Anforderungen umgesetzt sind.
- Unterstützungszeitraum ohne Begründung: Das Enddatum steht fest, die Überlegungen dahinter fehlen.
- Nur das Produkt: Die Verfahren für den Umgang mit Schwachstellen sind nicht beschrieben.
- Veraltete Stände: Die Dokumentation beschreibt eine frühere Version.
Beispiel aus dem Maschinenbau
Das Beispiel ist erfunden. Ein Hersteller baut die Steuerung KB-800. Sie unterliegt dem CRA und der Maschinenverordnung.
- Aufbau: Je Version eine Akte mit Risikobewertung, SBOM und Anforderungen.
- Bewertung: Eine Anforderung gilt nicht, weil das Produkt keine personenbezogenen Daten verarbeitet. Die Begründung steht in der Akte.
- Pflege: Version 2.0 übernimmt die Bewertung von 1.0, geänderte Punkte werden neu geprüft.
Checkliste
- Produkt, Klasse und Rolle sind festgehalten.
- Die Risikobewertung ist Teil der Dokumentation.
- Jede Anforderung aus Anhang I hat Status und Beleg, Ausnahmen sind begründet.
- Unterstützungszeitraum und Überlegungen dazu sind beschrieben.
- SBOM, Offenlegungskonzept und Kontaktadresse liegen vor.
- Testberichte decken Produkt und Schwachstellenverfahren ab.
- Angewandte Normen sind aufgelistet, auch teilweise Anwendung.
- Die EU-Konformitätserklärung liegt bei.
- Aufbewahrung und Pflege sind geregelt.
Die technische Dokumentation in Complass
Schluss mit Ordnern voller Word-Dateien, in denen niemand weiß, welche Version gilt. In Complass hat jede Produktversion ihre Akte:
- Produktakte: Je Produkt und Version liegen Anforderungen, Support-Zeitraum, SBOM und Konformitätsstatus zusammen.
- Anforderungen: Sie bewerten jede Anforderung. Eine neue Version kann die Bewertung der Vorversion übernehmen.
- Vollständigkeitsprüfung: Sie zeigt offene Punkte. Die Konformität bewertet sie nicht, die Erklärung bleibt beim Hersteller.
- Dokumente: Technische Dokumentation, Risikobewertung, EU-Konformitätserklärung und Nutzerinformationen entstehen als Entwurf aus der Akte. „[fehlt: …]“ zeigt, was noch fehlt.
- Freigabe: Die Freigabe friert ein Dokument mit Prüfsumme ein.
- Unterlagen für die Marktüberwachung: Die freigegebenen Unterlagen einer Version entstehen als ZIP-Paket.
Häufige Fragen
Müssen wir die Dokumentation veröffentlichen?
Nein. Sie bewahren sie für die Marktüberwachungsbehörden auf. Für Nutzer gelten die Informationen nach Anhang II.
Müssen wir die SBOM veröffentlichen?
Anhang I Teil II Nr. 1 verlangt, dass Sie eine SBOM erstellen, und nicht, dass Sie sie veröffentlichen. Anhang VII Nr. 8 nennt sie auf begründetes Verlangen der Behörde. Stellen Sie die SBOM Nutzern zur Verfügung, nennen Sie, wo sie abrufbar ist (Anhang II Nr. 9).
Reicht die bestehende Dokumentation nach der Maschinenverordnung?
Nicht von selbst. Die Dokumentation nach dem CRA muss die Angaben aus Anhang VII enthalten. Vieles lässt sich aber wiederverwenden, und beide Dokumentationen können gemeinsam gepflegt werden.
Brauchen wir für jede Version eine eigene Dokumentation?
Der CRA schreibt keine Ablage vor. Anhang VII verlangt aber Angaben zu den Softwareversionen, die sich auf die Anforderungen auswirken. Eine Akte je Version macht das am einfachsten nachvollziehbar.
Prüft jemand die Dokumentation vorab?
Das hängt vom Konformitätsbewertungsverfahren ab. Bei Verfahren mit notifizierter Stelle gehört sie zu deren Prüfung. Außerdem kann die Marktüberwachungsbehörde Unterlagen auf begründetes Verlangen anfordern.
In einer Demo zeigen wir Ihnen an der Demo-Firma, wie aus einer Produktakte der Entwurf der Dokumentation entsteht.
Weiterlesen
- Leitfaden „Vom CRA betroffen?“
- Leitfaden „SBOM nach CRA“
- Leitfaden „Schwachstellenprozess nach CRA“
- Whitepaper zum CRA für Hersteller
- CRA in Complass
Keine Rechtsberatung. Dieser Leitfaden gibt einen allgemeinen Überblick und ersetzt nicht die Prüfung im Einzelfall. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847 im Amtsblatt. Stand: November 2026.