Emailing the policy round and asking people to reply is the most common way UK SMEs distribute controlled documents. It is also one of the most common places I raise a finding — not because the email is wrong, but because of what it quietly stops proving the moment the document is revised.
Here is a question I ask in almost every surveillance audit, and it is deliberately simple:
It sounds like an easy one. Most organisations have something — a folder of emails, a spreadsheet, a signed sheet from an induction. The trouble is that the question contains three separate demands, and the usual evidence only answers one of them. It asks who, it asks read, and — the part that does the damage — it asks the current version.
This article is about the gap between those three demands and the email trail most SMEs use to meet them. It is not an argument that email is forbidden. It isn't. It is an explanation of the specific point at which an email trail stops being evidence, so you can decide whether that point applies to you.
Start by being precise about the requirement, because this is where a lot of well-meaning advice overreaches.
No clause of ISO 9001 names a tool, a platform, or a signature mechanism. Anyone telling you the standard mandates read-and-sign software is selling you something. What the standard requires is a set of outcomes, and it leaves the method entirely to you.
Paraphrasing the relevant obligations rather than reproducing them — you should work from your own legally-obtained copy of the standard for the exact wording — a controlled-document system has to be able to demonstrate broadly four things:
Read those together and something becomes clear. Three of the four are about version. The standard is far less interested in the ceremony of signing than in whether you can connect a named person to a specific revision of a specific document at a specific point in time. That is the whole game.
Consider the normal sequence. You revise the policy. You attach it to an email. You send it to thirty people. Some reply “read and understood.” You file the replies.
On the day, that is genuine evidence. You have names, you have timestamps, you have an affirmative statement. If an auditor asked on that Tuesday afternoon, you would pass comfortably.
Now let eight months go by, which is roughly the gap between issuing a policy and being asked about it. In that time the policy is revised twice — a change of named contact, then a tightened escalation route. Here is what has happened to your evidence without anybody touching it:
An emailed attachment is a copy, taken at the moment of sending. It does not update when the source document does. Every one of those thirty inboxes now holds a policy that is two revisions out of date, and nothing in the system knows that.
“Read and understood” read and understood what? Unless the email named a revision number — and almost none do — the reply is an acknowledgement of an unidentified document. It is not that the evidence is weak; it is that it no longer has a subject.
Six of those thirty have left. Four people have joined and were never on the original email. Your acknowledgement set now describes a workforce that no longer exists, and the gap grows silently every month.
None of this involves anyone doing anything wrong. The process worked exactly as designed. It simply had no mechanism for staying true, and the decay is invisible until somebody asks the question.
It is worth being specific here, because the general worry (“email is bad”) is less useful than the actual mechanism.
The organisation produces the folder of replies. The auditor picks one at random — say a supervisor who acknowledged the manual-handling policy in January. The auditor then asks to see the policy currently in force. It is revision 4, issued in May. The acknowledgement was against revision 2.
At that point there is no argument to make. Not because anybody was careless, but because the record cannot answer the question. The finding writes itself: acknowledgement of a superseded document, with no evidence of re-issue after revision. And it is rarely just one person — if the mechanism failed for the supervisor, it failed for everyone on that list, so a single sample turns into a systemic finding.
The same shape appears wherever documents live somewhere that does not track who has read what. A shared drive with a Policies folder has the same hole: perfect availability, no record of awareness. This is why using SharePoint for ISO document control works well for storage and version history, but needs something on top of it before it answers the awareness question.
Whatever mechanism you choose — and a genuinely small, stable team can do this on paper — the record needs four fields. The third is the one that fails.
| Field | Why the auditor wants it | Typical email trail |
|---|---|---|
| Who | Ties the acknowledgement to a named individual, not a team or a distribution list | Usually fine — the sender address identifies the person |
| When | Establishes the acknowledgement happened after the revision was issued | Usually fine — the mail header is timestamped |
| Which version | Distinguishes the current document from every superseded one. Without it the other three fields describe nothing in particular | Almost always missing. The attachment carried no revision reference and the reply names no document |
| Retrievable | Can be produced on request, by someone who is not the person who filed it, months later | Depends entirely on one person's mailbox and filing habits — and on them still working there |
Notice that two of the four are fine. Email is not useless; it is partially sufficient, which is worse, because partial sufficiency is what stops people looking at it again.
In rough order of how much administration they cost you.
The cheapest fix, and for a stable ten-person business it can be enough. Two disciplines: the document itself carries a visible revision number and date on its front page, and the covering email quotes that revision in the subject line — “Manual Handling Policy rev 4 (May 2026) — please confirm”. Now the reply has a subject, and the acknowledgement can be matched to a version years later.
What it does not fix: the leavers-and-joiners drift, and the fact that reconstructing a full picture still means reading a mailbox.
A single sheet, one row per person per document version, updated when either changes. It is a real answer — it is what organisations did for decades before any of this was software, and a well-kept register beats a badly-configured system every time.
What it costs: somebody has to keep it, and it is only as current as the last time they did. Registers fail at holidays and at growth.
Rather than distributing a copy and collecting replies, staff open the live document and record acknowledgement against it. Because the acknowledgement is attached to the document record, the version is captured automatically rather than remembered — and when a new revision is issued, the system knows the previous acknowledgements no longer cover it.
The practical difference is not the signature. It is that the question “who has read the current version?” becomes a query rather than an investigation.
Read-and-sign distribution is built into the PICMS document command centre, and it works on the third model above. A document is issued from its controlled record; recipients acknowledge against that record; the acknowledgement stores the person, the timestamp and the revision. Issue a new revision and the outstanding list rebuilds itself — the people who acknowledged rev 3 are simply not counted as having acknowledged rev 4.
Two things worth being straight about. First, this is a record-keeping control, not a comprehension test: it evidences that someone opened the current version and confirmed it, which is what the awareness requirement is aimed at, and it does not tell you they understood it. Nothing does. Second, none of this removes the need for the underlying document control to be right — a tidy acknowledgement trail against a badly-versioned document is just a neater way of failing.
If you would rather see the mechanism than read about it, the features page walks through the document command centre, and the internal audit checklist covers what else tends to get sampled in the same visit.
PICMS issues controlled documents from their own record and captures each acknowledgement against the revision in force — so when you re-issue, the outstanding list rebuilds itself instead of quietly going stale.