ENISAs NIS2-Leitfaden nennt das unterschriebene Bestätigungsformular als Nachweisbeispiel; eine genaue Lektüre von Art. 21(2)(g) NIS2, Nummer 8 der Durchführungsverordnung 2024/2690 und ENISAs Nachweiszeilen zeigt, was dieses Formular fixieren muss.
ENISAs NIS2-Leitfaden nennt das unterschriebene Bestätigungsformular als Nachweisbeispiel; eine genaue Lektüre von Art. 21(2)(g) NIS2, Nummer 8 der Durchführungsverordnung 2024/2690 und ENISAs Nachweiszeilen zeigt, was dieses Formular fixieren muss.
Die Technical Implementation Guidance zu NIS2, die ENISA im Juni 2025 veröffentlicht hat, führt dies unter ihren Nachweisbeispielen für die Sicherheitsrichtlinie auf (ENISA publiziert ausschliesslich auf Englisch; ihre Zitate stehen in diesem Beitrag im englischen Original, jeweils mit einer sinngemässen deutschen Wiedergabe):
„Where applicable, acknowledgement forms or employment contracts, signed by personnel, which confirm they have read and understood the security policies.“
Sinngemäss: Soweit anwendbar, von den Mitarbeitenden unterschriebene Bestätigungsformulare oder Arbeitsverträge, die bestätigen, dass sie die Sicherheitsrichtlinien gelesen und verstanden haben.
Das steht auf der gedruckten Seite 14, unter Nummer 1.1 des Anhangs: eine Unterschrift unter einer Richtlinie, die schlichteste Form der Aufzeichnung. Die Frage, die ein Audit daran stellt, ist kurz. Wer hat welche Version gelesen, und wann. Ein unterschriebenes Formular beantwortet das Wer und das Wann; offen bleibt in der Regel die Version. Eine Unterschrift unter einem Richtlinientitel aus einem früheren Jahr sagt nichts über den heute geltenden Text, und nichts über den Zyklus, den sie erfüllen sollte.
Artikel 21(2) der NIS-2-Richtlinie beginnt mit einem Einleitungssatz und einer Liste von Buchstabe a bis j:
„Die in Absatz 1 genannten Maßnahmen müssen auf einem gefahrenübergreifenden Ansatz beruhen, der darauf abzielt, die Netz- und Informationssysteme und die physische Umwelt dieser Systeme vor Sicherheitsvorfällen zu schützen, und zumindest Folgendes umfassen: […] g) grundlegende Verfahren im Bereich der Cyberhygiene und Schulungen im Bereich der Cybersicherheit;“
Diese Klausel bindet wesentliche und wichtige Einrichtungen über ihre Mitgliedstaaten. Artikel 20(2), ebenfalls an die Mitgliedstaaten gerichtet, sieht vor, dass diese wesentliche und wichtige Einrichtungen auffordern, „allen Mitarbeitern regelmäßig entsprechende Schulungen anzubieten“: für die Mitarbeitenden eine Aufforderung.
Die Durchführungsverordnung (EU) 2024/2690 konkretisiert sie. Artikel 1 bindet elf Klassen von Einrichtungen, die „betreffenden Einrichtungen“, unmittelbar; alle anderen unter NIS2 können sie als die Lesart der Kommission derselben Massnahmen lesen. Nummer 8 des Anhangs, überschrieben mit „Grundlegende Verfahren im Bereich der Cyberhygiene und Schulungen im Bereich der Cybersicherheit“ und Buchstabe g zugeordnet, zerfällt in zwei Teile.
Nummer 8.1 ist Sensibilisierung. Sie erreicht die „Mitarbeitenden, einschließlich der Mitglieder von Leitungsorganen, sowie direkte Anbieter und Diensteanbieter“ (8.1.1), und die Einrichtungen bieten ein Sensibilisierungsprogramm an, das:
„a) zeitlich so geplant ist, dass die Maßnahmen wiederholt werden und neue Mitarbeitende erreichen;“ (8.1.2)
„Das Sensibilisierungsprogramm wird – soweit angemessen – in geplanten Zeitabständen im Hinblick auf seine Wirksamkeit getestet. Das Sensibilisierungsprogramm wird in geplanten Zeitabständen aktualisiert und angeboten […]“ (8.1.3)
Nummer 8.2 ist Schulung, eine eigene Unternummer: Mitarbeitende, die „regelmäßig geschult werden“ (8.2.1), ein Programm, das „regelmäßig aktualisiert und durchgeführt“ wird (8.2.5), ein unverklausuliertes „ihre Wirksamkeit ist zu bewerten“ (8.2.3). Kein Satz in Nummer 8 nennt einen konkreten Zeitraum.
Die Bestätigungspflicht selbst steht unter einem anderen Buchstaben. Nummer 1.1.1, die Artikel 21(2)(a) konkretisiert, sagt, die Sicherheitsrichtlinie (in der amtlichen deutschen Fassung das „Konzept für die Sicherheit von Netz- und Informationssystemen“) müsse „f) den einschlägigen Mitarbeitenden und interessierten externen Beteiligten mitgeteilt und von ihnen anerkannt werden“. Das ist die einzige Bestätigungsklausel der Verordnung (ihr Wort dafür ist „anerkannt“); sie gehört zur Richtlinie, wo ENISA das unterschriebene Formular einsortiert.
Der Leitfaden führt je Nummer des Anhangs „examples of evidence“ (Nachweisbeispiele) auf und sagt auf Seite 9, was sie sind: „The guidance, examples of evidence and tips are non-exhaustive. Their partial or complete implementation does not assume compliance or conformity with the requirements of the regulation.“ (Sinngemäss: Der Leitfaden, die Nachweisbeispiele und die Tipps sind nicht abschliessend. Ihre teilweise oder vollständige Umsetzung setzt keine Einhaltung oder Konformität mit den Anforderungen der Verordnung voraus.) Die Zeilen, auf die es ankommt, aus dem PDF v1.0, nach gedruckter Seite:
| Nummer im Anhang | ENISAs Nachweisbeispiel (gedruckte Seite) |
|---|---|
| 1.1 (Sicherheitsrichtlinie) | „Where applicable, acknowledgement forms or employment contracts, signed by personnel, which confirm they have read and understood the security policies.“ (S. 14, drittes von fünf; sinngemäss: siehe oben) |
| 8.1 (Sensibilisierung) | „Logs, sign-in sheet, certificates of completion or acknowledgements given to employees upon completing the programme, showing which employees have taken part in the awareness-raising programme.“ (S. 112, drittes von drei unter 8.1.2; das erste ist die Programmübersicht) Sinngemäss: Protokolle, Anwesenheitslisten, Abschlusszertifikate oder Bestätigungen, die Mitarbeitenden nach Abschluss des Programms ausgehändigt werden und zeigen, welche Mitarbeitenden am Sensibilisierungsprogramm teilgenommen haben. |
| 8.2 (Sicherheitsschulungen) | „A comprehensive outline of the training programme, detailing the objectives for different roles and how to reach them, content and frequency of the training.“ (S. 113, einziger Punkt unter 8.2.1) Sinngemäss: Eine umfassende Übersicht des Schulungsprogramms, die die Ziele für die verschiedenen Rollen und den Weg dorthin, den Inhalt und die Häufigkeit der Schulung darlegt. |
Die Zählung über das PDF hinweg zeigt in dieselbe Richtung. „Read and understood“ kommt im 170-seitigen PDF viermal vor: zweimal auf Seite 14 unter 1.1, einmal unter 12.2 (S. 150), einmal unter 12.3 (S. 151), nie unter Nummer 8. „Acknowledg-“ kommt ausserhalb der Titelei 22-mal vor, viermal unter Nummer 8 (8.1.2, 8.1.3, 8.2.4, 8.2.5), jeweils „given to employees upon completing the programme“ (sinngemäss: den Mitarbeitenden nach Abschluss des Programms ausgehändigt) oder der Schulung, und als Beleg dafür, „which employees have taken part“ (welche Mitarbeitenden teilgenommen haben) oder anwesend waren. Unter Nummer 8 ist ENISAs Bestätigung also die Abschlussaufzeichnung eines Programms; die Bestätigung, dass eine Richtlinie gelesen wurde, steht unter 1.1, 10.1 (S. 122), 12.2 und 12.3. Die Unterscheidung, die bleibt, ist, was die Aufzeichnung bestätigt: ein besuchtes Programm oder eine gelesene Richtlinie.
Drei Artefakte beantworten die Frage üblicherweise.
Ein E-Mail-Verlauf. Jemand hängt die Richtlinie an und bittet um eine bestätigende Antwort. Der Server stempelt die Antwort, das Datum ist also belastbar. Der Anhang ist eine Kopie der Datei zum Sendezeitpunkt; ob sie mit der am Audittag geltenden Version übereinstimmt, kann der Verlauf nicht sagen. Eine Antwort aus einem gemeinsamen Postfach ist keine Person. Nichts in dem Austausch sagt, für welchen Zyklus die Bestätigung gedacht war.
Ein unterschriebener Ausdruck. Die Unterschrift gehört zu einer Person, und das Datum ist handschriftlich. Der Ausdruck trägt einen Titel und die Versionsangabe, die jemand in die Fusszeile getippt hat, und die Angabe ist so verlässlich wie das Tippen. Eine Unterschrift mit Datum aus einem früheren Jahr kann nicht für das Intervall dieses Jahres sprechen.
Ein Häkchen in einem HR-System. Es hält fest, wer und wann, unter einem Login. Es zeigt auf das, was das Feld gerade enthält, einen Titel, einen Dateinamen, eine Version, falls jemand eine eingetragen hat, und bleibt gesetzt, bis es jemand entfernt; einen eigenen Zyklus trägt es also nicht.
Keines der drei prüft irgendetwas vor der Bestätigung; Antwort, Unterschrift und Häkchen stehen jemandem, der das Dokument nie geöffnet hat, genauso offen. Woran es scheitert, sind Version und Zyklus, selten das Datum.
Eine Aufzeichnung, die die Auditfrage für eine Person unmittelbar beantwortet, fixiert fünf Dinge.
| Fixpunkt | Worauf er verweist | Was ohne ihn bricht |
|---|---|---|
| Veröffentlichte Version | Die veröffentlichte Version, mit Nummer, so wie angezeigt | „Die Richtlinie gelesen“ zeigt auf einen Titel, der inzwischen einen anderen Text meint |
| Person | Die Person, die unter ihrem eigenen Login bestätigt und nur das sieht, was ihr gehört | Ein gemeinsames Postfach oder ein Admin, der stellvertretend ein Häkchen setzt, hält einen anderen Sachverhalt fest |
| Zyklus | Die erfüllte Pflicht: das geplante Intervall oder die Neuveröffentlichung, die es neu eröffnet hat | Die Bestätigung vom letzten Jahr sieht aus wie die von diesem Jahr |
| Datum | Der bei der Bestätigung geschriebene Zeitstempel | Die Einordnung gegenüber Veröffentlichungsdaten und Fristen wird zum Raten |
| Lesesperre | Eine Vorbedingung: Bestätigen ist erst möglich, wenn das Ende des Dokuments erreicht wurde | „Ich habe es gelesen“ steht auch jemandem offen, der nichts geöffnet hat |
Die Version ist die veröffentlichte und muss unveränderlich sein, der Punkt, den der frühere Beitrag zu Records für freigegebene Dokumente gemacht hat. Die Person zählt nur, wenn die Person die Aufzeichnung selbst schreibt; das Zugriffsmodell eines Compliance-Tools ist Teil der Glaubwürdigkeit der Aufzeichnung. Der Zyklus folgt aus „zeitlich so geplant ist, dass die Maßnahmen wiederholt werden“ und „in geplanten Zeitabständen“: Ein Zeitraum ist nicht vorgeschrieben, der Zyklus ist also, was die Organisation festgelegt hat, und ob eine Neuveröffentlichung ihn neu eröffnet, entscheidet die Organisation. Die Lesesperre ist eine Designentscheidung; ENISA hat „a signed document or digital acknowledgement“ (ein unterschriebenes Dokument oder eine digitale Bestätigung) im Blick und, je nach Rolle, einen bestätigten „extract or a summary“ (Auszug oder eine Zusammenfassung) (S. 13). Ich würde sie den schwächsten Fixpunkt nennen: „Ich habe es gelesen“ heisst dann mindestens „Ich bin bis zum Ende gekommen“, und nichts über Aufmerksamkeit.
Auch mit allen fünf halten Sie die Bestätigung einer einzelnen Person in der Hand, fixiert: Diese Person hat an diesem Datum bestätigt, diese Version gelesen zu haben, der Sachverhalt, den ENISA unter der Richtlinie einsortiert. Sie kann nicht zeigen, dass das Sensibilisierungsprogramm gelaufen ist oder gewirkt hat, oder dass die Richtlinie wirksam ist; dafür nennt der Leitfaden unter 8.1 und 8.2 Programmübersichten, Materialien, Teilnahmeaufzeichnungen, Quiz-Ergebnisse und Feedback-Formulare.
Die Person. Das Portal läuft auf der Rolle Mitarbeiter, im Changelog von devguard vom 26. August 2026 als „eine neue Organisationsrolle nur für das Portal“ beschrieben, ohne Admin-Berechtigungen: Alles ausserhalb des Portals schickt Mitarbeitende direkt dorthin zurück. Innen sieht eine Person immer nur, was ihr gehört; eine ihr nicht zugewiesene Richtlinie antwortet mit „Diese Richtlinie ist Ihnen nicht zugewiesen“.
Die Version und die Lesesperre. Das Portal liefert die zuletzt veröffentlichte Version aus, überschrieben mit Versionsnummer und Veröffentlichungsdatum, und zeigt das Dokument nach „Richtliniendokument ansehen“ Seite für Seite an. Das Kontrollkästchen „Ich habe diese Richtlinie gelesen und verstanden“ bleibt deaktiviert, bis das Ende der letzten Seite in den sichtbaren Bereich gescrollt wurde; bis dahin sagt die Seite „Lesen Sie das gesamte Dokument oben, bevor Sie es bestätigen“.
Der Zyklus und das Datum. Das Bestätigen hält je Person und Zyklus eine Bestätigung fest, fixiert auf genau die Version auf dem Bildschirm. Die Seite zeigt danach, welche Version Sie wann bestätigt haben und ob inzwischen eine neuere gilt. Wer veröffentlicht, kann stattdessen verlangen, dass alle bis zu einem selbst gewählten Datum erneut bestätigen; bis dahin gilt die Person als ausstehend, danach als überfällig, und die frühere Markierung bleibt als Historie erhalten. Jede Bestätigung landet mit Wer und Wann im Audit Log der Organisation.
[Screenshot: die Richtlinienseite des Portals mit der Kopfzeile aus Version und Veröffentlichungsdatum, „Richtliniendokument ansehen“ und dem noch deaktivierten Kontrollkästchen „Ich habe diese Richtlinie gelesen und verstanden“ samt dem Hinweis „Lesen Sie das gesamte Dokument oben, bevor Sie es bestätigen“]
Die Kosten, die ich lieber selbst nenne, als sie entdecken zu lassen:
Die Aufzeichnung beantwortet, wer welche veröffentlichte Version für welchen Zyklus an welchem Datum gelesen und dabei das Ende erreicht hat, und nur das. Was der Leitfaden zum Programm fragt, seine Übersicht, seine Materialien, wer teilgenommen hat, ob es gewirkt hat, lebt in anderen Dokumenten; der Beitrag zu Records behandelt deren Versionierung. Trainings stellen dieselben Fragen von der anderen Seite, die Zuweisung, ihre Wiederkehr und die Aufzeichnung, die sie hinterlässt, und bekommen einen eigenen Beitrag.
devguards Richtlinien-Modul, an dem die oben beschriebene Bestätigung hängt, wird auf der Seite zu Richtlinien vorgestellt.
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.