Read receipts, intranet views, signed PDFs and training-system ticks all leave the same gap. Here’s why per-person, per-version confirmation that reopens automatically when a policy changes is the evidence auditors accept.
TL;DR
- “We sent the all-staff email” is not proof that a policy was read. Sending shows a message went out. It says nothing about who read which version, or when.
- Read receipts are unreliable. Most email clients let the recipient decline to send one, and they never record the policy version a person saw.
- The evidence auditors want is specific: a named individual confirming they’ve read a specific version, on a specific date, and confirming again when the policy changes. (This recorded confirmation is what compliance teams mean by “attestation.”)
- The method that stands up is per-person, per-version confirmation that re-confirms automatically. Send to the right people by role, capture each person’s confirmation against a version, and reopen that confirmation automatically when the document is updated.
- This is the gap Injio Docs closes through its Read & Acknowledge capability, and it’s already live in regulated healthcare environments.
Quick definition: Policy attestation is a formal term for a recorded confirmation that a named person has read and accepted a specific policy. Throughout this article, we’ll mostly call it “confirmation,” because that’s all it really is, done in a way you can prove later.
The quiet panic behind a simple question
There’s a particular moment that makes compliance and governance leaders go cold. An auditor, a regulator, or a lawyer leans forward and asks: “Can you show me that every clinician has read the current infection-control policy?”
If the honest answer is “we emailed it to everyone in March,” you don’t have evidence. You have a hope with a timestamp.
This isn’t a knock on anyone’s diligence. It’s a structural problem with the tools most organisations lean on. Sending, viewing, signing and ticking all feel like proof. Under scrutiny, none of them answer the question that matters: did this named person read this specific version of this policy, and can you prove it?
Let’s walk through why each common method leaves a gap, and what closing it properly looks like.
Why “we sent the email” fails as evidence
Sending a policy and confirming someone read it are two completely different things, and treating them as one is where most policy programmes quietly break.
An email proves you meant to communicate. It does not prove the message was received, read, understood, or (most importantly) which version landed in front of which person. Think of it like posting a letter: Australia Post can tell you it was lodged, but lodging a letter has never proven anybody opened it. So, organisations need to reach for something that looks sturdier.
Here’s are some common options organisations provide as proof and where each option falls short.
Read receipts: optional, dismissible, version-blind
Read receipts feel like the obvious fix, but they’re built on sand. In Outlook, Apple Mail, Thunderbird and most professional clients, the recipient is asked whether to send a receipt, and plenty click “no” out of habit or privacy instinct. As one analysis of messaging tools puts it, an email marked “read” is not reliably an email that was read.
Even when a receipt fires, it tells you a message was opened. It doesn’t tell you a policy was read, and it never tells you which version. A read receipt on the March email is worthless once you publish the April revision.
Intranet and news-post views: traffic, not confirmation
Publishing a policy to a SharePoint news post or intranet page generates view counts. Views are a traffic metric. They tell you a page loaded in a browser, not that a specific, named person read the content and accepted their obligations under it. A page view isn’t a confirmation, and it can’t be filtered down to “show me the eleven people on the night roster who still haven’t confirmed.”
Signed PDFs: real signatures, unmanageable at scale
A countersigned PDF is genuine evidence for one document at one point in time. The trouble is the paper trail. Multiply one PDF by every staff member, every policy, and every revision, and you’ve built a filing problem that ages badly. When the policy changes, every one of those signatures silently goes stale, and working out who’s on the current version becomes a manual archaeology project.
Detached training-system ticks: the confirmation that floats free
Learning management systems (LMS) capture a clean “completed” tick, which is why so many compliance teams route policies through training modules. That tick is usually detached from the policy itself. The system records “Jordan completed the module on 12 May.” It doesn’t tie that to version 3.2 of the document Jordan actually opened, and it rarely reopens automatically when the underlying policy is amended. You end up with confirmation records and policy versions living in two systems that drift apart.
What auditors ask for
Here’s the useful part. The standards themselves tell you what good evidence looks like, and it’s narrower than most teams assume.
ISO 27001 doesn’t mandate a specific confirmation system. What it requires is that awareness is demonstrable, and that documented information is controlled, identifiable and retrievable, with protection against unintended modification (Clauses 7.3 and 7.5). The 2022 revision of Annex A 5.1 places a stronger focus on evidence that you communicated than its predecessor did.
In practice, auditors converge on the same five questions:
- When was the policy distributed?
- Who confirmed it?
- Which version did they confirm?
- Were non-responders followed up?
- How are the records retained?
Email distribution, read receipts and spreadsheet tracking can answer, at best, the first of those, and only partially. They send information out without producing retrievable, version-linked confirmation records. When an auditor asks who confirmed which version and when, manual methods force a reconstruction, and reconstruction under pressure is exactly what auditors treat as weak evidence.
The goal isn’t “more proof.” It’s the right shape of proof.
The method that stands up: per-person, per-version, and self-renewing
Genuine policy read confirmation has three moving parts. Get these right and the auditor’s five questions answer themselves.
- Send to the right people, by role. The policy goes to the right people rather than “everyone.” A manual-handling policy lands with the people who do manual handling. This does two things. It makes the obligation meaningful, and it makes your non-responder list short and actionable instead of an inbox-wide blur.
- Capture each person’s confirmation against a version. Each person confirms they’ve read a specific version on a specific date. That confirmation is tied to the document version, so it isn’t floating in a separate training system or implied by a view count. One person, one version, one timestamp, recorded and reportable.
- Reopen the confirmation automatically when the policy changes. This is the piece almost everything else misses. When the policy is updated, the confirmation request reopens automatically, and everyone in scope is asked to confirm the new version. Your evidence never silently goes stale, because the system treats a new version as a new obligation. (This is the “re-confirmation,” or auto re-attestation, that compliance frameworks increasingly expect.)
Put plainly: reading a policy should be confirmed against the document version rather than buried as an event in someone’s inbox. That single shift is what turns “we hope they read it” into “here’s the report.”
What this looks like in the real world
This isn’t theoretical. A healthcare provider running clinical services across several centres needed to prove the right people had read the right policies, rather than assume it. Working with WebVine, they implemented Injio’s Read & Acknowledge capability.
The setup illustrates the method neatly:
- A Policies & Procedures Hub for roughly 800 controlled documents, covering around 175 authorised users across multiple centres.
- Targeted distribution by group and role, so staff only see what’s relevant to them.
- Per-version individual confirmation, where each person confirms they’ve read a specific version on a specific date, with every confirmation recorded, tracked and reportable.
The outcome is the bit that matters. When a regulator asks “show me that every clinician has read the current infection-control policy,” the answer is a report rather than a scramble. The same thinking runs through the wider Injio Docs approach to controlled documents: a single defensible version of record, sign-offs captured against the exact version a named person approved, and read evidence tied to that version. It matters more than ever now that the same documents feed Microsoft 365 Copilot, because as WebVine’s Head of Product & Delivery James Dellow put it, AI generated answers are only as defensible as the documents they’re built from.
Where to start if your current proof is an inbox
If your current process relies on inboxes, spreadsheets or manual reminders, the priority is to add a defensible proof layer, not necessarily to rebuild the whole system. You don’t need to rip anything out to close this gap. Here’s how you need to improve your approach:
- Separate “we sent it” from “they confirmed it” in your own thinking first. List every policy where sending is currently doing the work that confirming should be doing.
- Tie the confirmation to the version, so each person confirms the exact policy version they read. When that version changes, the confirmation automatically reopens for the relevant audience, creating a fresh, reportable obligation without a manual re-send.
- Make the non-responder list a live report, not a quarterly spreadsheet reconciliation.
- Identify your highest-risk policies, the ones a regulator would ask about first (infection control, privacy, safety, code of conduct). Start there rather than with the whole library.
Ideally, this approach is undertaken systematically. Most organisations already have the foundation, a SharePoint and Microsoft 365 environment, to support this. The missing layer is structured, version-linked confirmation sitting on top of content you already trust.
See policy-read evidence in action
If your current proof that staff read a policy is an inbox and a hope, it’s worth seeing what defensible evidence looks like. See policy-read evidence in action, watch the Document Trust You Can Prove session and book a walkthrough on your own content with our team.
FAQs
Are email read receipts enough to prove someone read a policy?
No. Read receipts are unreliable, because most email clients let the recipient decline to send one, and they never record which version of a policy was read. Genuine evidence means a named individual confirming a specific version on a specific date, and confirming again when that policy changes.
What does “policy attestation” actually mean?
It’s a recorded confirmation that a named person has read and accepted a specific version of a policy. The word sounds formal, but in practice it’s simply a confirmation captured in a way you can prove later, tied to the right person, the right version and the right date.
What’s the difference between sending a policy and confirming it was read?
Sending proves a message went out. Confirmation proves a specific, named person read and accepted a specific version of the document. Auditors want the second, and “we sent the all-staff email” only offers a weak version of the first.
What evidence do ISO 27001 auditors typically request for policies?
In practice: when the policy was distributed, who confirmed it, which version they confirmed, whether non-responders were followed up, and how the records are retained. ISO 27001 requires awareness to be demonstrable and documented information to be controlled, identifiable and retrievable (Clauses 7.3 and 7.5).
Why isn’t a training-system (LMS) tick enough on its own?
An LMS captures the “completed” tick, but that tick is usually detached from the policy document itself. It records that someone finished a module, not that they confirmed version 3.2 of the live policy, and it rarely reopens automatically when the policy is amended, so the confirmation records and policy versions drift apart.
What is automatic re-confirmation (auto re-attestation), and why does it matter?
It means that when a policy is updated, the confirmation request reopens automatically and everyone in scope is asked to confirm the new version. It matters because it stops your evidence going stale. A new version is treated as a new obligation, with no manual re-send required.
Doesn’t SharePoint already do this out of the box?
Partly. SharePoint gives you versioning, retention and basic approval flows. What it doesn’t provide natively is the proof layer: a clear version of record and per-person, per-version read evidence. That’s the gap Injio Docs is designed to close on the Microsoft 365 foundation you already have.
Sources
- Injio / WebVine, Document Trust You Can Prove: Versions, Approvals, and Policy Read Acknowledgements (webinar wrap-up): com
- Policy Confirm, ISO 27001 policy acknowledgement requirements (Clauses 7.3 and 7.5; why manual methods create audit risk): com
- Stuart Barker, ISO 27001 Annex A 5.1: Policies for Information Security (2022 revision’s stronger focus on communication evidence): com
- ISO 27001 Pro, 1: Policies for Information Security (define, approve, communicate, enforce; audit evidence checklist): iso27001pro.com
- 10RUPTiV, Can we really trust read receipts, delivery receipts, and message recalls? (why read receipts are unreliable): com
Author bio
Chloe Dervin is Managing Director of WebVine, the Sydney-based digital transformation consultancy behind Injio. She works with organisations in regulated sectors (healthcare, government and beyond) to turn everyday SharePoint and Microsoft 365 environments into genuinely defensible document systems: clear versions of record, audit-ready sign-offs, and per-version proof that staff have read the policies that apply to them. Her focus is practical document trust that stands up when an auditor asks the hard question.
