Der Auditor fragt nach dem Protokoll des Management-Reviews vom März – in dem Stand, in dem es Monate zuvor freigegeben wurde. NIS2-Artikel 20(1) legt die Billigung beim Leitungsorgan ab, und die Durchführungsverordnung (EU) 2024/2690 sagt immer wieder «dokumentiert» und «in geplanten Zeitabständen»: eine genaue Lektüre dessen, was diese Verben voraussetzen, und der drei Eigenschaften, die jedes System für Records erfüllen muss.
Der Auditor fragt nach dem Protokoll des Management-Reviews vom März – in dem Stand, in dem es Monate zuvor freigegeben wurde. NIS2-Artikel 20(1) legt die Billigung beim Leitungsorgan ab, und die Durchführungsverordnung (EU) 2024/2690 sagt immer wieder «dokumentiert» und «in geplanten Zeitabständen»: eine genaue Lektüre dessen, was diese Verben voraussetzen, und der drei Eigenschaften, die jedes System für Records erfüllen muss.
Die Dokumentenanforderung eines Auditors ist selten exotisch: das Protokoll des Management-Reviews vom März, die Ergebnisse der letzten beiden Access-Reviews, der jüngste Penetrationstest-Bericht. Unbequem ist, was die Anfrage eigentlich prüft. Der Auditor will nicht einfach das Dokument — er will das Dokument in dem Stand, in dem es Monate zuvor freigegeben wurde. Wenn Ihre ehrliche Antwort ein Netzlaufwerk ist, auf dem management-review_final_v2.docx zuletzt im Mai geändert wurde, können Sie zeigen, was die Datei heute sagt. Was sie im März sagte, als sie genehmigt wurde? Das ist Erinnerungssache. Lesen wir also die Texte, aus denen solche Anforderungen entstehen, denn ihre Verben setzen mehr voraus als einen Ordner.
Der Anfang liegt beim Governance-Artikel. Artikel 20(1) der NIS2-Richtlinie lautet in der amtlichen deutschen Fassung:
«Die Mitgliedstaaten stellen sicher, dass die Leitungsorgane wesentlicher und wichtiger Einrichtungen die von diesen Einrichtungen zur Einhaltung von Artikel 21 ergriffenen Risikomanagementmaßnahmen im Bereich der Cybersicherheit billigen, ihre Umsetzung überwachen und für Verstöße gegen diesen Artikel durch die betreffenden Einrichtungen verantwortlich gemacht werden können.»
Billigung, Überwachung und Verantwortlichkeit des Leitungsorgans stehen in einem einzigen Satz. NIS2 ist eine Richtlinie; die Pflichten erreichen Unternehmen also über die nationale Umsetzung und nicht direkt. Aber der Satz, den die Mitgliedstaaten umsetzen, ist genau dieser. Eine Billigung, für die jemand verantwortlich gemacht werden kann, ist ein datierter Akt. Irgendwo muss ein Artefakt zeigen, dass er stattgefunden hat.
Wie die Massnahmen aussehen, hat die Kommission anschliessend in der Durchführungsverordnung (EU) 2024/2690 vom 17. Oktober 2024 ausbuchstabiert. Ihr Anwendungsbereich in Artikel 1 umfasst digitale Infrastruktur und digitale Anbieter (DNS-Diensteanbieter, TLD-Namenregister, Cloud, Rechenzentren, CDNs, Managed Service Provider und Managed Security Service Provider, Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdienste); unmittelbar bindet sie also nur diese Einrichtungen. Für alle anderen unter NIS2 ist sie die Konkretisierung der Massnahmen aus Artikel 21(2) durch die Kommission selbst — und genau als das zitierbar. Ich lese ihren Anhang als eine einzige Dokumentationspflicht mit Datumsangaben. Schauen wir zu, wie sich die Verben häufen (die deutsche Fassung nennt die Sicherheitsrichtlinie «Konzept für die Sicherheit von Netz- und Informationssystemen»; hier kurz: die Richtlinie):
«In geplanten Zeitabständen» zieht sich durch den gesamten Anhang: Rollen und Verantwortlichkeiten (1.2.6), Ergebnisse der Risikobewertung (2.1.4), unabhängige Überprüfungen (2.3.4), Schwachstellenscans mit aufgezeichneten Nachweisen der Ergebnisse (6.10.2(b)). Selbst das Ablehnen einer Anforderung erzeugt Papier: Hält eine Einrichtung eine der «soweit angemessen»-Anforderungen für auf sie nicht anwendbar, muss sie nach Artikel 2(2) «ihre diesbezügliche Begründung in verständlicher Weise dokumentieren». Jede dieser Stellen paart einen Kalender mit einem Artefakt, und mehrere paaren das Artefakt mit einer Unterschrift des Leitungsorgans.
Bevor wir das März-Protokoll sinnvoll ablegen können, brauchen wir Namen für die Stapel. Ein ISMS erzeugt drei Arten von Papier, und sie verhalten sich unterschiedlich:
Wie Prüfer das lesen, zeigt die Technical Implementation Guidance der ENISA zu 2024/2690 (Juni 2025). Zu den Nachweis-Beispielen für den Richtlinien-Review-Punkt 1.1.2 zählt sie «Records of the management review» und «[r]eview comments or change logs» zur Richtlinie; für Post-Incident-Reviews nennt sie «Minutes of the post-incident review team» (Zitate im englischen Original; die Guidance liegt nur auf Englisch vor). Die Guidance ist unverbindlich, aber das Muster ist konsistent: Wo eine Anforderung «dokumentiert» sagt, erwartet ein Prüfer als Artefakt ein datiertes Dokument.
Der übliche Fehler ist, Records in einem der beiden anderen Stapel abzulegen. Schieben Sie das März-Protokoll durch den Richtlinien-Workflow, bekommen Sie eine Freigabezeremonie um ein Dokument herum, das selbst die Spur einer Freigabe ist: schwerfällig und semantisch zirkulär. Hängen Sie es als Nachweis an ein Control, steht es schief da, denn Protokolle belegen selten ein einzelnes Control; sie belegen, dass eine Sitzung stattfand und Entscheidungen fielen. Also landen die meisten Records am dritten Ort, dem Netzlaufwerk – und dem fehlt jede Eigenschaft, die der nächste Abschnitt herleitet.
Lesen wir die Anhang-Passagen noch einmal, diesmal als die Person, die die Prüfungsanfrage beantworten muss. Eine kleine Spezifikation fällt heraus.
Eine definierte Art, mit Rhythmus und Verantwortlichem. «In geplanten Zeitabständen» und «mindestens jährlich» hängen an Arten von Dokumenten, nicht an einzelnen Dateien. Das Management-Review kehrt wieder, das Access-Review kehrt wieder, der Scan-Bericht kehrt wieder. Die Frage «Was müsste jetzt gerade existieren, und wer schuldet es?» braucht also eine Antwort, bevor die Anfrage eintrifft. Das heisst: Jeder Record gehört zu einer Kategorie, und die Kategorie, nicht das Dokument, kennt das Intervall und die verantwortliche Rolle. Existieren die Kategorien, ist ein fehlendes März-Review im April sichtbar. Existieren sie nicht, wird es im Audit entdeckt.
Ein Status, den man ablesen kann. Ein Dokument ist Entwurf, in Arbeit oder freigegeben. Dateinamenskonventionen kodieren das schlecht; ist final_v2 die zweite Version des finalen Dokuments oder der zweite Anlauf zur Finalität? Status funktioniert besser als Feld mit definierten Werten, damit «Zeig mir alles, was noch nicht finalisiert ist» eine Abfrage ist und keine archäologische Übung.
Eine unveränderliche Version, geschnitten bei der Freigabe. Lassen Sie mich zuerst ehrlich zur Quellenlage sein: 2024/2690 enthält keine Klausel, die verlangt, vergangene Zustände eines Dokuments beweisen zu können. Verlangt wird, dass Ergebnisse dokumentiert werden, dass Unterlagen für die aufgeführten Zeiträume aufbewahrt werden (1.1.1(h)) und dass die Richtlinie das Datum ihrer förmlichen Genehmigung trägt (1.1.1(k)). Die Unveränderlichkeits-Anforderung folgt aus der Situation des Auditors, nicht aus dem Verordnungstext. Das Review fand im März statt; das Audit ist im November; dazwischen lag die Datei beschreibbar herum. Wenn die Freigabe keine Version einfriert, übergeben Sie dem Auditor den aktuellen Stand plus Ihre Versicherung, dass sich seit der Genehmigung nichts Wesentliches geändert hat. Ein Dokument, das – wie 1.1.1(k) verlangt – sein Genehmigungsdatum trägt, ist erheblich überzeugender, wenn der genehmigte Stand noch vorzeigbar ist. Ein Dokument als final zu markieren schneidet einen Snapshot; spätere Änderungen erzeugen Version 2 und lassen Version 1 unangetastet.
Nichts davon braucht ein bestimmtes Produkt. Ein Git-Tag auf einem Repository mit Markdown-Protokollen erfüllt alle drei Eigenschaften. Ein exportiertes PDF in einem Write-once-Bucket plus eine Tabelle mit Kategorien und Fälligkeiten ebenso, solange die Disziplin hält. Jedes System, das einen Snapshot einfrieren und einen Zeitplan führen kann, kommt infrage.
An dieser Stelle schulde ich Ihnen eine Offenlegung: Genau diese Entscheidungen mussten wir in devguard treffen. Also zeige ich Ihnen, was wir entschieden haben — und was wir bewusst weggelassen haben. Wir liefern das als Modul namens Records aus: verfasste, datierte Compliance-Dokumente, gruppiert in Kategorien, die das Team selbst definiert – Sitzungsprotokolle, Zugriffsanträge, Whistleblower-Meldungen, Pentest-Ergebnisse –, mit Versionen, die nur hinzukommen und nie umgeschrieben werden.
Die Art lebt in der Kategorie. Eine Kategorie trägt einen Verantwortlichen (eine Business-Rolle, keinen einzelnen Nutzer, damit die Zuständigkeit Personalwechsel übersteht), eine Standardvorlage, die einmalig in neue Einträge kopiert wird, und einen optionalen Rhythmus: monatlich, quartalsweise, halbjährlich oder jährlich. Einen kontinuierlichen Modus haben wir bewusst weggelassen, denn ein diskretes, datiertes Dokument hat keinen kontinuierlichen Modus. Das nächste Fälligkeitsdatum wird aus dem letzten finalisierten Eintrag plus dem Rhythmus berechnet; nichts legt automatisch Entwürfe an.
Der Status ist an jedem Eintrag ablesbar und kennt drei Werte – Entwurf, in Arbeit, final –, und jeder Eintrag trägt ein kurzes Kürzel wie RE-012.
Die Version ist ein Snapshot. Einen Eintrag als final zu markieren hält fest, wer wann freigegeben hat, und schneidet eine unveränderliche Version: Die erste Finalisierung erzeugt Version 1, die nächste Version 2. Wird der Eintrag danach bearbeitet, öffnet er sich wieder; die geschnittenen Versionen bleiben unangetastet.
Zwei Dinge haben wir bewusst nicht gebaut, und beide haben einen Preis. Erstens gibt es keine Freigabekette. Wer Schreibrechte auf Records hat, setzt den Status von Hand; ein Freigabe-Gate wie bei den Richtlinien gibt es nicht. Das Modul hindert niemanden daran, ein Protokoll auf final zu setzen, bevor die Sitzung stattgefunden hat. Wenn Ihr Prozess ein Freigabe-Gate braucht, dann ist dieses Gate Ihre Sitzungsdisziplin und Ihre Schreibrechte; das Werkzeug hält das Ergebnis fest und schiedsrichtert nicht.
Zweitens haben Records keine Wirkung auf die Control-Coverage. Eine Kategorie mit Controls oder Risiken zu verknüpfen hilft der Auffindbarkeit und tut nicht mehr als das. Ein Record belegt, was wann geschrieben und freigegeben wurde; ihn abzulegen hakt kein Control ab und ändert keinen Coverage-Status. Ich halte diese Zurückhaltung für das eigentliche Design: In dem Moment, in dem das Ablegen von Protokollen einen Coverage-Status umlegen würde, würden Teams Protokolle ablegen, um Coverage-Status umzulegen.
Mit den drei Eigenschaften an Ort und Stelle hört die Prüfungsanfrage auf, eine Suche zu sein, und wird ein Nachschlagen: eine Kategorie, die das März-Protokoll erwartet hat, ein Status, der sagt, dass es freigegeben wurde, und eine eingefrorene Version, die zeigt, was unterschrieben wurde, von wem, an welchem Datum. Das ist der kleine, konkrete Fall des Arguments aus audit-ready is a state you keep: Ein Audit zieht eine Stichprobe aus dem Normalbetrieb, und die Stichprobe ist nur dann langweilig, wenn die Artefakte die ganze Zeit über erzeugt – und eingefroren – wurden.
Das oben beschriebene Records-Modul ist Teil von devguard: devguard.ch/platform.
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.