Die eine Pflicht legt eine Zahl von Jahren fest, die andere gar kein Intervall. Hier stehen die Klauseln, die jeweils die eine und die andere auferlegen, und die Felder, die daraus für jeden Nachweiseintrag folgen.
Die eine Pflicht legt eine Zahl von Jahren fest, die andere gar kein Intervall. Hier stehen die Klauseln, die jeweils die eine und die andere auferlegen, und die Felder, die daraus für jeden Nachweiseintrag folgen.
Von den zwei Pflichten, die ein Regulierer an ein Stück Compliance-Nachweis knüpft, ist die mit einer Zahl darin die leichtere, und sie ist diejenige, um die herum Nachweisablagen gebaut werden. Die Verordnung (EU) 2024/2847, die Cyberresilienz-Verordnung, trägt beide. Art. 13(13) verpflichtet Hersteller, die technische Dokumentation und die EU-Konformitätserklärung „nach dem Inverkehrbringen des Produkts mit digitalen Elementen mindestens zehn Jahre lang oder für die Dauer des Unterstützungszeitraums, je nachdem, welcher Zeitraum länger ist“ für die Marktüberwachungsbehörden aufzubewahren. Art. 31(2) verlangt dann, dass dieselbe Dokumentation „gegebenenfalls, zumindest während des Unterstützungszeitraums, laufend aktualisiert“ wird, und das ist eine wiederkehrende Handlung, an der kein Intervall hängt. Eine Ablage, die jedem Eintrag ein Datum gibt, beantwortet den ersten Artikel und sieht aus, als hätte sie den zweiten mitbeantwortet.
Über die Rechtsakte hinweg gelesen, lautet die Pflicht Nachweisbarkeit: einen bestimmten Nachweis vorlegen, gegenüber einer benannten Stelle, zu einem Zeitpunkt, den Sie nicht wählen.
Die Cyberresilienz-Verordnung klärt die ersten beiden Punkte und ergänzt eine Dauer. Art. 13(13) benennt den Pflichtenträger (Hersteller), das Objekt (technische Dokumentation und EU-Konformitätserklärung), das Gegenüber (Marktüberwachungsbehörden) und wie lange die Pflicht läuft. Art. 31(1) und Anhang VII sagen, was in diesem Objekt steckt: die Software-Stückliste, das Konzept für die koordinierte Offenlegung von Schwachstellen, Prüfberichte, ein Exemplar der Konformitätserklärung selbst. Was die Verordnung nicht klärt, ist der Zeitpunkt, und der kommt von der Aufsichtsseite.
Die DSGVO formuliert die Nachweispflicht direkt und hängt ihr nirgends eine Frist an. Art. 5(2): „Der Verantwortliche ist für die Einhaltung des Absatzes 1 verantwortlich und muss dessen Einhaltung nachweisen können (‚Rechenschaftspflicht‘).“ Art. 24(1) verlangt vom Verantwortlichen Massnahmen, „um sicherzustellen und den Nachweis dafür erbringen zu können, dass die Verarbeitung gemäss dieser Verordnung erfolgt“, und schliesst:
„Diese Massnahmen werden erforderlichenfalls überprüft und aktualisiert.“
Dieser Satz legt kein Intervall fest und benennt nichts, was die Uhr in Gang setzt. Art. 30(4) liefert die Hälfte auf Abruf: Das Verzeichnis von Verarbeitungstätigkeiten wird „der Aufsichtsbehörde auf Anfrage zur Verfügung“ gestellt. Art. 30(5) nimmt Unternehmen und Einrichtungen aus, die weniger als 250 Mitarbeiter beschäftigen, sofern keine der dort aufgezählten Bedingungen greift; diese Pflicht gilt also nicht für alle.
Die NIS-2-Richtlinie legt dieselbe Forderung in die Hand der Aufsicht. Art. 32(2) verpflichtet die Mitgliedstaaten sicherzustellen, dass die zuständigen Behörden gegenüber wesentlichen Einrichtungen „mindestens“ sieben Massnahmen vornehmen können; die letzte davon, Buchstabe g, lautet:
„Anforderung von Nachweisen für die Umsetzung der Cybersicherheitskonzepte, z. B. der Ergebnisse von Sicherheitsprüfungen, die von einem qualifizierten Prüfer durchgeführt wurden, und der entsprechenden zugrunde liegenden Nachweise.“
Dieselbe Befugnis besteht für wichtige Einrichtungen nach Art. 33(2) Buchstabe f, innerhalb der nachträglichen Aufsicht, die Art. 33(1) einrichtet. Zwei Details in dieser Formulierung verdienen ihren Platz in einem Datenmodell. Verlangt wird das Prüfergebnis und das Material, das darunterliegt. Und Art. 32(3) begrenzt die Anfrage: Bei der Ausübung ihrer Befugnisse nach Buchstabe e, f oder g „geben die zuständigen Behörden den Zweck der Anfrage und die erbetenen Informationen an“. Was ankommt, ist eine eingegrenzte Frage nach einer bestimmten Sache, an einem Datum, das niemand auf der Empfängerseite ausgesucht hat.
NIS2 hat kein Gegenstück zu Art. 24(1) DSGVO, und man nimmt leicht an, es gäbe eines: Art. 21(1) und (2) enthalten keinen Satz über Überprüfung und Aktualisierung, und ich habe danach gesucht. Der Druck, den NIS2 auf die Aktualität ausübt, ist stattdessen aufsichtsrechtlich: Eine Behörde kann an jedem Tag fragen, also muss der Nachweis an jedem Tag angemessen sein.
Der Wortlaut, der als „die Klausel zur dokumentierten Information in der ISO 27001“ zitiert wird, stammt nicht ursprünglich aus der ISO/IEC 27001. Er leitet sich aus der Harmonized Structure ab, deren Anwendung die ISO/IEC-Direktiven, Teil 1, Consolidated ISO Supplement für Managementsystemnormen vorschreiben. Annex SL, Klausel SL.8.2: „Type A MSS shall apply the harmonized structure detailed in Appendix 2.“ (englisches Original; eine offizielle deutsche Fassung dieses Texts liegt nicht vor, alle folgenden Zitate daraus bleiben ebenfalls im Original). Typ A ist in demselben Annex definiert als eine MSS, die „requirements“ liefert, und genau das sind ISO/IEC 27001 und ISO 22301 beide: Jede trägt einen Titel, der auf „— Requirements“ endet.
„Leitet sich ab“ ist so weit, wie ich gehe. Die Direktiven erlauben einem Komitee, „add or insert discipline-specific text“ (SL.8.3(e)) und, unter aussergewöhnlichen fachspezifischen Umständen, „amend the text and introduce a deviation“ (SL.8.3(i)). Das frei verfügbare Harmonized-Structure-Dokument, Appendix 2 zu Annex SL und von jener Supplement-Seite aus erreichbar, wurde am 30.07.2025 mit TMB-Resolution 74/2025 verabschiedet. Es trägt einen Change-Log-Eintrag, der die „[a]ddition of a full stop at the end of Annex SL clause 7.5.3“ festhält. Ein Revisionsprotokoll, das 2025 noch die Zeichensetzung innerhalb von 7.5.3 nachhält, schliesst jede Behauptung textlicher Identität mit einer Norm aus, deren aktuelle Ausgabe von 2022 stammt. Aus diesem Katalogeintrag stammt das Ausgabejahr; die Norm selbst liegt hinter einer Bezahlschranke, ich habe sie nicht geöffnet, und nichts von dem hier Zitierten stammt aus ihr.
Der frei verfügbare Text zeigt aber, dass das Skelett die beiden Pflichten bereits trennt. Klausel 7.5.2, „Creating and updating documented information“, verlangt von der Organisation sicherzustellen, dass Folgendes angemessen ist:
- identification and description (e.g. a title, date, author, or reference number);- format (e.g. language, software version, graphics) and media (e.g. paper, electronic);- review and approval for suitability and adequacy.
Klausel 7.5.3, „Control of documented information“, verlangt, dass dokumentierte Information „shall be controlled to ensure ... it is available and suitable for use, where and when it is needed“, und listet die Tätigkeiten auf, die die Organisation „as applicable“ behandeln soll: distribution, access, retrieval and use; storage and preservation; control of changes; „retention and disposition“.
Die Aktualitätspflicht sitzt in 7.5.2, die Aufbewahrungspflicht in 7.5.3, eine Unterklausel voneinander entfernt, innerhalb des Skeletts, das jede Anforderungsnorm anwenden muss. Keine von beiden trägt eine Frist.
Eine Zählung ist es wert, veröffentlicht zu werden, samt der Angabe, worüber gezählt wurde. Über den normativen Text dieses Harmonized-Structure-Dokuments hinweg kommt das Wort „retain“ null Mal vor. Die wiederkehrende Formel lautet „Documented information shall be available as evidence of …“, fünf Vorkommen, in den Klauseln 7.2, 9.1, 9.2.2, 9.3.3 und 10.2, und sie deckt Kompetenz, Überwachungsergebnisse, das interne Auditprogramm, Ergebnisse der Managementbewertung und Korrekturmassnahmen ab. Diese Zählung bezieht sich auf die Harmonized Structure, nicht auf die ISO/IEC 27001. „Available“ ist das massgebliche Verb, und es ist dieselbe Forderung, die die Verordnungen stellen: abrufbar in dem Moment, in dem jemand fragt.
| Pflicht | Klausel | Was sie begrenzt | Was bricht, wenn Sie nur die jeweils andere nachhalten |
|---|---|---|---|
| Aufbewahrung | CRA Art. 13(13) | Wie lange die Dokumentation für die Marktüberwachungsbehörden bereitgehalten wird: mindestens zehn Jahre oder der Unterstützungszeitraum | Der Eintrag wird entsorgt, während die Pflicht noch läuft, und es ist nichts mehr da, was vorgelegt werden könnte |
| Aktualität (Dokument) | CRA Art. 31(2) | Dass die Dokumentation „gegebenenfalls, zumindest während des Unterstützungszeitraums, laufend aktualisiert“ wird | Die Datei ist gültig aufbewahrt und beschreibt das Produkt, das sie dokumentiert, nicht mehr |
| Aktualität (Prozess) | DSGVO Art. 24(1) | Dass Massnahmen „erforderlichenfalls überprüft und aktualisiert“ werden, eine wiederkehrende Handlung ohne Intervall | Der Nachweis vom letzten Jahr liegt in der Akte, und nichts hält fest, dass ein frischer Blick fällig ist |
| Verfügbarkeit | DSGVO Art. 30(4); NIS2 Art. 32(2)(g) | Dass einer benannten Behörde auf Anfrage der Eintrag und der Nachweis darunter ausgehändigt werden kann | Ein aktueller, gut aufbewahrter Eintrag, den niemand gegen eine eingegrenzte Anfrage auffinden kann |
Die zwei Uhren haben verschiedene Eigner. Das ist der praktische Grund, warum ein Feld nicht beide bedienen kann. Den Gültigkeitszeitraum eines Dokuments setzt, wer es ausgestellt hat: eine Zertifizierungsstelle, ein Pentest-Anbieter, eine Gegenpartei, die einen Auftragsverarbeitungsvertrag unterschrieben hat. Die Organisation, die das Dokument hält, erbt dieses Datum und kann es nicht verschieben. Eine Review-Kadenz ist die eigene Entscheidung der Organisation, und jemand in der Organisation muss dafür geradestehen.
Die Kollisionen sind alltäglich: Ein Zertifikat läuft drei Monate in einen zwölfmonatigen Review-Zyklus hinein ab, der Kalender sagt also „in Ordnung“, während das Artefakt tot ist; oder ein Review wird für ein Dokument fällig, das noch gültig ist, weil gefragt wird, ob die Aussage trägt, und nicht, ob das PDF abgelaufen ist.
Die Aufbewahrung hat ausserdem ein definiertes Ende, das die Aktualität nicht hat. Harmonized Structure 7.5.3 paart „retention“ mit „disposition“, und CRA Art. 13(13) läuft aus. Eine Aktualitätspflicht läuft, bis die zugrunde liegende Verpflichtung endet, und deshalb tritt sie nie als Countdown auf.
Fünf Felder, in jedem Werkzeug, auch in einem Spreadsheet:
| Feld | Frage, die es beantwortet | Pflicht, der es dient | Wer es setzt |
|---|---|---|---|
| Eigner | Wer dafür geradesteht, dass dieser Nachweis existiert und auffindbar ist | Verfügbarkeit (DSGVO Art. 30(4), NIS2 Art. 32(2)(g)) | Die Organisation |
| Freigebende Person, samt Zeitstempel der Freigabe | Wer diesen Nachweis zuletzt als angemessen beurteilt hat, und wann | Aktualität (HS 7.5.2, „review and approval for suitability and adequacy“) | Die Organisation |
| Gültigkeitszeitraum am Dokument (ausgestellt, läuft ab) | Liegt dieses Artefakt noch innerhalb des Zeitraums, für den sein Aussteller einsteht | Aktualität, auf Dokumentebene (CRA Art. 31(2)) | Der Aussteller |
| Review-Kadenz und nächstes Review-Datum am Eintrag | Wann muss jemand da wieder hinsehen | Aktualität, auf Aussageebene (DSGVO Art. 24(1)) | Die Organisation |
| Verknüpfung zum Control oder zur Anforderung, die er stützt | Wofür das ein Nachweis ist und wogegen er vorgelegt werden kann | Verfügbarkeit | Die Organisation |
Die nicht offensichtliche Paarung ist die dritte gegen die vierte. Ein Ablaufdatum gehört zum Dokument, weil ein Nachweiseintrag mehrere Dokumente mit verschiedenen Ablaufdaten halten kann: ein Zertifikat, den Bericht dahinter, ein Attestierungsschreiben. Setzen Sie ein einzelnes Ablaufdatum auf den Eintrag, dann speichern Sie entweder das früheste, das für jeden anderen Anhang falsch ist, oder eine Kopie, die von ihrer Quelle wegdriftet. Ein Review-Datum gehört zum Eintrag, weil „ist das noch angemessen?“ eine Frage an die Aussage ist und nicht an einen einzelnen Anhang. Aufbewahrung und Entsorgung hängen dann an derjenigen der beiden Ebenen, an die die jeweils geltende Pflicht bindet.
Das alles zu erfassen, während die Arbeit passiert, statt in der Woche vor einem Audit, ist ein eigenes Argument; Angelo hat es in Audit-Bereitschaft ist ein Zustand, den man hält vorgebracht.
devguard ist ein durchgearbeitetes Beispiel für diese Form und trennt die zwei Datumsangaben entlang derselben Naht. Das Ablaufdatum gehört zum Anhang: Jede Datei an einem Nachweiseintrag trägt ihr eigenes Ausstellungs- und ihr eigenes Ablaufdatum, sodass ein Zertifikat und der Bericht dahinter an verschiedenen Tagen ablaufen können, ohne dass eines das andere überschreibt. Das Review gehört zum Eintrag: Ein Nachweiseintrag trägt einen Review-Zeitplan, das Datum des letzten Reviews und das Datum, an dem das nächste fällig wird. Dieses nächste Datum wird aus dem Zeitplan abgeleitet und nicht eingetippt, es kann der gewählten Kadenz also nicht unbemerkt widersprechen. Ein Eintrag, den eine Integration tatsächlich aktuell hält, kann stattdessen so markiert werden, dass überhaupt kein periodisches Review geschuldet ist, was etwas anderes ist als eine Kadenz von null, und deshalb trägt ein solcher Eintrag gar kein nächstes Review-Datum.
Die Freigabe ist das Review. Einen Nachweiseintrag freizugeben hält fest, wer ihn freigegeben hat und wann, und verankert im selben Zug das Datum des letzten und des nächsten Reviews neu. Es gibt kein separates „als geprüft markieren“ und damit auch keinen zweiten Zeitstempel, der vom ersten wegdriften könnte.
NIST SP 800-53A Rev. 5 ist eine US-Bundesmethodik für Assessments, und ich verwende sie hier als Beschreibung dessen, was ein Assessment ist, nicht als Rahmenwerk, das irgendjemand hier übernehmen müsste. Abschnitt 2.4.1 ordnet Assessment-Objekte als „specifications, mechanisms, activities, and individuals“ ein und definiert das erste: „Specifications are the document-based artifacts (e.g., policies, procedures, plans, system security and privacy requirements, functional specifications, architectural designs)“ (englisches Original; die Publikation liegt nur auf Englisch vor, alle Zitate in diesem Abschnitt bleiben im Original). Ein Dokument ist eine Sache, die bewertet wird. Drei der vier Objekttypen lassen sich in einer Dokumentenablage überhaupt nicht halten.
Die Methoden wirken auf diese Objekte. Examine ist „the process of reviewing, inspecting, observing, studying, or analyzing one or more assessment objects“. Das Ergebnis ist eine Feststellung, erzeugt von einem Menschen: Jeder Feststellungssatz, „executed by an assessor“, ergibt satisfied oder other than satisfied, und other than satisfied „may also indicate that the assessor was unable to obtain sufficient information to make the determination“. Ein Artefakt kann vorhanden sein, richtig abgelegt, noch fristgerecht, und die Feststellung kommt trotzdem nicht zustande.
Ein Datenmodell, das das Anlegen einer Verknüpfung als Feststellung behandelt, hält deshalb einen Schluss fest, den niemand gezogen hat. Was eine Verknüpfung ehrlich festhalten kann, ist, dass etwas Relevantes existiert und nicht abschliessend beurteilt wurde.
devguard leitet die Abdeckung eines Controls beim Lesen aus dem ab, was daran hängt, in einer festen Reihenfolge. Ein Control, das als nicht relevant markiert ist, meldet das und hört dort auf. Sonst entscheiden seine Tasks: alle Tasks erledigt liest sich als vollständig abgedeckt, einige davon begonnen als teilweise, keine davon begonnen als nicht abgedeckt. Nur ein Control, das überhaupt keine Tasks trägt, fällt auf seine Nachweise durch, und eine Nachweisverknüpfung allein liest sich als teilweise.
Lesen Sie diesen letzten Schritt als Obergrenze. Einen Nachweis mit einem Control zu verknüpfen, das keine Tasks trägt, hebt es von unbekannt auf teilweise, und teilweise zählt in der aggregierten Prozentzahl als abgedeckt. Eine Datei anzuhängen bewegt die Zahl also, bevor irgendjemand beurteilt hat, ob die Datei zeigt, dass das Control wirkt. Das ist der ehrliche Preis dieses Entwurfs. Was ein Nachweis allein nie erzeugen kann, ist volle Abdeckung: Dafür braucht es Tasks, und jede einzelne davon erledigt. Wo Tasks existieren, entscheiden sie den Status vollständig, und die Nachweise werden nie erreicht.
Die Nachweiserfassung in devguard ist inzwischen automatisiert, in einer ganz bestimmten Form, und die Form zählt mehr als das Wort. Sie deklarieren Collectors in einer Konfigurationsdatei, jeder davon ein Befehl, der ohnehin schon irgendwo in Ihrer Pipeline läuft: ein Dependency-Audit, ein Scanner-Bericht, die Ausgabe eines Plans. Die devguard CLI führt sie aus, prüft jedes Artefakt gegen einen Satz von Secret-Mustern, bevor irgendetwas Ihre Maschine verlässt, und lädt die Ausgabe in einen benannten Nachweiseintrag. Dateien, die so ankommen, sind in der App als automatisiert markiert, mit dem Namen des Collectors neben der Markierung, sodass niemand später rekonstruieren muss, ob ein Mensch die Datei dort abgelegt hat.
Jeder Push ersetzt die vorherige Datei dieses Collectors. Ein Nachweiseintrag hält genau ein aktuelles Artefakt pro Collector, und von Hand hochgeladene Dateien oder Dateien aus einem anderen Collector bleiben unangetastet. Die Ersetzung ist endgültig: Das vorherige Artefakt wird entfernt und nicht archiviert, hinter einem Collector steht also keine Versionshistorie, und wer einen Collector umbenennt, beginnt eine neue Serie, während die alte Datei liegen bleibt und nichts sie mehr erneuert.
Jede hochgeladene Datei trägt ein Aktualitätsfenster, pro Collector gesetzt. Läuft das Fenster ohne Erneuerung ab, erscheint die Datei in der Fristen-Ansicht unter „Automated Evidence“, in derselben Liste wie ein überfälliges Review. Eine Pipeline, die zu laufen aufgehört hat, zeigt sich damit als abgelaufene Datei statt als Schweigen, und das ist der Fehlerfall, für den zu entwerfen sich lohnt.
Halten Sie das nun gegen die zwei Uhren. Die Automatisierung ist genau in einer davon gut, in der Aktualität auf Dokumentebene. Das Artefakt wird neu erzeugt, sein Ausstellungsdatum wandert mit, das Aktualitätsfenster beginnt von vorn, und ein abgelaufenes meldet sich auf einer Seite, auf die ohnehin jemand schaut. Das ist die Gestalt der Pflicht aus CRA Art. 31(2), und für alles, was ein Befehl erzeugen kann, ist sie damit tatsächlich erledigt.
Den Rest rührt sie nicht an, und zwar absichtlich. Ein Push ändert die Abdeckung eines Controls nicht und setzt das Review-Datum des Eintrags nicht zurück. Die Frage aus Art. 24(1) DSGVO, ob diese Massnahme noch angemessen ist, ist ein Urteil über eine Aussage, und eine frische Datei ist eine Eingabe für dieses Urteil, nicht das Urteil selbst. Der Aufbewahrung hilft sie ebenso wenig, und in einer Hinsicht läuft sie ihr entgegen: Weil jeder Push das vorherige Artefakt dieses Collectors endgültig entfernt, ist ein Collector der falsche Ort für etwas, an das eine zehnjährige Aufbewahrungspflicht bindet. Und die Verfügbarkeit hängt weiterhin daran, dass jemand den Eintrag mit dem Control oder der Anforderung verknüpft hat, die er beantwortet.
Es gibt im Produkt noch eine schwächere Sache mit einem ähnlichen Namen, und die ist davon zu trennen. Ein Nachweiseintrag kann mit der Integrations-Aktion beschriftet werden, aus der sein Nachweis erwartungsgemäss stammt, und die Liste zeigt dann diesen Namen anstelle von „Manual“. Das ist eine Beschriftung, die festhält, woher der Nachweis kommen soll, und kein Job, der ihn holt; jemand hängt die Datei weiterhin selbst an.
Die Automatisierung kauft also die Aktualitätsuhr auf Dokumentebene, und sie kauft sie gut. Die Aufbewahrungsuhr, die Review-Uhr und die Verknüpfung dazu, wofür der Nachweis ein Nachweis ist, bleiben genau dort, wo sie waren, mit dem Namen einer Person an jeder von ihnen.
Was auch immer Sie bereits betreiben (ein Spreadsheet, eine Wiki-Seite, einen Ordner mit datierten Unterordnern): Die Änderung, die sich selbst bezahlt macht, sind zwei Datumsspalten statt einer. Ein Ablaufdatum, das zum Dokument gehört und mit ihm von seinem Aussteller kam, und ein nächstes Review-Datum, das zur Aussage gehört und das Sie selbst setzen. Schreiben Sie eine Rollenbezeichnung an die zweite Spalte, denn die erste kommt mit einem Eigner an, die zweite nicht. Dann liefern „was läuft als Nächstes ab?“ und „was muss als Nächstes angesehen werden?“ nicht mehr dieselbe Liste, und das ist das erste Anzeichen dafür, dass die zwei Pflichten getrennt nachgehalten werden.
Das in diesem Beitrag beschriebene Nachweismodell ist unter docs.devguard.ch/evidence dokumentiert.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.