Policy vs Process vs Procedure: Clear Differences Explained

There is a meeting happening right now in some HR department somewhere in the world. Someone has just sent a document titled “Onboarding Policy” to the team for review. Halfway through, a colleague raises their hand and says, “Wait, is this a policy or a process?” The room goes quiet. Everyone has a vague feeling they should know the answer. No one does.

This is not a trivial confusion. When organisations mix up these three terms (policy, process, and procedure) they end up with documents that no one reads, compliance gaps no one notices, and accountability structures built on sand. Getting this distinction right is foundational to how well any organisation actually runs.

So let’s settle it, once and for all.

The One-Line Version

• A policy is the why: the principle behind a rule.
• A process is the what: the sequence of activities to achieve an outcome.
• A procedure is the how: the step-by-step instructions for doing a specific task.

They are not interchangeable. They are not even at the same level of abstraction. They exist in a hierarchy, and each one depends on the one above it.

What Is a Policy?

A policy is a formal statement of intent. It tells the organisation, and everyone in it, what the organisation stands for, what it will and will not allow, and why.

Policies do not tell you how to do anything. They tell you what is expected and within what boundaries behaviour must sit.

A data protection policy, for example, does not tell you how to encrypt a file. It tells you that the organisation is committed to protecting personal data, that employees must handle customer information with care, and that violations will be treated seriously. The what and the how are someone else’s job.

Good policies tend to share a few characteristics:

• They are written for a broad audience, not a specialist.
• They are principle-based, not task-based.
• They do not become outdated every time software changes or a team restructures.
• They carry authority, usually signed off at board or executive level.

Policies are the foundation of the entire governance structure. Every process and procedure that follows should be traceable back to a policy. If you cannot point to the policy a procedure is serving, you should ask whether the procedure needs to exist at all.

One practical test: if you removed the word “policy” from the document title and replaced it with “our position on X,” would it still make sense? If yes, you probably have a genuine policy document.

What Is a Process?

A process is a structured sequence of activities that, together, produce a defined outcome. It answers the question: what needs to happen, in what order, and who is responsible for each part?

Think of a process as the skeleton of work. It shows you the major bones: the stages, the handoffs, the decision points, but not the fine detail of how each bone moves.

A customer complaint process, for example, might look like this:

1. Complaint received
2. Acknowledgement sent within 24 hours
3. Complaint categorised and assigned to relevant team
4. Investigation completed within five working days
5. Resolution communicated to customer
6. Complaint closed and logged

That is a process. It is not telling you what words to use in the acknowledgement email. It is not telling you how to log the complaint in the CRM. It is showing you the shape of the work and who owns each stage.

Processes are typically owned by a function or a team. They exist at a level where a manager or process owner can look at the whole thing and see whether it is working or broken. They are often visualised as flowcharts or swimlane diagrams, but even a well-written narrative can describe a process clearly.

Where policies answer to the board, processes answer to operations. They are the bridge between strategic intent and day-to-day execution.

What Is a Procedure?

A procedure is where things get precise. It is a documented, step-by-step description of how a specific task within a process is to be performed. If you handed it to someone on their first day with no other context, they should be able to follow it correctly.

Using the complaint example above: the procedure for “log the complaint in the CRM” might look like this:

1. Open the CRM and navigate to the Complaints module.
2. Click “New Complaint.”
3. Enter the customer’s account number in the reference field.
4. Select the complaint category from the dropdown menu.
5. Paste the complaint text into the Description field verbatim.
6. Set the status to “Open.”
7. Assign to the relevant team queue.
8. Click Save.

That is a procedure. It is specific. It is repeatable. Someone else doing the exact same steps should get the exact same outcome.

Procedures are where procedural compliance lives. They are also the first thing that needs updating when a system changes, a tool is replaced, or a regulation shifts. This is worth noting: procedures are operationally critical but also operationally volatile. An organisation that has good tracking and reporting built into its document management will catch stale procedures before they cause problems.

Why the Distinction Matters in Practice

When organisations conflate these three types of documents, several things go wrong.

Policies become unusable. When a policy document includes step-by-step system instructions, it immediately starts ageing. The next software update, the next team restructure, the next system migration, and suddenly your “policy” is inaccurate. Employees stop trusting it. Compliance becomes spotty.

Processes become either too vague or too granular. A process that lists every click an employee needs to make is not a process; it is a procedure masquerading as one. Conversely, a process that says only “handle customer complaints appropriately” is not a process; it is a policy aspiration.

Procedures lose their authority. When there is no process they belong to, and no policy they are serving, procedures feel arbitrary. Employees skip steps they do not understand. Variations creep in. Audits become nightmares.

Getting the architecture right means each layer does its job. Policies govern. Processes coordinate. Procedures execute.

The Hierarchy in Action: A Real-World Example

Let us use employee data access as a worked example.

The policy states: The organisation will ensure that access to personal employee data is restricted to authorised individuals, in line with applicable data protection legislation.

The process sets out: When a new employee joins, the HR team initiates an access request. IT reviews the request against role-based access controls. Access is granted and logged. On departure, access is revoked within 24 hours.

The procedure tells the IT administrator, step by step, how to provision access in the identity management system, what fields to complete, what approval to attach, and where to log the action.

Each document is doing something the others cannot. The policy would not survive a system migration if it included procedure-level detail. The procedure would have no meaning without the process that contextualises it. The process would have no authority without the policy that mandates it.

This layered approach is what enterprise-grade policy management is designed to support, giving large organisations the architecture they need to keep governance coherent at scale, without drowning teams in documents.

A Note on Common Mistakes

Calling everything a “policy.” This is the most common error. Teams produce detailed task guides and label them policies because it makes them sound more authoritative. The result is a policy library full of procedural documents that no one can maintain.

Writing processes that only one person understands. Process documents should be legible to anyone in the organisation who might need to know how work flows. When only the person who wrote it can interpret it, it stops being a process and becomes institutional knowledge locked in one person’s head.

Skipping the process layer entirely. Some organisations have policies and procedures but no processes. This creates a gap between “why we do this” and “how we do this,” a gap where confusion, inconsistency, and compliance risk grow.

Never reviewing any of them. Policies, processes, and procedures all need a review cycle. A data access policy written five years ago may not reflect current regulatory requirements. A procedure written for legacy software is actively misleading staff. AI-assisted document intelligence is increasingly being used to flag outdated content before it becomes a liability, surfacing inconsistencies and version conflicts that manual review would miss.

Making Documents Work for the People Using Them

Writing the right kind of document is one challenge. Making sure it reaches the right people and that those people actually engage with it is another.

A procedure buried in a SharePoint folder from 2019 is not a procedure; it is a historical artefact. Effective procedure management means targeted distribution, ensuring the right document lands with the right employee at the right moment, ideally when it is contextually relevant to their work.

The same goes for employee interaction with policy and process documents. Passive uploads do not create compliance. Active employee interaction (acknowledgements, attestations, version-aware delivery) is what turns a document into a governance event with a traceable record.

And underpinning all of this is the question of trust. Organisations handling sensitive HR, legal, financial, or operational documentation need to know that their document infrastructure is secure and compliant, not just today, but as regulatory requirements evolve.

Summary: The Three Layers

Frequently Asked Questions