A standard operating procedure is a promise the organization makes to itself. It says: this is how we do this thing, every time, regardless of who does it. When SOPs work, they produce consistency across shifts, geographies, and staff turnover. When SOPs fail, they sit in binders that no one opens, stored in wikis that no one maintains, while the actual work gets done by whoever was trained last year and remembers parts of the process.
The difference between SOPs that people actually follow and SOPs that gather dust is rarely the writer's intelligence. It is a set of disciplines about scope, voice, and maintenance. A good SOP is short enough to read, specific enough to execute, and maintained often enough to still be true. A bad SOP is long enough to intimidate, vague enough to argue about, and stale enough that the team already ignores it.
This guide walks through the structure, the language, and the templates that produce SOPs teams actually use.
What SOPs Are For
Standard operating procedures serve four distinct purposes, and strong SOPs do all of them without noise.
Consistency. Any trained team member should be able to follow the SOP and produce the same outcome as any other trained team member.
Training. A new hire reading the SOP should understand not just what to do but why it matters.
Compliance and audit. In regulated industries, the SOP is evidence that a controlled process exists. External auditors read SOPs as part of their assessment.
Institutional memory. When the person who knew how to do this thing leaves or retires, the SOP is what the organization has left.
Different SOPs may emphasize different purposes. A safety SOP emphasizes consistency and compliance. A customer onboarding SOP emphasizes consistency and training. A disaster recovery SOP emphasizes institutional memory above all. The writer should know which purpose dominates before choosing the structure.
The Core Structure
Most effective SOPs share a common structure. The exact format varies by industry, but the components do not.
Part 1: Header. Title, document ID, version, effective date, last reviewed date, owner.
Part 2: Purpose. One to two sentences on what this SOP exists to accomplish.
Part 3: Scope. Who this SOP applies to, when it applies, when it does not apply.
Part 4: Definitions. Any terms that readers might not know, defined briefly.
Part 5: Responsibilities. Who does what. Often presented as a RACI or similar table.
Part 6: Procedure. The step-by-step instructions. The core of the SOP.
Part 7: References. Related SOPs, policies, regulatory citations, and supporting documents.
Part 8: Revision history. Who changed what, when, and why.
SOPs that skip any of these components usually show the gap. An SOP without a revision history leaves readers unsure which version is current. An SOP without responsibilities produces disagreements about ownership. An SOP without a scope statement invites misapplication.
Template 1: Standard SOP Format
Use this for most operational procedures in corporate, technical, or service contexts.
# [SOP Title]
**Document ID:** [Code]
**Version:** [Number]
**Effective date:** [Date]
**Last reviewed:** [Date]
**Next review due:** [Date]
**Owner:** [Name, role]
**Approver:** [Name, role]
## 1. Purpose
[One to two sentences on what this procedure exists to accomplish. Example: "This SOP describes the process for onboarding a new customer into the production environment, ensuring consistent setup and compliance with data protection requirements."]
## 2. Scope
This SOP applies to: [specific teams, roles, or situations].
This SOP does not apply to: [explicit exclusions].
This SOP is used when: [specific triggering event or condition].
## 3. Definitions
| Term | Definition |
|---|---|
| [Term 1] | [Brief definition] |
| [Term 2] | [Brief definition] |
| [Term 3] | [Brief definition] |
## 4. Responsibilities
| Role | Responsibility |
|---|---|
| [Role 1] | [Specific responsibility in this procedure] |
| [Role 2] | [Specific responsibility in this procedure] |
| [Role 3] | [Specific responsibility in this procedure] |
## 5. Procedure
### 5.1 [Step name]
1. [Action, one step, imperative voice]
2. [Action]
3. [Action]
Expected outcome: [What should be true after this step]
### 5.2 [Step name]
1. [Action]
2. [Action]
Expected outcome: [What should be true after this step]
### 5.3 [Step name]
1. [Action]
2. [Action]
Expected outcome: [What should be true after this step]
## 6. Exceptions and escalations
- If [condition X] occurs, [specific action and escalation].
- If [condition Y] occurs, [specific action and escalation].
- For issues not covered by this SOP, escalate to [specific role or team].
## 7. Records
The following records are produced by this procedure and retained for [duration]:
- [Record 1] stored in [location]
- [Record 2] stored in [location]
## 8. References
- [Related SOP 1]
- [Policy document]
- [Regulatory citation, if applicable]
## 9. Revision history
| Version | Date | Changed by | Summary of change |
|---|---|---|---|
| 1.0 | [Date] | [Name] | Initial release |
| 1.1 | [Date] | [Name] | [Summary of change] |
| 2.0 | [Date] | [Name] | [Summary of change] |
This template works across a wide range of SOPs because it separates the durable parts (purpose, scope, responsibilities) from the operational parts (procedure, exceptions) and from the change-tracking parts (references, revision history).
Template 2: Simple Task-Based SOP
Use this for shorter SOPs on specific tasks where the full formal structure would be excessive.
# How to [task name]
**Owner:** [Role]
**Last updated:** [Date]
**Time to complete:** [Estimate]
## When to use this
[One sentence on the trigger or situation.]
## What you need
- [Tool or access 1]
- [Tool or access 2]
- [Information input]
## Steps
1. [Action in imperative voice]
2. [Action]
3. [Action]
4. [Action]
## Check your work
Before closing, confirm:
- [ ] [Verification 1]
- [ ] [Verification 2]
- [ ] [Verification 3]
## If something goes wrong
- If [problem A], [action].
- If [problem B], [action].
- For anything else, reach out to [specific role or Slack channel].
A task-based SOP is often 200 to 400 words. It does not try to be a complete regulatory document. It tries to be a fast reference that someone can follow without interrupting the person who knows. For internal tools, common support tasks, and recurring routine work, this format is often more useful than the formal SOP structure.
The Right Level of Detail
The most common SOP failure is the wrong level of detail. Too much detail makes the SOP unreadable and brittle. Too little detail leaves judgment calls that produce inconsistency.
A useful test: imagine the person most likely to use this SOP and identify three details. What do they already know and do not need explained? What do they not know and need explained? What varies between instances in a way the SOP should acknowledge?
| Detail Category | Treatment |
|---|---|
| Things the reader already knows from training | Do not re-explain; reference training material |
| Things the reader will not know the first time | Explain in steps; consider a screenshot or example |
| Things that vary by context | Name the variation and provide guidance |
| Edge cases that rarely come up | Put in exceptions section, not the main flow |
| Tool-specific UI details that change often | Reference tool documentation, do not screenshot |
| Compliance-critical steps | Call out explicitly, including why they matter |
| Safety-critical steps | Call out with explicit warnings |
SOPs that explain every detail, including things every reader already knows, are skimmed and lose credibility. SOPs that assume readers know what they do not know produce errors. Balancing these requires knowing the reader.
"Instructions are written for the person you cannot talk to. If you could talk to them, you would give them the context and the specifics. The SOP is the next best thing to that conversation." William Zinsser, On Writing Well
Language Patterns That Work
SOP language should be direct, specific, and imperative. The reader is following instructions, not reading an essay.
| Weaker Phrasing | Stronger Phrasing |
|---|---|
| The operator should ensure that | Check that |
| It is important to | [Just state the step] |
| One must be careful when | Warning: [specific risk]. Do [specific action]. |
| Generally speaking, it is advisable to | Always [specific action] |
| After a period of time | After [specific duration] |
| A number of | [Specific number] |
| Attempt to | [Just state the action] |
| In the event that | If |
| At this time | Now |
| Utilize | Use |
Imperative voice is the default for SOP steps. "Click Submit" is clearer than "The user should click Submit." Passive constructions like "The form is then submitted" obscure who does what.
Numbers should be specific. "Wait 5 minutes" is better than "wait a short time." "Temperature between 18 and 22 degrees Celsius" is better than "room temperature." SOPs are where precision matters.
Visual Elements in SOPs
Text-only SOPs are harder to follow than SOPs that use visual elements appropriately. But visuals add maintenance burden: every screenshot is a potential source of staleness when the underlying tool changes.
| Visual Element | When to Use | When to Avoid |
|---|---|---|
| Flowchart | Decision-heavy processes with branching | Simple linear procedures |
| Screenshot | Rare critical steps where UI confusion is likely | Every step; UI changes break them |
| Diagram | System relationships, physical layouts | Information that is clearer as text |
| Table | Comparisons, role assignments, thresholds | Narrative explanations |
| Checklist | Verification steps, readiness checks | Main procedural flow |
| Photo | Physical equipment setup | Anything that might change cosmetically |
| Video link | Complex physical tasks | Everything; videos are hard to update |
When in doubt, prefer text. Text is faster to edit when the process changes. Screenshots that are three versions out of date are worse than no screenshots at all.
Responsibility Assignment
SOPs that do not clearly assign responsibility produce disputes. A common convention is a RACI chart for each major step.
- R: Responsible. The person who does the work.
- A: Accountable. The single person ultimately answerable for the outcome.
- C: Consulted. People whose input is needed.
- I: Informed. People who need to know the outcome.
A RACI per SOP is often excessive. A simpler "responsibilities" table at the top, and a named actor in each procedural step, is usually enough. The discipline is to avoid writing "the team" or "someone" when a specific role would be clearer.
"If an SOP does not tell me who does each step, it is describing a process that no one will be held responsible for. That is not an SOP. That is a wish." Josh Bernoff, Writing Without Bullshit
Version Control and Revision
SOPs that are not actively maintained become unreliable. The failure mode is familiar: an SOP is written, circulated, and filed. Over the next year, the process evolves. The SOP does not. Six months later, new hires are trained on the SOP, experienced staff work from memory, and the two groups produce different outcomes.
Strong SOP practice includes scheduled review at least annually, mandatory updates when the underlying process changes, named ownership for each SOP, and a clear revision process.
| Revision Trigger | Expected Response |
|---|---|
| Underlying process changes | Update SOP within 30 days, notify users |
| Tool changes materially | Update SOP with new screenshots or references |
| Regulatory change | Update SOP before the effective date |
| Incident or near-miss | Review whether SOP was followed; update if gap found |
| Annual review date | Verify accuracy, refresh even if no changes |
| New role or team takes on the work | Update ownership; refresh from their perspective |
Version numbers should follow a clear convention. Major versions (1.0, 2.0) for significant changes. Minor versions (1.1, 1.2) for smaller updates. Every change logged in the revision history with who, when, and why.
Storage and Access
SOPs that are hard to find are functionally absent. A clear storage discipline improves SOP usage dramatically.
Common storage approaches and tradeoffs:
| Approach | Strength | Weakness |
|---|---|---|
| Centralized document management system | Single source, controlled access, audit trail | Requires discipline, can be slow |
| Wiki | Fast to edit, easy to cross-link | Can lose structure without governance |
| Shared drive with naming convention | Familiar, simple | Hard to search, version confusion |
| Printed binder in physical workplace | Always accessible on the floor | Gets outdated quickly |
| In-tool help text | Contextual to the task | Limited space, hard to maintain |
| Training system | Tied to onboarding | May not be searchable after training |
For regulated environments, a centralized document management system with audit trails is often required. For less regulated contexts, a well-governed wiki with clear ownership can work. The key is that everyone knows where to look.
The documentation patterns discussed at When Notes Fly on living documents and the export workflows at File Converter Free for producing PDF versions of SOPs support a hybrid approach: editable source of truth with stable PDF exports for audit retention.
Common Failure Modes
Failure: The SOP is too long. A 30-page SOP for a routine task is ignored. Fix: break into smaller SOPs, or cut the procedure to its essential steps.
Failure: The SOP is too abstract. It describes principles rather than actions. Fix: rewrite as numbered steps in imperative voice.
Failure: The SOP is written by someone who does not do the task. Steps are missing or out of order. Fix: have the person who does the task draft or at least review the SOP.
Failure: The SOP has never been tested. Fix: have someone unfamiliar with the task follow the SOP exactly and flag everywhere they had to guess.
Failure: The SOP has no revision history. Readers do not know if they have the current version. Fix: enforce a revision history and display the version prominently.
Failure: The SOP conflicts with another SOP. Two documents disagree about who does what. Fix: consolidate or explicitly reference and resolve the conflict.
Failure: The SOP uses the passive voice. No one knows who does what. Fix: rewrite in active voice with a named actor per step.
Writing SOPs for Complex Processes
Long, complex processes are harder to capture in a single SOP. Several patterns help.
Break into phases. A software release SOP might have separate SOPs for planning, preparation, execution, and post-release. Each SOP is shorter and more focused.
Hierarchy of SOPs. A top-level SOP describes the overall process and references specific sub-SOPs for each phase. Readers can navigate to the level of detail they need.
Runbooks for specific scenarios. A runbook is an SOP variant optimized for time-pressured execution. It is often shorter, more checklist-like, and assumes high reader familiarity.
Playbooks for judgment-heavy work. A playbook is an SOP variant that acknowledges judgment is required. It provides frameworks, criteria, and examples rather than strict step-by-step rules.
Matching the format to the work is part of the craft. A judgment-heavy process forced into a strict SOP produces rules that get broken, and documents that lose credibility.
"The best procedures are the shortest ones that still give the reader what they need. Every additional sentence is friction. Every missing detail is risk." Ann Handley, Everybody Writes
SOPs in Regulated Industries
In pharmaceutical, medical device, aviation, food service, financial services, and similar industries, SOPs are regulatory requirements, not optional operational documents. The standards are higher and the consequences of failure are larger.
Common regulatory requirements include: formal approval before use, documented training for all staff expected to follow the SOP, audit trail of revisions, retention of superseded versions for specified periods, and periodic review even when no changes are made.
Writers of SOPs in regulated environments often follow a house template tied to the regulatory framework (21 CFR Part 11, ISO 13485, FDA 21 CFR 820, and others). These templates are usually mandatory and cover structure, approval, and retention.
The operations and compliance guidance at Corpy covers how SOP requirements vary across jurisdictions for multi-country operations, and the cognitive research on instructional clarity at What's Your IQ reinforces why clear, short, imperative SOPs outperform long, hedged ones even in regulated settings.
Building an SOP Program
Organizations where SOPs are consistently used and maintained share a few traits. A named owner exists for every SOP. An annual review cycle is enforced. Changes to underlying processes trigger mandatory SOP updates before rollout. Training on SOPs is tracked. A library of SOPs is searchable and kept current.
Organizations where SOPs are consistently ignored share different traits. SOPs are written during audits and not updated afterward. Ownership is unclear or assigned to someone who left. Changes happen in the field without corresponding document updates. New hires are trained by shadowing, not by reading.
The most efficient improvement for most organizations is to designate SOP owners, schedule annual reviews, and make SOP updates a required part of process changes. Within a few quarters, the gap between documented process and actual practice tends to close.
For related guidance on business documentation, see our articles on how to write effective meeting minutes and how to write performance review comments that help.
References
Zinsser, W. (2006). On Writing Well. Harper Perennial.
Bernoff, J. (2016). Writing Without Bullshit. Harper Business.
Handley, A. (2014). Everybody Writes. Wiley.
ISO 9001:2015. Quality Management Systems. https://www.iso.org/standard/62085.html
FDA 21 CFR Part 820. Quality System Regulation. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
Society for Technical Communication. Documentation Best Practices. https://www.stc.org/
Harvard Business Review. The Right Way to Build Processes. https://hbr.org/topic/subject/operations-management
Project Management Institute. Process Documentation Guide. https://www.pmi.org/learning/library
Frequently Asked Questions
How long should a standard operating procedure be?
Most effective SOPs are two to six pages for typical operational procedures, shorter for simple tasks, longer for complex regulated processes. Length should match the complexity of the task. A 30-page SOP for a routine task will be ignored. Break long SOPs into phases or sub-SOPs if needed.
What is the difference between an SOP and a work instruction?
An SOP describes what needs to happen and who is responsible, at a level useful for consistency, training, and audit. A work instruction goes deeper into how to perform a specific step. Some organizations use both: SOPs for overall processes, work instructions for specific tasks within them.
How often should SOPs be reviewed?
At least annually, and always when the underlying process, tool, or regulation changes. An SOP that has not been reviewed in two years is rarely still accurate. Schedule reviews formally and track them, as audit and compliance programs typically require documented periodic review.
Who should write an SOP?
The person who does the work, usually in partnership with a quality or operations owner. Writers who have never done the task miss steps, get the order wrong, or use terminology the practitioners do not use. The final draft should be tested by someone unfamiliar with the task following it exactly.
Should SOPs include screenshots?
Sparingly. Screenshots add clarity for specific confusing steps but add maintenance burden: every UI change breaks them. Use screenshots only where the risk of misinterpretation is high. For most procedures, clear text and a tool reference is more maintainable than screenshot-heavy documentation.
What is the best format for an SOP?
A standard format includes header, purpose, scope, definitions, responsibilities, procedure, exceptions, references, and revision history. Procedural steps should be numbered, in imperative voice, with a named actor where relevant. Tables work well for responsibilities and definitions. Flowcharts help with decision-heavy processes.
How do I make sure people actually follow the SOP?
Three disciplines matter most: keep it short enough to read, keep it current with the actual process, and make it easy to find. Teams ignore SOPs that are stale, buried, or too long to be practical. Quarterly reviews, named owners, and a searchable library tend to drive compliance more than enforcement alone.