What is the difference between a policy and a procedure?
Written by PolicyDrafters. Published , updated .
A policy states what the organisation requires and is approved by leadership; a procedure states the numbered steps that carry it out, each with an owner and a record. The policy changes rarely; the procedure changes with the tool or team. ISO/IEC 27001:2022 sets them apart: the policy in clause 5.2, operating procedures in Annex A 5.37.
What is a policy, and what is a procedure?
A policy is a written rule that an organisation commits to. It states what is required, who it applies to, who owns it and who may grant an exception. It is approved by the people who carry the risk, usually leadership or a board. It changes rarely, because the rule does not move when the tools do.
A procedure is the written method that carries a policy out. It states the steps in order, the owner of each step, the system or form each step uses, and the record each step leaves behind. It is owned by whoever runs the process. It changes whenever the process does: a new tool, a new team, a new regulator's question.
Read together, the policy proves the commitment exists and the procedure proves it is kept. That is why auditors and regulators ask to see both.
How do you tell a policy from a procedure?
Read the sentence and ask one question: does it say what must be true, or how to make it true? "All staff complete security awareness training within thirty days of starting" says what must be true, so it is a policy statement. "Send the new starter the training link on day one, record the completion date in the HR system, and chase after twenty-one days" says how to make it true, so it is a procedure.
The first sentence survives a change of training provider; the second does not. That is the whole difference, and it decides who approves the document, how often it changes, and what an auditor will do with it.
Why do auditors, regulators and staff read them differently?
Three readers care about the split, and each reads the two documents for a different reason. The auditor and the regulator read them as evidence; the member of staff reads them as instructions.
An auditor reads the policy to confirm the rule exists and is approved. Then the auditor reads the procedure to confirm the rule is followed, and then samples the records the procedure says it produces. If the policy and the procedure are one undifferentiated document, the auditor cannot tell which sentences are commitments and which are instructions. The auditor will ask for both to be separated before the audit continues.
ISO/IEC 27001:2022 makes the distinction explicit. It asks for a documented information security policy in clause 5.2 and for documented operating procedures in Annex A control 5.37 [1].
A regulator reads the policy as a statement of what the firm has committed to, and the procedure as evidence of how that commitment is kept. The FATF Recommendations ask firms to [2]:
- have policies, controls and procedures approved by senior management (the interpretive note to Recommendation 1)
- implement programmes against money laundering (Recommendation 18)
- apply customer due diligence measures step by step, as a separate requirement (Recommendation 10)
A firm that hands over one document called a policy that is really a procedure, or the reverse, will be asked for the other one.
A member of staff reads the procedure to do the job and the policy to understand why. A new starter does not need the rationale for a leave policy; they need the steps for requesting leave. A manager handling a grievance needs both: the policy that says what the organisation promises, and the procedure that says what to do on day one, day five and day ten.
A worked example: data retention as policy and as procedure
Take data retention. The policy says:
- Personal data is kept no longer than the purpose requires.
- The retention schedule in appendix A sets the period for each category.
- The data protection lead owns the schedule and approves exceptions.
- This policy is reviewed annually and when the law changes.
Four sentences, approved by leadership, unchanged for years at a time.
The procedure says:
- On the first working day of each quarter, the operations lead exports from the CRM the list of customer records older than the retention period.
- The operations lead checks the list against open contracts and legal holds.
- The operations lead deletes the records with no hold using the bulk-delete tool.
- The operations lead exports the deletion log.
- The operations lead files the log under the quarter's folder.
- The data protection lead signs the log.
Six steps, each with an owner, a tool and a record. When the CRM changes, the procedure changes and the policy does not.
Now take the common failure. One document, titled "Data retention policy", contains both the rule and the quarterly steps. The CRM changes. Nobody wants to take a procedural change to the board, so the document is not updated.
Six months later the auditor reads that deletions are run in a tool that no longer exists. The finding is not "your procedure is out of date" but "your policy is not followed". That is a worse finding, against a document that was never meant to carry those steps.
How do a policy and a procedure compare?
| Aspect | Policy | Procedure |
|---|---|---|
| States | The rule: what must be true | The method: how it is made true |
| Applies to | Everyone in scope, named by role | The people who perform each step |
| Approved by | Leadership or the board | The process owner |
| Changes when | The rule or the law changes | The tool, team or regulator's question changes |
| Contains | Purpose, scope, rule, roles, exceptions, review cycle | Numbered steps, owner per step, system or form, record produced |
| Proves | The commitment exists | The commitment is kept |
| Length | One to three pages | As long as the steps need, often with a checklist |
- States
- PolicyThe rule: what must be true
- ProcedureThe method: how it is made true
- Applies to
- PolicyEveryone in scope, named by role
- ProcedureThe people who perform each step
- Approved by
- PolicyLeadership or the board
- ProcedureThe process owner
- Changes when
- PolicyThe rule or the law changes
- ProcedureThe tool, team or regulator's question changes
- Contains
- PolicyPurpose, scope, rule, roles, exceptions, review cycle
- ProcedureNumbered steps, owner per step, system or form, record produced
- Proves
- PolicyThe commitment exists
- ProcedureThe commitment is kept
- Length
- PolicyOne to three pages
- ProcedureAs long as the steps need, often with a checklist
What sections should a policy and a procedure have?
Every policy we draft has the same seven parts, in this order:
- Purpose.
- Scope.
- The policy statements themselves.
- Roles and responsibilities.
- Exceptions and who approves them.
- Related documents.
- The revision block.
Every procedure has six parts:
- Purpose and scope, in one paragraph.
- The roles involved.
- The numbered steps, with an owner and a record for each.
- The forms and systems used.
- What to do when a step fails.
- The revision block.
The two templates look alike on the page, because they share the document ID convention and the revision block. They read differently on purpose, because a reader should know within a sentence which kind of document is in front of them.
ISO 9001:2015 calls both "documented information" (clause 7.5). It asks only that documented information be identified, formatted, reviewed and approved (clause 7.5.2) and controlled (clause 7.5.3) [3]. The distinction between the two kinds is the drafter's discipline, not the standard's requirement.
ISO has since withdrawn the 2015 edition and replaced it with ISO 9001:2026. The clauses cited here are from the 2015 text.
How do you split a document that is doing both jobs?
Start with the verbs. Sentences with "must", "will" and "is required to" are candidates for the policy. Sentences with "then", "open", "send", "record" and "file" are procedure.
Move the second group into a new document, give each step a number and an owner, and name the record it produces. What is left in the first document is usually close to a policy already. Add the scope, the exception route and the review cycle if they are missing.
Then give each document its own approver and its own revision block, and link them to each other. The policy's related-documents section names the procedure; the procedure's purpose paragraph names the policy it serves.
The order matters when you have many documents to split. Start with the ones an auditor or regulator has asked for, because those will be read soonest. Start too with the ones that change most often, because those are the ones the single-document format has been silently breaking.
When is one document enough?
A small organisation with one process owner can keep a policy and its procedure in one file, if the file has two clearly separated sections. Those sections need separate approvers and separate revision histories.
The test is whether the procedure section can change without the policy section being re-approved. If it can, the file is two documents sharing a cover. If it cannot, it is one document doing two jobs, and the first tool change will show it.
An employee handbook is the common case. It is mostly policy, with the procedures for leave, grievances and discipline either in appendices or in a separate SOP library that the handbook refers to.
An AML/KYC manual is the other common case. There the regulator expects both the policy commitments and the step-by-step procedures in one manual, in clearly labelled parts. Small businesses setting up their HR documents and financial services firms writing their first manual meet this question first.
Questions
- Do I need both a policy and a procedure?
- Most organisations need both a policy and a procedure for any rule an auditor or regulator will ask about. The policy shows that the rule exists and who approved it; the procedure shows how it is followed and which records show it was done.
- What is an SOP?
- A standard operating procedure (SOP) is a procedure written to a fixed template, so every process in the organisation reads the same way. It sits under a policy and sets out the steps, owners and records for one process.
- Can a policy and its procedure live in one file?
- A policy and its procedure can live in one file, as long as they are separate sections with separate approvers and revision histories. The policy section is approved by leadership and changes rarely; the procedure section is owned by the person who runs the process and changes when the process does. One file with one approver for both is where the trouble starts.
- Who should write a policy, and who should write a procedure?
- The policy is drafted for the people who have to apply it and approved by whoever carries the risk. The procedure is drafted with the person who does the work, because they know the steps and the records. PolicyDrafters drafts both from an intake that asks those people the questions, and our legal team reviews the result.
The documents this guide is about
Applies to
Employee handbook
An employee handbook is the document that sets out an employer's rules, benefits and procedures for its staff in one place, with an acknowledgement form that each person signs to record that they have read it.
$1,200 to $2,500
10 working days
SOP library
An SOP library is a set of standard operating procedures (SOPs) written to one template, listed in one register and changed under one change-control procedure.
$1,200 to $2,500
12 working days
AML/KYC manual
An AML/KYC manual is the document that sets out how a firm assesses its money laundering and terrorist financing risk, identifies and verifies its customers, monitors their activity, reports suspicion and proves that all of it happened.
$3,000 to $5,000
15 working days
Information security policy set
An information security policy set is the group of written policies and procedures that states how a company protects its systems and data: who may access what, how staff may use company devices, how incidents and outages are handled, which vendors may hold the data, and who owns each control.
$1,200 to $2,500
12 working days