CRA-Dokumentation aktuell halten: Was die Verordnung tatsächlich verlangt

Die meisten Teams begegnen den Dokumentationspflichten des CRA als einem Tor. Technische Dokumentation zusammenstellen, Konformitätserklärung unterschreiben, CE-Kennzeichnung anbringen, ausliefern. Die Unterlagen wandern in einen Ordner und das Team kehrt zur Produktentwicklung zurück. Diese Lesart ist verständlich, denn so funktionieren einmalige Zertifizierungsregime. So funktioniert der CRA nicht. Der Verordnungstext knüpft die Dokumentationspflicht an den gesamten Unterstützungszeitraum, und Unterlagen, die bei der CE-Kennzeichnung korrekt waren, aber das Produkt vom letzten Jahr beschreiben, sind ein Prüfungsbefund, der nur darauf wartet, festgestellt zu werden.

Dieser Beitrag behandelt, was die Verordnung über die Aktualität der Dokumentation sagt, welche Ereignisse eine Aktualisierung verlangen und wie ein praktikabler Pflegerhythmus aussieht. Er baut auf den Nachweisanforderungen der technischen Dokumentation auf, die den geforderten Inhalt behandeln, sowie auf der Abhängigkeitskette der Artefakte, die zeigt, wie die Dokumente einander speisen.

Drei Dokumente mit ausdrücklicher Aktualisierungspflicht

Der CRA benennt drei Dokumente, die aktuell gehalten werden müssen, jedes mit eigener Formulierung.

Die technische Dokumentation trägt die stärkste Formulierung. Artikel 31(2) verlangt, dass sie vor dem Inverkehrbringen erstellt und danach "kontinuierlich aktualisiert" wird, "gegebenenfalls mindestens während des Unterstützungszeitraums". Zwei Dinge in diesem Satz verdienen Aufmerksamkeit. "Kontinuierlich" schließt die Lesart des jährlichen Aktenordners aus. Und "mindestens während des Unterstützungszeitraums" setzt eine Untergrenze. Die Pflicht erlischt nicht mit der ersten Zusammenstellung der Unterlagen, sie läuft, solange das Produkt unterstützt wird, nach Artikel 13(8) mindestens fünf Jahre, sofern die erwartete Nutzungsdauer des Produkts nicht tatsächlich kürzer ist.

Die Cybersicherheits-Risikobewertung hat ihre eigene Uhr. Artikel 13(3) verlangt, dass sie dokumentiert und während des Unterstützungszeitraums "gegebenenfalls aktualisiert" wird, und Artikel 13(4) macht sie zum Bestandteil der technischen Dokumentation. Da die Bewertung den Verwendungszweck, die vernünftigerweise vorhersehbare Verwendung und die Einsatzumgebung des Produkts abbilden muss, macht jede wesentliche Änderung dieser Eingaben die dokumentierte Bewertung falsch, bis sie aktualisiert ist. Eine Bewertung, die noch die Architektur von vor zwei Releases beschreibt, besteht diesen Test nicht, obwohl nichts darin je falsch war, als es geschrieben wurde.

Die EU-Konformitätserklärung schließt den Kreis. Artikel 28 verlangt, dass sie auf dem neuesten Stand gehalten wird. Die Erklärung versichert, dass das Produkt die grundlegenden Anforderungen erfüllt. Alles, was die Grundlage dieser Zusicherung verändert, eine neue Konformitätsbewertung, eine geänderte Normenliste, ein geänderter Unterstützungszeitraum, bedeutet, dass die Erklärung entsprechend erneuert werden muss.

Die Ereignisse, die eine Aktualisierung auslösen

Die Verordnung verteilt keinen Prüfkalender. Sie definiert die Bedingungen, unter denen Dokumentation veraltet, und vier Arten von Ereignissen leisten dabei die meiste Arbeit.

Neue Releases sind der Alltagsfall. Jede Softwareversion, die Funktionalität, Schnittstellen oder Abhängigkeiten ändert, entwertet potenziell Teile der Unterlagen, die Architekturbeschreibung, die SBOM, die Asset-Liste der Risikobewertung. Die meisten Releases erfordern nur gezielte Anpassungen, aber die Prüfung muss stattfinden.

Die wesentliche Änderung ist der scharfe Fall. Nach Artikel 32 in Verbindung mit den Leitlinien der Kommission macht eine Änderung, die die Konformität des Produkts mit den grundlegenden Anforderungen berührt oder seinen Verwendungszweck verändert, das geänderte Produkt rechtlich zu einem neuen Produkt. Das bedeutet eine neue Konformitätsbewertung, aktualisierte technische Dokumentation und eine neue Konformitätserklärung, bevor die geänderte Version in Verkehr gebracht wird. Die Grenze zwischen gewöhnlichem Update und wesentlicher Änderung ist eine Ermessensentscheidung, die der Hersteller treffen und verteidigen können muss. Genau das ist ein Grund, den Bewertungsstand bei jedem Inverkehrbringen festzuhalten, damit es etwas Konkretes zum Vergleichen gibt.

Bedrohungs- und Schwachstellenereignisse bilden die dritte Klasse. Der Risikomanagementrahmen, auf den der CRA verweist, abgebildet in Abschnitt 6.7.3 der Bewertungsmethodik, erwartet eine erneute Überprüfung der Risikobewertung, wenn sich die Bedrohungslage verschiebt, eine relevante Schwachstelle in einer Komponente offengelegt wird oder ein Sicherheitsvorfall das Produkt berührt. Ein kritischer CVE in einer Bibliothek auf der SBOM des Produkts ist genau ein solches Ereignis. Ebenso eine glaubwürdige Schwachstellenmeldung über den eigenen Meldekanal des Herstellers.

Änderungen am Unterstützungszeitraum sind der stille vierte Fall. Der Unterstützungszeitraum erscheint in den Anhang-II-Nutzerinformationen und verankert mehrere Pflichten. Ihn zu verlängern, zu verkürzen oder auslaufen zu lassen, ohne die Nutzer zu informieren, sind allesamt Dokumentationsereignisse. Artikel 13(8) erwartet, dass Nutzer wissen, wie es um die Unterstützung steht.

Veraltete Dokumentation ist unmittelbar prüfbar

Was diesen Pflichten Zähne verleiht, ist Artikel 13(13). Der Hersteller muss die technische Dokumentation und die EU-Konformitätserklärung mindestens zehn Jahre nach dem Inverkehrbringen oder für den Unterstützungszeitraum, je nachdem, welcher Zeitraum länger ist, für die Marktüberwachungsbehörden bereithalten. Eine Behörde, die die Unterlagen anfordert, erhält den Zustand, in dem sie sich tatsächlich befinden. Beschreiben die Unterlagen ein Produkt, das drei Versionen zurückliegt, ist die Abweichung beim ersten Vergleich mit dem ausgelieferten Produkt sichtbar, und die Last der Erklärung liegt beim Hersteller.

Deshalb zählen auch Aufzeichnungen zu festen Zeitpunkten. Ein Hersteller, der den Stand seiner Bewertung bei jedem Inverkehrbringen und jeder wesentlichen Änderung festhält, kann einer Behörde genau zeigen, was wann galt, und belegen, dass spätere Änderungen in spätere Aufzeichnungen eingeflossen sind. Ein Hersteller mit einem einzigen, fortlaufend überschriebenen Dokument kann nur die Gegenwart zeigen.

Ein Rhythmus, der in der Praxis funktioniert

Die Logik der Verordnung legt einen doppelten Rhythmus nahe, und die Risikomanagementnormen, auf die sie sich stützt (ISO 31000, IEC 62443), sagen dasselbe. Eine zeitbasierte Basisüberprüfung fängt schleichende Drift ab, die kein einzelnes Ereignis anzeigt. Eine ereignisgesteuerte Überprüfung fängt die plötzlichen Änderungen zwischen den Basisterminen ab. Praktisch heißt das vier Gewohnheiten.

Erstens, eine Überprüfungsregelmäßigkeit festlegen und einhalten. Die Bewertungsmethodik erwartet ein dokumentiertes Überprüfungsintervall für die Risikomanagementaktivitäten, vierteljährlich, wo erhöhte Restrisiken im Register verbleiben, halbjährlich, wo alles aktiv mitigiert wird. Das festgelegte Intervall ist selbst Teil der technischen Dokumentation, ein Prüfer kann also kontrollieren, ob es eingehalten wurde. Unterlagen, die vierteljährliche Überprüfungen versprechen und keine aufweisen, sind selbst dokumentierte Nichtkonformität.

Zweitens, Dokumentationsprüfungen an den Release-Prozess koppeln. Die Frage "ändert dieses Release die Unterlagen" gehört in die Definition of Done, und die Frage nach der wesentlichen Änderung gehört in die Release-Planung, bevor das geänderte Produkt ausgeliefert wird, nicht danach.

Drittens, auslösende Ereignisse festhalten, wenn sie eintreten, und sie danach schließen. Ein CVE-Treffer, eine offengelegte Schwachstelle, eine veränderte Bedrohungslage. Jedes wird ein erfasster Vorgang, der offen bleibt, bis die geforderte erneute Überprüfung stattgefunden hat. Die Aufzeichnung erfasster und erledigter Auslöser ist der Nachweis, dass die Überwachung in die Bewertung zurückfließt. Genau das fragt Abschnitt 6.7.3 eigentlich ab.

Viertens, zu den rechtlichen Momenten einen Schnappschuss anfertigen. Inverkehrbringen und wesentliche Änderung sind die beiden Punkte, an denen die Verordnung genau wissen will, was die Dokumentation aussagte. Eine unveränderliche, versionierte Aufnahme zu jedem dieser Momente, aufbewahrt für das Fenster aus Artikel 13(13), verwandelt eine spätere Prüfung von einer Debatte in ein Nachschlagen.

Wie das im CRA Portal funktioniert

Der Produktarbeitsbereich im CRA Portal setzt diesen Rhythmus um, statt ihn der Kalenderdisziplin zu überlassen.

Jedes Produkt führt eine periodische Überprüfungsuhr. Der Rhythmus wird aus dem produkteigenen Regelmäßigkeitsartefakt gelesen, dem C6.7-Dokument, das der Arbeitsbereich aus dem Risikoregister entwirft, und kann ausdrücklich überschrieben werden. Sobald das Produkt einen Inverkehrbringens-Schnappschuss hat, läuft die Uhr. Eine Erinnerungs-E-Mail geht dreißig Tage vor Fälligkeit der Überprüfung hinaus und erneut bei Überfälligkeit. Das Abschließen der Überprüfung stempelt das Datum, verschiebt den nächsten Fälligkeitstermin und legt einen unveränderlichen Überprüfungsdatensatz ab, wer geprüft hat, wann, in welchem Rhythmus, als exportierbaren Nachweis, dass die festgelegte Regelmäßigkeit gelebt wird.

Überprüfungsauslöser werden am selben Ort erfasst, und die Plattform erzeugt einige davon selbst. Ein Lieferketten-Scan, der eine kritische, hochschwere oder aktiv ausgenutzte Schwachstelle in einer SBOM-Komponente findet, öffnet einen Auslöser auf jedem bewerteten Produkt, und eine Schwachstellenmeldung über das Meldeportal des Unternehmens öffnet einen, sobald sie als echt eingestuft wird. Auslöser, die zwei Wochen unbearbeitet offen stehen, erhalten eine Erinnerung. Sie zu schließen ist Teil des Überprüfungsabschlusses.

Veralterung wird bei Änderung ebenso erkannt wie über die Zeit. Jede Exportfreigabe ist an einen Hash des Bewertungsinhalts gebunden, sodass jede Bearbeitung nach der Freigabe die Freigabe als veraltet markiert und den Export der technischen Dokumentation sperrt, bis ein zweiter Prüfer erneut freigibt. Derselbe Hash wird in jedem Schnappschuss festgehalten. Driftet der Bewertungsinhalt vom letzten Inverkehrbringens-Stand ab, zeigt der Arbeitsbereich einen Hinweis auf eine mögliche wesentliche Änderung und verweist auf den Schnappschuss- und Neubewertungsablauf. Die Entscheidung bleibt beim Hersteller, die Drifterkennung nicht.

Der Unterstützungszeitraum bekommt einen Countdown. Neunzig und dreißig Tage vor dem erklärten Ende warnt der Arbeitsbereich und erinnert per E-Mail, mit Verweis auf das Anhang-II-Blatt, in das die End-of-Support-Mitteilung an die Nutzer gehört.

Nichts davon hält die Dokumentation von allein aktuell. Es macht Veralterung früh sichtbar, und das ist der Teil, an dem Kalenderdisziplin zuverlässig scheitert. Der Anhang-VII-Erklärtext behandelt den geforderten Inhalt der Unterlagen, und der Beitrag zur Artefaktkette zeigt, wie eine Aktualisierung in einem Dokument in die übrigen durchschlägt. Das Muster ist überall dasselbe. Unter dem CRA wird Dokumentation gepflegt wie das Produkt, das sie beschreibt, in einem Rhythmus, mit Auslösern und mit einer Aufzeichnung jeder Revision.