What is policy acknowledgement?

Policy acknowledgement is a named person confirming that they have read a specific version of a policy, at a recorded time, in a way that can be shown to someone else later.

Organizations ask for it because a policy only works when the people it applies to know it exists and know what it says. Auditors, customers and regulators ask for it because it is the evidence that this happened. A code of conduct on the intranet proves the organization wrote one. A list of who confirmed version 2.1 of it, and when, proves people were told.

The four elements of a valid acknowledgement

Whatever system is used, an acknowledgement that holds up afterwards has the same four parts. If one is missing, what is left is a sign that something was sent, not a confirmation by the person.

1. The policy, at a version

Policies change. If a confirmation only says “information security policy”, nobody can later tell whether the person read the version from 2024 or the one that added the rules on AI tools. The version is what turns a confirmation into evidence about a particular text.

2. An identified person

The confirmation is only worth something if it is known who made it. That means the person proves who they are at the moment they confirm, not just that someone clicked a link that was forwarded.

3. An explicit action

Acknowledgement is something the person does. Opening an email or a file can happen by accident, by preview, or by a security scanner. Ticking a policy and pressing confirm cannot. For policies where reading is not enough, the action can be stronger: answering a few questions correctly, or signing.

4. A kept record

The record is what is left when someone asks a year later. It names the person, the policy, the version and the time, and it is stored where nobody can quietly correct it. It also has to be possible to find again, per person or for a whole round, without rebuilding it by hand.

Acknowledgement is not distribution

Distribution means a policy was sent or made available. Acknowledgement means a person confirmed it. Most organizations that think they have acknowledgement actually have distribution: an all-staff email, a page on the intranet, a folder in SharePoint.

Distribution is necessary, but it answers a different question. “Did we publish the policy?” is answered by the intranet. “Does Noah in the Oslo office know the new travel rules?” is only answered by a confirmation from Noah. Why an email read receipt or a view log does not close that gap is covered in read receipt vs policy acknowledgement.

Levels of acknowledgement

Not every policy needs the same proof. A remote work policy and an anti-bribery policy carry different risk. Organizations usually use three levels:

• Confirmation. The person opens the policy, ticks it and confirms. Enough for most policies.
• Confirmation with understanding checked. The person answers a few questions about the policy correctly before they can confirm. Used for policies where misunderstanding is costly, such as information security or data protection.
• Signature. The person signs, drawn or typed, as part of confirming. Used where a policy, a contract or a framework expects a signature.

Who should acknowledge

Everyone a policy applies to, which is rarely everyone. A code of conduct goes to all staff and often to contractors. A secure development policy goes to engineering. A vendor code goes to suppliers. Acknowledgement works when each policy is sent to the groups it is for, so people are not asked to confirm documents that are not about them and stop reading the ones that are.

When acknowledgement happens

Acknowledgement is not done once. It is repeated in four situations:

• A new version. A changed policy needs a new confirmation of the new text. Confirmations of the old version stay in the record as what they were.
• A new person. Someone who joins, or moves into a group a policy applies to, confirms it then, not at the next annual round.
• A regular cycle. Many frameworks and customers expect policies to be reconfirmed periodically, most often once a year.
• A corrected document. If the document behind a version is replaced, the people who confirmed the earlier document have not seen the current one.

An example

A 140-person logistics company with ISO 27001 certification sends its five core policies out once a year, in January, as one cycle called Annual policy acknowledgement 2026. Office staff, warehouse staff and contractors are in different groups, so each person gets only the policies that apply to them. People confirm from a link in their email or from the company's policy portal. Each has 14 days. Reminders go out 3 days before their deadline and again when it has passed.

By the end of the month, the information security manager can show the auditor one certificate for the whole round, and, for any sampled employee, a PDF with every policy and version that person confirmed and when.

Where it is required

Few standards use the words “policy acknowledgement”, but many require what it proves. ISO 27001 asks that people are aware of the information security policy (clause 7.3) and that this is documented (clause 7.5). SOC 2 asks that policies are communicated to the people responsible for them. NIS2 makes management responsible for cybersecurity measures, which includes making sure staff know them. Customers ask the same in their supplier questionnaires. The details are on the ISO 27001 and SOC 2 pages, and what an auditor accepts as proof is covered under audit proof.