Most standard operating procedures get read twice: once by the auditor, and once by the quality manager who wrote them. That is not a joke - it is the normal state of affairs in many companies, and the real reason QM documentation has a bad reputation internally.
Yet a good SOP is one of the most useful documents a company can have: it answers the question "How do we actually do this here - and whose job is it?" before anyone has to ask. This guide shows you how to write a standard operating procedure that does both: pass the audit and actually help in day-to-day business.
What is a standard operating procedure?
A standard operating procedure (SOP) is a binding description of how a specific procedure runs in your company: which steps happen in what order, who is responsible for what, which documents and systems are involved, and what applies when something deviates.
Typical examples from mid-sized manufacturers:
- Complaint handling: from the customer call to the 8D response
- Incoming goods inspection: from delivery to release or blocking
- Document control: how new instructions are created, reviewed, and distributed
- Handling nonconforming products: labeling, quarantine stock, disposition
SOPs are the backbone of QM documentation under ISO 9001. Since the 2015 revision, the standard hardly prescribes specific documented procedures anymore - it requires "documented information" wherever it is necessary for the effectiveness of the management system. In practice, that means you decide for yourself which workflows need an SOP. You decide for yourself - and you must be able to justify that decision in the audit.
SOP vs. work instruction: the three-level model
The terms get mixed up all the time. The easiest way to keep them straight is three levels, from coarse to fine:
Level 1 - Process: The big picture. "Order fulfillment" is a process: from quote to invoice, cutting across several departments. It is usually described as a process map or flowchart in the QM manual.
Level 2 - Procedure: A bounded workflow within a process, often cross-departmental. "Complaint handling" is a procedure within the order fulfillment process. This is where the SOP lives: it describes the what, who, and when - but not every single hand movement.
Level 3 - Work step: The concrete task at one workstation. "Setting the blocking flag in the ERP" or "calibrating gauge XY" belongs in a work instruction (WI). It describes the how, in detail: click paths, machine settings, inspection steps - precise enough that a trained employee can work from it.
The rule of thumb: The SOP says that goods get blocked when they deviate and who makes that call. The WI says which fields to fill in the system to do it.
Get this separation wrong and you end up with SOPs running to 20 pages of click-by-click instructions - outdated with every ERP update - or work instructions that suddenly settle questions of responsibility nobody would ever look for there.
The standard structure of an SOP
There is no normatively prescribed structure, but one framework has proven itself across industries. It consists of six sections:
1. Purpose
One or two sentences: Why does this procedure exist, what is it meant to ensure? Example: "This SOP governs the handling of customer complaints with the goal of systematically eliminating root causes and responding to the customer within defined deadlines."
2. Scope
Who and what does the document apply to - and what explicitly not? "Applies to all customer complaints in series production at the Lüdenscheid site. Complaints in project business are governed by SOP-07-12." The exclusion is often more important than the inclusion list, because it prevents disputes over responsibility.
3. Terms and abbreviations
Only if needed. If "8D", "blocked stock", or "NCR" mean different things to different people in your company, clarify them here. If not: leave it out.
4. Responsibilities
Who triggers, who executes, who decides, who gets informed? The clearest format is a small table of roles - not names. "Ms. Berger" will change jobs at some point; "Head of Quality Assurance" stays. A RACI logic (responsible, accountable, consulted, informed) helps, but is not a must.
5. Process description
The centerpiece. Two representations have proven themselves: a flowchart for the overview plus a numbered step table with the columns Step - Who - What - Tool/Evidence. Example excerpt for complaint handling:
| No. | Who | What | Evidence |
|---|---|---|---|
| 1 | Sales | Log the complaint; customer receives confirmation of receipt within 24 h | Complaint number in the ERP |
| 2 | QA | Identify and block affected stock | Blocking flag |
| 3 | QA + Production | Root cause analysis, define containment action | 8D report, step D3 |
| 4 | Head of QA | Approve corrective action | Signature/approval in the system |
Important: include the decision points and special cases. What happens when the customer demands an answer within 48 hours but the root cause analysis takes two weeks? That is exactly where procedures fail in everyday use - not on the standard case.
6. Related documents
Forms, checklists, work instructions, standards the SOP references - with document numbers, not just titles. Add a header or footer block with version number, creation date, approval, and change history. Without it, the document cannot be controlled.
Practical tips: how the SOP gets read instead of filed away
Write how the work is done - not how it is audited
The most common mistake: the SOP describes an ideal flow that never actually existed. On paper, incoming inspection checks every delivery against the inspection plan; on the shop floor, the warehouse operator has been waving the A-supplier through for years, because that was agreed at some point - verbally, three plant managers ago. The result is a document that gets shown at the audit and ignored afterwards. Worse still: when a real nonconformity occurs, nobody knows what actually applies.
If the lived practice is good, document the practice. If it is bad, fix the practice first - and document afterwards. An SOP is not a wish list.
Ask the people who do the work
The quality manager knows the procedure from a process perspective. What he does not know are the special cases: that the customer Meier always wants special packaging, that the labeling system crashes on batches over 999 pieces, that the night shift handles release differently because no QA staff is in the building then. These details decide whether the SOP holds up when it matters.
In practice, that means: before writing, spend 30 minutes talking to each role involved. Not "What should the workflow look like?" but "What exactly did you do last time? And when did it go differently?" The second question is where the gold is.
Short, concrete, active
- One procedure per SOP. "Purchasing and supplier evaluation" is two documents.
- Active sentences with a clear subject: "QA blocks the stock" instead of "The stock is to be blocked."
- Target length: three to five pages. Anything longer usually needs to be split up or moved down to work-instruction level.
- No prose about quality policy. That is what the manual is for.
Test the document
Give the draft to someone who knows the procedure but was not involved in writing it - and have them say out loud where they stumble. Ten minutes that deliver more than any document template.
The maintenance part: why SOPs go stale after the audit
The life cycle of many SOPs looks like this: before the certification audit, they get created or overhauled in one big push. Then, for three years - nothing. The ERP gets replaced, two key people leave, a new product is added, and the SOP still describes the state as of audit day. At the next audit, the big push starts all over again.
The problem is structural: responsibility for keeping the document current formally sits with the process owner - in practice, with nobody. Changes to the workflow get discussed and implemented in the team, but the path back into the document has no trigger.
Three countermeasures that work:
- Define change triggers: Every change to a system, responsibility, or workflow triggers a document review. Make it a fixed item on the checklist for ERP migrations, staffing changes, and new products - not a judgment call.
- Reviews with a date and a name: Every SOP gets a review date (e.g., annually) and a named process owner listed in the document. A review is allowed to take five minutes and end with "no changes" - but it takes place.
- Regularly ask the people doing the work, not just check the documents: The fastest staleness indicator is the gap between document and practice. Talk to the people involved every few months and you will find that gap before the auditor does.
Points two and three are exactly where AI-supported tools now come in. At wissa.ai, an AI conducts structured interviews with the employees who run the procedure every day - 15 to 20 minutes per person, via chat, no workshop needed. The result is the raw draft of the process description: who does what, in what order, with which systems - including the special cases and exceptions that appear in no QM manual because nobody ever wrote them down. Contradictions between statements from different employees are flagged with their source instead of silently smoothed over - precisely the spots where an SOP would otherwise write past reality. And because the documentation updates after every interview and shows changes as a diff against the previous version, the three-year push turns into ongoing maintenance. The final editorial pass and the approval stay with QM - but the most laborious part, gathering the lived practice, is done.
Conclusion
A good SOP is short, describes the lived practice including special cases, names responsibilities as roles, and has a clear maintenance mechanism. The structure - purpose, scope, responsibilities, process, related documents - is quickly learned. The real work is in the listening: the best SOPs are written not by the person with the best prose, but by the person who asked the right people.
If you want to shortcut that part: wissa.ai interviews your knowledge holders and delivers the raw draft of your procedure documentation - traceable down to the individual statement, GDPR-compliant on EU servers. Join the beta waitlist.
FAQ
Are SOPs mandatory under ISO 9001?
No. ISO 9001:2015 no longer prescribes specific documented procedures; it requires "documented information" where it is necessary for the effectiveness of the QM system. You decide for yourself which workflows need an SOP - but you must be able to justify that decision in the audit. Rule of thumb: wherever mistakes are expensive, several departments are involved, or knowledge depends on individual people.
What is the difference between an SOP and a work instruction?
The SOP describes a workflow at the middle level: who does what and when, often across departments. The work instruction describes a single task in detail: concrete hand movements, system steps, inspection criteria at one workstation. Mnemonic: the SOP defines that stock gets blocked and who decides - the WI defines how to execute the block in the system.
How long should an SOP be?
Three to five pages is a good target range. If the document gets much longer, it usually mixes two procedures or contains detail steps that belong at work-instruction level. Brevity is not an end in itself, but a long document never gets opened in daily work - and thereby misses its purpose.
Who should write the SOP?
Formally, the process owner is responsible, often supported by the quality manager. But the content has to come from the people doing the work: they know the actual flow and the special cases. A proven division of roles: the practitioners provide the content (via interviews or tools like wissa.ai), QM structures and writes, the process owner approves.
How often does an SOP need to be updated?
There is no normative interval. What works is a combination: a fixed annual review by the process owner plus an event-driven check on every change to systems, responsibilities, or workflows. What matters is that both have a named owner and a trigger - otherwise the document quietly goes stale until the next audit.