SOP, policy, process, work instruction
Four words used interchangeably in most companies, describing four different documents with four different jobs. Mixing them is the commonest reason a document is unusable.
The four words teams use interchangeably, what each one actually is, and why mixing them produces documents nobody can follow.
Policy — the rule, and who decided it
A policy states a position. It says what the organisation will and will not do, and it is short. “Expenses over a set threshold require approval before they are committed” is a policy. It contains no steps, names no software, and does not tell anyone how to get approval.
A policy is written by whoever has the authority to set the rule, and it changes rarely. If your policy needs updating because a tool changed, it was not a policy — it was a work instruction with a policy heading on it.
Process — the shape of the work, end to end
A process describes how work moves: the stages, the order, who hands what to whom. It spans roles and often spans departments. Purchasing is a process; it starts with a need and ends with a paid invoice, and it passes through several pairs of hands on the way.
A process document answers “what happens, in what order, and who is involved”. It deliberately does not answer “which buttons”. Its readers are people trying to understand or improve the flow, not people executing a step today.
This is the document most teams skip, and skipping it is why their SOPs contradict each other — nobody agreed the shape before writing the details.
SOP — one procedure, performed the same way every time
A standard operating procedure covers a single repeatable procedure, performed by a defined role, with a defined trigger and a defined finished state. It sits inside a process. Purchasing is the process; “raising a purchase request” is an SOP within it.
The test for whether something is an SOP: can one person, in one role, complete it from beginning to end? If completing it requires three different people at three different times, you are describing a process and it will read badly as an SOP.
The SOP is where the detail lives — the steps, the checks, the exceptions, what to do when it goes wrong. It is the document this site is mostly built around.
Work instruction — the keystrokes
A work instruction is the narrowest of the four: exactly how to perform one task in one system. Screens, fields, the order of clicks. “Entering a supplier record” is a work instruction.
It is the most volatile document you will hold, because it dies the moment the software changes its interface. That is the argument for keeping work instructions out of your SOPs rather than embedded in them — a vendor redesign should force one small document to be rewritten, not fifteen large ones.
What goes wrong when they are mixed
The commonest failure is a single document trying to be all four. It opens with the rule, drifts into the end-to-end flow, then into the steps, then into screenshots. It is long, it is out of date within a quarter, and nobody reads it — because the person who needed step four had to scroll past the policy and the flow diagram to reach it.
The second failure is a policy written as an SOP. It names a tool and a person, so it has to be revised every time either changes, and each revision needs the approval a policy change requires. The rule underneath never changed at all.
The third is an SOP written as a process. It spans four roles, so no single person can be held to it, and it quietly becomes nobody’s responsibility.
How to tell which one you are writing
Ask what would make the document wrong. If a change of position by management would make it wrong, it is a policy. If reorganising who does what would make it wrong, it is a process. If a change in how the task is performed would make it wrong, it is an SOP. If a software update would make it wrong, it is a work instruction.
Then ask who reads it and when. A policy is read once and referred to in disputes. A process is read when someone is trying to understand or change the flow. An SOP is read while doing the thing. A work instruction is read with one hand on the mouse.
Two documents with different answers to those questions should be two documents, even when they cover the same subject and it feels wasteful to split them.
Once you know which one you are writing, the method for writing an SOP covers the structure, and the blank template is the starting point. If the document you need is the end-to-end flow rather than one procedure, the process documentation template is the right one.
Editor's notes
Written by Free Biz Docs about the document above — not reader submissions.
The four-way split is a working taxonomy, not a standard
Policy, process, SOP, work instruction is a division that earns its keep, and it is not defined this way anywhere authoritative. Organisations use these words differently, several management-system schemes use a different vocabulary again, and plenty of sound documentation collapses two of the four.
So the value of the piece is not the labels. It is the observation that four different kinds of statement have four different revision rhythms, and that a document mixing them has to be revised at the pace of its most volatile part.
"What would make this wrong" is the only test that travels
Everything else in the post depends on agreeing to the vocabulary. That test does not: whatever your organisation calls the document, asking which kind of change would falsify it tells you how often it needs revising and who has to approve that.
If you take one thing from the page and discard the taxonomy entirely, take that question.
Splitting a document has a cost and the post names it
"Even when it feels wasteful to split them" concedes the real objection rather than talking past it. Two documents mean two things to keep current, two things to find, and two chances for one to go stale while the other does not.
The trade is that a combined document goes stale as a whole. Which is worse depends on how often each half actually changes — and for a very small team the answer sometimes genuinely favours one document.
These documents are starting structures for you to build on, not professional or legal advice. Anything that will have legal or contractual effect, or that varies by jurisdiction, should be reviewed by someone qualified in the relevant place.
Common questions
- What is the difference between a policy and an SOP?
- A policy states a position — what the organisation will and will not do — and contains no steps. An SOP covers one repeatable procedure performed by a defined role, with a trigger and a finished state. If your policy needs updating because a tool changed, it was not a policy.
- What is the difference between a process and an SOP?
- A process describes how work moves end to end, across roles and often across departments. An SOP is one procedure inside it. The test: if completing it needs three different people at three different times, you are describing a process and it will read badly as an SOP.
- Is a work instruction the same as an SOP?
- No. A work instruction is the narrowest document — exactly how to perform one task in one system, down to the fields and the order of clicks. It is also the most volatile, which is the argument for keeping work instructions out of your SOPs rather than embedded in them.
- How do I tell which document I am writing?
- Ask what would make it wrong. A change of position by management means it is a policy. Reorganising who does what means it is a process. A change in how the task is performed means it is an SOP. A software update means it is a work instruction.
- What happens if I combine them into one document?
- You get the commonest failure: a document that opens with the rule, drifts into the flow, then the steps, then screenshots. It is long, stale within a quarter, and unread — because the person who needed step four had to scroll past the policy to reach it.