SOP vs. Policy vs. Process: Why Are There Three of Them?
If you have ever opened a company folder and found a document called “Client Onboarding Process SOP Policy FINAL v3”, congratulations. Someone gave up.
SOPs, policies, and processes often get lumped together because all three help an organization operate consistently, when the truth is they serve different jobs.
And yes, even a tiny business can have all three. You do not need 47 employees, a compliance department, and a terrifying employee handbook.
Here is the easiest way to remember them:
Policy = the rule
Process = the flow
SOP = the instructions
That alone will get you pretty far.
What Is a Policy?
A policy establishes a rule, expectation, boundary, or standard within an organization.
It answers questions like:
What are we allowed to do?
What are we required to do?
What happens in this situation?
What standard are we expected to follow?
Who does this apply to?
For example, imagine your business has a rule that client files containing confidential information must only be stored in approved company systems.
That is a policy.
The policy does not necessarily need to explain which folder to click, what to name the file, or how to upload it. It establishes the expectation everyone must follow.
Examples of policies
A small business or nonprofit might have:
Code of Conduct
Information Security Policy
Client Communication Policy
Payment and Billing Policy
Confidentiality Policy
Remote Work Policy
Data Retention Policy
Conflict of Interest Policy
Policies tend to be broader because they are supposed to guide decisions across multiple situations.
Think of it as “Here are the rules of the house.”
What Is a Process?
A process describes how work moves from one stage to another.
It answers:
What happens, in what order, and who is involved?
Take client onboarding, for example. Your process might look like this:
Client approves the proposal.
Agreement is prepared.
Client signs the agreement.
Initial payment is received.
Client information is collected.
Project workspace is created.
Kickoff meeting is scheduled.
Work begins.
That is the process.
Notice that we are not explaining every click and every tiny action but showing the sequence instead. Process is especially useful when several people, departments, systems, or approvals are involved.
Examples of processes
You might document your:
Client onboarding process
Hiring process
Invoice approval process
Content publishing process
Grant application process
Donation processing process
Customer support escalation process
Employee offboarding process
Processes give people the map. They can see where something starts, where it goes next, who takes over, and where it ends.
What Is an SOP?
An SOP, or Standard Operating Procedure, gives someone the instructions needed to perform a specific task consistently. And, this is where you get more detailed.
Suppose one step in your client onboarding process says:
Create the client workspace.
Great. But how? The SOP might explain:
Open the project management system.
Select the Client Project template.
Create a new workspace using the approved naming format.
Add the client's contact information.
Create the required project folders.
Assign the project owner.
Add the standard onboarding tasks.
Confirm permissions before inviting the client.
Now someone can actually perform the task without messaging you:
“Hey, quick question...”
A phrase that has destroyed approximately 700 hours of founder productivity.
So, What Is the Actual Difference?
Here is one scenario using all three.
Your company handles client invoices.
POLICY | PROCESS | SOP |
|---|---|---|
Invoices must be reviewed and approved before they are sent to clients. | Draft invoice → Review → Approval → Send to client → Track payment → Follow up if overdue | How to Create and Send a Client Invoice |
That establishes the rule. | That shows how the work moves. | This document explains which system to use, what information to enter, how to name the invoice, who approves it, how to send it, and where to record the payment status. |
Same area of work but three different purposes.
Do You Need a Separate Document for Everything?
Please don't.
Documentation is supposed to make work easier. If your team needs a map to navigate the documentation about the documentation, we may have gone too far.
A five-person business does not need the same documentation structure as a multinational company. Some simple processes can live inside an SOP. Several related SOPs can support one broader process. A policy can sometimes be one page.
The question is whether someone can find the information they need and understand what they are supposed to do.
When Should You Create a Policy?
Create a policy when people need a consistent rule or standard.
You probably need one when the question sounds like:
“What are we supposed to do when this happens?”
Policies are especially useful around money, confidentiality, security, workplace conduct, client communication, approvals, access, and responsibilities. If different people are making completely different decisions about the same situation, you may be missing a policy.
When Should You Document a Process?
Document a process when work passes through multiple stages or people.
If everyone understands their individual tasks but nobody seems to know what happens before or after their part, document the process.
Processes are also useful for finding bottlenecks.
Maybe the problem is not that your team works slowly. Maybe every request needs approval from one person who is currently in six meetings, answering Slack, reviewing invoices, and wondering why their coffee has been cold since 9:14 a.m.
A documented process makes that easier to see.
When Should You Create an SOP?
Create an SOP when a task needs to be performed consistently and repeatedly.
A good candidate is usually something that:
Happens regularly
Has several steps
Can easily be done incorrectly
Needs to be delegated
Requires specific tools or systems
Depends heavily on knowledge currently sitting inside one person's head
If you have explained the same task three times this month, congratulations again. You have found an SOP candidate.
One Workflow Can Have All Three
This is where the pieces finally click.
Imagine a nonprofit managing donations.
The policy might establish how donor information must be protected.
The process might show the journey from receiving a donation through recording, acknowledgment, reconciliation, and reporting.
The SOPs might explain how to enter a donation into the CRM, issue a donation acknowledgment, update donor information, or reconcile transactions.
They support each other.
You do not have to choose between SOPs, policies, and processes. You just need to use the right one for the problem you are trying to solve.