Understanding the Hierarchy of Policies, Procedures, and SOPs
Organisations run on clarity. When expectations are clear, decisions are consistent, and processes are repeatable, performance improves. But many teams confuse policies, procedures, and standard operating procedures (SOPs) — using the terms interchangeably when they actually serve very different purposes.
Understanding their hierarchy is key to building a scalable, well-governed organisation.
Let’s break it down.
The Big Picture: Strategy to Execution
Think of policies, procedures, and SOPs as layers:
Policies → Procedures → SOPs
Or more simply:
Why → What → How
Each layer becomes more detailed and operational as you move down.
Policies: The “Why” and “What We Believe”
What Is a Policy?
A policy is a high-level statement that defines an organisation’s principles, rules, or intentions. It sets boundaries and expectations.
Policies answer:
- What is allowed?
- What is not allowed?
- The principles guide our decisions?
- What standards must we meet?
They do not explain step-by-step instructions.
Purpose of Policies
Policies exist to:
- Provide governance and direction
- Ensure compliance (legal, regulatory, ethical)
- Promote consistency in decision-making
- Define accountability
- Reduce risk
They are typically approved by senior leadership or the board and apply broadly across the organisation.
Example
Information Security Policy
- All company data must be protected according to its classification.
- Access must follow the principle of least privilege.
- Employees must complete annual security training.
Notice: It doesn’t explain how to configure systems. It defines the standard.
Procedures: The “What to Do”
What Is a Procedure?
A procedure outlines the steps or stages required to comply with a policy or complete a process.
Procedures answer:
- What steps must be followed?
- Who is responsible?
- In what order do actions occur?
- What approvals are required?
They provide structure but are not necessarily granular or tool-specific.
Purpose of Procedures
Procedures exist to:
- Translate policy into action
- Ensure consistency across teams
- Clarify roles and responsibilities
- Create repeatable workflows
- Reduce ambiguity
Procedures are often owned by department heads or process owners.
Example
Following our Information Security Policy:
User Access Management Procedure
- Manager submits access request form.
- IT reviews request against role requirements.
- Security approves privileged access.
- IT provisions account.
- Access review conducted quarterly.
It explains what happens and in what order — but not every click or system configuration detail.
SOPs (Standard Operating Procedures): The “How to Do It”
What Is an SOP?
An SOP is a detailed, step-by-step instruction document describing exactly how to perform a specific task.
SOPs answer:
- Exactly how do I complete this task?
- Which system do I log into?
- What fields do I fill out?
- Which buttons do I click?
- What do I do if something goes wrong?
They are operational, tactical, and highly detailed.
Purpose of SOPs
SOPs exist to:
- Ensure quality and consistency
- Reduce errors
- Enable training and onboarding
- Protect institutional knowledge
- Improve efficiency
They are typically maintained by operational teams or subject-matter experts.
Example
From our earlier procedure:
SOP: Provisioning a New User Account
- Log into Active Directory.
- Select “Create New User.”
- Enter employee ID from HR system.
- Assign role-based access group.
- Enable MFA.
- Send onboarding email template A-3.
- Document completion in ticketing system.
This is tactical and task-specific.
Visualising the Hierarchy
| Level | Focus | Detail Level | Audience | Example |
|---|---|---|---|---|
| Policy | Principles & rules | High | Entire organisation | Data must be protected |
| Procedure | Process flow | Medium | Departments/roles | Steps to request access |
| SOP | Task execution | High | Operators/frontline staff | Click-by-click account setup |
Why This Hierarchy Matters
When these layers are clearly defined:
1. Governance Becomes Clear
Leaders define what must be true. Teams define how to make it happen.
2. Accountability Improves
Policies are owned at the strategic level. Procedures are owned at the process level. SOPs are owned at the operational level.
3. Scaling Becomes Easier
As organisations grow:
- Policies stay relatively stable.
- Procedures evolve as structures change.
- SOPs update as tools and systems change.
4. Risk Is Reduced
Clear documentation reduces:
- Compliance failures
- Inconsistent decisions
- Knowledge loss when employees leave
- Operational errors
Common Mistakes Organisations Make
1. Writing SOPs That Are Actually Policies
Example: “Employees must treat customers respectfully.”
That’s a policy — not a procedure.
2. Writing Policies That Are Too Detailed
If your policy includes screenshots, it’s probably an SOP.
3. Skipping the Middle Layer
Some organisations jump straight from policy to SOP. Without procedures, cross-functional alignment suffers.
4. Treating Them as Static
All three layers should be reviewed periodically — but at different frequencies:
- Policies: Annually or as regulations change
- Procedures: When processes change
- SOPs: Whenever tools or workflows change
A Simple Analogy
Think of building a house:
- Policy: “All houses must meet local building codes and safety standards.”
- Procedure: “Steps for obtaining construction permits and inspections.”
- SOP: “How to install electrical wiring in Room A.”
Each layer serves a distinct function. Remove one, and the structure becomes unstable.
Final Thoughts
Policies, procedures, and SOPs are not bureaucratic paperwork — they are structural tools for clarity, control, and growth.
In summary:
- Policies set direction.
- Procedures define process.
- SOPs drive execution.
Organisations that clearly separate and maintain these layers operate with greater consistency, lower risk, and higher performance.
And ultimately, that clarity is what turns strategy into reliable results.