How to Write Policies and Procedures That People Actually Follow

Most policies and procedures fail quietly. Not because the rules are wrong, but because nobody can find them, understand them, or trust that they're current. The document exists — it just doesn't change how anyone works.

This guide walks through how to write policies and procedures your team will actually read and follow: how a policy differs from a procedure, a reusable structure you can apply to every document, how to write in plain language, and how to keep the whole set current with review and approval. By the end you'll have a repeatable system, not a one-off document that goes stale the week after you publish it.

Policy vs. procedure: what's the difference?

A policy states a rule and the reasoning behind it — the what and why. A procedure lays out the steps to carry that rule out — the how. A policy might say all customer refunds over $500 require manager approval; the procedure explains exactly how to request, record, and issue that refund.

Keeping the two separate matters because they change at different speeds. Policies shift when leadership, law, or risk changes — occasionally. Procedures change whenever a tool, form, or step changes — often. Bolt them into one document and every small workflow tweak forces you to re-approve the whole policy. Split them, and your teams can update the steps without reopening the rule.

A quick way to tell which you're writing: if a sentence could start with "we must" or "we will," it's policy. If it starts with "first, then, next," it's procedure.

Start with scope, not the first sentence

The most common mistake is drafting policy statements before deciding what the document is even for. Before you write a line, pin down three things:

• Purpose — the problem this document solves, in one sentence.
• Scope — who it applies to, which situations, and any explicit exclusions.
• Owner — the single person or role accountable for keeping it accurate.

Scope is where most documents go wrong. A policy that tries to cover every team and edge case becomes too long to read and too rigid to follow. It's better to write two focused documents than one that hedges on every line. Government guidance on preparing standard operating procedures makes the same point: the level of detail should suit the nature and complexity of the process — no more than the work actually requires.

A structure you can reuse for every document

Consistency is what turns a pile of documents into a policies and procedures manual. When every document follows the same skeleton, readers learn where to look once and find it everywhere. Government guidance on preparing standard operating procedures recommends a fixed, repeatable format for exactly this reason — it reduces variation and makes the whole set easier to maintain.

Use these sections as your template:

1. Title and identifier — a clear name plus a document ID and version number.
2. Purpose — why the document exists.
3. Scope — who and what it covers, and what it excludes.
4. Definitions — any terms a new reader wouldn't know.
5. Policy statement — the rule itself (for procedures, a short summary of the process).
6. Roles and responsibilities — who does what.
7. Procedure steps — numbered, sequential actions.
8. Exceptions — how to handle cases the rule doesn't fit.
9. Revision history — what changed, when, and who approved it.

You won't need every section in every document — a short procedure may skip definitions — but keeping the order fixed means nothing important gets forgotten. Templates make this effortless: start each new document from the same boilerplate instead of a blank page, and the structure takes care of itself.

Policies and procedures examples: the structure in practice

A remote-work policy uses the policy statement to define eligibility and expectations, and roles to clarify what managers approve. An expense procedure leans on numbered steps and a linked form. An incident-response procedure needs strong roles and responsibilities and exceptions, because the whole point is knowing who acts when something goes wrong. Same skeleton, different emphasis.

Write in plain language

A policy only works if the people bound by it can understand it. Plain-language guidance from public-sector writing standards is blunt about this: write for your reader, use common words, keep sentences short, and prefer the active voice. "Submit the form to your manager" beats "The form should be submitted to the relevant supervisory personnel."

A few rules that carry most of the weight:

• Use command words precisely. Must and shall mean mandatory; should means recommended; may means optional. Mixing them up creates real confusion — and, for compliance documents, real risk.
• One idea per paragraph. If a step has sub-steps, break them out as a numbered list rather than burying them in prose.
• Cut the jargon. Define a term the first time you use it, then stay consistent. Don't call it a "ticket" in one section and a "case" in the next.
• Keep each document short. Aim for a few pages. If it sprawls, that's usually a sign it should be split into a policy plus one or more procedures.

Readability isn't a nicety here. If a reader has to interpret a policy, they'll interpret it however is easiest for them — which is rarely what you intended.

Move drafts through review and approval

An unreviewed policy is just an opinion. Before anything goes live, it needs the right eyes on it and a record that they signed off. Established guidance on standard operating procedures treats this as non-negotiable: procedures should be formally reviewed and approved before they're used, and you should always be able to identify the current revision.

A workable approval flow has three stages:

1. Draft — the owner writes it and pulls in subject-matter experts for input.
2. Review — stakeholders (legal, HR, security, operations — whoever the policy touches) comment and request changes.
3. Approval — an accountable approver signs off, and the version becomes official.

The friction usually isn't the reviewing — it's the coordination. Chasing feedback across email threads and attachments is where policies stall for months. Sonat's approval workflows let you route each document through the right reviewers in parallel or in sequence, capture comments in one place, and record who approved what and when. That approval trail is exactly the evidence an auditor asks for.

Publish to a single source of truth

The fastest way to undermine good policies is to let copies multiply. When the same procedure lives in a shared drive, three inboxes, and someone's desktop, people will follow whichever version they happen to open — usually the outdated one.

Keep one authoritative, published home for every document, and point everyone to it. A policy and procedure management approach worth its name means the published version is always the current version, obsolete copies can't be mistaken for live ones, and the right version is available at the point where people actually do the work. With Sonat you publish once to the web — on your own domain if you want — with full-text search so employees find the exact policy in seconds instead of asking a colleague.

Keep policies current with a review cycle

Policies and procedures are living documents. The moment a tool, law, or process changes, an unmaintained document starts steering people wrong. So build maintenance into the system instead of treating it as an emergency.

Two habits keep a manual healthy:

• Scheduled reviews. Give every document an owner and a review date. Rather than overhauling everything at once, review a portion of the manual each quarter so the whole set gets scrutiny over a year without burning anyone out. Higher-risk areas — data protection, safety, finance — deserve a shorter cycle.
• Trigger-based reviews. Some changes can't wait for the calendar. A new regulation, a security incident, a reorganization, or a platform change should trigger an immediate review of the affected documents.

This is where version control earns its keep. Every change should be tracked, every past version recoverable, and every update visibly stamped with what changed and who approved it. Sonat keeps an unlimited version archive for every topic, so you can see how a policy evolved and restore an earlier version if you need to — the revision history writes itself.

Turn documents into a system

Writing policies and procedures people actually follow comes down to a few repeatable moves: separate the rule from the steps, use one consistent structure, write in plain language, route every draft through real review and approval, publish to a single source of truth, and revisit on a schedule. None of it is exotic. What makes it work is doing it the same way every time.