How to prove to an auditor that employees have read a policy

The fourth and final part of the Documents in SharePoint series. In part three we set up a library for controlled documentation and ended with the one thing SharePoint can’t prove on its own. Today is about that.

In an information security audit, sooner or later comes a question that catches out even organisations with carefully kept documentation: “Who has read version 2.1 of the security policy? And who hasn’t yet?”

The policy is approved, it sits in the right place in the right version, and the audit log shows who opened it. But opening is not acknowledging. Someone who opened the document may not have read it to the end, and someone who read it may not have confirmed it anywhere. The answer is then usually: “We sent it out by email” — and the auditor notes a finding.

This part is about how to prove acknowledgement. We compare three approaches, from the simplest to the strongest, and say honestly when each one is enough.

What exactly is asked of you

ISO/IEC 27001

In clause 7.3, the standard wants people working for the organisation to be aware of the security policy, of their part in making the security management system work, and of the consequences of not following the rules. Clause 7.2 adds that documented information must be retained as evidence of competence. And Annex A, according to the commonly quoted wording of control 5.1, wants policies to be communicated to the people concerned and acknowledged by them; according to the same wording, control 6.3 then wants training and regular updates on policies according to role.

The text of the standard doesn’t say in what form to prove this. In audit practice, though, evidence of acknowledgement is expected — whether a signature, a confirmation email or a record in a system.

The Czech Cybersecurity Act (NIS2)

NIS2 is an EU directive that each member state transposes into its own law, so the exact requirements depend on the country; we use the Czech implementation as an example.

Since 1 November 2025, the new Act No. 264/2025 Coll., on Cybersecurity, which transposes the EU NIS2 directive, has been in force in the Czech Republic. The security measures are set out in two decrees: Decree No. 409/2025 Coll. for the higher-obligations regime and Decree No. 410/2025 Coll. for the lower-obligations regime. The act mainly covers medium-sized and large enterprises in the listed sectors (according to the Czech cybersecurity authority NÚKIB, roughly from 50 employees or from EUR 10 million in turnover or balance sheet total). Implementation of the measures must start no later than one year after the decision on registering the service is delivered.

What the decrees ask for in the area this article is about:

• Inform people about the policy. The decree for the higher regime wants the security policy and documentation to be managed so that the persons concerned are “informed of the rights, obligations and procedures they contain” (§ 6(5)(b)). Both decrees want the policy to be reviewed regularly; the decree for the lower regime also wants a policy of secure user behaviour to be set.
• Train and verify. The higher regime wants users to be instructed about their obligations and the security policy through induction and regular training, and security awareness to be verified regularly (§ 10(3)). The lower regime wants induction and regular cybersecurity training (§ 5(2)).
• Keep records. Both decrees want records of instruction and training with a list of the people who completed them (Decree No. 409/2025 Coll. § 10(5), Decree No. 410/2025 Coll. § 5(3)). Top management must complete the training demonstrably.

To be fair: the decrees do not ask for a signature under every policy, and they don’t set how long training records must be kept. They want people to be informed and trained, and you to be able to show it in a record with names. A record of acknowledgement of a specific policy version is a natural way to keep such a record — and with check questions it can also serve as one piece of evidence that awareness is being verified. Whether the act applies to you, and in which regime, is a separate question; NÚKIB runs a portal and a self-identification tool for that.

What good evidence must contain

Whichever approach you choose, the auditor will ask the same things. A good acknowledgement record answers all of them:

• Who — a specific person, not “a department”.
• What — a specific document in a specific version. Confirming version 1.0 says nothing about version 2.1.
• When — the date and time of confirmation.
• Who hasn’t yet — a list of those the document applies to who haven’t confirmed it. This is the question most organisations can’t answer.
• Immutability — a record that can’t be edited afterwards or “topped up” the day before the audit.
• Repetition — for security policies, acknowledgement is usually repeated, say once a year, and a new version of the document means a new round.

Approach 1: an attendance sheet or email

The simplest and still the most common. Training with recorded attendance, a signature on a paper sheet, or an email with the policy attached and a request to reply “I have read it”.

When it’s enough: a small organisation, few documents, few changes. A few dozen people, three or four policies, an update once a year.

Where it fails: for every new version, everything is repeated by hand. The “who hasn’t yet” overview is pieced together from emails and spreadsheets. A signature on a sheet doesn’t prove which version the person read. And when the person who kept the sheets leaves, the overview often leaves with them.

Approach 2: your own Power Automate solution

If you have Microsoft 365, you also have Power Automate and SharePoint lists. You can build your own register from them: when a new version is published, a flow sends people a task or an email with an “I acknowledge” button, writes the response to a list (who, when, document, version), and another flow sends a reminder to those who haven’t confirmed.

When it’s enough: you have someone who knows Power Automate, the number of documents is reasonable, and you don’t mind maintaining the solution yourselves.

What to keep in mind:

• Immutability of the record. Anyone with edit rights can write to a SharePoint list — and the flow writes under the account its connection runs under. For the record to hold up, the list needs carefully set permissions and, ideally, retention through a retention label.
• Targeting. Who does the document apply to? The whole organisation, a department, a group? When group membership changes, who adds the new people?
• Maintenance. Flows break when their author leaves or a licence changes. Who will fix them a year from now?
• Reporting. What percentage of people have confirmed the current version, by team? That’s already a job for Power BI or a custom view.

It’s a fair approach, and enough for many organisations. Just be aware that you’re not building one flow but a small application you will have to run.

Approach 3: a specialised app

For organisations with dozens of controlled documents and hundreds of people, or where acknowledgement is subject to regular checks, a ready-made app makes sense. It typically differs from a home-built Power Automate solution in the things you would otherwise have to build and look after yourselves:

• Release with approval — a document goes out to people only after it is approved, with deputies you can set up.
• Targeting groups and assigning documents to people who join a group — including documents that already apply.
• Checking understanding — for key documents, check questions before confirmation.
• Repeated acknowledgement at a set interval and a new round for a new version.
• An immutable register with a timestamp, and a compliance overview by team and document.
• Records retention for a set period and a register ready to print for the auditor.

When choosing, ask two things above all: where the data lives (in your Microsoft 365 or on the vendor’s server) and what exactly counts as evidence (how it is ensured that the record can’t be changed). For completeness: we have the Controlled documents app for this, which runs in your Microsoft 365 and stores records in your SharePoint — but ask any vendor the questions above.

What it is not

One more honest note, because you often ask about it: a read confirmation is not a qualified electronic signature. It is a verifiable record for internal control and audit. If you need a document to carry a signature with legal effect — typically contracts or some HR documents — that’s a different category of tools.

How to choose

Situation	Sensible choice
Up to 30 people, a few policies, changes once a year	Attendance sheet or email, carefully archived
Dozens to hundreds of people, you have capacity for Power Automate	Your own solution on top of a SharePoint list
Hundreds of people, dozens of documents, regular repetition, checks	A specialised app

Key takeaways

1. Opening is not acknowledgement. The evidence must say who, when, which version — and who hasn’t yet.
2. Choose the approach by scale, not by fashion. A sheet is enough for a small organisation; as the number of people, documents and versions grows, the cost of manual records rises faster than it seems.
3. The evidence must still hold up a year from now. Immutability of the record, the retention period and where the data lives matter more than how convenient it is to confirm.

---

This part concludes the Documents in SharePoint series. If you’re dealing with moving documents, preparing for an ISO audit or obligations under cybersecurity law, we’re happy to go through with you what you have and what’s missing — usually as part of our governance design. Get in touch.

The whole series: What SharePoint does out of the box · Moving from a file server step by step · ISO 27001 and ISO 9001 in SharePoint · How to prove a policy was read.