Pick any documentation folder belonging to a small or growing team and you will find the same thing. A fourteen-page document called “Customer onboarding policy” that is actually a step-by-step procedure. A one-line “work instruction” that is actually a high-level commitment. A “procedure” that explains the company's values on data handling for six paragraphs before getting anywhere near a numbered step.
Everything is in there. Nothing is in the right place. When an auditor asks for the policy, you hand them a procedure. When a new starter asks how to do the task, you hand them a policy. Both leave unsatisfied.
The fix is not better writing. It is sorting. Three document types, three different jobs, three different update cadences. Here is how to tell them apart.
Policies: what the organisation commits to
A policy is a statement of intent. It says what the company will do (or will not do) on a given topic, and why. It commits the organisation to a standard.
Policies have a characteristic shape.
- Audience. Everyone who needs to know what the organisation stands for on this topic. Often includes people outside the company - regulators, customers, partners.
- Trigger. Joining the company, a regulatory change, an annual review cycle, a significant incident that prompted re-examination.
- Content. Commitments, principles, scope, responsibilities, references to governing law or standards, consequences of breach.
- Update cadence. Rarely. Usually annually or when a significant regulatory or strategic change occurs.
- Consequence if outdated. Typically compliance or reputational risk. If your data protection policy references GDPR incorrectly, that is a regulator-facing problem.
Typical policies include data protection, equal opportunities, anti-bribery, health and safety, acceptable use, whistleblowing, safeguarding. Most organisations have between ten and thirty of these depending on sector.
A good policy is short, specific, and reviewed on a schedule. It does not contain step-by-step instructions. If someone reading your policy ends up wanting to know “but how do I actually do it,” that is a sign you have merged a policy and a procedure.
SOPs: the step-by-step of a process
A Standard Operating Procedure is a procedural document. It describes how a specific process is carried out, from beginning to end, with enough detail that a qualified person can follow it and reach the correct outcome.
SOPs have their own shape.
- Audience. The people who execute the process - typically operational staff, sometimes supervisors.
- Trigger. When the process needs to run. During the task, or immediately before it.
- Content. Scope, prerequisites, sequenced steps, decision points, verification, what to do if things go wrong, who owns the SOP.
- Update cadence. Whenever the process materially changes. Often quarterly or semi-annual review in a busy operation, with ad-hoc updates when equipment or regulation changes.
- Consequence if outdated. Quality issues, safety incidents, compliance gaps, inconsistent work.
A good SOP is practical, imperative, and verifiable. It reads like a manual. It has steps that start with verbs. It specifies evidence where evidence matters. If your SOP reads like a mission statement, something has gone wrong.
Typical SOPs are tasks like “close the kitchen at end of shift,” “process a new customer onboarding,” “perform weekly safety check on equipment,” “handle a safeguarding concern.” Each is a bounded, repeatable operational activity.
Work instructions: the atomic “how” of a single step
A work instruction is the smallest unit of documented procedure. It covers a single step, or a small group of tightly-related steps, in enough detail that someone can perform it correctly the first time.
Work instructions have a narrower shape.
- Audience. The person performing the specific step, at the moment they are performing it.
- Trigger. Mid-task. A work instruction is read while the work is happening, often on a phone, often on a shop floor or at a customer site.
- Content. A short description, often with a photo or a short video clip, that shows exactly how to do that one thing.
- Update cadence. Whenever the method changes. Equipment replacement, new tool, change to preferred technique - same-day update ideally.
- Consequence if outdated. Immediate quality or safety impact on the next person who follows it.
A work instruction might live inside an SOP as one of its numbered steps, or stand alone as an atomic how-to - “how to reset the till,” “how to decant cleaning fluid,” “how to stage a delivery on shelf 4.”
The important thing is that a work instruction does one thing and explains it concretely. A work instruction called “customer service” is not a work instruction; it is an aspiration.
Why muddling them causes chaos
Three problems compound when these three document types live in the same folder with the same labels.
The audit mismatch. Auditors typically ask for policies (statements of commitment) and evidence (records of execution). They do not usually want to read a step-by-step of how you close the kitchen. If your policies are actually procedures, you end up handing over the wrong document and having to explain what they are really looking for.
The operational mismatch. Operational staff need to do the task now, in the next three minutes, on the phone in their pocket. They do not need a fifteen-page PDF that opens with a statement of values. They need the five steps, in order, with the photo proof button. If your SOPs are actually policies, your team stops opening them.
The update mismatch. The three document types have different update triggers. Policies change when the law or strategy changes. SOPs change when the process changes. Work instructions change when the method changes. Mixing them means every review cycle either touches too much or too little, and things rot unevenly.
A decision matrix
When you are sitting in front of a blank document and wondering which of the three it should be, three questions settle it.
- Who will read this, and when?An external auditor reviewing annually → policy. An operational team member about to do a task → SOP. A staff member mid-step, needing to know exactly how → work instruction.
- What outcome does the document produce?Adherence to a standard → policy. Completion of a procedure → SOP. Correct execution of a specific action → work instruction.
- What breaks if this is outdated?A compliance or reputational gap → policy. Variable quality or safety across a process → SOP. An immediate error on the next attempt → work instruction.
If you answer those three questions before you write, the document writes itself to the right shape. If you answer them after, you end up with the “customer onboarding policy” that is actually a procedure.
What a clean documentation system looks like
The practical test is simple. A visitor to your documentation system should be able to answer three questions inside a minute:
- Where are the policies, and what does this organisation stand for?
- Where are the SOPs, and how are the main processes executed?
- Where are the work instructions, and how is a specific step performed in practice?
If the answer is “they are all in the Drive folder somewhere, you just have to search,” the three document types have collapsed into one amorphous pile, and the work of separating them is overdue.
The separation is not cosmetic. It is the difference between a team that can execute, prove execution, and explain its commitments - and a team that can do none of the three, because every document is trying to be all three at once. Browse the template library for examples of each document type done well.