A Standard Operating Procedure (SOP) explains how a recurring activity should be performed.
An effective SOP should help different authorised users perform the same process consistently while understanding:
This template can be adapted for:
Remove sections that are not relevant to the process.
SOP Title:
[Insert procedure title]
SOP Number:
[Insert reference number]
Department:
[Department]
Process Owner:
[Role or department]
Document Owner:
[Role or department]
Author:
[Name or role]
Reviewer:
[Name or role]
Approver:
[Name or role]
Version:
[Version]
Status:
[Draft / Under Review / Approved / Superseded]
Effective Date:
[Date]
Next Review Date:
[Date]
Confidentiality:
[Classification]
Record significant changes made to the SOP.
| Version | Date | Author | Description of Change | Reviewer | Approval |
|---|---|---|---|---|---|
| 0.1 | [Date] | [Name] | Initial draft | [Name] | [Status] |
| 0.2 | [Date] | [Name] | [Change] | [Name] | [Status] |
| 1.0 | [Date] | [Name] | Approved version | [Name] | [Status] |
Avoid changing a controlled SOP without recording the reason for the change.
Explain why the procedure exists.
Purpose
[Describe the purpose of the process.]
A good purpose statement should explain the operational outcome the SOP is intended to support.
For example:
Define where the SOP applies.
[Locations, branches, departments, facilities, or online environments.]
[Systems, software, platforms, or equipment.]
Explain what causes the procedure to begin.
Examples:
Trigger:
[Describe the event that starts the procedure.]
Describe what should exist when the procedure has been completed successfully.
Expected Outcome:
[Describe the final result.]
Examples:
Identify everyone involved in the process.
| Role | Responsibility |
|---|---|
| [Role] | [Responsibility] |
| [Role] | [Responsibility] |
| [Role] | [Responsibility] |
[Identify the person or function responsible for the overall process.]
[Identify the roles authorised to perform the procedure.]
[Identify who approves relevant decisions.]
[Identify who handles exceptions or unresolved issues.]
Identify information, materials, approvals, or resources needed to start.
| Input | Source | Required Before Start? | Responsible Party |
|---|---|---|---|
| [Input] | [Source] | [Yes/No] | [Role] |
| [Input] | [Source] | [Yes/No] | [Role] |
Examples include:
[Required roles.]
[Required permissions or system access.]
Before beginning the procedure, confirm:
Define terms that may be unfamiliar to users.
| Term | Definition |
|---|---|
| [Term] | [Definition] |
| [Term] | [Definition] |
| [Term] | [Definition] |
Use the same terminology consistently throughout the SOP.
Identify policies, standards, procedures, contracts, regulations, or internal requirements relevant to the process.
Explain how each requirement affects the procedure where necessary.
Provide a high-level view before presenting detailed instructions.
Example:
The overview should help users understand the complete workflow before performing individual steps.
Responsible Role:
[Role]
Action:
[Describe the action.]
Required Information:
[Information needed.]
System or Tool:
[System/tool.]
Expected Result:
[Expected result.]
Control Point:
[Control or check.]
Responsible Role:
[Role]
Action:
[Describe the action.]
Required Information:
[Information needed.]
System or Tool:
[System/tool.]
Expected Result:
[Expected result.]
Control Point:
[Control or check.]
Responsible Role:
[Role]
Action:
[Describe the action.]
Required Information:
[Information needed.]
System or Tool:
[System/tool.]
Expected Result:
[Expected result.]
Control Point:
[Control or check.]
Responsible Role:
[Role]
Action:
[Describe the action.]
Required Information:
[Information needed.]
System or Tool:
[System/tool.]
Expected Result:
[Expected result.]
Control Point:
[Control or check.]
Responsible Role:
[Role]
Action:
[Describe the action.]
Required Information:
[Information needed.]
System or Tool:
[System/tool.]
Expected Result:
[Expected result.]
Control Point:
[Control or check.]
Some procedures require different actions depending on circumstances.
Question or Condition:
[Describe the decision.]
If Yes:
[Action.]
If No:
[Action.]
Question or Condition:
[Describe the decision.]
If Condition A Applies:
[Action.]
If Condition B Applies:
[Action.]
Make decision points explicit rather than hiding them inside long paragraphs.
Identify activities that require formal approval.
| Approval Point | Decision Required | Approver | Evidence of Approval |
|---|---|---|---|
| [Point] | [Decision] | [Role] | [Record] |
| [Point] | [Decision] | [Role] | [Record] |
Do not assume that an employee’s completion of an activity automatically constitutes approval.
Identify controls designed to prevent errors or inconsistencies.
| Control | Purpose | Responsible Role | Frequency |
|---|---|---|---|
| [Control] | [Purpose] | [Role] | [Frequency] |
| [Control] | [Purpose] | [Role] | [Frequency] |
Examples:
Where applicable, explain compliance requirements relevant to the process.
Consider:
[Requirement]
[Explain how the procedure addresses the requirement.]
Where the process involves information, document how it should be handled.
[Source.]
[Approved location.]
[Who may access the information.]
[Retention requirement.]
[Approved disposal method.]
Do not place passwords, private keys, authentication tokens, or other sensitive credentials in an SOP.
Identify records produced during the process.
| Record | Created By | Storage Location | Retention |
|---|---|---|---|
| [Record] | [Role] | [Location] | [Period] |
| [Record] | [Role] | [Location] | [Period] |
Records may include:
Explain what happens when the normal procedure cannot be followed.
[Describe exception.]
Immediate Action:
[Action.]
Responsible Role:
[Role.]
Escalation:
[Escalation path.]
Required Record:
[Record.]
Escalate the process when:
[First-line resolution.]
[Supervisor or specialist escalation.]
[Management or specialist escalation.]
Describe how common errors should be identified and corrected.
| Error | Detection | Immediate Action | Escalation |
|---|---|---|---|
| [Error] | [Detection] | [Action] | [Role] |
| [Error] | [Detection] | [Action] | [Role] |
[Explain how errors should be recorded.]
Where appropriate, define expected performance levels.
| Activity | Standard | Measurement |
|---|---|---|
| [Activity] | [Standard] | [Measurement] |
| [Activity] | [Standard] | [Measurement] |
Possible measures include:
The procedure is considered complete when:
If another person or team takes responsibility after the process, document the handover.
[Information to be transferred.]
[Role.]
[Method.]
[How receipt is confirmed.]
Where communication is part of the procedure, specify what should be communicated.
[Event.]
[Recipient.]
[Email / Portal / Phone / System / Other]
[Role.]
Define how the effectiveness of the procedure will be monitored.
[Target.]
[Frequency.]
[Explain how performance is reported.]
Identify risks that could affect the process.
| Risk | Cause | Potential Effect | Control |
|---|---|---|---|
| [Risk] | [Cause] | [Effect] | [Control] |
| [Risk] | [Cause] | [Effect] | [Control] |
| [Risk] | [Cause] | [Effect] | [Control] |
Focus on risks that are relevant to the actual process.
Where the process is important to ongoing operations, document what happens when normal resources are unavailable.
[Alternative procedure.]
[Alternative responsibility.]
[Alternative location or method.]
[Recovery or alternative information source.]
[Escalation and continuity arrangements.]
Identify the training required for users of the SOP.
[Describe how users demonstrate competence.]
[Frequency or trigger.]
[Record location.]
Define when the SOP should be reviewed.
Review the SOP:
An SOP should not prevent legitimate improvement.
Process owners should periodically assess:
[Describe potential improvement.]
[Describe proposed change.]
[Describe expected benefit.]
[Approval requirements.]
Before formally approving an SOP, test whether a suitable user can follow it.
[Name or role]
[Date]
[Describe the scenario.]
[Pass / Requires Revision]
Testing is particularly valuable when the SOP will be used by people who were not involved in creating the process.
A useful SOP should be:
Specific
Tell users what needs to happen rather than relying on assumptions.
Sequential
Present actions in an order that matches the actual workflow.
Role-based
Make it clear who performs each important activity.
Controlled
Identify approvals, checks, and other controls.
Practical
Reflect how the process actually operates.
Measurable
Where appropriate, define standards and completion criteria.
Maintainable
Make it possible to update the SOP when the underlying process changes.
Accessible
Users should be able to find the correct version when they need it.
Avoid:
Useful areas include:
Useful areas include:
Useful areas include:
Useful areas include:
Useful areas include:
Useful areas include:
Useful areas include:
Explore related Lamtas resources:
This template is a general framework for developing standard operating procedures.
The completed SOP should be adapted to the organisation’s actual workflow, systems, responsibilities, controls, policies, and applicable requirements.
Where a procedure concerns safety-critical operations, regulated activities, financial controls, information security, personal data, engineering systems, healthcare, or other high-risk activities, the final procedure should be reviewed and approved by appropriately qualified personnel.
A Standard Operating Procedure is valuable when it converts a recurring activity into a controlled and understandable process.
The strongest SOPs do not merely list instructions.
They connect:
Trigger → Inputs → Responsibility → Procedure → Controls → Exceptions → Records → Verification → Completion
That structure helps organisations reduce ambiguity, improve consistency, train new personnel, preserve operational knowledge, support quality management, and identify opportunities for process improvement.