What Is an SOP? A Complete Guide to Standard Operating Procedures
Most organisations lose consistency in the same place: the gap between how a task is supposed to be done and how it actually gets done when the person who normally does it is on holiday. An SOP closes that gap. It is the written record of how one task is carried out, in enough detail that someone competent but unfamiliar can follow it and get the same result.
This guide covers what an SOP is, how it differs from a policy, what belongs inside one, which format to choose, how to write and test one, and how to make sure the people who need it have actually read it.
What is an SOP?
SOP stands for standard operating procedure. It is a document that sets out, step by step, how a specific task or process should be performed, by whom, and to what standard. The point is repeatability: the same input produces the same output regardless of who is doing the work or when.
An SOP is narrower than it sounds. It does not describe a whole department. It describes one task — issuing a refund, closing the month, onboarding a contractor, decommissioning a laptop, handling a data subject access request. If your draft covers more than one task, you are writing a manual, not an SOP, and it should be broken up.
SOPs show up most often in organisations that are audited or regulated. In the United States that includes manufacturers and labs working to FDA requirements, employers with OSHA obligations, healthcare organisations under HIPAA, public companies documenting controls for SOX, and anyone certifying to ISO 9001. But regulation is not the only reason to write them. Any team that has ever had a process walk out of the door with a departing employee has a reason to write SOPs.
SOP vs policy vs process vs work instruction
These four terms get used interchangeably and shouldn’t be. Each answers a different question, and mixing them is the fastest way to produce a document nobody can use.
| Document type | Question it answers | Example |
|---|---|---|
| Policy | What is the rule, and why does it exist? | All company laptops must be encrypted. |
| Process | What are the stages from start to finish, and who owns each one? | New starter onboarding: offer accepted, contract signed, IT provisioning, day one induction, 30-day review. |
| SOP | How is one task in that process performed, step by step? | How to provision a new starter’s Microsoft 365 account. |
| Work instruction | How is a single step performed, at the keyboard or the machine? | How to assign a licence in the Microsoft 365 admin centre. |
In practice, the policy tells people what they must do, the SOP tells them how to do it, and the acknowledgement record proves they were told. Compliance teams need all three, because an auditor asking “how do you know your staff know this?” is not satisfied by a policy alone.
Why SOPs are worth the effort
- Consistency. The same task produces the same result across shifts, sites and people.
- Faster onboarding. A new starter can be productive on a task without shadowing someone for a week.
- Evidence for auditors. A current, version-controlled SOP with a record of who read it is the artefact most audits are looking for.
- Lower risk. Steps that exist to prevent a specific failure — a second approval, a backup check, a safety isolation — stop being optional.
- Knowledge retention. The process stays with the organisation when the person leaves.
- A basis for improvement. You cannot improve a process that only exists in someone’s head. Writing it down makes the waste visible.
We have covered this in more depth in our article on the benefits of writing SOPs.
What to include in an SOP
Not every SOP needs every field below, but a document control block at the top and a revision history at the bottom should be non-negotiable. Without them you cannot prove which version was in force on a given date.
| Element | What it is for |
|---|---|
| Title and reference number | Unique identifier so the document can be cited, searched and superseded cleanly. |
| Version number and effective date | Establishes which version was in force when the work was done. |
| Owner and approver | Names the person accountable for accuracy and the person who signed it off. |
| Purpose | One or two sentences on why the procedure exists and what it protects against. |
| Scope | Which roles, sites, systems or situations the SOP applies to — and which it does not. |
| Roles and responsibilities | Who performs, who checks, who approves, who is informed. |
| Definitions and abbreviations | Any term a new starter would not know. Keep it short or nobody reads it. |
| Prerequisites | Access rights, equipment, materials, training or approvals needed before starting. |
| Procedure | The numbered steps. One action per step, in the order performed. |
| Safety, quality and compliance notes | Warnings, tolerances and regulatory requirements placed next to the step they apply to, not buried at the end. |
| Records and outputs | What the task produces and where it is filed. |
| Related documents | Links to the parent policy, related SOPs and any forms. |
| Revision history | Date, version, what changed and who approved it. |
| Review date | When the SOP must next be checked, whether or not anything has changed. |
Choosing the right SOP format
Format is a decision about the reader, not about house style. A checklist and a flowchart are both correct answers to different problems. Match the format to how complex the task is and how much judgement the person has to exercise.
| Format | Use it when | Watch out for |
|---|---|---|
| Simple checklist | The task is routine, the steps are short, and the risk is forgetting one. | Offers no explanation, so it only works for people already trained. |
| Step-by-step list | The task is linear and has fewer than roughly a dozen steps. | Becomes unreadable once branching creeps in. |
| Hierarchical list | Steps have sub-steps, or the same procedure serves both experienced and new staff. | Over-nesting. Three levels is usually the limit. |
| Flowchart | The path changes depending on a decision or an outcome. | Hard to edit and hard to read on a phone. Pair it with written steps. |
| Screen recording or video | The task is performed in software and is easier shown than described. | Goes out of date the moment the interface changes, and cannot be searched. |
Whichever you pick, the writing itself follows the same rules: short sentences, one instruction per step, active voice, and the verb first — “Open the ticket”, not “The ticket should then be opened”. Our guide on SOP format and writing style goes through layout and language in detail.
How to write an SOP, step by step
1. Confirm the task actually needs an SOP
Good candidates are tasks that are repeated, that carry risk if done wrong, that are performed by more than one person, or that are subject to audit. A task done once a year by one expert may be better served by a handover note.
2. Set the scope and purpose before you write a single step
Decide exactly where the procedure starts, where it ends, and who it applies to. Most unusable SOPs are unusable because this was skipped. Our article on defining scope and purpose covers how to write these statements so they hold up.
3. Name the audience and the author
The author should be the person who does the work, not the manager who describes it. The audience determines the level of detail: an SOP for a first-week starter needs assumptions spelled out that a ten-year veteran would find insulting. If those two audiences are genuinely different, write two documents.
4. Observe the task as it is actually performed
Watch someone do it end to end and write down what they do, including the workarounds. The gap between the official method and the real one is the most valuable information you will collect — either the workaround is an improvement worth adopting, or it is a risk worth closing.
5. Draft the steps
Number every step. One action per step. Put any warning immediately before the step it relates to. Name systems, buttons and forms exactly as they appear on screen. Avoid “as appropriate”, “as required” and “if necessary” — if judgement is genuinely needed, state the criteria.
6. Test it with someone who does not do the job
Hand the draft to a colleague from another team and ask them to follow it literally, without asking questions. Every place they stop is a defect. This one step catches more problems than any review meeting, and it is covered in our guide to testing and adjusting an SOP.
7. Approve, number and publish
Route the draft to the named approver, assign it a reference number and version, set an effective date and a review date, and publish it in one place that everyone can reach. SOPs stored in personal drives, email attachments and team folders are the root cause of people following superseded versions.
8. Distribute it and record who has read it
Publishing is not distributing. Target the SOP at the roles it applies to, tell them it is mandatory, give them a deadline, and keep a record of who confirmed they have read it. This is where most SOP programmes quietly fail, and it is covered in distributing SOPs and training staff.
A worked SOP example
Here is a short SOP written to the structure above. It is deliberately mundane, because most SOPs are.
| Reference | SOP-HR-014 |
| Title | Revoking system access for a departing employee |
| Version | 3.0, effective 1 March |
| Owner | HR Operations Manager |
| Approver | Head of Information Security |
| Review date | 1 March, annually |
Purpose. To ensure that all system access for a departing employee is removed on or before their last working day, so that former employees cannot access company systems or data.
Scope. Applies to all permanent and fixed-term employees leaving the organisation, at all US sites. Contractors are covered by SOP-HR-016.
Responsibilities. HR Operations raises the leaver record. IT Service Desk performs the revocations. The departing employee’s line manager confirms handover of files and equipment.
Procedure.
- On receipt of a resignation or termination notice, HR Operations creates a leaver record and records the confirmed last working day.
- HR Operations raises an offboarding ticket with the IT Service Desk no later than three working days before the last working day.
- The line manager completes the handover checklist and confirms the owner of any shared mailboxes, distribution lists or files held by the leaver.
- On the last working day, IT Service Desk disables the user’s Microsoft 365 account. Do not delete the account — deletion removes the mailbox and any audit history.
- IT Service Desk revokes active sessions and removes the account from all security groups.
- IT Service Desk transfers mailbox and file ownership to the manager named in step 3.
- IT Service Desk records the equipment returned and its condition.
- HR Operations closes the leaver record once the ticket is marked complete, and files the completed checklist against the employee record.
Records produced. Offboarding ticket, handover checklist, equipment return log.
Related documents. Acceptable Use Policy, SOP-HR-016 Contractor offboarding, SOP-IT-022 Account lifecycle management.
Numbering and version control
A numbering scheme does not need to be clever. It needs to be stable and to make the document findable. A common approach is a short prefix for the owning function, a sequence number, and a version: SOP-FIN-007 v2.1. Keep the reference number for the life of the procedure and change only the version; retiring a number and reusing it later is how two different documents end up cited in the same audit.
- Increment the major version when the steps change in a way that affects how the work is done.
- Increment the minor version for corrections that do not change the method.
- Record every change in the revision history, with the date, the change and the approver.
- Mark superseded versions as withdrawn and remove them from circulation, but keep them archived. Audits frequently ask what the procedure said at the time of an incident.
- Re-issue the SOP for acknowledgement whenever the major version changes. A prior acknowledgement of v2 is not evidence that anyone has read v3.
Getting SOPs read, understood and acknowledged
An SOP that sits in a document library is a liability rather than a control. The question an auditor asks is not “do you have a procedure?” but “can you show me that the people who perform this task have read the current version?” Email and intranet announcements cannot answer that, because there is no reliable record of who opened them and no way to chase the people who did not.
This is the problem DocRead for Microsoft 365 was built for. It works on top of SharePoint and Microsoft 365, so the SOPs stay where they already live, and it adds the layer around them: targeting documents at the right roles, departments, locations or groups; a mandatory read-and-acknowledge step with a deadline; automated reminders and escalation when someone misses it; live dashboards showing who has and has not confirmed; and a full audit trail of approvals, updates and acknowledgements. There is a matching version for organisations running SharePoint Server on premises.
If your SOPs already live in SharePoint and you are planning a rollout, our article on implementing SOPs with SharePoint sets out the practical sequence.
Reviewing and updating SOPs
Every SOP should carry a review date, and the review should happen whether or not anyone thinks the procedure has changed. Beyond the scheduled review, these events should trigger one immediately:
- A system, tool or supplier used in the procedure changes.
- A regulation, standard or contractual obligation changes.
- An incident, near miss, complaint or audit finding touches the procedure.
- The team structure changes and responsibilities move.
- Staff repeatedly deviate from the written steps — usually a sign the SOP is wrong, not the staff.
Assign the review to a named owner rather than a team, give it a due date, and treat an overdue review the same way you would treat an overdue control. Our guide to the SOP review process covers ownership, expiry dates and self-regulating review cycles.
Common SOP mistakes
- Writing for the wrong reader. Procedures written by experts for experts leave out the steps a new starter most needs.
- Covering too much. One SOP per task. A forty-page document covering a whole department will not be read.
- Vague instructions. “Check the file is correct” is not a step. State what correct looks like.
- No single source of truth. Copies in email, personal drives and team sites guarantee that someone is following an old version.
- No acknowledgement trail. Distribution without a record proves nothing.
- Never reviewed. An SOP that describes a system you replaced two years ago actively teaches people to ignore SOPs.
- Written and then abandoned. The document is the start of the job, not the end of it.
We have written about these failure modes at length in common problems organisations have with SOPs, and about what good looks like in SOP best practices.
SOP frequently asked questions
What does SOP stand for?
Standard operating procedure. In everyday use, “an SOP” means the document itself; “SOPs” means the set of procedures an organisation maintains.
How long should an SOP be?
As long as the task requires and no longer. Most single-task SOPs fit on one to three pages. If yours runs much longer, it is probably covering several tasks and should be split.
Who should write the SOP?
The person who performs the task drafts it, a peer tests it, and a manager or compliance owner approves it. Procedures written entirely by people who have never done the work are the ones staff quietly ignore.
How often should SOPs be reviewed?
Set a fixed review interval appropriate to the risk — annually is a common baseline for low-risk procedures, with shorter cycles for regulated or safety-critical work — and review immediately whenever a trigger event occurs.
Do employees need to sign SOPs?
If you need to demonstrate compliance, yes. A recorded acknowledgement against a specific version and date is what turns a document into evidence. Where the risk is high, pair the acknowledgement with a short comprehension check so you know the content landed, not just that the page was opened.
What is the difference between an SOP and a policy?
A policy states the rule and the reason. An SOP states the method. Policies tend to change rarely and apply broadly; SOPs change whenever the underlying system or step changes.
Where should SOPs be stored?
In one controlled location with version history and permissions — for most Microsoft-based organisations, a SharePoint document library. Storage alone is not enough; the library needs a distribution and acknowledgement process on top of it.
Start with the lifecycle, not the document
Writing the SOP is the visible part of the work and the smallest part of it. Scope, audience, format, testing, distribution, training and review are what determine whether the procedure is followed a year from now. Our free Standard Operating Procedures Manual walks through all six stages of that lifecycle in one document.