How to write an SOP + free SOP template and examples

They may seem simple, but SOPs are surprisingly tricky. On the surface, SOPs (Standard Operating Procedures) describe how a specific process is carried out at your organization. Pretty straightforward, right?

In reality, there are a lot of requirements for writing a good SOP and auditors have a sharp eye out for any missing components and unclear steps.  

Here’s what you need to know to write GxP-compliant SOPs — plus a free SOP template and examples you can use to get started.

What’s the purpose of an SOP? 

An SOP has one main job: clearly define how your team executes a process so that anyone reading it knows exactly what happens, who does it, and when. It takes a repeatable process and makes sure it gets carried out the same way every time.

SOPs are important for auditors too. They’ll read the steps documented in your SOPs and compare them against your organization’s actual activity. If they match, you’re good to go. If not, they immediately dive into why. Are your SOPs unclear? Is your team untrained? Where is the process breaking down?

What’s the difference between an SOP and work instructions?

One of the most common mistakes Quality teams make is confusing SOPs with work instructions. It’s easy to hear “thoroughly describe your process” and think it means “list, in detail, every single action that has to happen” – but that’s not the purpose of an SOP.

An SOP defines the process. A work instruction defines step-by-step actions.

Here’s an example of how an SOP and work instructions each might discuss tracking deviations:

• SOP: The Quality Assurance team documents the deviation in the tracking system and assigns an investigator. The investigator performs a root cause analysis according to the procedure outlined in SOP-004 Root Cause Analysis…
• Work Instructions: Log into ZenQMS. Click the “+” in the top navigation bar. Click “Create a New Issue”...

What does an SOP need to include? 

SOP templates can vary between organizations, but no matter your process, you must include some key components. Beyond the standard metadata (such as name, document ID, effective date, version information, etc.), here’s what inspectors expect to see in your SOP documents: 

Purpose

Every SOP should start with a sentence or two defining the goal of the document. Why does this SOP exist? What is achieved by executing this specific procedure? This helps your team – and auditors – understand what this SOP is designed to control.

Scope

This is where you describe who and what the SOP applies to and when it’s applicable. Does it apply to a specific product? To certain manufacturing stages? To a particular team or role?

Roles and Responsibilities

This section defines who is in charge of what within the described procedure. Think about which team or roles execute which stages, who reviews, who is accountable for monitoring, etc. 

Reference Documents

You can’t assume your reader knows anything outside of what’s included in this SOP document, which is why a “Reference Documents” section is required. This section is a list of all other documents, policies, procedures, work instructions, external standards, etc. that is relevant to this SOP. For example, if your SOP includes a sentence like “Quality Assurance monitors that all signatures are 21 CFR Part 11 compliant according to SOP 206,” then you must link both SOP 206 and the external guidance for 21 CFR Part 11 compliance within this section. 

Definitions

Using the same logic that requires reference documents, it’s understandable that a “Definitions” section is also required. All acronyms, abbreviations, key terms, etc. must be defined for easy reference. For example, if you use the word “CAPA,” you must clarify it stands for Corrective and Preventive Actions and provide a definition for the term. Don’t assume the reader understands your nomenclature. Ambiguity and compliance do not mix. 

Process Overview

Now we get to the good stuff. This section is the heart of the SOP where you describe your process clearly and thoroughly. You’ll likely have subheads within this section to delineate each stage of your process, but beyond just the steps to execute the given process, this overview must also include:

• Details on responsibilities, communication, and notifications. Clearly say who is doing what, who they’re notifying next, and how they’re handing it off to the next responsible party.
• Timelines. When does each necessary stage need to be completed? What is the timeline for review or approval?  
• Details on monitoring. How are you checking that the process is followed? How are you monitoring the outcome of the procedures included? How will you know if something goes wrong?
• Information on documentation. Where are you documenting outcomes?

Remember, your SOPs should be auditable. If you say your procedure includes doing X at Y time, an auditor should be able to check your records to see if it actually happened according to your SOP. 

How do you write a good SOP? 

A good SOP is all about clarity, usability, and compliance. It has to stand up under real-world use and audit scrutiny, which means it must follow these SOP best practices: 

• Write in present tense. This “best practice” is technically a “hard requirement.” Auditors don’t want to know what you will do one day, but rather what you’re actively doing right now.
• Keep it high-level enough to stay relevant. SOPs are a delicate balance between overly-detailed and too vague. It should be clear to the reader exactly what is required when, but including too many minute details make your SOPs fragile. If something doesn’t impact the overall procedure, but instead impacts the actual step-by-step execution, it’s often better to include it in the work instructions rather than your SOP. For example, avoid naming specific tools, platforms, or systems unless absolutely necessary — otherwise, you’ll have to revise and retrain every time you make a small change.
• Plan for “what ifs.” Auditors will ask what happens if something goes wrong. Always address how you handle any problems that may occur. (This could be as simple as referencing your Issues Management SOP – but remember to link it in the Reference Documents!).
• Stay clear and concise. An SOP isn’t the time to bust out your thesaurus. Write as clearly and simply as you can to make it easy for your reader to understand exactly what they need to do.

The best tool to store and manage your SOPs

Writing clear, compliant SOPs is a major task — but the other half of the battle is making sure they’re stored, version-controlled, and accessible in a way that stands up to audits.

Too often, organizations keep SOPs scattered across shared drives, disconnected systems, or even physical binders. Not only is this hard to manage, it also increases the risk of employees using outdated procedures — a huge red flag for auditors.

That’s why the best way to store and manage your SOPs is in an electronic quality management system (eQMS).

An eQMS gives you:

• Centralized, controlled access to all SOPs
• Automated version control and approval workflows
• Audit-ready records showing who reviewed, approved, and trained on each version
• Easy assignment of SOP training with completion tracking
• Real-time visibility into compliance across your team

With an eQMS, you can enforce training, monitor adherence, and continuously improve without chasing down paperwork.

Free SOP template with examples

Looking for a jumping off point for your own SOPs or curious to see examples for each SOP section? Check out the sample SOP template for GxP-regulated organizations by clicking the button below.