How to Write an SOP
A standard operating procedure people can actually follow — and an inspector can trust.
What a how-to is not
A how-to is SPEQ’s practitioner method, not a procedure. It does not replace your own SOP, it is not a validated approach, and the judgement calls in it belong to your quality unit.
A standard operating procedure documents how a task is done consistently and correctly. The best SOPs describe what actually happens (and should happen), in language the person doing the job can follow under pressure. The worst are aspirational fiction no one uses — which is exactly what an inspector finds when practice and procedure diverge.
- 1
Define the scope and purpose
State what the SOP covers, what it does not, and why it exists. A tight scope keeps the procedure usable; a vague one produces a document that tries to cover everything and helps no one.
- 2
Observe the actual process
Watch the task being done (go to the gemba). Write from what actually happens, reconciled with what should happen — not from an idealised flow that no one follows.
- 3
Write for the person doing the job
Use clear, sequential, actionable steps and unambiguous language. If a step can be misread, it will be. Include the decision points and what to do when things do not go to plan.
- 4
Define roles and responsibilities
Say who does what, who verifies, and who approves. Ambiguity about responsibility is where procedures fail in practice.
- 5
Review and approve
Have the SOP reviewed by someone who does the job and approved through your document-control process. The reviewer who performs the task catches the steps a writer misses.
- 6
Train before it takes effect
An SOP is not in force until the people who use it are trained on it. Train first, then make it effective — releasing an untrained SOP guarantees a practice-versus-procedure gap.
- 7
Control the version
Manage the SOP under document control — unique identifier, version, effective date, and a single source of truth. Uncontrolled copies are how the floor ends up running last year’s procedure.
- !Writing what should happen rather than what does — creating a gap between practice and procedure.
- !Making the SOP effective before anyone is trained on it.
- !Uncontrolled printed copies circulating alongside the controlled version.
- !Steps written for the author, not the operator — ambiguous, non-sequential, or missing the "what if" paths.
How to Write an SOP: frequently asked questions
Common questions on write an sop.
What makes an SOP inspection-ready?
It describes what actually happens, is written so the person doing the job can follow it, is controlled (identifier, version, effective date), and everyone who uses it is trained on the current version. The fastest way to a finding is a gap between the SOP and observed practice.
Who should write and review an SOP?
The writer should understand the task; the reviewer should include someone who actually performs it, because they catch the steps a desk-writer misses. Approval goes through your document-control process. Writing an SOP in isolation from the floor is the classic error.
When does an SOP become effective?
Only after it is approved through document control and the people who use it are trained on it. Training before the effective date is what prevents a practice-versus-procedure gap the moment the SOP goes live.
How do you keep SOPs from drifting from practice?
Write from observed practice, train on every revision, periodically review SOPs against what the floor actually does, and make revision easy enough that people update the SOP instead of working around it. Drift is a document-control and culture problem, not a formatting one.