Standard operating procedures are the connective tissue of any organization that has grown past a small team. They turn individual expertise into institutional capability, they compress onboarding from months to weeks, they make audits survivable, and they give leaders the confidence that work is happening the same way regardless of who is on shift. Yet most SOPs in most organizations fail to deliver these benefits. They exist as documents but not as living guides. They were written once by someone who does not do the work, approved by someone who did not read them closely, and then left untouched until an audit forces a review. The gap between what an SOP is supposed to do and what most SOPs actually do is enormous.
This guide walks through how to write SOPs that actually work. You will find six complete templates covering the most common formats - ISO-aligned, simple two-page, detailed narrative, checklist, flowchart-based, and role-play - along with fully drafted sample SOPs for recurring situations across operations, security, quality, and customer service. You will find comparison tables that show when to use each format, expert commentary drawn from practitioners in regulated and unregulated industries, a common mistakes section based on audit findings, and a practical review workflow you can adopt.
Every template and example in this guide is carefully curated from formats that survive real audits and real operational pressure. The writing style is opinionated where opinions matter - we insist on specific owners for every step, we separate policy from instruction, we favor numbered steps over prose wherever action is required, and we treat revision history as mandatory. The goal is SOPs that people actually use, not SOPs that exist only to satisfy auditors.
What an SOP Must Accomplish
Before choosing a format, be clear on the job an SOP does. An effective SOP satisfies six requirements:
- It tells a trained operator what to do in a specific situation, without ambiguity.
- It identifies who is responsible for what, so handoffs and escalations are clear.
- It captures enough purpose and rationale that an operator who encounters an edge case can make a reasonable judgment.
- It supports audit by documenting what the process is supposed to be.
- It survives personnel change by encoding knowledge that would otherwise live only in people's heads.
- It stays current through a defined review and update cycle.
An SOP that satisfies only some of these fails in characteristic ways. If it lacks purpose, operators treat it as arbitrary and deviate under pressure. If it lacks clear ownership, edge cases bounce between teams. If it is never reviewed, it drifts from reality until nobody trusts it. Design your SOPs to satisfy all six requirements and they become the asset they are supposed to be.
An SOP is a contract between the organization and the person doing the work. The organization commits to documenting the way the work should be done. The worker commits to following it, flagging deviations, and suggesting improvements. When either side breaks this contract, the SOP becomes a piece of paper instead of a tool.
SOP Format Comparison
Not every procedure needs the same format. The table below maps SOP formats to the situations where each works best.
| Format | Best For | Length | Formality | Review Cycle |
|---|---|---|---|---|
| ISO-aligned | Regulated, audited, safety-critical | 3 to 8 pages | Very high | Annual minimum |
| Simple two page | General operations, internal use | 1 to 3 pages | Medium | Annual |
| Detailed narrative | Complex processes, new operators | 5 to 12 pages | High | Annual |
| Checklist | Repetitive sequential tasks | 0.5 to 2 pages | Low to medium | Semiannual |
| Flowchart | Decision-heavy processes | 1 to 3 pages | Medium | Annual |
| Role-play | Customer-facing scripts and scenarios | 2 to 5 pages | Medium | Quarterly |
A mature documentation system uses multiple formats together. For example, a customer support function might maintain an ISO-aligned policy SOP that defines principles and responsibilities, a flowchart SOP that shows escalation paths, and several checklist SOPs for specific recurring tasks. The policy SOP changes rarely; the checklists update frequently. This layered approach works because each layer does what it is best at.
Universal SOP Structure
Regardless of format, every SOP benefits from a consistent structure that an operator can scan under pressure. Use these sections as starting points and adapt them to your context.
Standard Operating Procedure
Title: [Descriptive title] Document ID: [Unique identifier] Version: [Number] Effective Date: [YYYY-MM-DD] Owner: [Role, not individual name] Approver: [Role]
1. Purpose [One to three sentences on what this SOP exists to ensure]
2. Scope [Who this SOP applies to, what situations are covered, what is out of scope]
3. Definitions [Key terms used in this SOP]
4. Responsibilities [Roles and what each role is responsible for]
5. Procedure [Numbered steps with owners where relevant]
6. References [Related SOPs, policies, regulations, or work instructions]
7. Revision History [Table of changes with date, version, author, summary]
The Document ID, Version, Effective Date, Owner, and Approver fields at the top appear in every SOP in your library, and together they make the document traceable. The Purpose, Scope, Definitions, and Responsibilities sections establish context in roughly one page. The Procedure section is where the actual work instructions live. References and Revision History close the document and make it maintainable.
Template 1: ISO-Aligned SOP
Use this format for procedures that must withstand ISO 9001, ISO 13485, ISO 27001, FDA, or similar regulatory scrutiny. The extra formality pays for itself in audit.
Standard Operating Procedure Customer Data Transfer and Secure Handling
Document ID: SOP-IS-0012 Version: 3.2 Effective Date: 2025-04-01 Owner: Information Security Manager Approver: VP Information Security
1. Purpose
This procedure defines the requirements for transferring customer personal data between internal systems and to approved external parties. It exists to ensure that all such transfers comply with the company's data protection policy, applicable privacy regulations, and contractual obligations to customers.
2. Scope
This SOP applies to all employees and contractors who transfer, export, or share customer personal data in any format. It covers transfers within internal systems, transfers to approved third-party processors, and transfers responsive to customer data subject requests. It does not cover transfers of anonymized or synthetic data that do not constitute personal data under applicable regulation.
3. Definitions
- Personal data: Information relating to an identified or identifiable natural person, as defined in the company's data protection policy.
- Approved external party: A third-party processor with a signed data processing agreement on file and current in the approved vendor register.
- Encrypted channel: A transfer mechanism that uses TLS 1.2 or above for data in transit and AES-256 or equivalent for data at rest.
4. Responsibilities
- The requester is responsible for verifying that the intended recipient is an approved external party and that the transfer is covered by an existing legal basis.
- The data owner is responsible for approving the transfer in writing or through the data transfer workflow tool.
- The information security team is responsible for maintaining the approved vendor register and reviewing transfer logs monthly.
5. Procedure
5.1 The requester identifies the data to be transferred and the intended recipient.
5.2 The requester verifies recipient status in the approved vendor register. If the recipient is not in the register, the transfer cannot proceed until the recipient is approved per SOP-IS-0008 Vendor Approval.
5.3 The requester submits a transfer request in the data transfer workflow tool, specifying data categories, volume, purpose, and intended recipient.
5.4 The data owner reviews and approves the request within two business days. If the request is denied, the data owner documents the reason in the workflow tool.
5.5 Upon approval, the requester initiates the transfer through an encrypted channel. Acceptable channels are defined in the associated work instruction WI-IS-0012a.
5.6 The requester records the transfer in the data transfer log, including date, recipient, data categories, and reference to the approval.
5.7 The information security team reviews the data transfer log on the last business day of each month and flags any anomalies for investigation.
6. References
- Data Protection Policy POL-IS-0001
- Vendor Approval SOP-IS-0008
- Data Transfer Work Instruction WI-IS-0012a
- Data Processing Agreement template LEG-TMP-0004
7. Revision History
Version Date Author Summary of Changes 3.2 2025-04-01 L. Patel Updated encryption standards to TLS 1.2 minimum 3.1 2024-09-15 L. Patel Added reference to WI-IS-0012a 3.0 2024-02-01 R. Okoro Rewritten for GDPR alignment
Template 2: Simple Two Page SOP
Use this format for straightforward internal operations procedures that do not require ISO-level formality.
Standard Operating Procedure Customer Refund Processing
Document ID: SOP-CS-0017 Version: 2.0 Effective Date: 2025-03-01 Owner: Customer Service Team Lead
Purpose Ensure customer refunds are processed consistently, tracked accurately, and completed within our service commitments.
Scope Refunds up to $500 requested by customers via chat, email, or phone. Refunds above $500 follow the escalation procedure in section 5 of this SOP.
Who Does What
- Customer Service Agent: Receives request, verifies eligibility, processes refund.
- Team Lead: Approves refunds above $500 or outside standard eligibility.
- Finance Reconciliation: Matches refund log to transaction records weekly.
Procedure
- Verify the customer's identity using the standard identity check questions.
- Check refund eligibility using the Refund Eligibility Matrix (see Reference A).
- If eligible and under $500: process the refund in the billing system using refund reason code from the matrix.
- If not eligible: explain the reason using approved language from the Refund Denial Scripts (Reference B) and offer alternative resolutions.
- If above $500 or outside standard eligibility: escalate to Team Lead through the support queue tag "refund-escalate." Do not process without approval.
- Record the refund in the Refund Log with customer ID, order ID, amount, reason code, and agent ID.
- Send the customer confirmation using email template REF-001 or REF-002 depending on reason.
Service Commitments
- Eligible refunds processed within 1 business day of request.
- Escalated refunds decided within 2 business days.
- All refunds appear in customer account within 5 to 10 business days depending on payment method.
References A. Refund Eligibility Matrix (wiki page /support/refund-matrix) B. Refund Denial Scripts (wiki page /support/denial-scripts) C. Refund Log (shared spreadsheet maintained by Team Lead)
Revision History
Version Date Author Changes 2.0 2025-03-01 M. Chen Raised auto-approval threshold from $250 to $500 1.3 2024-07-15 M. Chen Added identity check requirement
Template 3: Detailed Narrative SOP
Use this format when the procedure is complex enough that operators benefit from context around each step.
Standard Operating Procedure New Employee Onboarding - First Week
Document ID: SOP-HR-0023 Version: 4.1 Effective Date: 2025-02-15 Owner: People Operations Manager
Purpose
Onboard new employees so they feel welcome, understand what is expected of them, have access to the systems and information they need, and are positioned to contribute meaningfully by the end of their first week. The first week is the single most important period for retention and long-term performance, and this SOP defines the minimum experience every new hire receives.
Scope
All full-time and part-time employees joining the company. Contractors and interns follow a modified version defined in SOP-HR-0024.
Pre-Arrival (one week before start date)
The People Operations Coordinator sends the pre-arrival email on Monday of the week before the start date. The email confirms first-day logistics, describes what to wear, attaches a Day One schedule, and provides a link to complete pre-employment forms.
The hiring manager confirms workspace assignment, requests equipment provisioning, and schedules a 30-minute Day One welcome meeting. If the employee will work remotely, the hiring manager confirms equipment shipping timing and video conferencing setup.
IT provisions accounts, email, and equipment based on the new hire role template. For remote employees, equipment ships to arrive two business days before the start date.
Day One
9:00 AM: Welcome meeting with hiring manager (30 minutes). The manager walks through the first week schedule, introduces the team, and answers initial questions.
9:30 AM: IT orientation and account setup (60 minutes). The new hire logs into all required systems and confirms access.
11:00 AM: People Ops overview (30 minutes). Benefits, policies, and HR contacts are reviewed. The new hire completes outstanding paperwork.
1:00 PM: Lunch with team or manager (60 minutes). No work content; relationship building only.
2:00 PM: Role-specific Day One tasks from the role onboarding plan. Typical tasks include reviewing the team wiki, reading the product documentation, and setting up local development environment for engineers or reviewing the CRM for sales hires.
4:30 PM: Check-in with hiring manager (15 minutes). The manager asks how the day went, answers questions, and confirms Day Two expectations.
Days Two Through Five
Each morning, the new hire reviews the day's agenda with the hiring manager in a 15-minute check-in. The agenda alternates structured learning and early contribution work.
By end of Day Three, the new hire has completed all mandatory compliance training including security awareness, data protection, and role-specific training from the learning management system.
By end of Day Four, the new hire has met one-on-one with each of their direct collaborators for introduction meetings of 30 minutes each.
By end of Day Five, the new hire has delivered a small first contribution appropriate to their role. This could be a documented system walkthrough for operations roles, a first code commit for engineering roles, or a first customer shadow for sales roles. The contribution does not have to be high-impact; its purpose is to confirm access and integration are working.
Week One Wrap
At end of Week One, the hiring manager meets with the new hire for 30 minutes to review the week, surface any blockers, and confirm the plan for Week Two. The new hire also completes a short feedback survey through the People Ops tool so that we can improve the onboarding experience over time.
References
- Role Onboarding Plans (shared folder /hr/onboarding/role-plans)
- Pre-Arrival Email Templates (wiki page /hr/onboarding/templates)
- New Hire Feedback Survey (feedback tool)
Revision History
Version Date Author Changes 4.1 2025-02-15 A. Oyelaran Added remote-specific equipment timing 4.0 2024-09-01 A. Oyelaran Restructured from per-day to outcome-based
Template 4: Checklist SOP
Use this format for repetitive sequential tasks where operators need to confirm each step completes.
Standard Operating Procedure Daily Store Opening Checklist
Document ID: SOP-OPS-0004 Version: 1.6 Effective Date: 2025-01-15 Owner: Store Operations Manager
Purpose: Ensure the store is safe, clean, and ready for customers by 9:00 AM every day.
Completed by: Opening Associate, counter-signed by Shift Lead
Before 8:00 AM
- Enter through staff entrance; disarm security system
- Turn on lights (front, back, displays)
- Check refrigeration temperatures (record on log)
- Walk sales floor for spills, debris, or hazards
- Address any hazards immediately or barricade and escalate
8:00 AM - 8:30 AM
- Count cash drawer; record variance if any
- Print daily sales targets
- Review any overnight shipment notifications
- Replenish any Out-of-Stock displays from backstock
8:30 AM - 9:00 AM
- Unlock front doors, set to "closed" signage until 9:00 AM sharp
- Verify point-of-sale terminals are operational
- Verify credit card reader is connected
- Post opening status in team chat
- At 9:00 AM, flip signage to "open" and unlock front entry
Shift Lead Sign-Off I confirm all opening checks are complete. Name: _______________ Time: _______________
Escalation Any items that could not be completed must be noted in the exceptions log with reason and escalated to Store Manager by text before 9:30 AM.
Template 5: Flowchart SOP
Use this format for decision-heavy processes where the next step depends on conditions.
Standard Operating Procedure Incident Response Initial Triage
Document ID: SOP-SEC-0007 Version: 2.3 Effective Date: 2025-03-10 Owner: Security Operations Manager
Purpose: Standardize the first 30 minutes of response to any potential security incident so that severity is classified correctly and escalation happens without delay.
Scope: All potential security incidents reported to the Security Operations Center by monitoring tools, employees, or external parties.
Triage Flow
Incident reported | v Verify authenticity | +----+----+ | | False Confirmed Close | v Classify severity / | \ Low Medium High | | | | | v | | Page on-call lead + CISO | v | | Page on-call v | lead Begin IR-HIGH runbook v | Create | ticket v Create ticket + Slack alert | v Begin IR-MED runbookSeverity Definitions
Severity Criteria Response Target Low No production impact; no data exposure; no privilege escalation 4 business hours to initial investigation Medium Limited production impact or indicators of limited data exposure 1 hour to initial response High Production outage, confirmed data exposure, privileged access compromise 15 minutes to initial response, incident commander assigned On-Call Roles
- On-call Lead: Responsible for initial triage and classification.
- CISO or delegate: Notified for all High severity incidents.
- Incident Commander: Assigned for High severity, drives response from triage through resolution.
Immediate Actions by Severity
Low: Open ticket in security incident queue. Assign to analyst for investigation within target window.
Medium: Open ticket. Page on-call lead. Post status in #security-ops. Begin IR-MED runbook.
High: Open ticket with severity flagged. Page on-call lead and CISO simultaneously. Assign incident commander. Initiate IR-HIGH runbook including customer communications preparation.
References
- IR-MED Runbook SOP-SEC-0008
- IR-HIGH Runbook SOP-SEC-0009
- On-Call Rotation Schedule (paging tool)
Template 6: Role-Play / Customer-Facing Scenario SOP
Use this format for procedures that involve customer interactions where specific language and sequences matter.
Standard Operating Procedure Billing Dispute Handling - Initial Call
Document ID: SOP-CS-0022 Version: 1.4 Effective Date: 2025-02-20 Owner: Customer Service Quality Manager
Purpose: Guide support representatives through initial billing dispute calls with consistent tone, required disclosures, and correct information gathering.
Step 1: Greeting and Acknowledgment
When a customer opens the call with a billing concern, respond with empathy and ownership before asking for information:
"Thank you for calling. I understand this is frustrating, and I want to make sure we get it resolved for you today. I'm going to take a look at your account right now."
Avoid: "That's our billing policy" or "You'll need to talk to billing" or anything that sounds dismissive before you have the facts.
Step 2: Identity Verification
Complete the standard identity verification from SOP-CS-0001 before discussing account specifics. Read this exactly:
"Before I pull up the details, I need to verify your identity. Can you confirm the email address on your account and the last four digits of the payment method on file?"
Step 3: Information Gathering
Ask these three questions in order:
- "Can you tell me the date and amount of the charge you're disputing?"
- "What happened that led you to contact us today - did the service not match what was ordered, or is this a charge you don't recognize?"
- "Have you already contacted your bank or card issuer about this?"
Step 4: Confirm Understanding
Paraphrase back to the customer to confirm before proceeding:
"Let me make sure I have this right. On March 3rd, there was a charge of $74.99, and you believe this is [their reason]. Is that correct?"
Step 5: Resolution Paths
If the dispute is valid and under $500, process per SOP-CS-0017 Refund Processing.
If the dispute requires additional investigation, say:
"Thank you for explaining. I'm going to open a formal dispute review. Our billing specialist will investigate and contact you within 2 business days with a resolution. Here's the reference number: [ticket ID]. Is there anything else I can help with today?"
If the customer has already disputed with their bank, follow SOP-CS-0023 Chargeback Handling.
Step 6: Close
Always close with:
"Thank you for bringing this to our attention. We'll be in touch within 2 business days. Have a good rest of your day."
Required Disclosures
If the customer asks about their refund rights, read the exact language from the Refund Policy Disclosure Script (SCR-CS-0004). Do not paraphrase.
Quality Criteria
Quality reviewers will evaluate these calls on:
- Empathetic opening before information gathering
- Complete identity verification
- Correct sequence of the three gathering questions
- Paraphrased confirmation before resolution
- Appropriate resolution path selected
- Required disclosures delivered when triggered
Writing Clear Steps
The quality of an SOP depends almost entirely on the clarity of its individual steps. Several patterns produce clearer steps.
Use active verbs. Every step starts with a verb that names a specific action: verify, enter, submit, confirm, escalate, log. Avoid "make sure" which signals uncertainty about what the action actually is.
Use one verb per step. If a step contains "verify X and submit Y," split it into two steps. Compound steps are harder to follow under pressure and make audit sampling difficult.
Name the tool or system explicitly. "Submit through the ticket system" is better than "submit the ticket" because it removes ambiguity about which of the three ticket systems an operator might use.
Specify thresholds and conditions. "Escalate if the value exceeds $500" is better than "escalate if the value is high." Numbers are unambiguous; adjectives are not.
State the outcome. When a step could be confused with a different action, state what the output should be. "Generate the weekly report (a PDF saved to the shared report folder)" prevents the common confusion about which deliverable counts as complete.
Weak vs Strong Step Examples
| Weak | Strong |
|---|---|
| Make sure the system is working. | Verify that the POS terminal displays the home screen and that the test transaction completes successfully. |
| Submit the ticket. | Submit the ticket in Zendesk, selecting category Billing and priority Medium. |
| Escalate if needed. | Escalate to the Team Lead via Slack channel #support-escalate if the refund amount exceeds $500 or the customer has contacted support about the same issue within the previous 30 days. |
| Handle the customer properly. | Greet the customer using the approved opening script, verify identity per SOP-CS-0001, then proceed to the billing dispute sequence in this SOP. |
Common Mistakes to Avoid
Writing SOPs without the operator. SOPs drafted only by managers or consultants describe an idealized process. Always include operator input in the first draft.
Mixing policy with instruction. An SOP that shifts between "it is our policy to protect customer data" and "click the Send button" is harder to maintain than separate policy and SOP documents.
Missing responsibilities. Procedures without named roles leave edge cases unresolved. Every step that involves decision or handoff needs a named role.
No revision history. An SOP without revision history is impossible to audit for drift. Maintain the history as part of the document, not in a separate change log.
Not stating scope. When scope is unclear, operators apply the SOP to situations it was not designed for. Be explicit about what is in and out of scope.
Using the same format for everything. Different procedures need different formats. Forcing all SOPs into one template produces documents that are either too formal for simple tasks or too thin for complex ones.
Overuse of "approximately" and "typically." Vague qualifiers undermine the purpose of an SOP. Replace with specific values whenever possible.
Never reviewing. Unreviewed SOPs drift from reality. Review calendars exist for a reason; honor them.
The audit finding I see most often is not that SOPs are missing - it is that the SOP on paper does not match what operators actually do. Drift is the default condition of any written procedure because work evolves faster than documentation. The fix is not more rigor in writing; it is a disciplined review cadence that catches drift before audit does.
SOP Review Workflow
Adopt a standard review workflow to keep SOPs current. A common pattern:
Owner scheduled review. The owner reviews the SOP on its scheduled cadence. The first step is to re-read the document against current practice.
Operator walk-through. The owner sits with an operator while they perform the procedure. Capture every deviation between the written steps and what the operator actually does.
Gap analysis. For each deviation, decide whether the SOP needs to be updated to match reality or operators need retraining to match the SOP. Incident and audit patterns may also inform updates.
Draft revision. Update the document. Include the rationale for each substantive change in the revision history.
Stakeholder review. Circulate the draft to affected teams with a specific deadline for comments. Address comments visibly in the revision history.
Approval. Route the final version to the approver defined in the document header.
Publication and training. Publish the new version in the documentation system. Notify affected operators and, for substantive changes, schedule a short training session.
Confirmation. After a month, verify that operators are following the new version through random sampling or supervisor observation.
SOP Library Organization
Once you have more than a handful of SOPs, organization matters. A simple but robust approach:
- Prefix by domain. Use Document IDs that start with a short code for the domain: SOP-HR, SOP-IS, SOP-CS, SOP-OPS, SOP-SEC. This makes the library easy to browse and reference.
- Sequential numbering within domain. SOP-IS-0001, SOP-IS-0002, and so on. Do not reuse retired numbers.
- Central index. Maintain a single index page or spreadsheet listing all active SOPs, their owners, effective dates, and next review dates. Keep the index current.
- Retirement rather than deletion. When an SOP is replaced, retire it rather than deleting. Mark it retired, add a pointer to the replacement, and keep it readable for audit purposes.
- Version control. Use a versioning scheme consistently: major.minor where major changes signal substantive rewrites and minor changes signal clarifications.
Frequently Asked Questions
What is the difference between an SOP and a work instruction? An SOP describes what to do and why at a level that survives tool and personnel changes. A work instruction describes the exact steps to perform a specific task, often tied to a specific tool. SOPs reference work instructions; work instructions do not stand alone.
How long should an SOP be? Most effective SOPs are two to five pages. If yours is longer, check whether multiple procedures are combined or whether work-instruction-level detail has crept in.
Who should write SOPs? The operator who does the work drafts the first version. The owner, subject matter experts, and quality representatives refine it. SOPs written only by people who do not do the work describe an idealized process that nobody follows.
How often should SOPs be reviewed? Annually at minimum for low-risk procedures, semiannually for medium-risk, quarterly for high-risk. Also review on significant process changes and after incidents or audit findings.
What is the ISO SOP format? A structured format with document identifier, revision number, purpose, scope, definitions, responsibilities, procedure, references, and revision history. Required for ISO-certified organizations and useful discipline for others.
Should SOPs include screenshots or diagrams? Include visuals when they reduce ambiguity, not as decoration. For screenshots that go stale quickly, keep them in work instructions rather than SOPs. For stable diagrams, embed them directly.
How do I get employees to actually use SOPs? Make SOPs easy to find, keep them short, update them based on operator feedback, and tie compliance to quality review. When employees believe the SOP reflects how work should actually be done, they follow it. When the SOP is aspirational fiction, they ignore it.
Conclusion and Next Steps
SOPs become assets when they are written by operators, maintained by owners, and reviewed on a predictable cadence. The templates in this guide give you starting points; the discipline of drafting, reviewing, and maintaining them is what makes them useful.
Your next steps are concrete. First, identify three procedures in your organization that either have no SOP or have an SOP nobody trusts. Second, match each to the right format from this guide. Third, sit with the operator who performs the work and draft the first version together. Fourth, route through stakeholder review and approval following the workflow outlined above. Fifth, schedule the first review date on the calendar and assign the owner.
A small library of well-maintained SOPs beats a large library of stale ones. Start with the handful of procedures where inconsistency is causing real problems, get those right, and expand from there.
Frequently Asked Questions
What is the difference between an SOP and a work instruction?
An SOP describes what to do and why, at a level that remains useful across changes in specific tools or personnel. A work instruction describes how to do a specific task step by step, including the exact clicks, settings, or physical actions required. In a well-organized documentation system, SOPs sit at the policy and process level, while work instructions sit underneath them at the task level. For example, an SOP for customer data handling might require that all customer data transfers use encrypted channels and be logged; the work instruction would specify which tool to use, which menu to click, and which fields to fill in. Keeping the two separated makes your documentation more resilient because tool changes affect work instructions but not the higher-level SOPs.
How long should an SOP be?
Most effective SOPs are two to five pages. Shorter SOPs often omit important context, like purpose, scope, or definitions, and leave the reader guessing. Longer SOPs tend to conflate policy with instruction and become hard to scan under operational pressure. If your SOP runs past six pages, check whether you have combined multiple distinct procedures that should be separate documents, or whether you have included step-by-step task instructions that belong in work instructions referenced from the SOP. The test of a good length is whether a trained employee can locate the section they need and act on it within 30 seconds. If it takes longer, the document is either too long or poorly structured.
Who should write SOPs?
The person who does the work should draft the first version. This is the single most important principle of SOP authorship. A process owner who has never performed the task produces a document full of optimistic simplifications. The worker who actually does the task produces a draft that reflects reality. The process owner, subject matter expert, and quality representative then review and refine the draft to align with policy, regulations, and cross-functional standards. A common workflow is: operator drafts, supervisor refines, quality reviews, stakeholders approve, and the operator re-reads to confirm the final version matches what they actually do. SOPs written only by managers or consultants without operator input tend to describe an idealized process that nobody follows.
How often should SOPs be reviewed?
Schedule reviews at three triggers: on a calendar cadence regardless of changes, on significant process or tool changes, and on incidents or audit findings that point to the procedure. A common calendar cadence is annual for low-risk procedures, semiannual for medium-risk, and quarterly for high-risk or regulated procedures. The calendar review should be a substantive re-read, not a signature on the cover page. Ask the current operators whether the document still matches reality, whether steps are missing or outdated, and whether any frequent problem could be prevented by a change to the procedure. Document the review date and outcome on the SOP itself so the next auditor can verify compliance with your review schedule.
What is the ISO SOP format?
ISO-aligned SOPs follow a structured format with specific mandatory elements: document identifier and revision number, purpose statement, scope, definitions, responsibilities, detailed procedure, references, and revision history. The exact section names vary slightly between ISO 9001 quality management, ISO 13485 medical devices, ISO 27001 information security, and other standards, but the underlying structure is consistent. ISO format is required for organizations seeking or maintaining ISO certification and is a useful discipline even for organizations not pursuing certification because it prompts thinking about scope, responsibility, and traceability. The main downside is that ISO-format SOPs can feel overly formal for simple procedures, which is why many organizations use a simplified format for low-risk processes and ISO format for regulated or audited areas.
Should SOPs include screenshots or diagrams?
Include visuals when they reduce ambiguity, not as decoration. Diagrams are especially useful for process flows with decision points, organizational responsibilities across teams, and physical procedures where a picture saves paragraphs of description. Screenshots work for step-by-step tool interactions when the exact screen layout matters. The tradeoff is that visuals become outdated quickly - a screenshot of a software interface may be stale within months when the tool updates. For visual elements that change, keep the SOP focused on the underlying process and place the specific visuals in a separate work instruction that can be updated without re-approving the SOP. For stable physical or organizational diagrams, embed them directly. Always caption visuals clearly so a reader can understand what they depict without additional context.