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 Maßnahmen, „um sicherzustellen und den Nachweis dafür erbringen zu können, dass die Verarbeitung gemäß dieser Verordnung erfolgt“, und schließt:
„Diese Maßnahmen 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 Maßnahmen 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 außergewö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, schließt 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 Korrekturmaßnahmen ab. Diese Zählung bezieht sich auf die Harmonized Structure, nicht auf die ISO/IEC 27001. „Available“ ist das maßgebliche 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 Maßnahmen „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 außerdem 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.
devguards Nachweisschema ist ein durchgearbeitetes Beispiel für diese Form. Die zwei Datumsangaben sitzen auf zwei verschiedenen Modellen:
// packages/app-db/prisma/schema.prisma (weitere Felder ausgelassen)model Evidence { reviewFrequency EvidenceReviewFrequency? lastReviewedAt DateTime? nextReviewAt DateTime?}model EvidenceFile { documentKind EvidenceDocumentKind? issuedAt DateTime? expiresAt DateTime?}
nextReviewAt wird berechnet und nicht eingetippt: computeNextReviewAt in apps/app/api/evidence/next-review.ts bildet MONTHLY, QUARTERLY, SEMI_ANNUAL und ANNUAL auf addMonths(from, 1 | 3 | 6 | 12) ab. CONTINUOUS bildet auf null ab: Ein Eintrag, der laufend verifiziert wird, hat kein nächstes Review-Datum, weil die Frage auf ihn nicht zutrifft.
Die Freigabe ist das Review. Eine Mutation stempelt approvedAt und approvedBy und setzt lastReviewedAt und nextReviewAt im selben Schreibvorgang neu, und der Kommentar darüber sagt, warum: „Approval is the single sign-off event (there is no separate ‚mark reviewed‘)“ (Codekommentar im englischen Original). Es gibt 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 abschließend beurteilt wurde.
devguard leitet den Abdeckungsstatus eines Controls beim Lesen ab, in einer festen Rangfolge:
// apps/app/api/coverage/derive-coverage-status.ts — Rumpf von// deriveControlCoverageStatus(); der Docstring gibt die Rangfolge an als// "not-relevant → tasks → evidence-links → UNKNOWN"if (signals.isNotRelevant) return 'NOT_RELEVANT';const tasks = signals.taskStatuses.filter(s => s !== 'CANCELLED');if (tasks.length > 0) { if (tasks.every(s => s === 'DONE')) return 'FULL'; if ( tasks.some(s => s === 'DONE' || s === 'IN_REVIEW' || s === 'IN_PROGRESS') ) return 'PARTIAL'; return 'NONE';}if (signals.hasEvidenceLinks) return 'PARTIAL';return 'UNKNOWN';
Lesen Sie das als Obergrenze. Einen Nachweis mit einem Control zu verknüpfen, das keine Tasks trägt, hebt es von UNKNOWN auf PARTIAL, und PARTIAL 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 FULL: Dieser Zweig verlangt Tasks, und jede einzelne davon auf DONE. Wo Tasks existieren, entscheiden sie den Status vollständig, und der Nachweiszweig wird nie erreicht.
In devguard gibt es keine automatisierte Nachweiserfassung. Die Design-Spezifikation des Nachweissystems stellt die Runtime mit genau diesen Worten außerhalb des Umfangs („Any automated evidence-collection runtime — check execution, result→coverage reconcilers, scheduler/worker runs, connector DSLs“) und beschreibt das, was stattdessen ausgeliefert wurde, als „a display-only association“, bei der „nothing runs“ (Spezifikationstext im englischen Original). Der Code bestätigt das. setAutomation in apps/app/api/evidence/index.ts schreibt eine einzige Spalte:
return ctx.db.evidence.update({ where: { id: input.id }, data: { automationActionId: input.automationActionId },});
Die Nachweisliste hat eine Spalte mit der Überschrift „Collection“; sie zeigt den Namen der verknüpften Aktion an oder „Manual“, wenn keine Verknüpfung besteht. Integrations-Konnektoren existieren an anderer Stelle in der Codebasis, in packages/app-workers/src/integrations/, und keiner von ihnen liest oder schreibt Nachweise. Nichts holt das Artefakt ab; jemand hängt es an, und jemand gibt es frei.
[screenshot: evidence detail, review cadence panel]
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.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.