Your only release engineer gave notice. She wrote four pages describing the deploy sequence. Three weeks later someone followed it, missed a buried step, and took production down for forty minutes.
Your senior release engineer gave notice on a Monday. She was the only person who knew the full production deploy sequence, including the two manual steps that are not in the runbook and the one service that has to be restarted in a specific order or the migration hangs. You have eleven working days.
So you ask her to write it down. She produces four pages of dense prose describing what she does. Three weeks after she leaves, someone follows it, misses a step that was buried in a subordinate clause, and takes production down for forty minutes.
The document existed. It was not an SOP. That distinction is the entire subject of this guide.
A standard operating procedure is a document that lets a competent person who has not done a task before perform it correctly, in the right order, without asking anyone.
Read that definition again, because every practical rule that follows is derived from it. Not "documents how we do things." Not "captures institutional knowledge." An SOP is judged by whether someone can execute from it successfully. If they cannot, it is documentation, which is a different and less useful artifact.
This standard is unforgiving and it is the reason most SOPs fail. Prose describing a process is not the same as instructions for performing it. The engineer above wrote an accurate description. It was not executable.
Three consequences follow immediately:
The reader is a competent stranger. They have the relevant baseline skills but no context on your specific setup. Write for them, not for the person who already knows.
Ambiguity is a defect. "Verify the service is healthy" is ambiguous. "Confirm the /health endpoint returns 200 and queue depth is under 500" is not. If two competent people could reasonably do different things from the same sentence, that sentence is broken.
Order is content. A list of steps in the wrong order is wrong, even if every step is individually correct.
These four terms get used interchangeably in most organizations and the confusion is expensive, because it means people write the wrong document for the need.
A policy states what must be true and why. "All production changes require approval from a second engineer." It is a rule. It does not tell you how to get approval.
A process describes the flow of work across people and functions at a high level. "Change request is raised, reviewed by the release board, scheduled, deployed, verified." It shows the shape and the handoffs. It is usually best drawn rather than written.
An SOP covers one bounded task performed by one role, start to finish, in enough detail to execute. "How to deploy a hotfix to production." It sits inside a process, at one of the boxes.
A work instruction is the most granular layer, covering a single operation, often at the level of specific tool interactions. "How to roll back a migration in the admin console." A complex SOP step frequently points to a work instruction.
The hierarchy runs policy, process, SOP, work instruction, from broadest to narrowest. The most common mistake is writing something at process altitude and calling it an SOP. It reads fine and is useless at 2am, because it tells you the shape of the work and not the actions.
The second most common mistake is the opposite: burying a policy decision inside a procedural step. If a step says "get approval if the change is risky," you have hidden a judgment call inside an instruction. Either define risky precisely or move the decision to a policy and reference it.
There is no single mandated format outside regulated industries, where your quality system dictates one. Absent that constraint, the following structure works because each element earns its place.
Header block. Title, unique identifier, version number, effective date, next review date, owner, approver. This is metadata and it is what makes an SOP library governable rather than a folder of documents of unknown vintage.
Purpose. One or two sentences. What this procedure accomplishes and why it exists. If you cannot write this without hedging, the scope is wrong.
Scope. When this SOP applies and, critically, when it does not. Explicit exclusions prevent the most common misuse, which is applying a procedure to a situation it was never designed for.
Roles and responsibilities. Who performs, who approves, who is informed. Name roles, never individuals. Individuals leave.
Prerequisites. Access, permissions, tools, materials, and conditions required before starting. This section is routinely omitted and is the number one cause of a procedure stalling halfway through, when someone discovers at step 9 that they do not have the credential step 9 requires.
Procedure. The numbered steps. This is the document.
Verification. How the performer confirms the task succeeded. Without this, "done" means "I performed the steps," which is not the same as "the outcome was achieved."
Exceptions and escalation. What to do when reality departs from the happy path, and who to contact. An SOP with no failure branch sends people to Slack the first time anything is unusual, which is precisely when you least want improvisation.
Related documents. Links to the parent process, referenced work instructions, and applicable policies.
Revision history. What changed, when, and why. The "why" column is the one people skip and the one that has value in two years.
1. Watch the task being performed. Do not interview. Interviewing produces the idealized version, because experts compress and omit the parts that have become automatic. Observe someone doing it and note every action, including the ones they do not mention. The gap between the described process and the observed process is where the outages live.
2. Fix the boundaries before writing a word. Where does this procedure start and where does it end. Vague boundaries produce SOPs that sprawl into adjacent work and become too long to use. A good boundary is a clean handoff or a state change.
3. Draft the steps as commands. Imperative mood, one action per step, active voice. "Open the deployment dashboard." Not "The deployment dashboard should then be opened by the engineer." The passive construction hides who acts, and who acts is the most important information in a procedure.
4. Add decision points explicitly. When a step branches, make the condition and both paths visible. "If queue depth exceeds 500, go to step 12. Otherwise continue to step 8." Never leave the branch implied.
5. Insert verification after consequential steps. Not after every step, which produces noise. After the ones where silent failure would be discovered late and painfully.
6. Add screenshots or diagrams only where words are genuinely worse. Visuals help for interface navigation and physical tasks. They also go stale faster than text and are harder to maintain, so use them deliberately rather than by default.
7. Test it with someone who has never done the task. This is the step that separates SOPs that work from SOPs that exist. Hand it to a competent stranger, watch them execute, and do not help. Every question they ask is a defect in your document. Fix the document, not the person.
8. Have the task owner review for accuracy, then the tester review for clarity. These are different reviews and combining them means one of them does not happen properly.
9. Approve, version, publish, and calendar the review date. An SOP without a review date is a future liability, because it will be wrong eventually and nothing will surface that fact.
One action per step. If a step contains "and," look hard at whether it should be two steps. Compound steps get half-completed.
Start every step with a verb. Open. Run. Confirm. Select. Notify. This is a formatting rule that turns out to be a thinking rule, because a step that will not start with a verb usually is not a step.
Be specific about objects. "The report" is ambiguous. "The weekly reconciliation report in Finance/Monthly Close" is not.
Quantify anything quantifiable. Replace "wait a moment" with "wait 30 seconds." Replace "a large file" with "a file over 50MB." Replace "high error rate" with a number.
Never use "simply," "just," or "obviously." They add nothing, they age badly, and they signal to a struggling reader that they are the problem.
Keep it to one screen where possible. If the procedure runs past two pages, ask whether it is really two procedures. Long SOPs get skimmed, and skimming a procedure defeats its purpose.
Write the failure path. Most SOPs document success only. The failure path is where the reader most needs guidance, because that is the moment they are least equipped to improvise.
Written by the expert, for the expert. The person who knows the task best is usually the worst person to write it alone, because their knowledge is compressed. Pair them with someone who does not know the task and let the gap surface.
Description masquerading as instruction. "The team reviews submissions weekly and escalates anomalies" describes. It does not instruct. Nobody can execute from it.
No owner. An SOP without a named owning role is nobody's job to update, and it will not be updated.
Stale and still authoritative. The worst state for an SOP is being wrong while still looking official. It is more dangerous than having no SOP, because people follow it. Every SOP needs a review date, and an overdue one should be visibly flagged rather than quietly trusted.
Stored where nobody looks. An excellent SOP in a folder three levels deep in a drive nobody browses is functionally nonexistent. Findability is not a nice-to-have, it is a condition of the document working at all.
Too many SOPs. Organizations that go hard on documentation often produce hundreds of procedures nobody can navigate. A smaller, well-maintained set beats a comprehensive stale one, every time.
An SOP that changes without control is not standard, which removes the entire point.
Version everything. Major version for changes that alter what someone does. Minor version for clarifications that do not change the actions. Anyone reading should be able to tell at a glance whether the procedure has materially changed since they last performed it.
Require approval proportional to risk. A formatting fix does not need the same sign-off as a change to a safety-critical step. Uniform approval requirements produce either bottlenecks or rubber stamping, usually both.
Set review cadence by volatility, not by calendar convention. Annual review is a default, not a principle. A procedure touching a system that ships weekly needs review more often. One covering a stable physical process may not.
Trigger review on change, not only on schedule. When the underlying tool, system, or regulation changes, the SOP review should be part of that change, not discovered nine months later during an audit.
Record why, not just what. A revision history saying "updated step 7" is nearly worthless. "Updated step 7 after the March incident, where the previous wait time was insufficient under load" is the sentence that stops someone reverting your fix.
The storage decision determines whether the library survives its first year.
Requirements that matter: full-text search that actually works, visible version and review status on every document, a clear owner field, controlled edit rights with open read access, and links between related procedures that do not break when things move.
Shared drives fail on version visibility and on links. Wikis do well on search and editing and poorly on approval control and version discipline, since anyone can change anything and the notion of an approved version blurs. Purpose-built process tools handle the workflow well and vary widely on whether the documents themselves are pleasant to write and read.
If your SOPs are simple, standalone, and rarely cross-referenced, most options work. If they are interlinked, if steps in one procedure depend on definitions in another, or if changing one document should surface the effect on five others, the structural properties of the tool start to matter a great deal. That is the same problem contracts have, and it has the same solution: documents that understand their own structure rather than being formatted text that looks structured.
Worth reading alongside this: our collection of SOP examples by team for concrete starting points, and SOP software for engineering teams if you are evaluating tooling. If you want to map where your current process leaks before choosing anything, the document workflow generator is a fast way to do it, and the template library has formats you can start from.
An SOP covers a complete bounded task performed by one role, from start to finish, such as onboarding a new vendor or deploying a hotfix. A work instruction covers a single granular operation inside that task, often specific to one tool, such as how to add a vendor record in the ERP. SOPs answer "how do I accomplish this task." Work instructions answer "how do I perform this specific operation." In practice, a well-scoped SOP references work instructions rather than inlining every tool interaction, which keeps the SOP readable and lets the work instruction be updated when the tool's interface changes without reopening the whole procedure.
As short as it can be while still being executable by someone who has not done the task. That is usually one to three pages and ten to thirty steps. If you are past that, the most likely explanation is that the scope covers more than one task and should be split. Length is a symptom rather than a problem in itself, but long SOPs get skimmed and a skimmed procedure is not being followed, so treat length as a signal that something upstream needs fixing.
Ideally a pair: the person who performs the task, for accuracy, and someone who does not, for clarity. The performer alone writes something correct and unusable, because expertise compresses and omits. A technical writer alone writes something readable and subtly wrong. The pairing catches both failure modes. Whoever writes it, the owning role should be a role rather than a person, so the maintenance obligation survives turnover.
Set the cadence by how fast the underlying reality changes rather than by a uniform annual default. Procedures touching frequently updated software may need quarterly review. Stable physical or administrative processes may be fine annually or longer. More important than the cadence is triggering review on change: when the tool, system, regulation, or org structure the SOP depends on changes, the review should happen as part of that change rather than waiting for the calendar.
Outside regulated industries there is no single mandated format. The widely used structure is header metadata, purpose, scope, roles, prerequisites, numbered procedure, verification, exceptions and escalation, related documents, and revision history. In regulated environments such as pharmaceutical manufacturing or clinical research, your quality management system will specify a format and you should follow it exactly rather than improving on it, because format compliance is itself auditable.
Use them where words are genuinely worse, which is mainly interface navigation and physical tasks. Be aware of the maintenance cost: screenshots go stale faster than text, they are harder to update, and a stale screenshot actively misleads in a way that stale text often does not, because readers trust images. A reasonable rule is to use screenshots for the steps where people most often get lost, and text everywhere else.
Mostly by making the SOP better rather than by enforcing compliance. People deviate when the procedure is wrong, out of date, unfindable, or slower than what they already do. Each of those is fixable and each is a document problem rather than a people problem. Test procedures with real users, keep them current, put them where the work happens rather than in a separate documentation system, and make it easy to report that a step is wrong. A procedure people trust gets followed without enforcement, and one they do not trust will not be followed regardless of enforcement.
HERO is a document editor built for structured business documents, which means SOPs where steps, references, and defined terms are real structural objects rather than formatted text. Change a definition or renumber a section and every document in the project that depends on it updates, instead of silently going wrong. If your procedure library is big enough that keeping it consistent has become a job, that is the problem we built for. Book a demo.