Standard Operating Procedure Template

What is a Standard Operating Procedure?

A standard operating procedure is the written method for a task that must be done the same way every time: numbered steps, the person responsible for each, and a date when it will be checked again. It matters because undocumented procedure lives in one person's head. When they are on leave, the task is done differently, and the difference shows up as a defect, a fine or a customer complaint.

SOPs are written wherever consistency has a consequence: laboratories, manufacturing lines, pharmacies, food production, clinical settings, finance teams running a month-end close, support desks handling escalations, and any business preparing for certification. The author should be the person who does the job, edited by someone who does not — the practitioner supplies the reality, the outsider catches the steps that were assumed rather than written. The audience is a competent new starter on their first unsupervised run, which is the standard the level of detail should be pitched to.

Where SOPs are regulated, the format is not yours to choose. Pharmaceutical and medical device manufacturers work under good manufacturing practice rules that dictate approval, distribution, training records and periodic review, enforced by the regulator for each market — the FDA in the US, the EMA and national authorities in the EU, the MHRA in the UK, CDSCO in India, the TGA in Australia. Food businesses work to HACCP-based systems. ISO management standards require documented information under their own clause wording. Find out which framework governs your document before designing the header.

An SOP describes how, not why or whether. Policy decides that expenses over a stated value need two approvals; the SOP explains how to route them. Keeping the two apart means you can change the approval limit without rewriting the procedure. An SOP is also not training — reading a document is not competence, and for anything with a safety or regulatory consequence the record you need is that the person was trained and assessed. And an SOP that describes an ideal nobody follows is worse than none, because it documents a gap between what you say you do and what you do.

What to put in a Standard Operating Procedure

These are the details this template asks for. Anything left blank is marked in red on the preview so you can see what is still missing.

How to write a Standard Operating Procedure

1. Fix the scope and the trigger

   One line on what this procedure covers, one on what it does not, and one on what starts it: a returned goods notification arrives, the last day of the month, a temperature alarm sounds. Procedures without a trigger get skipped because nobody knows when they apply. Procedures without a boundary grow until they cover three jobs badly.

2. Write numbered steps in the doing order

   One action per step, starting with a verb, in the order a person performs them. Number them so a colleague can say the problem is at step 7. Where a step branches, say so explicitly: if the reading is above 8.2, go to step 12. Put anything needed before starting — equipment, access, forms, materials — in a list ahead of step 1.

3. Name the role responsible for each step

   Put the role, not the person, against every step or group of steps: shift supervisor, QA technician, accounts payable clerk. Roles survive staff changes. Where a step needs a second person to verify, say so and say what they are verifying, since two signatures on an unclear check produce two people who each assumed the other looked properly.

4. Show what good and bad look like

   Give the acceptance criterion in numbers where you can: seal temperature 180 to 190 degrees, pH between 6.8 and 7.2, invoice matched to order and goods received note. Then say what to do when it is out of range — stop, quarantine, escalate to whom. A procedure that only describes the happy path fails on the first bad day.

5. Version it, approve it, set a review date

   The header carries document number, version, author, approver, effective date and review date. Approval should come from the person accountable for the outcome, not the author. Then withdraw the superseded version everywhere it lives — printed copies at the workstation are how old procedures survive. Record who was trained on the new version and when.

Common mistakes

• Writing the procedure from a manager's memory rather than watching the job done, which produces steps that skip the workarounds people actually rely on.
• Leaving out what to do when a check fails, so the operator improvises at the exact moment consistency matters most.
• Naming individuals instead of roles, which makes the document wrong the day someone changes job and leaves nobody clearly accountable.
• Failing to withdraw superseded printed copies, so two versions run side by side and the audit trail shows work done to a procedure you had retired.
• Bundling policy, procedure and training material into one document, so every change to an approval limit triggers a full re-approval and re-training cycle.

Frequently asked questions

This page explains general practice and is not legal advice. Requirements differ between countries and, in some cases, between states — check what applies where the document will be used.

Related templates

All templates · Operations templates