ENISA's NIS2 guidance lists the signed acknowledgement form as an example of evidence; a close read of NIS2 Art. 21(2)(g), Implementing Regulation 2024/2690 point 8 and ENISA's evidence rows shows what that form has to pin.
ENISA's NIS2 guidance lists the signed acknowledgement form as an example of evidence; a close read of NIS2 Art. 21(2)(g), Implementing Regulation 2024/2690 point 8 and ENISA's evidence rows shows what that form has to pin.
The NIS2 technical implementation guidance ENISA published in June 2025 lists this among its examples of evidence for the security policy:
"Where applicable, acknowledgement forms or employment contracts, signed by personnel, which confirm they have read and understood the security policies."
That is printed page 14, under Annex point 1.1: a signature under a policy, the plainest form of the record. The question an audit puts to it is short. Who read which version, and when. A signed form answers who and when; what it tends to leave open is the version. A signature under a policy title from an earlier year says nothing about the text current today, or about the cycle it was meant to satisfy.
NIS2 Article 21(2) opens with a chapeau and a list from (a) to (j):
"The measures referred to in paragraph 1 shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following: […] (g) basic cyber hygiene practices and cybersecurity training;"
That clause binds essential and important entities through their Member States. Article 20(2), addressed to Member States too, has them "encourage essential and important entities to offer similar training to their employees on a regular basis": for employees, an encouragement.
Implementing Regulation (EU) 2024/2690 concretises it. Article 1 binds eleven classes of entity, "the relevant entities", directly; everyone else under NIS2 can read it as the Commission's reading of the same measures. Annex point 8, headed "Basic cyber hygiene practices and security training" and keyed to point (g), splits in two.
Point 8.1 is awareness. It reaches "employees, including members of management bodies, as well as direct suppliers and service providers" (8.1.1), and the programme shall:
"(a) be scheduled over time, so that the activities are repeated and cover new employees;" (8.1.2)
"The awareness raising programme shall, where appropriate, be tested in terms of effectiveness. The awareness raising programme shall be updated and offered at planned intervals […]" (8.1.3)
Point 8.2 is training, a separate sub-point: "regular training" (8.2.1), a programme "updated and run periodically" (8.2.5), an unhedged "its effectiveness shall be assessed" (8.2.3). No sentence in point 8 names a period.
The acknowledgement duty itself sits under a different letter. Point 1.1.1, concretising Article 21(2)(a), says the security policy shall "(f) be communicated to and acknowledged by relevant employees and relevant interested external parties". That is the regulation's one acknowledgement clause; it belongs to the policy, where ENISA files the signed form.
The guidance lists "examples of evidence" per Annex point and says on page 9 what they are: "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." The rows that matter, from the v1.0 PDF, by printed page:
| Annex point | ENISA's example of evidence (printed page) |
|---|---|
| 1.1 (security policy) | "Where applicable, acknowledgement forms or employment contracts, signed by personnel, which confirm they have read and understood the security policies." (p. 14, third of five) |
| 8.1 (awareness raising) | "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." (p. 112, third of three under 8.1.2; the first is the programme outline) |
| 8.2 (security training) | "A comprehensive outline of the training programme, detailing the objectives for different roles and how to reach them, content and frequency of the training." (p. 113, sole bullet under 8.2.1) |
The counts across the PDF point the same way. "Read and understood" occurs four times in the 170-page PDF: twice on page 14 under 1.1, once under 12.2 (p. 150), once under 12.3 (p. 151), never under point 8. "Acknowledg-" occurs 22 times outside the front matter, four under point 8 (8.1.2, 8.1.3, 8.2.4, 8.2.5), each "given to employees upon completing the programme" or the training and showing "which employees have taken part" or attended. Under point 8, then, ENISA's acknowledgement is the completion record of a programme; the confirmation that a policy was read sits under 1.1, 10.1 (p. 122), 12.2 and 12.3. The distinction that survives is what the record confirms: a programme attended, or a policy read.
Three artefacts usually answer the question.
An email thread. Someone attaches the policy and asks for a confirming reply. The server stamps the reply, so the date is solid. The attachment is a copy of the file at send time; whether it matches the version current on audit day, the thread cannot say. A reply from a shared mailbox is not a person. Nothing in the exchange says which cycle the confirmation was for.
A signed printout. The signature belongs to a person and the date is handwritten. The printout carries a title and whatever version string was typed into its footer, and the string is as reliable as the typing. A signature dated in an earlier year cannot speak for this year's interval.
A tick in an HR system. It records who and when, under a login. It points at whatever the field holds, a title, a file name, a version if someone typed one, and stays set until cleared, so it carries no cycle of its own.
None of the three checks anything before the confirmation; reply, signature and tick are equally available to someone who never opened the document. The failure is version and cycle, rarely the date.
A record that answers the audit question outright, for one person, pins five things.
| Pin | What it references | What breaks without it |
|---|---|---|
| Published version | The published version, by number, as shown | "Read the policy" points at a title that now means a different text |
| Person | The person, confirming under their own login, shown only what is theirs | A shared mailbox, or an admin ticking on someone's behalf, records a different fact |
| Cycle | The obligation satisfied: the planned interval, or the republication that reopened it | Last year's confirmation looks the same as this year's |
| Date | The timestamp written at confirmation | Ordering against publication dates and deadlines turns into guesswork |
| Read gate | A precondition: confirming is possible only once the document's end has been reached | "I have read it" is available to someone who opened nothing |
The version is the published one and has to be immutable, the point the earlier post on records made about signed-off documents. The person only counts if the person writes the record; a compliance tool's own access model is part of the record's credibility. The cycle follows from "scheduled over time, so that the activities are repeated" and "planned intervals": no period is prescribed, so the cycle is whatever the organisation set, and a republication that reopens it is the organisation's call. The read gate is a design choice; ENISA contemplates "a signed document or digital acknowledgement" and, by role, an acknowledged "extract or a summary" (p. 13). I'd call it the weakest pin: "I have read it" comes to mean at least "I reached the end", and nothing about attention.
Even with all five, you hold one person's confirmation, pinned: this person confirmed reading this version on this date, the fact ENISA files under the policy. It cannot show that the awareness programme ran or worked, or that the policy is effective; for those the guidance lists outlines, materials, participation records, quiz results and feedback forms under 8.1 and 8.2.
The person. The portal runs on the Employee role, described in devguard's changelog of 26 August 2026 as "a new portal-only organization role", with no admin permissions: anything outside the portal sends an employee straight back to it. Inside, a person only ever sees what is theirs; a policy not assigned to them answers "This policy is not assigned to you".
The version and the read gate. The portal serves the latest published version, headed with its version number and publication date, and shows the document page by page after "View policy document". The checkbox "I have read and understood this policy" stays disabled until the end of the last page has scrolled into view; until then the page says "Read the whole document above before acknowledging it".
The cycle and the date. Acknowledging records one confirmation per person for each cycle, pinned to the exact version on screen. The page then shows which version you acknowledged, when, and whether a newer one is now current. A publisher can instead require everyone to acknowledge again by a date they choose; until then the person is pending, after it overdue, and the earlier mark stays as history. Every acknowledgement lands in the organisation's audit log with who and when.
[screenshot: the portal's policy page, showing the version-and-publication-date header, "View policy document", and the "I have read and understood this policy" checkbox, still disabled, with the hint "Read the whole document above before acknowledging it"]
The costs, which I'd rather state than have discovered:
The record answers who read which published version, for which cycle, on which date, having reached the end, and only that. What the guidance asks about the programme, its outline, its materials, who took part, whether it worked, lives in other documents; the records post covers their versioning. Trainings raise the same questions from the other side, the assignment, its recurrence and the record it leaves, and get their own post.
devguard's policies module, which the acknowledgement described above attaches to, is introduced on the policies page.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
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.