Technische Dokumentation im Cyber Resilience Act: Was wirklich zählt.

Unsere bisherigen Beiträge zum CRA haben gezeigt, welche Anforderungen Hersteller an die Cybersicherheit ihrer Produkte – von der sicheren Entwicklung bis zum Umgang mit Schwachstellen nach der Markteinführung – erfüllen müssen und welche Anwenderdokumentation gefordert ist. Im Beitrag Pflichtlektüre fürs Produkt: Welche Informationen müssen laut CRA mitgeliefert werden? haben wir diese Anforderungen an die Nutzerinformation bereits im Detail beleuchtet. Doch es gibt einen weiteren Dokumentationsaspekt: In Anhang VII beschreibt der CRA auch Anforderungen an die technische Dokumentation.

Rund um den Cyber Resilience Act herrscht oft noch Unsicherheit, besonders wenn es um die Dokumentationspflichten geht. Viele Unternehmen fragen sich, was genau sie bereitstellen müssen und vor allem für wen. Häufig werden zwei Dinge verwechselt, die im CRA strikt getrennt sind: Die Nutzerdokumentation richtet sich an den Endanwender. Sie erklärt, wie das Produkt genutzt, eingerichtet und aktuell gehalten wird. Sie muss verständlich, vollständig und für die Zielgruppe zugänglich sein. Die technische Dokumentation dagegen ist ein internes Nachweisdokument. Sie beschreibt, wie das Produkt konzipiert, entwickelt und abgesichert wurde. Sie ist nicht öffentlich und muss grundsätzlich nicht mit dem Produkt mitgeliefert werden.

Allerdings heißt das nicht, dass niemand Zugriff darauf bekommt. Die technische Dokumentation muss bei Inverkehrbringen vollständig vorliegen und auf Anforderung der Marktüberwachungsbehörde zur Verfügung gestellt werden. Die Behörde darf im Rahmen einer Kontrolle oder bei konkretem Verdacht Einsicht verlangen. In bestimmten Fällen, zum Beispiel bei kritischen Produkten oder Sicherheitsvorfällen, kann sie auch gezielt Teile der Dokumentation anfordern, etwa die Software-Stückliste oder Testberichte. Die Dokumentation selbst bleibt aber ein internes Dokument und wird weder veröffentlicht noch dem Kunden zur Verfügung gestellt.

Entscheidend ist nicht, dass es sich um ein einzelnes Dokument im klassischen Sinn handelt. Der Cyber Resilience Act schreibt keine bestimmte Form vor. Es muss kein PDF oder Bericht sein, der alles in sich vereint. Viel wichtiger ist, dass alle geforderten Inhalte vorhanden, nachvollziehbar strukturiert und jederzeit verfügbar sind. Wer also verschiedene Systeme im Einsatz hat, wie etwa ein Tool für die Software-Stückliste (siehe Governance: Software Bill of Materials (SBOM)), ein separates System für die Tests und ein zentrales Wiki für Architektur und Risikobewertung, darf diese Infrastruktur nutzen. Voraussetzung ist, dass die Informationen aktuell sind und im Zweifel schnell und vollständig bereitgestellt werden können. Für die Marktüberwachungsbehörde zählt am Ende die Nachvollziehbarkeit, nicht die Verpackung. Ein zentrales Verzeichnis oder eine Übersicht, die alle relevanten Inhalte und Systeme zusammenführt, kann dabei helfen, den Überblick zu behalten und im Ernstfall zügig zu reagieren.

Allgemeine Beschreibung des Produkts

Der erste Teil der technischen Dokumentation beschreibt das Produkt selbst. Es muss klar erkennbar sein, wofür das Produkt gedacht ist und welche Softwareversionen sicherheitsrelevant sind. Wenn es sich um ein Hardwareprodukt handelt, sind auch äußere Merkmale und der innere Aufbau zu dokumentieren. Ergänzend gehören an dieser Stelle auch die Nutzerinformationen gemäß Anhang II des CRA dazu, da sie unmittelbar mit dem sicheren Betrieb des Produkts zusammenhängen.

Technische Konzeption und Schwachstellenbehandlung

Im nächsten Schritt geht es um die Entwicklung, die Systemarchitektur und die Sicherheitsprozesse rund um das Produkt. Wie sich diese strukturiert aufbauen lassen, zeigen wir auch im Artikel CRA umsetzen: Anforderungen an die Behandlung von Schwachstellen?. In der technischen Dokumentation muss nachvollziehbar erklärt werden, wie das Produkt aufgebaut ist, wie die einzelnen Softwarekomponenten miteinander interagieren und wie sie in das Gesamtsystem eingebettet sind. Ebenso müssen Verfahren zur Behandlung von Schwachstellen dokumentiert werden. Dazu zählen unter anderem die Software-Stückliste, der Umgang mit gemeldeten Sicherheitslücken und der Nachweis einer funktionierenden Update-Infrastruktur. Auch die Herstellung und Qualitätssicherung müssen in diesem Zusammenhang beschrieben werden.

Gerade in agilen Teams kann an dieser Stelle ein Spannungsfeld entstehen. Das agile Manifest betont funktionierende Software mehr als umfassende Dokumentation. Es stellt Individuen und Interaktionen über Prozesse und Tools. Der CRA hingegen fordert belastbare Nachweise, strukturierte Verfahren und nachvollziehbare Dokumentation. Beides schließt sich nicht aus, verlangt aber ein bewusstes Austarieren zwischen agiler Praxis und regulatorischer Absicherung. Eine mögliche Lösung besteht darin, die Dokumentation als integralen Bestandteil des Entwicklungsprozesses zu betrachten und sie iterativ aufzubauen. Statt sie als statisches Ergebnis am Ende eines Projekts zu erzeugen, kann sie parallel zur Entwicklung gepflegt werden – beispielsweise durch automatisierte Reports, Architekturskizzen in Wikis oder strukturierte Reviews in jedem Sprint. So lässt sich der CRA erfüllen, ohne die Agilität zu verlieren.

Risikobewertung entlang des Lebenszyklus

Ein zentraler Bestandteil der Dokumentation ist die Bewertung der Cybersicherheitsrisiken. Diese muss von der Entwicklung über die Produktion bis hin zu Auslieferung und Wartung alle Phasen des Produktlebenszyklus abdecken. Es reicht nicht aus, Risiken pauschal zu benennen. Vielmehr ist zu zeigen, wie konkrete Bedrohungen erkannt, bewertet und durch geeignete Maßnahmen adressiert wurden. Die grundlegenden Anforderungen aus Anhang I Teil I dienen dabei als Bewertungsmaßstab.

Gleichzeitig bildet die Risikobewertung den Ausgangspunkt aller weiteren CRA-Maßnahmen. Sie legt fest, wo Handlungsbedarf besteht, und beeinflusst sowohl Architekturentscheidungen als auch Teststrategien und Supportkonzepte. Ihre Bedeutung endet jedoch nicht mit dem Produkt-Release. Die Risikobewertung ist ein lebendes Dokument, das kontinuierlich angepasst werden muss, zum Beispiel wenn neue Schwachstellen bekannt werden, sich Bedrohungslagen verändern oder Änderungen am Produkt vorgenommen werden. Ein funktionierender Prozess zur Pflege und Aktualisierung dieser Bewertung ist daher essenziell für die langfristige CRA-Konformität.

Festlegung des Unterstützungszeitraums

Ein weiterer wichtiger Punkt betrifft die Dauer, in der ein Produkt sicherheitsseitig betreut wird. Der sogenannte Unterstützungszeitraum muss im Vorfeld definiert und nachvollziehbar begründet werden. Es geht darum, zu dokumentieren, wie lange ein Produkt mit Sicherheitsupdates versorgt wird und welche Kriterien für das Ende dieses Zeitraums maßgeblich sind.

Der CRA legt kein fixes Minimum fest, fordert aber einen Zeitraum, der dem erwartbaren Einsatz und Risiko des Produkts gerecht wird. In der Regel wird man sich dabei am Produktlebenszyklus orientieren, also an der üblichen Nutzungsdauer im Feld. Produkte, die langfristig im Einsatz sind oder sicherheitskritische Funktionen übernehmen, müssen entsprechend länger betreut werden. Ein zu kurzer Zeitraum muss besonders gut begründet werden und kann im Einzelfall durch die Marktüberwachung infrage gestellt werden. Umgekehrt ist ein längerer Unterstützungszeitraum auch ein starkes Signal an den Kunden und kann regulatorische Diskussionen vermeiden. Die Festlegung sollte daher bewusst erfolgen und sowohl technische als auch betriebswirtschaftliche Perspektiven einbeziehen.

Verwendete Normen und Standards

Der CRA erlaubt es Herstellern, sich bei der Umsetzung der Anforderungen auf harmonisierte Normen, gemeinsame Spezifikationen oder Zertifizierungen nach europäischen Cybersicherheitszertifizierungsschemata zu stützen. Wenn solche Standards oder Zertifikate verwendet werden, müssen sie klar benannt werden. Aktuell existiert mit dem EUCC das erste offizielle europäische Zertifizierungsschema auf Basis der international anerkannten Common Criteria. Es bietet eine standardisierte und EU-weit akzeptierte Möglichkeit, die Konformität mit grundlegenden Sicherheitsanforderungen nachzuweisen. Weitere Schemata für Cloud-Dienste, 5G oder KI befinden sich in Vorbereitung. Daneben existieren etablierte branchenspezifische Standards wie SESIP für IoT-Plattformen oder IEC 62443 für industrielle Systeme, die ebenfalls als ergänzende Orientierung dienen können.

Falls keine solchen Normen oder Zertifizierungen angewendet werden, muss die Dokumentation detailliert beschreiben, wie die Anforderungen dennoch erfüllt werden. Auch eine teilweise Anwendung von Normen ist zulässig, muss dann aber entsprechend gekennzeichnet und erläutert werden.

Nachweis durch Tests und Prüfungen

Die technische Dokumentation muss nachvollziehbar belegen, dass das Produkt den Anforderungen des CRA entspricht. Dazu gehören strukturierte Test- und Prüfberichte, die sowohl die durchgeführten Methoden als auch deren Ergebnisse und Aussagekraft darstellen. Entscheidend ist, dass die gewählte Teststrategie zur Risikoeinschätzung passt und systematisch begründet ist.

In der Praxis kommen unterschiedliche Testarten zum Einsatz. Dazu zählen unter anderem die statische Analyse des Quellcodes, dynamische Laufzeitanalyse, Penetrationstests, Fuzzing, Bedrohungsmodellierung und komponentenbezogene Sicherheitstests. Ergänzend können Architektur- und Konfigurationsreviews sowie Integrationstests mit simulierten Angriffsszenarien sinnvoll sein. Welche Maßnahmen im Einzelfall angemessen sind, ergibt sich aus dem Produkttyp, der Einsatzumgebung und dem identifizierten Bedrohungspotenzial.

Orientierung bieten anerkannte Standards und Leitlinien. Das OWASP Application Security Verification Standard enthält konkrete Anforderungen an sicherheitsrelevante Funktionen und Testtiefe. Auch ENISA und das Bundesamt für Sicherheit in der Informationstechnik empfehlen abgestufte, schichtenbasierte Tests entlang der Softwarearchitektur.

Ergänzend gibt es internationale Normen, die übergreifend Orientierung bieten. Dazu gehören ISO/IEC 25002:2024, ISO/IEC 25010:2023 sowie ISO/IEC 25019:2023 zur Beschreibung von Softwarequalitätsmerkmalen, ISO/IEC/IEEE 29119-1:2022 für strukturierte Testprozesse sowie IEEE 1012-2016 für Verifikation und Validierung. Diese Normen unterstützen bei der Dokumentation, bei der Planung von Testmaßnahmen und bei der Einbettung der Qualitätssicherung in den Entwicklungsprozess. Mit dem Certified Tester Security Tester (CT-SEC) bietet das ISTQB zudem eine Zertifizierung an, mit der sich Teams gezielt auf sicherheitsrelevante Testaufgaben vorbereiten können.

Wichtig ist, dass Tests nicht isoliert betrachtet werden, sondern als fester Bestandteil eines kontinuierlichen Sicherheitsprozesses. Die gewählten Verfahren müssen zum Produkt passen, nachvollziehbar dokumentiert und im Zweifel wiederholbar sein.

EU-Konformitätserklärung

Ein vollständiger technischer Nachweis wäre nicht denkbar ohne die Konformitätserklärung. Dieses Dokument bestätigt, dass das Produkt alle einschlägigen Anforderungen erfüllt. Es ist formaler Bestandteil der technischen Dokumentation und muss bei einer Prüfung ebenfalls vorgelegt werden können.

Zugriff auf die Software-Stückliste

Auch wenn die Software-Stückliste bereits in einem anderen Teil der Dokumentation enthalten ist, kann die Marktüberwachungsbehörde sie gesondert anfordern. Hersteller müssen daher sicherstellen, dass die SBOM aktuell, vollständig und klar strukturiert vorliegt. Sie ist ein zentrales Element zur Bewertung der Cybersicherheitsrisiken und wird daher besonders streng geprüft. Werkzeuge, mit denen das leicht gelingt, haben wir im Beitrag Governance: Software Bill of Materials (SBOM) vorgestellt.

Dokumentation als Sicherheitsnachweis

Die technische Dokumentation ist der zentrale Beleg dafür, dass ein Produkt im Sinne der Verordnung sicher entwickelt wurde. Sie muss vorliegen, bevor ein Produkt auf den Markt kommt. Wer hier lückenhaft oder oberflächlich arbeitet, riskiert nicht nur Beanstandungen, sondern auch empfindliche Sanktionen. Gleichzeitig ist eine vollständige und gut gepflegte Dokumentation ein Zeichen für Qualität und Sorgfalt. Sie schafft Vertrauen bei Kunden, Partnern und Behörden. Wer die Anforderungen des CRA frühzeitig ernst nimmt, hat langfristig weniger Aufwand und deutlich bessere Argumente, falls es einmal darauf ankommt.

Fazit

Der CRA macht Schluss mit lückenhafter technischer Dokumentation. Was in welchem Umfang dokumentiert werden muss, ist nun klar geregelt. Hersteller sollten nicht den Fehler machen, diesen Teil der Verordnung als lästige Pflicht zu betrachten. Die technische Dokumentation ist kein Nebenprodukt, sondern ein zentrales Element der Produktsicherheit. Sie bildet die Grundlage für Konformität, behördliche Nachvollziehbarkeit und langfristige Wartbarkeit.

Nehmen Sie sich daher jetzt die Zeit für eine strukturierte Bestandsaufnahme. Prüfen Sie, welche Anforderungen aus Anhang VII bereits erfüllt sind und wo Lücken bei Architektur, Risikobewertung, Tests, Updateprozessen oder der SBOM bestehen. Gerne unterstützen wir Sie mit unserem CRA-Workshop: praxisnah, kompakt und mit einem klaren Fahrplan für die Umsetzung.