---
title: "Standard Operating Procedures: What They Are and Why"
sidebarTitle: "Overview"
description: "Learn what SOPs are, when to write one, how they differ from how-to guides, and what required fields every published SOP must include."
---
> **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version.
Standard Operating Procedures (SOPs) are the backbone of consistent, repeatable work across your organization. When a process matters enough to get right every time — onboarding a new team member, processing a refund, deploying a release — an SOP ensures that anyone who follows it arrives at the same outcome, regardless of experience level or context.
## What Is an SOP?
An SOP is a formally documented, step-by-step procedure that describes how to carry out a specific, repeatable business process. Unlike informal notes or ad-hoc instructions, an SOP is owned, versioned, reviewed, and approved. It carries organizational weight: when a process has an active SOP, following that SOP is the expected standard.
SOPs are most valuable when:
- A process is performed frequently and must be consistent across people or teams
- Errors in the process carry significant risk (compliance, safety, customer impact)
- The process involves handoffs between departments or roles
- You need an audit trail showing that a procedure was followed correctly
## SOPs vs. How-To Guides
Both SOPs and how-to guides explain how to do something, but they serve different purposes and carry different authority.
| | SOP | How-To Guide |
|---|---|---|
| **Formality** | Formal, policy-level document | Instructional, reference material |
| **Compliance** | Required — following it is the standard | Optional — provides helpful context |
| **Ownership** | Assigned owner, approval chain | Any contributor can write one |
| **Versioning** | Strict version history with review dates | Informal updates as needed |
| **Scope** | Single, well-bounded business process | Broader topic or skill area |
Use an SOP when deviating from the procedure would be a problem. Use a how-to guide when you want to teach, explain, or provide supplemental context that supports but doesn't replace judgment.
## The SOP Lifecycle
Every SOP moves through a defined lifecycle from creation to retirement. Understanding where an SOP sits in this lifecycle tells you whether it's safe to rely on, currently under review, or no longer current.
```
Draft → Review → Approved → Active → Archived
```
- **Draft** — The SOP is being written or revised. It has not been reviewed and should not be used as an operational standard.
- **Review** — The SOP has been submitted to a reviewer or approver. It may not yet reflect final decisions.
- **Approved** — A qualified approver has signed off. The SOP is ready to be published.
- **Active** — The SOP is published and is the current operational standard. This is the version everyone should follow.
- **Archived** — The SOP has been superseded by a newer version or retired because the process no longer exists. Archived SOPs are read-only and kept for historical reference.
## Key Fields Every SOP Contains
A well-structured SOP includes the following fields. These are not optional — every published SOP must have all of them filled in before it can move to the Approved state.
| Field | Purpose |
|---|---|
| **Title** | A clear, action-oriented name describing the process |
| **Owner** | The person or role responsible for maintaining this SOP |
| **Department** | The team or function this SOP belongs to |
| **Effective Date** | The date this version became Active |
| **Revision History** | A log of every version, including what changed and who approved it |
| **Scope** | What this SOP covers and, importantly, what it does not cover |
| **Procedure Steps** | The numbered, step-by-step instructions for carrying out the process |
| **Related Documents** | Links to related SOPs, how-to guides, templates, or policy documents |
The **Owner** field is not just a name — it means that person is responsible for keeping the SOP accurate, initiating reviews on schedule, and responding to questions about the procedure.
## Explore This Section
Follow the step-by-step process for drafting a new SOP, filling in header fields, writing effective procedure steps, and submitting for review.
Understand the approval workflow, how version control works, and what happens when an SOP is published or archived.
## Frequently Asked Questions
Most SOPs should be reviewed at least once every 12 months. High-risk or compliance-sensitive procedures — such as those tied to data handling, financial controls, or safety — should be reviewed every 6 months. You can set a scheduled review reminder directly on the SOP record so the owner is notified automatically when a review is due. If a process changes significantly before the scheduled review date, initiate an unscheduled review immediately rather than waiting for the cycle.
Anyone in the organization can draft an SOP, but a draft doesn't become an operational standard until it has been reviewed and approved by a qualified approver — typically the process owner's manager, a department lead, or a designated admin. The person who writes the SOP is not always the owner; you can assign ownership to a different person during the drafting phase. Ownership should reflect who is accountable for the process, not just who documented it.
A good SOP title clearly names the process it describes, starting with an action verb or a noun that identifies the subject. Aim for specificity: "Process a Customer Refund Request" is better than "Refunds." Avoid titles that describe outcomes rather than processes ("Accurate Refunds") or titles so broad they could cover multiple procedures ("Finance Operations"). A reader should be able to tell from the title alone whether this SOP applies to their situation, without having to open it.
A policy states what must be done and why — it defines rules, requirements, and intent. An SOP describes how to do it — the specific steps, sequence, and actions required to comply with or execute that policy. Policies are typically owned at a senior or organizational level; SOPs are owned by the teams that execute the underlying processes. A single policy may be supported by multiple SOPs. Always link an SOP to its governing policy in the Related Documents field when one exists.