Standard Operating Procedure (SOP)

In this Article

A structured SOP template for operations and admin teams — with purpose, scope, roles, step-by-step procedure, and revision history sections. Download as a Word document and generate a completed SOP for any repeatable process in WordFields.


Standard Operating Procedure
SOP title — e.g. Supplier Invoice Processing Procedure
SOP Number Department prefix + sequential number — e.g. OPS-001
Version Version number — e.g. 1.0 or 2.1
Effective Date Date this version comes into effect
Review Date Date by which this SOP must be reviewed
Author Name and job title of the person who wrote this SOP
Approved by Name and job title of the approving manager
Department Owning department — e.g. Operations / Procurement / Finance
Purpose

One to three sentences stating why this SOP exists and what outcome it is designed to achieve

Scope

This SOP applies to: Name the roles, teams, or departments who must follow this procedure

This SOP does not apply to: Name any exceptions or exclusions, or leave blank if none

Roles and Responsibilities
Role Responsibility
Role or job title What this person is responsible for in this procedure
Role or job title What this person is responsible for in this procedure
Role or job title — add more rows as needed What this person is responsible for in this procedure
Definitions

Define any terms, acronyms, or abbreviations used. Delete this section if no definitions are needed.

Term / Acronym Definition
Term or acronym Plain-language definition
Term or acronym — add more rows as needed Plain-language definition
Procedure

Notes on how steps are structured — e.g. note any conditional logic or approval triggers. Leave blank if not needed.

  1. Action — who does what, using what tool or system, to what standard
  2. Action
  3. Action
  4. Action
  5. Action
  6. Action — include any approval, sign-off, or escalation trigger here
  7. Action — include any recording, filing, or notification requirement here

For processes with decision points: If [condition], proceed to Step X. If [condition], proceed to Step Y.

Related Documents

List any policies, procedures, forms, or reference documents. Delete this section if none.

Revision History
Version Date Author Summary of Changes
1.0 Initial version date Initial author name Initial version
Version number of latest revision — e.g. 1.1 Date of latest revision Author of latest revision Brief description of what changed

Download as a Word document and generate a completed SOP using the WordFields form — title, version, date, author, approver, and all procedural content fill in from a single form without editing the source file.

What's included

Each SOP auto-populates the following fields when used in WordFields:

  • SOP title, document number, version, and effective and review dates
  • Author and approver names and job titles, and owning department
  • Purpose statement and scope definition
  • Roles and responsibilities table with named roles and their specific duties
  • Definitions table for terms and acronyms used in the procedure
  • Numbered procedure steps with conditional logic notes where applicable
  • Related documents list with reference numbers
  • Revision history table recording version changes with dates and summaries
  • Organisation name (pulled from workspace settings automatically)

When to write a standard operating procedure

Use this SOP template to document any repeatable operational process that must be performed consistently by more than one person, or that must be performed consistently by one person across time. The practical threshold is simple: if variation in how this task is performed could cause an error, a compliance failure, or a quality defect, it needs an SOP. Operations managers documenting procurement workflows, admin teams standardising supplier communication processes, and quality managers building a document library for ISO 9001 compliance are the primary users. For teams working toward or maintaining ISO 9001:2015 certification, every process referenced under Clause 7.5 as documented information requires a controlled document of this type — this template satisfies that requirement directly.

The revision history table is not administrative padding — it is the mechanism that makes an SOP a controlled document rather than a shared file. An SOP without a revision history gives no indication of whether it reflects the current process or an outdated version from two years ago. Every time the procedure changes, updating the revision history creates a dated audit trail that demonstrates the organisation actively manages its documented information. For teams storing SOPs in WordFields, generating a new version of the document through the form — updating the version number, effective date, and revision summary — takes less than two minutes and produces a correctly formatted document ready for distribution and filing. Teams managing multiple SOPs across departments can create a separate WordFields template per process area, with standing fields pre-filled for the department, approver, and review cycle, so new SOPs follow the same structure without any formatting work.

Frequently asked questions

What should a standard operating procedure include?

A standard operating procedure should include a title block with the SOP title, document number, version, effective date, and author; a purpose section explaining why the procedure exists; a scope section defining who the procedure applies to and what it covers; a roles and responsibilities section naming who does what; a step-by-step procedure section with numbered instructions in the order they are performed; a references section listing related documents or policies; and a revision history table recording every version change. All sections must be present for the SOP to function as a controlled document.

What is the correct format for an SOP?

The most widely used SOP format for business and operations teams is the step-by-step format — numbered instructions presented in the order they must be performed, with each step covering one discrete action. For processes with decision points or conditional outcomes, a hierarchical format with sub-steps or a flowchart supplement is more appropriate. For routine tasks that experienced team members perform regularly, a checklist format can serve as a concise reference. Whichever format you choose, always begin with the title block, purpose, and scope before the procedure steps.

What is the difference between an SOP and a policy?

A policy states what must be done — it defines rules, principles, or requirements that govern behaviour within an organisation. An SOP explains how to do it — it provides step-by-step instructions for carrying out a specific task in accordance with those policies. Policies are typically broader and less detailed than SOPs. SOPs must always align with relevant policies, but they operate at the procedural level, not the governance level. When a policy changes, the SOPs that implement it must be reviewed and updated accordingly.

How long should a standard operating procedure be?

An SOP should be exactly as long as the procedure requires — no longer. Simple, routine procedures can often be documented in one to two pages. Complex multi-step processes with multiple roles and decision points may run to five or more pages. The most common mistake is writing SOPs that are too long because they include background information, rationale, or detail that belongs in a separate policy or training document. If someone cannot find the next step they need in under ten seconds of scanning, the SOP is too long or too poorly formatted.

Who should write an SOP?

The person with the most detailed knowledge of how the procedure is actually performed — typically the team lead, operations manager, or subject matter expert for that process area. The draft should then be reviewed by the people who will use it, who will often identify missing steps, ambiguous instructions, or practical constraints the author overlooked. For compliance-sensitive procedures, a senior manager or quality officer should sign off before the SOP is approved and distributed. The author and approver should always be different people.

How often should SOPs be reviewed and updated?

SOPs should be reviewed at least every twelve months as a matter of routine, and immediately whenever the underlying process changes, a regulatory requirement changes, or the SOP fails to prevent an error it was designed to prevent. Every review should be recorded in the revision history table with the date, a summary of what changed, and the name of the reviewer. SOPs that are not periodically reviewed become outdated without anyone noticing, which is one of the most common findings in operational audits and ISO compliance reviews.

What is an SOP number and why does it matter?

An SOP number is a unique identifier assigned to each SOP document within your organisation's document control system. It matters because it allows SOPs to be referenced precisely in other documents, training records, audit reports, and compliance submissions — without relying on the document title, which may change across versions. A common numbering convention is a prefix indicating the department or process area followed by a sequential number, for example OPS-001, OPS-002. Once assigned, an SOP number should never change, even if the document is substantially revised.

Do SOPs need to be approved before use?

Yes. An SOP should be reviewed and formally approved by a person with appropriate authority — typically a department head, quality manager, or operations director — before it is distributed or used. The approval should be recorded in the document itself, either with a signature block on the title page or an entry in the revision history table. Using an unapproved SOP creates a compliance risk because there is no documented evidence that the procedure was reviewed for accuracy, safety, or regulatory alignment before staff were instructed to follow it.

Explore more professional document and email templates you can copy, customize, and use immediately