A Policy on Policies: Why Governance Needs Its Own Rulebook

Most organisations have plenty of policies and no rule for the policies themselves. A data-protection procedure, a safeguarding note and a supplier rule can each be careful, and staff can still be looking at three copies that all claim to be current.

A policy on policies is that rule. It does not restate every other document. It says how a policy comes into force, who owns it, how often it is reviewed, how versions are marked, how a document is retired, and how an exception is granted. Policy on policies governance is the work of making those rules true in the files people open.

Public NHS policies already do this. South East Coast Ambulance Service’s Community First Responder Policy, version 4, September 2025, includes an equality analysis taken from the trust’s policy on policies. The outline at the end is a draft you can copy. It is not that trust’s text, and it is not legal advice.

What the parent rule decides once

Decide these questions in one place:

• what counts as a policy, as distinct from guidance, a form or a briefing;
• who may approve one;
• where the current copy lives;
• how long it stays in force, and what an overdue review means;
• what happens to the old copy;
• who may allow a departure, and where that departure is recorded.

Individual policies can then stay shorter. They state the operational rule. They inherit document control from the parent.

Ownership

Every policy needs a named owner, usually a post rather than a personal inbox, so the duty survives a resignation. Name a deputy for leave and vacancies.

The owner is accountable for the content: whether it is still right, whether it clashes with another document, and whether staff can follow it. Authorship is a different fact. The person who drafted the words may have moved on. The owner is who the organisation asks when the words are challenged.

The owner keeps the current copy accurate, starts the review on time, proposes retirement, and answers conflicts. Say which second post or forum gives approval, so the owner is not the only signature on their own draft.

PolicyOps can store the owner against the policy and tie staff answers to the current copy. The owner remains accountable for the content. Publishing and retiring stay authorised governance actions, recorded on the policy and in the audit trail.

Approval

Approval is the moment a draft becomes the copy people must follow. Name the route, including any split between a minor correction and a change of substance. A typo and a new duty can share a path, or they can be separated. Either choice works. An unstated choice means every edit waits for a committee, or none of them do.

For each approval, record the version, the approver, the date, the effective date if later, and what changed. Keep drafts out of the place staff look for the live rule. If two bodies could both claim a document, say which one wins, so clinical, employment and information-governance homes do not each file a separate “final” copy.

Review cycle

A review date is a promise that someone will look again, including when the text stays the same. Set a default period, who may shorten it, and what an overdue policy does: stay in force and be flagged, stay in force for a grace period, or be suspended. A no-change review still records a name, a date and the next date. Name who may open an early review after a change in the law, a serious incident, a merger, or a conflict staff have reported.

Versioning

Versioning is how you answer “what did we tell people in March?” Require a version identifier that increases when the approved text changes, a plain status (draft, current, superseded, retired), one current version at a time, and a kept copy of the previous current version, marked so nobody treats it as the live rule.

Name the system of record. Email and personal drives are not the version to follow. When a new version is approved, mark the old one superseded the same day.

PolicyOps uses Current as the version for ordinary answers. Publishing a replacement makes it Current and marks the previous version Superseded. People with a governance role can open the history. Staff are shown the current copy.

Retirement

A retired document that still looks current will be followed. Retirement should be as deliberate as approval. State who may retire a policy, the reason they need (the activity has stopped, another document now covers it, or the rule has been withdrawn), and what staff are told.

On that day the text leaves the current library and remains available to people with a reason to see history. Set the retention period with your records or information-governance lead, and write the number in the parent rule so it is not reinvented for each document.

An action taken under the old version stays referable to that version, so the old text and its dates have to survive. If another policy replaces this one, supersede it. Use retirement with no successor when the rule itself has ended.

In PolicyOps, retiring a current policy removes it from staff lists and staff answers and keeps the versions, the provenance and the audit history. The lifecycle decision and a workspace audit event are both recorded.

Exceptions

An exception is a permitted departure from a current policy for a defined case. It is not a quiet decision to ignore the policy, and it is not a new version of it.

Require the policy and clause, the case, who asked, who approved, the reason, the start and the end, any conditions, and the place the exception is stored so the owner sees it at the next review. Give it an end date, and say that it lapses unless renewed in writing. An exception that never expires becomes a second policy.

For a material departure, the requester and the approver are different posts. An exception for one team is not a permission for every team. Repeated exceptions are a reason to amend the policy.

When someone asks a question, the current clause and any live exception are different facts. PolicyOps can show the cited passage and a limitation, and route the follow-up to a person. Granting the exception stays with the approver named in your rule.

Conflicts

Give staff one instruction. They use the current version in the system of record. If a published page and that record differ, say which prevails. If two current documents conflict, say whether they follow the more specific rule or stop and ask the named owner. Record the question against the version it concerns. A clash staff have already hit is a review trigger.

PolicyOps can present the passages and keep the clarification with that version. The owner or reviewer records the outcome. The documents change only through the approval route.

A short template outline

Copy this into your house style. Fill the brackets. Delete a line only after you have decided it on purpose.

1. Purpose. This policy sets the rules for writing, approving, reviewing, versioning, retiring and making exceptions to [organisation] policies. It applies to [document types]. It does not itself set the operational rules in those documents.

2. System of record. The current copy of each policy is held in [named library]. Email, local drives and old intranet pages are not authoritative. If the library and a published page differ, [say which prevails].

3. Ownership. Each policy has an owner post and a deputy. The owner keeps the content fit for use, starts reviews, proposes retirement, and answers conflicts. The owner [may / may not] approve their own policy. Deputies act when the owner is absent.

4. Approval. Drafts are marked draft and are not for general use. [Name the approver or forum] approves a new policy or a material change. Minor corrections follow [route]. The record states the version, the approver, the approval date, the effective date and a summary of the change.

5. Review cycle. The default period is [12 / 24 / 36] months. An overdue policy [stays in force and is flagged / has a grace period of X / is suspended]. A no-change review is recorded, with the next date. [Role] may open an early review after [law, incident, merger, or a reported conflict].

6. Versioning. Approved text carries a version identifier and one status: draft, current, superseded or retired. Only one version is current. The previous current version is kept and marked superseded. Staff are directed to the current version.

7. Retirement. [Role] may retire a policy when [conditions]. Retired text leaves the current library and is kept for [period] for people authorised to see history. Actions taken while it was current remain referable to that version. If another policy replaces it, the old one is superseded.

8. Exceptions. Record the clause, the case, the requester, a different approver, the reason, any conditions, and a start and end date. It lapses on the end date unless renewed, and it does not change the policy for anyone else. Repeated exceptions go back to the owner as a proposed amendment.

9. Conflicts. Staff use the current version in the system of record. If two current documents conflict, they [follow the rule you chose] and tell [the owner]. The question is kept with the version it concerns.

10. This policy. This policy on policies is owned by [post], approved by [forum], reviewed every [period], and versioned under the rules above.

Putting it to work

Adopt the parent rule before you tidy the whole estate. Give it an owner and a review date, or it becomes another unowned file. Then put one busy policy through the outline and see which fields you cannot fill. Those gaps are the ones staff already work around.

PolicyOps holds the owner, the version and the audit record, and gives staff an answer from the current copy with the passage it came from. Approval, retirement and exceptions stay with the people the rulebook names.