How to Write a Standard Operating Procedure: Format, Steps, and a Simple Template
You know the task works when the person who usually does it is in the room. The trouble starts when they're on vacation, a new hire takes over, or an auditor asks how the task is done. A standard operating procedure fixes that. It turns one person's know-how into instructions anyone on the team can follow the same way, every time.
This guide covers what an SOP is, which sections it needs, how to write steps people can follow, and how to keep the document current once it's approved.
What is a standard operating procedure?
A standard operating procedure (SOP) is a set of written, step-by-step instructions for a routine task that an organization repeats. Its purpose is to make the work consistent, so the result is the same whoever does it.
The U.S. Environmental Protection Agency's guidance on preparing SOPs lists the main benefits. A good SOP reduces variation even when staff change. It supports training, reduces miscommunication, and can address safety concerns. It also shows auditors that you meet your own and regulatory requirements. Inspectors often use SOPs as checklists during audits.
The same guidance adds a warning: even the best-written SOP fails if people don't follow it. It also fails if they can't find the current copy where they do the work.
SOP vs. policy vs. checklist
These documents are easy to mix up, so it helps to separate them early:
- A policy says what the organization requires and why.
- A standard operating procedure says how to carry out a specific, repeated task, step by step.
- A checklist confirms that the steps were done, in order. In the EPA's words, "the checklist is not the SOP, but a part of the SOP." Attach checklists to the SOP and reference them at the step where they're used.
Before you write: decide what needs an SOP
Not every task needs a formal procedure. Start by agreeing on how your team decides what gets documented. Good candidates usually have one or more of these traits:
- The task is repeated often, or by many different people.
- Mistakes are costly, unsafe, or hard to undo.
- The task is audited or regulated.
- Only one or two people currently know how to do it.
Then pick the right author. SOPs should be written by people who actually do the work. When a process spans several roles, write it as a team. That brings in everyone's experience and builds buy-in from the people who will use the procedure.
Standard operating procedure format: the sections to include
There is no single "correct" SOP format. Structure varies by organization and by type of procedure. Most well-built SOPs still share the same core sections, and you can drop any that don't apply. Here is a simple SOP template based on the EPA's general format:
- Title page / header. A clear title, an SOP ID number, the revision number and date, the team or department it applies to, and who prepared and approved it.
- Purpose. One or two sentences on why the procedure exists, including any regulation or standard it supports.
- Scope. What the procedure covers, when it applies, and any limits on its use.
- Definitions. Acronyms, abbreviations, and specialized terms.
- Roles and responsibilities. Who performs each part, and any training or qualifications they need.
- Materials, tools, or systems. Equipment, software, forms, and access needed before starting.
- Safety warnings and cautions. Anything that could cause injury, damage, or invalid results. List them here and again at the step where they apply.
- Procedure. The numbered steps, in order.
- Quality checks. How the person confirms the work was done correctly, and what to do if it wasn't.
- Records. Which forms to fill in, what to record, and where files are stored.
- References and attachments. Related SOPs, checklists, and forms.
- Revision history. What changed, when, and who approved it.
A table of contents is optional for short SOPs. It helps with long ones, especially when you want to show which sections changed in a revision.
How to write an SOP: 7 steps
1. Walk through the task with the person who does it
Watch the task being done, or do it yourself while taking notes. Capture the real sequence, including the small checks experienced staff do without thinking. Those are the steps a newcomer misses.
2. Write for someone new to the task
The EPA sets a useful bar for detail. A person with a basic understanding but limited experience of the procedure should be able to complete it successfully without supervision. If a step depends on prior training, say so in the roles section instead of explaining the basics inside every step.
3. Use short, active, imperative steps
Write each step as a direct instruction: "Close the ticket," not "The ticket should be closed." Federal plain-language guidance explains why: active voice makes it clear who should do what and removes ambiguity about responsibilities. The EPA's SOP guidance makes the same point. Write in a concise, step-by-step, easy-to-read format, in active voice and present tense.
A few rules that keep steps clear:
- One action per step. If a step contains "and then," split it.
- Put conditions first: "If the total exceeds the limit, escalate to the finance lead."
- Name the exact screen, field, or form, not "the system."
- Cut words that don't change what the reader does.
4. Choose the right format for each part
Simple linear tasks work well as a numbered list. Tasks with many sub-steps need a hierarchical list (1, 1.1, 1.2). Use a flowchart wherever the process branches on a decision. The EPA guidance recommends flowcharts and diagrams to break up long text and summarize a series of steps. Add screenshots or photos where seeing the target saves words.
5. Test the draft with someone who didn't write it
Before you approve a draft, hand it to someone who hasn't done the task and watch them follow it. Note every hesitation, wrong turn, and question. The EPA calls this especially helpful: draft SOPs should be tested by people other than the original writer. Plain-language practice suggests the same thing. Test early, then revise and test again. For short procedures, ask testers to explain each step back in their own words. For longer ones, watch them use it to complete the real task.
6. Review and approve it formally
Have the SOP reviewed by at least one person with experience of the process, then approved by whoever owns it. Often that is the direct supervisor plus a quality or compliance lead. Signature approval, electronic or on paper, shows that management reviewed and approved the procedure. That record matters in an audit.
7. Publish it where the work happens
Make the current version easy to find from the place the task is done. If people have to dig through shared drives, they'll fall back on memory or an old printout. The SOP then stops doing its job.
SOP document control: keep only one current version
An SOP is only useful if everyone is following the same version. That's the job of document control:
- Number every SOP. Use a consistent ID scheme, and show the short title, ID, revision number, date, and page count ("Page 2 of 6") on each page so anyone can confirm it's complete and current.
- Keep a master list. Track each SOP's number, version, issue date, title, author, owner, and status in one place.
- Retire old versions. Archive superseded versions so they can't be used by mistake, but keep them available for audits and historical review.
- Protect against unauthorized edits. Give readers read-only access and limit edit rights to authors and approvers.
How often should SOPs be reviewed?
Update an SOP and get it re-approved whenever the process changes. Don't wait for the scheduled review. Beyond that, review each SOP on a fixed cycle. The EPA's guidance suggests every one to two years as an example. A review confirms the procedure is still accurate and still needed. Record the review date on the SOP, and withdraw and archive any SOP that describes a process you no longer follow.
Keep the review process light. If reviewing is slow and painful, people put it off, and the SOP drifts out of date.
Keeping SOPs current without the busywork
Most of the effort in a standard operating procedure comes after the first draft: routing it for approval, tracking revisions, and making sure people see the latest version. A documentation platform can take on much of that work.
Sonat is built for this. Your team can draft SOPs in Google Docs or the Sonat editor and send them through approval workflows before they go live. Every past version stays on record, and readers always get the current SOP in one searchable place. Viewers are free and unlimited, so you can share procedures with the whole organization without counting seats.
Conclusion
A strong standard operating procedure isn't a long document. It's a clear one. Write it with the people who do the work, structure it with a consistent template, and phrase every step as one short, active instruction. Test it on someone new before you approve it. Then use document control to make sure there's only ever one current version, and review it on a schedule. Do that, and the task gets done the same way whoever does it.