A standard operating procedure (SOP) is a written document that prescribes the exact steps to perform a recurring task so the outcome is the same regardless of who performs it. The defining feature is repeatability. Two trained people follow the SOP independently and should produce the same result. SOPs exist where consistency matters more than individual judgment. Pharmaceutical manufacturing under FDA 21 CFR Part 211 is one such place. ISO 9001 quality systems are another. So are OSHA-regulated hazardous operations and the change-management runbooks behind every production deployment at a serious software company.
That is the definition. Three questions matter more. When does an SOP actually create value? How does it differ from the four other documents people confuse it with? Why have most SOPs in circulation decayed to the point that operators ignore them? This guide answers them from a working documentation professional's perspective. That person writes SOPs, maintains them, and explains to auditors why the binder version does not match the intranet version.
What a standard operating procedure actually is
The phrase "standard operating procedure" carries four loaded words. Each excludes a category of document sometimes mistakenly called an SOP.
Standard means the procedure is the agreed default for the task. There may be exceptions, but those exceptions are themselves documented. An ad-hoc method one team uses is not standard.
Operating means the document describes what people do, not what the organization believes or aspires to. Mission statements and values are not operating documents.
Procedure means an ordered sequence of actions with defined inputs, outputs, and decision points. A bulleted list of best practices with no order is not a procedure.
A working SOP combines all four properties. It is the agreed default, written for the people who do the task. It is structured as an ordered procedure with controlled inputs and outputs. And it is owned by someone responsible for keeping it current.
The US Environmental Protection Agency's guidance document on SOPs defines them as "a set of written instructions that document a routine or repetitive activity followed by an organization." That definition is correct but incomplete. The structural elements make an SOP auditable. A fixed metadata header, numbered steps, role-based responsibilities, a revision history — these separate an SOP from a how-to article. We cover each below.
SOP vs work instruction vs policy vs process map
These four terms are routinely used interchangeably and routinely cause confusion in audits. They describe different documents with different audiences and different lifecycles.
| Document | Scope | Audience | Length | Lifecycle |
|---|---|---|---|---|
| Policy | What the organization requires and why | Everyone affected | 1 to 3 pages | Reviewed yearly, changes are governance events |
| SOP | How a defined process is performed | Trained operators | 2 to 8 pages | Reviewed every 12 to 24 months |
| Work instruction | Granular steps for a single task | Person performing the task | 1 to 3 pages | Reviewed on equipment or method change |
| Process map | Visual overview of a workflow | Anyone who needs orientation | 1 page | Updated when process structure changes |
A policy declares the rule. An SOP describes the procedure that implements the rule. A work instruction details a single task inside that procedure. A process map shows how the whole thing fits together visually.
A concrete example. A medical device company has a policy that all returned products must be evaluated before destruction or refurbishment. The SOP titled "Returned Product Evaluation" describes the end-to-end procedure: receipt, quarantine, documentation, evaluation, disposition, and disposal. Inside that SOP, the step "Decontaminate the returned item according to WI-3001" references a separate work instruction that lists the exact sterilization parameters. A process map on the wall shows the flow of the returned product through the building. Each document has a job. None of them can replace the others.
The most common mistake: writing a work instruction and calling it an SOP. The document ends up too detailed for the people who need to understand the procedure. It also ends up too narrow to be a controlled record of how the process actually runs. The second most common mistake: writing a policy and calling it an SOP. The document ends up vague about who does what and under what trigger. That makes it useless for training, and unauditable.
Where SOPs are legally required
In multiple industries, an SOP is not optional. Knowing which regulatory regime applies matters. It determines what the SOP must contain and how frequently it must be reviewed.
Pharmaceutical manufacturing. FDA 21 CFR Part 211 (Current Good Manufacturing Practice for Finished Pharmaceuticals) requires written procedures across nearly every operation. Section 211.100 requires written procedures for production and process control. Section 211.160 requires written procedures for laboratory controls. Section 211.180 requires written records of every production, control, and distribution activity. Failure to have current written procedures is one of the most common findings in FDA Form 483 observations.
Quality management. ISO 9001:2015 clause 7.5 covers documented information. The 2015 revision moved away from prescribing specific documents. The old standard required a quality manual and six mandatory procedures. Instead, the 2015 version requires the organization to determine what documented information its quality management system actually needs. Clause 7.5.3 requires that documented information be controlled, reviewed for continued suitability, and approved before use. In practice, this means SOPs covering the core processes any external auditor would expect.
Workplace safety. OSHA 29 CFR 1910.119 (Process Safety Management of Highly Hazardous Chemicals) requires written operating procedures for any process involving listed chemicals above threshold quantities. OSHA 29 CFR 1910.147 (Lockout/Tagout) requires written procedures for controlling hazardous energy during servicing and maintenance. OSHA 29 CFR 1910.1200 (Hazard Communication) requires a written hazard communication program. Each of these regulations specifies what the written procedure must contain.
Information security. ISO 27001:2022 Annex A controls reference documented procedures for incident response, access control, change management, and supplier management. SOC 2 audits inspect written procedures for change management, logical access, and incident response as part of the Trust Services Criteria.
Outside these regulated contexts, an SOP is a best practice, not a legal requirement. Whether to write one comes down to consistency, training cost, and audit defensibility, not compliance.
Anatomy of a good SOP
A working SOP has two layers: a fixed metadata block at the top and seven canonical body sections. The metadata block is what makes the document controllable. The body is what makes it executable.
Metadata header. SOP number, title, version, effective date, document owner, approver, and review date. This block goes on every page. Without it, you have a procedure. With it, you have a controlled document that an auditor can trace.
Purpose. One or two sentences explaining what outcome the procedure achieves and why the procedure exists. Read only the Purpose, and you should know whether this is the right document for your question.
Scope. Which roles, sites, equipment, conditions, and product lines the SOP applies to. The Scope explicitly lists what the procedure does not cover. Scope statements that try to apply universally are a warning sign. They usually mean the author never thought about boundaries.
Responsibilities. Roles, not individuals. "Quality Control Inspector" not "Sarah Chen." Roles are stable; individuals turn over. List who performs, who supervises, and who approves each part of the procedure.
Materials and equipment. Every input the operator needs before starting: consumables, tools, software access, PPE, calibration records. The inventory exists for one reason. It stops the operator from starting the procedure and discovering, halfway through, that something is missing.
Procedure. Numbered steps. Each step contains one action verb and one observable outcome. Decision points get explicit branching ("If reading is below 7.2, go to step 12. If reading is at or above 7.2, go to step 15"). Bullets lose ordering information; numbered steps preserve it.
Safety and compliance. Warnings, regulatory references, and required protective equipment in a dedicated section, not buried inside steps. When safety information is mixed into procedural steps, readers skim it. When it is broken out, it can be acknowledged and signed off separately.
Revision history. A change log table with version, date, author, and a one-line summary of changes. This is the section auditors check first. It tells them whether the document has been maintained, or written once and abandoned.
The SOP template guide walks through each of these sections with a downloadable format example.
When SOPs become shelfware
An SOP that nobody reads is worse than no SOP, because it creates a false impression that the procedure is controlled when it is not. Four failure modes account for most shelfware.
No review cycle. An SOP written once and never revisited will drift from actual practice as equipment changes, regulations update, and people invent workarounds. Most quality systems require review every 12 to 24 months. The teams that actually maintain their SOPs trigger review on change events — new equipment, regulatory updates, audit findings. They do not wait for the calendar.
Format mismatch with the audience. A 14-page PDF SOP for a forklift safety procedure is unreadable to the person operating the forklift. The format has to match the consumption context. Shop-floor procedures need to fit on a laminated card or a single screen. Office-based procedures can be longer. The format decision matters more than the content.
Document length that exceeds attention. A focused SOP runs 2 to 8 pages. Beyond that, the document is trying to be a training manual, a reference document, and a procedure at the same time. Split it. The parent SOP describes the process. Linked work instructions describe the granular steps.
Drift between document and practice. The SOP says to "log into System A and approve the request." The team migrated to System B six months ago. The SOP is now fiction. Operators learn to ignore the document and ask a senior colleague how things actually work. The institutional knowledge that should live in the SOP lives in someone's head instead. It leaves when they do.
The honest assessment: an SOP with no documented review in 18 to 24 months has typically decayed past usefulness. The question is whether the organization has noticed.
How documentation teams manage SOPs at scale
A team with 6 SOPs can keep them in Word documents on a shared drive. A team with 50 SOPs across 4 departments and 3 sites cannot. Three problems compound past a certain volume.
Role-based variation. The same procedure executed by a senior operator, a junior operator, and a contractor typically needs three different levels of detail. Maintaining three separate Word documents means three places to update when the procedure changes. The inevitable result: one of them ends up wrong.
Shared content blocks. A standard safety warning, a glossary entry, or a regulatory reference routinely appears in 20 SOPs. Say the regulation changes. The warning has to change with it. Updating it by hand in 20 documents is how SOPs become inconsistent. The right model is to write the block once and reference it everywhere it appears.
Version control and audit trail. An auditor asking "what version of SOP-014 was in effect on March 12, 2025" is asking a question Word documents cannot answer reliably. Version history that lives in filename suffixes (SOP-014-v3-FINAL-FINAL.docx) does not survive contact with a serious audit.
These three problems are the case for a component content management system. It is a tool that stores content as reusable topics and components. It applies conditional content rules for role-based variation, and maintains a versioned audit trail. The architectural shift from documents to structured topics is what we covered in structured authoring without the XML.
In Topicary, a procedure is a topic. Shared safety warnings are components inserted by reference. When the warning changes, every SOP using it updates. Role-specific variations are handled by conditional content tags rather than separate documents. Each published SOP is a named version snapshot tied to a specific point in time. An auditor might ask what was in effect on a specific date. The answer is one click, not a search through file shares. The SME review feature gives operators a token-based link to validate the procedure, no login needed. That removes the friction that usually keeps SMEs from reviewing on schedule. The structural argument for the model lives in why we built Topicary.
The structured-authoring model is overhead. For fewer than 20 SOPs maintained by a single person for a single audience, Word and a shared drive are the correct answer. The decision point is usually the moment you find yourself maintaining the same paragraph in 6 different documents.
What to do next
If you are starting from zero, write your first SOP with the seven canonical sections and a metadata header. Do not try to template every procedure at once. The format will earn its place as you scale.
If you already have a stack of SOPs, the most useful diagnostic is simple. Pull a random sample of 10 and check three things. When was each one last reviewed? Does the described procedure match how the work actually happens? Can you produce the version that was in effect 18 months ago? The gaps between those answers and the answers you would want to give an auditor are your maintenance backlog.
Future articles in this cluster will cover three things. Real templates for manufacturing, IT, and food service. A step-by-step guide for writing your first SOP. And a comparison of tools that go beyond Word.
Frequently asked questions
What is a SOP in simple terms?
A standard operating procedure is a written document that prescribes the exact steps to perform a recurring task so the outcome is the same regardless of who performs it. SOPs exist where consistency matters more than individual judgment, such as pharmaceutical manufacturing, food safety, IT change management, and any process subject to audit. The defining feature is that two trained people following the SOP independently should produce the same result.
What is the difference between an SOP and a work instruction?
An SOP describes the full procedure end to end, including its purpose, scope, roles, and trigger conditions. A work instruction covers a single task in granular detail with no surrounding context. An SOP for handling a returned medical device might run 6 pages and reference 4 separate work instructions for the actual sterilization, inspection, repackaging, and labeling steps. The SOP is the auditable wrapper; the work instructions are the executable detail.
Are SOPs legally required?
SOPs are legally required in multiple regulated contexts. FDA 21 CFR Part 211 requires written procedures for pharmaceutical manufacturing. OSHA 29 CFR 1910.119 requires them for processes involving highly hazardous chemicals. ISO 9001:2015 clause 7.5 requires documented information for any process whose absence would compromise the quality management system. Outside regulation, SOPs are best practice, not legal requirement.
Why do most SOPs become shelfware?
SOPs become shelfware for four reasons: no scheduled review cycle, format mismatch with the people executing the task, document length that exceeds attention span, and drift between written procedure and actual practice. An SOP with no recorded review in 18 to 24 months has typically decayed to fiction. ISO 9001:2015 clause 7.5.3 specifically requires documented information to be reviewed for continued suitability.
Who should write an SOP?
The subject matter expert supplies the procedure content; the document is owned by a technical writer, quality manager, or process owner. The split exists because SMEs know what should happen but rarely have time to maintain controlled documents, while writers can structure and version a document but cannot invent the procedure. For SOPs in regulated industries, a named approver who is not the author is required for sign-off.
How long should an SOP be?
It depends on the task. A focused SOP runs 2 to 8 pages. Routine procedures may fit in 1 to 3 pages. Multi-system processes can legitimately reach 15 pages, but at that length the document should be split into a parent SOP and linked work instructions. Length is determined by the task complexity and the audience's familiarity with it, not by a target page count. The test is whether a trained but unfamiliar operator can complete the task without asking a clarifying question.
Sources
- ISO 9001:2015 — Quality management systems — Requirements, International Organization for Standardization, 2015
- 21 CFR Part 211 — Current Good Manufacturing Practice for Finished Pharmaceuticals, US Food and Drug Administration, 2024
- 29 CFR 1910.119 — Process safety management of highly hazardous chemicals, US Occupational Safety and Health Administration, 2024
- 29 CFR 1910.147 — The control of hazardous energy (lockout/tagout), US Occupational Safety and Health Administration, 2024
- Guidance for Preparing Standard Operating Procedures (SOPs), US Environmental Protection Agency, 2007