What separates a policy from a standard, a procedure and a guideline?

Most written policies are ignored, and the reason is usually visible in the document itself. It states a principle, does not say who it applies to, does not say what to do when it cannot be followed, and names no one who can answer a question about it. Faced with that, people fall back on what they were doing before.

A policy that gets followed does four things: it says what the rule is, who it binds, what happens at the edges, and who owns it. Everything else in the document is supporting material.

What to take away

Policy, procedure, standard, guideline

These four words get used interchangeably and the confusion causes real damage: a procedure written as a policy is unchangeable when the tool changes, and a policy written as a guideline is unenforceable when it matters.

The practical value of the split: your policy on handling customer data should survive changing every system you use. If the policy names the system, it will not.

Keep policies short and stable. Push everything volatile down into a standard or a procedure that the policy references. If you find yourself revising a policy because a supplier changed, the content was in the wrong document.

The policy skeleton

<figure class="inline-figure">
  <img src="/inline/policy-templates-fig2-1280.webp" alt="Checklist of the nine sections in a policy skeleton (What separates a policy from a standard, a procedure and a guideline?)" loading="lazy" decoding="async" />
  <figcaption>The full skeleton: header block plus nine numbered sections, in the order they should appear. <a href="https://companyformtemplates.com/image-licence">Image: Company Form Templates</a></figcaption>
</figure>
[POLICY TITLE]

Policy owner        [role, not a person's name]
Approved by         [role or committee]
Approval date       [date]
Effective date [date: often not the same day]
Version             [n]
Next review         [date or trigger]
Supersedes          [version or document, if any]

1. PURPOSE
   Why this policy exists. One short paragraph, in terms of
 the outcome it protects, not "to establish a policy on X".

2. SCOPE
   2.1  Who this applies to (roles, locations, entities,
        contractors, third parties)
   2.2  What it applies to (systems, data, activities, assets)
   2.3  Who or what is expressly out of scope

3. DEFINITIONS
   Only terms that are genuinely ambiguous or used here in a
   narrower sense than in ordinary speech.

4. POLICY STATEMENTS
   4.1  [The rule, written as a requirement]
   4.2  [The rule, written as a requirement]
   ...

5. ROLES AND RESPONSIBILITIES
   Who does what under this policy. By role.

6. EXCEPTIONS
   How to request one, who can grant it, how long one lasts,
   and where granted exceptions are recorded.

7. NON-COMPLIANCE
   What happens when the policy is not followed.

8. RELATED DOCUMENTS
   The standards, procedures and other policies this connects to.

9. REVISION HISTORY
   Version | Date | What changed | Approved by

The header block earns its space

Almost every question people ask about a policy is answered by the header, if the header is complete.

Writing statements people can actually comply with

The policy statements section is where drafting quality shows.

Use one modal verb consistently. Decide whether must means mandatory and should means recommended, say so once, and never drift. A document that mixes must, shall, should, will, and is expected to has no enforceable line in it. The same discipline applies to invoices and receipts format, where one consistent label for each field prevents the reader from guessing.

One requirement per numbered statement. Compound statements cannot be complied with partially, audited, or referenced in a conversation.

Say who must do it. "Access must be reviewed quarterly" is a rule with no owner and it will not happen. "Each system owner must review access to their system quarterly" will.

Write the requirement, not the aspiration. "Staff should be mindful of confidentiality" cannot be followed or breached. "Customer records must not be copied to personal devices" can be.

Avoid naming products, versions, and thresholds in the policy. Those belong in a standard the policy points to, so the number can change without an approval cycle. Published frameworks are built this way for the same reason: the NIST Cybersecurity Framework supplies a structure to map your own practice against rather than a set of settings to copy.

Test each statement against a real Tuesday. Take a specific person in a specific role and walk through their actual day. If they would have to stop and ask someone what the policy means, rewrite it. A rule about what may be promised to a customer shows up in every quote that goes out, which is a better test of whether it landed than any attestation figure.

The two sections everybody drops

Exceptions. A policy with no exception route gets broken quietly rather than escaped openly. Somebody will hit a genuine case the drafters did not foresee, and if there is no way to raise it, they will just do the thing and not mention it. Then you have neither compliance nor visibility.

That register is often the most useful document in the system. Every place reality diverges from the rule points to a policy that needs rewriting.

Non-compliance. Say what actually happens, at the level you are willing to follow through on. A policy threatening consequences nobody has ever applied teaches people that the whole document is decorative. If the honest answer is "your manager will discuss it with you," write that.

Where you must get advice before publishing

Anything that touches employment needs review by someone qualified in the law of the place your people work: before it is issued, not after somebody relies on it.

That covers disciplinary and grievance processes, working hours and leave, remote and hybrid working, and monitoring of staff or their devices. Expenses, whistleblowing, harassment and conduct count too.

So do health and safety, redundancy, and anything describing what an employee may or may not do outside work. Technical policies with employment consequences count too: an acceptable-use policy that ends in dismissal, or a monitoring policy that touches privacy at work.

An expenses policy is a smaller example: it is only as good as the receipts behind it, which is the invoices and receipts side of the same rule.

The rules differ by country, often by region within a country, and by employment status, and they change. The UK government's summary of employment contracts and conditions shows how much of this is local and how little transfers.

A template written for one jurisdiction can be harmful in another: it may create obligations you did not intend, or promise a process you are not permitted to follow. Some policies must be consulted on, provided in a particular form, or lodged somewhere before they bind anyone.

So use a template for structure and language, then have an employment lawyer or a qualified adviser in your jurisdiction review the substance. The same applies to policies covering personal data, financial controls, and regulated activities in your sector. Nothing on this page is legal advice, and the skeleton above is a layout, not a compliance position.

Whether the policy is working

Most organizations measure whether the policy was published. That is not the same question.

Useful signals, in rough order of how much they tell you:

Attestation counts, the number of people who clicked to confirm they read it, measure distribution and nothing else. They are worth collecting for the record and worth ignoring as a measure of compliance.

Retiring a policy

A policy library grows and nobody prunes it, so eventually the set contradicts itself and people stop consulting any of it.

A retired policy gets marked withdrawn with the date and the reason. Keep it in an archive, not deleted, and remove it from wherever staff actually look. Deleting it outright means you cannot say what the rule was for the period somebody is asking about.

Two policies covering the same ground is worse than one imperfect policy, because now nobody knows which applies.

Before you publish

A new policy still has to be told to people, and the covering note that does it is worth writing like any other business letter: what has changed, what you need them to do, and by when.

Common questions