A policy document has an unusual property: it is a piece of writing whose value depends almost entirely on whether people can find it, understand it, and be shown to have received it. Most organisations write policies carefully and then manage them carelessly — three versions circulating, none dated, the current one buried in a shared drive nobody browses. This covers writing policies people will actually use and managing them so they hold up when someone asks which version applied last March.
What a policy is for
Three purposes, which pull in different directions:
- Guidance — telling people what to do, so they do it consistently without asking.
- Protection — establishing that the organisation set out expectations, which matters in employment disputes and regulatory inspections.
- Compliance — satisfying a legal or contractual requirement that the policy exists at all.
Documents written purely for the second and third purposes read like insurance and get ignored. Documents written purely for the first may fail an audit. The craft is writing something that serves all three without becoming a legal document nobody finishes.
Structure that works
Lead with what the reader must do. Not scope, not definitions, not a statement of the organisation's commitment to excellence. The first thing after the title should be what changes for the person reading it. Definitions and scope go at the end, where the reader who needs them will look.
One policy, one subject. A "People Policy" covering leave, expenses, conduct and equipment is four policies with a shared cover page, and it means every update touches a document four groups of people are subject to.
Separate policy from procedure. The policy says what and why — "expenses over £100 require prior approval". The procedure says how — which form, which system, who approves. Procedures change often; policies should not. Keeping them separate means you can update the process without a governance cycle. See writing standard operating procedures.
Be explicit about what is mandatory. "Should", "may", "must" and "will" carry different weight, and inconsistent use is the most common cause of arguments about a policy's meaning. Pick a convention and state it.
Keep it short. A 60-page handbook is read once, at induction, by nobody. A 3-page policy with a linked procedure gets consulted. Length is inversely related to compliance.
The writing craft applies as much here as anywhere: plain language business documents and concise writing: cut your word count.
Versioning, which is the part that fails
The question you must be able to answer, years later, is: which version was in force on a given date, and can we show the employee received it?
That requires a small amount of discipline applied consistently:
- A version number and effective date on every page, not just the cover. Pages get printed, photographed and forwarded individually.
- A document control block on page one or two: version, effective date, owner, approver, review date, and a change summary.
- A change log listing what changed in each version and when. Two lines per version is enough.
- Superseded versions retained, not deleted. The version that applied in 2024 is the relevant one for a 2024 dispute.
- One canonical location. Everything else links to it. A policy that exists as an attachment in an email thread has as many versions as recipients.
Filenames follow the same logic: Expenses-Policy_v3.2_2026-04-01.pdf. See naming and versioning shared files and document versioning best practices.
PDF, intranet page, or both
A real trade-off, and the answer is usually both with a clear rule about which is authoritative.
An intranet or wiki page is searchable, always current, easy to update, accessible on any device, and linkable. It is where people should read the policy.
A PDF is fixed, printable, signable, and preservable. It is what you produce when someone asks what the policy said on a particular date, and what you attach to an acknowledgement request. See PDF vs HTML for the general comparison.
The workable arrangement: the intranet page is the reading copy and always reflects the current version; a dated PDF is generated for each approved version and archived. Both carry the same version number. The archive answers historical questions; the page answers today's.
Whichever you choose, avoid the common failure: a PDF attached to an email in 2023, a slightly different PDF on the shared drive, and an intranet page updated in 2025, with no indication which governs.
Acknowledgement and distribution
For policies that carry consequences — conduct, IT acceptable use, health and safety, confidentiality — you generally need evidence that people received and accepted them.
Options, in increasing order of robustness:
- An email with the policy attached and a request to confirm. Weak evidence, better than none, and impossible to track at scale.
- An HR system acknowledgement, where the system records who acknowledged which version and when. This is the right answer for any organisation with an HR platform, because it ties the acknowledgement to a specific version.
- A signed acknowledgement page, e-signed rather than printed and scanned. Appropriate for policies with contractual effect. See how to create an electronic signature and digital signatures vs electronic signatures.
Whatever you use, the acknowledgement must record the version, not just the policy name. "Confirmed receipt of the Expenses Policy" is nearly useless if the policy has changed three times since.
Also: re-acknowledge on material change. A policy people accepted two versions ago is not a policy they have accepted.
Accessibility
Policy documents apply to everyone in the organisation, which makes accessibility a practical requirement rather than an aspiration — an employee who cannot read the policy cannot be expected to follow it, and in many jurisdictions failing to provide it accessibly is itself a compliance problem.
The essentials:
- Real headings, so the document is navigable by structure.
- Tagged PDF with correct reading order — reading order in tagged PDFs and tagged PDF vs untagged PDF.
- Alt text on any diagram — how to add alt text to PDF images.
- Real tables, properly tagged, for anything tabular — making accessible PDF tables.
- Never distribute a policy as a scan. A scanned, unOCR'd handbook is unreadable to assistive technology and unsearchable to everyone.
The standards: PDF accessibility guide and WCAG 2 for PDF accessibility.
Review cycles
Policies rot. Legislation changes, systems are replaced, the named approver leaves, the referenced form no longer exists.
- Set a review date on every policy — annually for most, more often for anything tracking fast-moving regulation.
- Name an owner, a role rather than a person, so ownership survives departures.
- Diary the reviews. A review date printed on a document that nobody diarises achieves nothing.
- Review means confirm or change. "Reviewed, no changes, next review 2027" is a legitimate and valuable outcome, and it should be recorded in the change log.
- Retire policies explicitly. A withdrawn policy should be marked as withdrawn and archived, not silently deleted — someone will ask what applied at the time.
The review process itself is a document review cycle like any other: running a document review cycle.
Retention
Employment-related policies typically need retention well beyond their period of use, because claims can be brought years after the events. Keep superseded versions, with their effective dates, for the length of the relevant limitation period at minimum — often six years, longer for anything touching health and safety or discrimination.
Archive in a durable format: PDF/A archival format explained and document retention policies.
Summary
Write policies short, lead with what the reader must do, and split stable policy from changeable procedure. Put a version number and effective date on every page, keep one canonical location, retain superseded versions, and record acknowledgements against a version rather than a title. Publish the reading copy where people will actually find it and archive a dated PDF of each approved version — because the question you will eventually be asked is not what the policy says, but what it said at the time.
