Cyber Resilience Act · 2026/2027
Technische CRA-Dokumentation: nach Produkt und Version ordnen
Informationsmaterial. Es ersetzt weder individuelle Rechtsberatung noch eine Konformitätsbewertung.
CRA-Anwendungsbereich prüfen und Produktbewertung herunterladen
Die technische CRA-Dokumentation ist kein einmalig für ein Audit erstelltes Dokument. Artikel 31 verlangt, dass sie vor dem Inverkehrbringen des Produkts mit digitalen Elementen erstellt und bei Bedarf aktualisiert wird, mindestens während des Unterstützungszeitraums.
Müssen Architektur, Entscheidungen und Testergebnisse aus E-Mails, Tickets und der Erinnerung des Teams rekonstruiert werden, ist nicht eine fehlende Vorlage das Problem. Es fehlt ein gepflegtes Modell für Produkt und Nachweise.
Was Anhang VII umfasst
Der genaue Inhalt hängt vom Produkt ab. Anhang VII nennt aber mindestens diese Informationsgruppen.
1. Allgemeine Produktbeschreibung
Dazu gehören die Zweckbestimmung, Softwarefassungen, die die Erfüllung der wesentlichen Cybersicherheitsanforderungen beeinflussen, und die Informationen und Anweisungen, die Nutzern bereitgestellt werden.
2. Konzeption, Entwicklung, Herstellung und Schwachstellenbehandlung
Die Dokumentation sollte genügend Informationen enthalten, um Konzeption und Architektur, Beziehungen zwischen Komponenten und die Schwachstellenbehandlungsprozesse des Herstellers zu verstehen.
Der CRA verweist hier ausdrücklich auf die SBOM, die Richtlinie zur koordinierten Offenlegung von Schwachstellen, den Nachweis einer Kontaktadresse für Schwachstellenmeldungen und die technischen Lösungen für die sichere Verteilung von Updates.
3. Bewertung der Cybersicherheitsrisiken
Die Aufzeichnung sollte zeigen, gegen welche Risiken das Produkt konzipiert, entwickelt, hergestellt, geliefert und gewartet wird und wie die Anforderungen aus Anhang I anwendbar sind.
4. Grundlage des Unterstützungszeitraums
Die Dokumentation benötigt mehr als ein Enddatum. Sie sollte die Informationen bewahren, die der Hersteller zur Bestimmung dieses Zeitraums verwendet hat.
5. Verwendete Normen und technische Lösungen
Werden einschlägige harmonisierte Normen, gemeinsame Spezifikationen oder Cybersicherheitszertifizierungssysteme verwendet, benennt die Dokumentation diese und die angewendeten Teile. Werden sie nicht verwendet, muss der Hersteller die gewählten Lösungen dokumentieren, mit denen die anwendbaren Anforderungen erfüllt werden.
6. Prüfberichte
Nachweise der Tests, mit denen das Produkt und die Schwachstellenbehandlungsprozesse anhand der anwendbaren Anforderungen geprüft wurden.
7. EU-Konformitätserklärung
Eine Kopie der Erklärung für das Produkt.
8. SBOM auf Anforderung einer Marktüberwachungsbehörde
Anhang VII sieht vor, dass die einschlägige SBOM auf begründete Anforderung bereitgestellt wird, wenn die Behörde sie zur Prüfung der Konformität benötigt.
Verwenden Sie einen Index statt einer riesigen PDF-Datei
Ein praktisches Modell ist ein Dokumentationsindex, der an eine Produktfassung gebunden ist.
| Bereich | Quellartefakt | Verantwortung | Fassung / Datum | Prüfnachweis |
|---|---|---|---|---|
| Zweckbestimmung | Produktaufzeichnung | Produktverantwortliche Person | v3.4 | Genehmigung |
| Architektur | Diagramm + Beschreibung | Entwicklung | v3.4 | Prüfung |
| Risikobewertung | Risikoregister | Sicherheit/Produkt | v3.4 | Entscheidungen |
| SBOM | Build-/Release-Artefakt | Entwicklung | Release 3.4.2 | Hash / Protokoll |
| Tests | Berichte | Qualitätssicherung/Sicherheit | Release 3.4.2 | Ergebnis |
| CVD | Richtlinie | Sicherheit | Rev. 5 | Genehmigung |
| Unterstützungszeitraum | Entscheidungsaufzeichnung | Produkt/Leitung | 2026-09 | Begründung |
Die technische Dokumentation kann aus vielen Artefakten bestehen. Entscheidend ist, bestimmen zu können, welches Artefakt für welche Fassung gilt und wer seine Aktualität bestätigt hat.
Vier Muster, die unnötige Kosten verursachen
„Wir haben eine Richtlinie, also ist das abgedeckt“
Eine Richtlinie beschreibt, wie die Organisation arbeiten möchte. Sie beweist nicht, dass ein bestimmtes Produktrelease bewertet und getestet wurde.
„Die Architektur ist im Repository; alle wissen, wo“
Nach einem Teamwechsel oder achtzehn Monaten ist „Alle wissen es“ keine brauchbare Nachweisquelle mehr.
„Die SBOM wird in der Pipeline erzeugt“
Gut — die Dokumentation muss dieses Artefakt dennoch mit Produkt, Release und Schwachstellenprozess verbinden.
„Vor dem Audit exportieren wir alles“
Sind die Quellaufzeichnungen widersprüchlich, macht ein Export diese Widersprüche nur schneller sichtbar.
Den Dokumentationsgegenstand vor der Vorlage bestimmen
Das folgende Modell ist unsere praktische Empfehlung zur Pflege der Herstellernachweise. Legen Sie zuerst Produkt, Fassungsfamilie und Zweckbestimmung fest. Unterscheiden Sie anschließend gemeinsame und releasespezifische Aufzeichnungen. Eine unternehmensweite Schwachstellenrichtlinie kann gemeinsam verwendet werden. Architekturbewertung und Testergebnis brauchen dagegen einen konkreten Produktbezug. Ohne diese Unterscheidung werden entweder unnötige Kopien erstellt oder allgemeine Unterlagen verwendet, die das bewertete Produkt nicht beschreiben. Der Gegenstand muss auch für Personen außerhalb der ursprünglichen Entwicklung verständlich sein.
Ein lesbarer Index nennt Informationsbereich, Quellaufzeichnung, zuständige Person und aktuellen Status. Er kann Entwicklungsberichte, genehmigte Risiken, Komponentenartefakte und Nutzerinformationen verknüpfen. Die bloße Aufzählung von Ordnernamen genügt nicht. Eine prüfende Person muss erkennen, wie ein Eintrag die Produktdokumentation stützt und welche Fassung er betrifft. Das Modell schreibt kein bestimmtes Dateiformat vor. Es macht Informationen nachvollziehbar. Der Index sollte außerdem erklären, welche Angaben noch fehlen und ob dafür eine fachliche Aufgabe oder nur eine bessere Verknüpfung nötig ist.
Ein hypothetischer Hersteller pflegt Firmware und Verwaltungsanwendung. Beschreiben Sie die Beziehungen ihrer Aufzeichnungen. Ein Firmwaretest belegt nicht automatisch das Verhalten der Anwendung. Eine gemeinsame Richtlinie beweist auch nicht, dass beide Releases sie eingehalten haben. Der Index zeigt gemeinsamen Prozess und getrennte Ausführungsnachweise. So wird ein umfangreiches Dokument nicht als Ersatz für mehrere unterschiedliche Produktfragen verwendet. Die einzelnen Nachweise dürfen gemeinsam geprüft werden, solange ihr jeweiliger Umfang und Bezug zum tatsächlich ausgelieferten Zustand klar bleiben.
Aktuelle Aufzeichnungen von historischen Nachweisen trennen
Eine laufend gepflegte Architekturseite beschreibt den aktuellen Entwurf. Eine Release-Aufzeichnung braucht dagegen die für dieses Release relevante Architektur. Der ausschließliche Verweis auf eine ständig veränderte Seite kann historische Zusammenhänge verlieren. Bewahren Sie Fassung, Momentaufnahme oder einen geeigneten stabilen Bezug auf. Erfassen Sie Prüfung und verwendende Produktentscheidung. Das Team darf eine alte Architektur nicht aus der Erinnerung rekonstruieren müssen. Bestehende Versionsverwaltung kann diese Aufgabe unterstützen, wenn die Referenzen tatsächlich eindeutig und später erreichbar bleiben.
Das gilt ebenso für Risikobewertungen und Testberichte. Eine spätere Risikoprüfung kann Annahmen ändern, obwohl das frühere Lieferprodukt unverändert bleibt. Bewahren Sie beide Zustände auf und erklären Sie ihre Beziehung. Eine überschriebene Tabelle zeigt nicht, was bei früherer Freigabe bekannt war. Diese empfohlene Arbeitsweise stützt eine ehrliche Chronologie. Sie wird an Produkt und vorhandene Systeme angepasst. Es ist nicht nötig, jede kleine Bearbeitung als gesondertes Dokument zu erzeugen, solange der relevante Entscheidungsstand zuverlässig erhalten bleibt.
Unterscheiden Sie geplante, vorläufige, genehmigte und ersetzte Aufzeichnungen. Ein Testplan ist kein Testergebnis. Eine noch nicht freigegebene Entscheidungsvorlage ist keine genehmigte Produktbewertung. Diese Zustände bleiben im Index sichtbar. Ersetzt ein neues Artefakt ein altes, wird die Beziehung dargestellt. Löschen Sie dabei nicht Nachweise, die für Produkthistorie oder Aufbewahrungspflichten nötig sind. Der Status eines Dokuments muss seine tatsächliche Verwendung erklären und darf nicht automatisch aus dem bloßen Vorhandensein einer Datei abgeleitet werden.
Risiko- und Anforderungszuordnung lesbar machen
Die Zuordnung nennt einschlägigen Bereich des Anhangs I, Produktrisiko, gewählte Maßnahme und Umsetzungs- oder Prüfnachweis. Wird ein Bereich als nicht anwendbar bewertet, gehören Produkteigenschaften und Begründung dazu. Eine Zeile „durch Richtlinie abgedeckt“ erklärt meist nicht die Anwendung auf ein bestimmtes Produkt. Der Leser braucht die Verbindung zu tatsächlichem Verhalten, Architektur oder Prozessausführung. Eine Organisationsregel kann den Ablauf beschreiben, während ihre Anwendung auf das konkrete Release durch weitere Aufzeichnungen belegt werden muss.
Bei einem hypothetischen Integritätsschutz für Updates verbindet der Eintrag ein manipuliertes Paketszenario mit Design, Entwicklungsänderung und Test. Der Bericht nennt Produkt, Release, Konfiguration und erwartete Ablehnung. Ein früherer Fehler vor der Korrektur bleibt nachvollziehbar. Das Beispiel zeigt die Nachweistiefe. Es behauptet nicht, ein einzelner Test belege jede Updatepflicht oder die Konformität des gesamten Produkts. Die Aussage muss auf das tatsächlich geprüfte Verhalten begrenzt bleiben, damit andere erforderliche Prüfungen nicht versehentlich als erledigt gelten.
Prüfen Sie mehrfach verwendete Zuordnungen auf Widersprüche. Mehrere Maßnahmen können ein Risiko behandeln. Eine Maßnahme kann wiederum mehrere Anforderungen stützen. Verwenden Sie klare Beziehungen statt unabhängig kopierter Tabellen, die auseinanderlaufen. Bei unsicherer Auslegung werden Frage und Prüfverantwortung genannt. Dokumentation soll Unsicherheit sichtbar machen. Sie darf daraus keine sichere Aussage erzeugen, nur weil alle Zeilen einer Prüfliste grün werden sollen. Die offene Frage ist ein Arbeitsgegenstand mit konkretem nächsten Schritt, kein Anlass zum Erfinden einer positiven Antwort.
Normen und andere technische Lösungen genau erklären
Die Dokumentation nennt die tatsächlich verwendete Grundlage technischer Lösungen. Prüfen Sie Status und Anwendbarkeit beanspruchter harmonisierter Normen, gemeinsamer Spezifikationen oder Zertifizierungssysteme anhand aktueller offizieller Quellen. Ein bekannter Normenname allein genügt nicht. Halten Sie Ausgabe, verwendete Teile und maßgebliche Produktfakten fest. Eine regulatorische Vermutungswirkung darf nicht aus einem fremden Unternehmenszertifikat oder einem ungeprüften Dokument abgeleitet werden. Die Produktaufzeichnung muss erkennen lassen, welche Grundlage einschlägig ist und welchen Teil der technischen Bewertung sie unterstützt.
Verwendet der Hersteller einen anderen technischen Ansatz, erklärt er den Bezug zu anwendbaren wesentlichen Anforderungen und die Prüfung der Umsetzung. NISTs Secure Software Development Framework kann beispielsweise Entwicklungspraktiken ordnen. Es ist kein EU-Recht und begründet allein keine CRA-Konformität. Trennen Sie nützliche Umsetzungshilfe und rechtlich anerkannte Bewertungsgrundlage. Dieser Unterschied muss auch in Kundenaussagen erhalten bleiben. Eine sachliche Beschreibung kann beide nennen, ohne aus der freiwilligen Anwendung eines Entwicklungsmodells eine gesetzliche Anerkennung oder Zertifizierung abzuleiten.
Kopieren Sie geschützte Normeninhalte nicht nur zum Füllen der Unterlagen. Verweisen Sie auf rechtmäßig verfügbare Materialien und dokumentieren Sie eigene Analyse, Umsetzung und Prüfungen. Die prüfende Person benötigt die Produktentscheidung. Ein großer Normenanhang kann sie verdecken. Bei fachlicher Auslegung bewahren Sie das produktbezogene Ergebnis und dessen Grundlage auf. Eine allgemeine Liste bekannter Normen ist kein Beweis abgeschlossener Bewertung. Entscheidend bleibt, welche technischen Anforderungen tatsächlich untersucht und wie ihre Anwendung auf das Produkt begründet wurden.
Eine Informationsanfrage kontrolliert beantworten
Unterlagen können Quellcodedetails, Schwachstellen, personenbezogene Angaben oder Geschäftsgeheimnisse enthalten. Legen Sie fest, wer sie für Behördenanfragen findet, prüft und die übermittelte Auswahl dokumentiert. Zugriffsschutz muss Nachweise schützen und zugleich die Erfüllung geltender Pflichten ermöglichen. Die Bezeichnung „vertraulich“ ersetzt keine Prüfung einer rechtmäßigen Anfrage. Sie ersetzt auch nicht die Vorbereitung einschlägiger Informationen. Zuständigkeit und Ablauf sollten vor einer tatsächlichen Anfrage klar sein, damit Zeit nicht durch ungeklärte Freigaben und unzugängliche Ablagen verloren geht.
Prüfen Sie vor Übermittlung Produktfassung, Vollständigkeit des angefragten Umfangs und Lesbarkeit der Artefakte. Ein interner Repositorylink liefert einem Empfänger ohne Zugang nicht die zugrunde liegende Information. Erfassen Sie Auswahl, Zeitpunkt und Anfragebezug. Erforderliche Übersetzung oder Formatierung darf technische Bedeutung nicht unbemerkt ändern. Diese empfohlenen Antwortkontrollen behaupten kein einheitliches Behördenverfahren für jeden Fall. Sie verbessern die Möglichkeit, die konkret benötigten Unterlagen korrekt und nachvollziehbar bereitzustellen und spätere Rückfragen derselben übermittelten Fassung zuzuordnen.
Üben Sie die Suche an einem Produkt. Eine Person außerhalb der Entwicklung findet über den Index Architektur, Risiken, Unterstützungsbegründung, Schwachstellenverfahren und relevante Tests. Beobachten Sie defekte Verbindungen, fehlende Rechte und unklare Fassungsgrenzen. Vergeben Sie Verbesserungsaufgaben mit Verantwortung. Die Übung prüft Verfügbarkeit und Verständlichkeit. Die rechtliche Bewertung der ausreichenden Dokumentation bleibt davon getrennt. Ein erfolgreicher Zugriff auf alle Dateien zeigt schließlich noch nicht, dass deren Inhalt jede anwendbare Anforderung erfüllt oder eine schwierige Produktklassifikation richtig vorgenommen wurde.
KI-Vorschläge mit sichtbarer Quelle prüfen
Ein KI-Assistent kann eine Zusammenfassung oder mögliche Anforderungszuordnung aus bereitgestellten Materialien vorschlagen. Der Vorschlag nennt Quelle und Unsicherheit. Er darf kein Testergebnis, keine Unterstützungszusage und keine Genehmigung erfinden, weil ein Feld leer ist. Menschen prüfen den Entwurf anhand ursprünglicher Nachweise, bevor eine freigegebene Aufzeichnung entsteht. Fehlender Nachweis bleibt fehlender Nachweis, auch wenn der erzeugte Text überzeugend klingt. Die Prüfung muss deshalb Aussagen kontrollieren und darf sich nicht auf Rechtschreibung oder einheitliche Formulierungen beschränken.
Für Übersetzungen gilt dieselbe Regel. Prüfen Sie Begriffe, Kennungen, Termine, Rollen und Bedingungen. Ein geändertes „kann“ oder „muss“ verändert die Bedeutung. Verknüpfen Sie Original und geprüfte Übersetzung, wo es die Aufzeichnung unterstützt. Übersetzungen dürfen keine zusätzlichen Fähigkeiten des Produkts einführen. Dazu gehören automatische Datenerhebung, Zertifizierung oder eine rechtliche Entscheidung durch die Software. Dokumentationsgenauigkeit ist wichtiger als ein durchgehend werblicher Ton. Die freigegebene Fassung muss nachweisbare Tatsachen erklären und darf offene Arbeit nicht als vorhandene Funktion darstellen.
Unterlagen am Änderungszeitpunkt pflegen
Unsere empfohlene Änderungsprüfung benennt betroffene Dokumentationsbereiche bei neuer Architektur, Zweckbestimmung, Komponente, Sicherheitsprozess oder Unterstützung. Die zuständige Person aktualisiert sie, solange technische Beteiligte und Tatsachen verfügbar sind. Die Release-Prüfung bestätigt bewerteten Umfang und offene Arbeiten. Eine jährliche Sammelaktion erzeugt unnötige Rekonstruktion und erhöht das Risiko alter Aussagen. Der Zeitpunkt der Pflege soll daher mit tatsächlicher Produktarbeit verbunden sein. Eine Änderung der Konfiguration kann beispielsweise einen Testbezug verändern, obwohl Produktname und allgemeine Beschreibung unverändert bleiben.
Prüfen Sie zusätzlich Zugriff auf Quellartefakte und Aktualität der Zuständigkeiten. Eine vollständige Akte kann nach Repositoryumzug oder Personalwechsel unbrauchbar werden. Dokumentieren Sie Übergaben und ändern Sie den Index. Historische Bezüge für frühere Releases bleiben erhalten. Die bloße Existenz einer Datei genügt nicht, wenn niemand ihren Produktbezug erklären oder Aktualität bestätigen kann. Diese Pflege sollte einen verantwortlichen Besitzer haben. Sonst wird der Index selbst zu einer weiteren veralteten Unterlage, deren letzte Fassung niemand eindeutig feststellen kann.
Wählen Sie zuerst ein Release und erstellen Sie den vollständigen Index aus vorhandenen Aufzeichnungen, bevor eine weitere Ablage gekauft wird. Ermitteln Sie reale Lücken. Trennen Sie fehlende fachliche Arbeit von fehlenden Verbindungen und vergeben Sie passende Zuständigkeit. Manche Lücken benötigen Entwicklung oder rechtliche Analyse und lassen sich nicht durch Formatierung reparieren. Das brauchbare Ergebnis ist eine gepflegte Produktakte: Aussagen sind auf Nachweise zurückführbar, Grenzen sind verständlich, und offene Fragen bleiben sichtbar mit einem konkreten Bearbeitungsweg.
Wie Pulsar den Dokumentationsverlauf ordnen kann
Dokumente, Nachweise, Risiken, Kontrollen und Berichte in Pulsar bewahren den Kontext von Bewertungen. Dadurch kann die Dokumentation als verknüpfte Aufzeichnungen funktionieren statt als Ordner, der nur endgültige Dateien enthält.
Die angestrebte Aufzeichnung sollte beantworten:
- Zu welchem Produkt und welcher Fassung gehört ein Artefakt?
- Welche Anforderung oder welches Risiko stützt es?
- Wer hat es erstellt und genehmigt?
- Wann war es aktuell?
- Welche Maßnahme oder Entscheidung belegt es?
- Was hat sich seit der vorherigen Prüfung geändert?
Pulsar liefert keine geschützten Normeninhalte und ersetzt nicht die technische Dokumentation des Herstellers. Es hilft, Struktur, Zuständigkeit und Nachvollziehbarkeit zu pflegen.
Dokumente und Nachweise in Pulsar GRC ansehen
Verwandte Leitfäden
Quellen
Quellen geprüft: 2. Oktober 2026.