Writing a Standard Operating Procedure: Structure, Example, Practical Tips

Many standard operating procedures are written ahead of an audit and afterwards read mostly by the quality team. Yet a good SOP can be one of the most useful documents a company has, because it answers the question "How do we 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: it serves its purpose in the audit and helps the team in day-to-day work.

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 carry the QM documentation under ISO 9001. Since the 2015 revision, the standard hardly prescribes specific documented procedures anymore and instead requires "documented information" wherever it is necessary for the effectiveness of the management system. In practice, you decide for yourself which workflows need an SOP, and you explain that decision in the audit.

SOP vs. work instruction: the three-level model

The two terms sit close together. The easiest way to keep them apart is three levels, from coarse to fine:

Level 1 - Process: The big picture. "Order fulfillment" is a process that runs from quote to invoice across several departments. It is usually described as a process map or flowchart in the QM manual. How to document at this level is covered in the process documentation guide.

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 and leaves the individual hand movements to the next level.

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, meaning click paths, machine settings, and inspection steps, precisely 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.

When you keep these levels apart, the SOP stays lean and survives an ERP update, because the click-by-click instructions live in the work instruction. In turn, every question of responsibility has its place in the SOP, where people will look for it.

The standard structure of an SOP

The standard does not prescribe a structure, but a framework of six sections has proven itself across industries:

1. Purpose

One or two sentences on why this procedure exists and what it is 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

This section states who and what the document applies to and what it explicitly excludes. "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 helpful than the inclusion list, because it draws clear lines of responsibility.

3. Terms and abbreviations

You only need this section if terms like "8D", "blocked stock", or "NCR" mean different things to different people in your company. Then you clarify them here, otherwise you leave it out.

4. Responsibilities

Who triggers, who executes, who decides, who gets informed? The clearest format is a small table of roles rather than names. "Ms. Berger" will change jobs at some point, while "Head of Quality Assurance" stays. A RACI matrix (responsible, accountable, consulted, informed) helps with sorting this out, but is not a must.

5. Process description

The process description is the centerpiece of the SOP. Two representations work well together: a flowchart or swimlane diagram for the overview and a numbered step table with the columns Step - Who - What - Tool/Evidence. Example excerpt for complaint handling:

Include the decision points and special cases as well. What happens, for example, when the customer asks for an answer within 48 hours but the root cause analysis takes two weeks? The standard case usually runs on its own, and spots like this show whether a procedure holds up in daily work.

6. Related documents

This section lists the forms, checklists, work instructions, and standards the SOP references, each with document number and title. Add a header or footer block with version number, creation date, approval, and change history so the document can be controlled.

Practical tips: how the SOP gets read instead of filed away

Write down how the work is actually done

An SOP helps when it describes the flow people actually follow. An example: on paper, incoming inspection checks every delivery against the inspection plan, while on the shop floor the warehouse operator has been waving the A-supplier through for years, because that was agreed verbally at some point, three plant managers ago. As long as both versions exist side by side, nobody is sure what applies when a real nonconformity occurs.

If the lived practice is good, document the practice. If it should be improved, change the workflow first and then document it, so the SOP describes the way the team works today.

Ask the people who do the work

The quality manager knows the procedure from a process perspective. The special cases are known to the colleagues who run it every day: 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. With these details, the SOP holds up when it matters.

In practice, that means spending about 30 minutes with each role involved before you write. Ask concretely: "What exactly did you do last time? And when did it go differently?" The second question in particular brings the exceptions to light. Which method suits which situation, whether interview, workshop, or observation, is compared in the guide on as-is process mapping.

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.
• Statements on quality policy belong in the quality manual, and the SOP stays with the workflow.

Test the document

Give the draft to someone who knows the procedure but was not involved in writing it, and ask them to say out loud where they stumble. These ten minutes quickly show you which passages can become clearer.

The maintenance part: keeping the SOP current after the audit

Many SOPs are created or overhauled in one big push before the certification audit and then often stay unchanged until the next recertification, which can be up to three years. In that time the ERP may get replaced, two key people leave, a new product is added, and the SOP still describes the state as of audit day.

This comes down to structure: responsibility for updates formally sits with the process owner, and changes to the workflow get discussed and implemented in the team. What is often missing is a trigger that carries the change back into the document.

Three habits keep the SOP current:

1. Define change triggers: Every change to a system, responsibility, or workflow triggers a document review. This review is a fixed item on the checklist for ERP migrations, staffing changes, and new products.
2. 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 may take five minutes and end with "no changes", as long as it takes place.
3. Regularly ask the people doing the work: Alongside the document review, talking to the people involved is the quickest way to see where document and practice drift apart. Check in every few months and you will find these spots early and can update them calmly.

Point three is where AI process documentation comes in. At wissa.ai, an AI conducts structured interviews with the employees who run the procedure every day, in conversations of around 15 to 20 minutes via chat, whenever it suits them. The result is process documentation that serves as a raw draft for the process description: who does what, in what order, with which systems, including the special cases and exceptions that so far exist only in the heads of the people involved. Where different employees describe a step differently, wissa flags the spot with its source, so QM can follow up exactly there. The documentation updates after every interview and shows changes as a diff against the previous version, which turns the big push before the audit into ongoing maintenance. The final editorial pass, the check against the requirements of the standard and the approval stay with QM, while wissa gathers the lived practice.

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 of purpose, scope, responsibilities, process, and related documents is quickly learned. Most of the work lies in listening, and the best SOPs come from someone who asked the people who carry the procedure every day.

If you would like to take on that part together with us: wissa.ai interviews your knowledge holders and delivers a raw draft for your procedure documentation, traceable down to the individual statement, hosted in Germany, with AI processing in the EU. A free trial package (10 credits, once per company, terms) usually covers a first interview, and you can start right away. Try one interview for free

FAQ

Are SOPs mandatory under ISO 9001?

No. ISO 9001:2015 no longer prescribes specific documented procedures and requires "documented information" where it is necessary for the effectiveness of the QM system. You decide for yourself which workflows need an SOP and explain 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. People like to open a short SOP in daily work, and that is exactly what it is for.

Who should write the SOP?

Formally, the process owner is responsible, often supported by the quality manager. The content is best sourced from the people doing the work, because they know the actual flow and the special cases. This division of roles has proven itself: the practitioners provide the content (via interviews or with 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. A combination works well: a fixed annual review by the process owner plus an event-driven check on every change to systems, responsibilities, or workflows. When both have a named owner and a trigger, the document stays current between audits.

Sources

• ISO 9001:2015, clause 4.4 (Quality management system and its processes) and clause 7.5 (Documented information)