Policy vs procedure: one rule written three ways

The difference in one sentence

A policy states the rule and the reason for it; a procedure states who does what, in which order, to follow it.

• A policy changes when the rule changes.
• A procedure changes when the people or the hand-offs change.

The example on this page is Northwind, a made-up online shop with 12 people. Its support team refunds paid orders in the Paynest admin panel, as in Process documentation. Northwind has one rule about refunds: support refunds up to 200 EUR alone; above that, finance approves in the ticket first.

One rule written three ways

The same rule at three levels of detail. Each version points down to the next, and each one leaves out what the next one holds.

As a policy

Title

Refund approval policy

Purpose

Stop fraud and costly mistakes on large refunds.

Scope

Every refund issued by Northwind staff, through any channel.

Rule

A refund over 200 EUR must be approved by finance before it is issued. No one may approve their own refund.

Owner

Head of finance

Approved by

Managing director, 1 October 2026

Review

Every year, and whenever the threshold changes

About 70 words. It uses "must", and it names no software and no button on purpose: if Northwind moves from Paynest to another payment provider, the policy stays true and nobody has to approve it again.

As a procedure

Title

Refund a paid order

Policy

Refund approval policy

Owner

Support lead

Roles

Support agent; finance

Steps

1. When a customer asks for a refund in a ticket, the support agent checks the order and the amount within 1 working day.
2. If the amount is 200 EUR or less, the agent goes on to step 4.
3. If it is over 200 EUR, the agent asks finance for approval in the ticket. Finance approves or rejects there within 1 working day, with a note on why.
4. Before refunding, the agent checks that the order is paid, that the amount is not more than the order total and, over 200 EUR, that finance's approval is in the ticket.
5. The agent issues the refund the same day, pastes the confirmation into the ticket and closes it.
6. Every Friday, finance reconciles the week's refunds and checks that each one over 200 EUR has its approval in the ticket.

It names roles, an order, a trigger or deadline for each step and one decision point (step 2). It still names no tool and no button, and it fits on one page. Its owner is the support lead, because support does most of the work.

As a work instruction

Only the support agent's part, steps 4 and 5 of the procedure, as it is done in Paynest:

Title

Issue a refund on a paid order

Reader

The support agent, signed in to Paynest

Steps

1. In Search orders, type the order number from the ticket, then click the order's row.
2. Check that the order shows Paid, that the amount is not more than the order total and, over 200 EUR, that finance's approval is in the ticket. If a check fails, stop and reply in the ticket.
3. Open Actions and choose Issue refund.
4. In Refund note, type the reason from the ticket.
5. Click Save refund. A saved refund cannot be taken back.
6. Paste the refund confirmation into the ticket.

Done when

The order shows the refund, and its confirmation is in the ticket.

This is the document that changes when Paynest moves a button. The policy above does not change, and neither does the procedure. A screenshot of each step, with the clicked control marked, belongs in this version only. Where the line falls between an SOP and a work instruction is shown in SOP vs work instruction.

Side by side

The owner, approver and review rows are Northwind's choice, not a standard.

SOP vs policy

A policy is the rule; an SOP is the written procedure that follows it.

An SOP is a procedure written down so it can be followed the same way every time. It sits under a policy, never beside it: the policy sets the rule, the SOP says who does what and when so the rule holds. In many small teams "SOP" means the step-by-step work instruction above, and the role-level procedure is never written down. That works until someone asks who approves what, and only the head of finance knows.

Is a procedure the same as an SOP? Nearly: an SOP is a procedure that has been written down, and in most document sets the two words name the same document. The click-by-click version is a separate document, the work instruction. How a procedure differs from the process above it is in Process vs procedure; what goes into an SOP is in What is an SOP.

Does a policy need a procedure

Not always. A policy that only allows or forbids something, such as "customer data is never sent from a personal email account", may need no procedure at all. There is nothing to do in order, only something not to do.

It needs one when someone has to act in a set order for the rule to hold, as with the refund approval. ComplianceBridge suggests weighing "the level of risk, complexity, and training needs associated with a topic" when deciding what goes in which document.

A procedure without a policy is common too: routine work with no rule behind it, such as a weekly sales export. A useful way to set up the set: each policy lists the procedures that carry it out, and each procedure names its policy, as the Northwind procedure does in its second field.

Two more document types sometimes sit between them. A standard turns a policy into a measurable requirement; as an illustration, not a definition, Northwind could set "refund requests are decided within 2 working days". A guideline recommends and does not oblige; PowerDMS calls guidelines "general recommendations. They're not mandatory or required."

Who approves policies and procedures

• Policies are usually approved high up. At the University of Texas at Austin, a policy in the Handbook of Operating Procedures must "be approved by the president after completion of the HOP policy development process" (UT Austin).
• Procedures are usually written by the managers whose teams follow them. IT Glue: "Managers of various departments can write procedures concerning the operations of their teams."
• Review cycles: PowerDMS says to "review and update policies at least once a year". Procedures change more often; IT Glue calls them "subject to frequent adjustments and changes", for example when a new tool arrives.

No law and no ISO clause fixes one approval chain or review cycle for every organisation. Each document should name its own owner, approver and next review date, as the Northwind policy does.

Sources