Policy vs Procedure: The Rule and the Steps That Enforce It

TL;DR

A policy is the rule and the reason behind it. A procedure is the ordered set of steps that carries the rule out on the floor. Policies drive procedures: a policy without a matching procedure is only a statement of intent. Most operational rules need both, at different levels, with the policy short and stable and the procedure specific and kept current.

• A policy is a short, high-level statement of intent: what the rule is, who owns it, and why it exists. It rarely changes.
• A procedure is the specific, ordered sequence of steps that turns the policy into action, written for the person doing the task.
• SOPs and work instructions both live at the procedure level.
• Under ISO 9001:2015, a documented Quality Policy is mandatory (clause 5.2); the procedure is where that rule becomes enforceable, teachable, and auditable.
• Write the policy first, build the procedures underneath it, and keep those procedures easy to update, because the steps are what keep the rule honest.
• SOPX documents the procedure layer: record a task once and get structured, video-first steps that enforce the policy. It does not define the board-level policy itself.

Policy vs procedure (the rule vs the steps that enforce it)

A policy is the rule. A procedure is the set of steps that carry out the rule. The policy states what your organization has decided and why. The procedure shows how someone actually does the work so the decision holds up on the floor. As Quality Magazine puts it, “policies drive procedures,” and a policy without a matching procedure is just a statement of intent. See the difference between quality policies and procedures for the quality-authority view.

Put plainly: a policy tells people the boundary and the goal. A procedure tells one person the exact order of actions to stay inside that boundary. You usually need both, and they live at different levels of your documentation.

For a shorter reference version, see the sibling glossary entry: policy vs procedure.

What is a policy (definition)

A policy is a short, high-level statement of intent and direction. It sets a rule, assigns responsibility, and explains the reason behind a decision. Quality Magazine describes a policy as “a plan meant to incorporate your organization’s goals,” almost a mini-mission for one topic. A policy rarely changes, and it does not tell anyone which button to press or which valve to close.

Good policies answer three questions:

• What is the rule? For example, all cooked product must reach a safe internal temperature before it leaves the line.
• Who owns it? For example, the quality manager approves changes.
• Why does it exist? For example, to prevent foodborne illness and stay compliant.

A policy is decision-oriented. It is written for managers, auditors, and anyone who needs to know the organization’s position.

What is a procedure (definition)

A procedure is the sequence of steps that turns a policy into action. Quality Magazine describes a procedure simply: it “tells you actions to take.” A procedure is specific, ordered, and written for the person doing the task. It names tools, settings, checks, and the order they happen in.

Procedures are where a Standard Operating Procedure (SOP) and a work instruction live. If you are unsure how far down to go, our guide on the difference between SOPs and work instructions breaks down the layers. The short version, from the ISO 9001 QMS documentation structure: a procedure outlines the steps and activities followed to perform a process, while a work instruction goes further into one task, focusing on the sequencing of steps, the tools and methods to use, and the required accuracy. They differ mainly in scope.

A procedure is action-oriented. It changes more often than a policy, because tools, layouts, and equipment change.

A worked example (a food-safety policy and the procedure that enforces it)

Food production makes the relationship easy to see, because regulators are explicit about it.

The policy. A food plant sets a hygiene policy: every employee must wash hands before handling food, after breaks, and after any contamination. That is the rule, and it is short. It states the boundary and the reason (preventing foodborne illness).

The procedure. The policy on its own does not stop anyone from doing a five-second rinse. The procedure is what makes the rule real. A handwashing SOP lists each step: wet hands, apply soap, scrub for a set time, rinse, dry with a single-use towel, and use the towel to turn off the tap. Now the rule is enforceable, teachable, and auditable.

This is exactly how food-safety systems are structured. The FDA’s HACCP principles and application guidelines describe HACCP as “a systematic approach to the identification, evaluation, and control of food safety hazards,” and they state that a HACCP system must be “built upon a solid foundation of prerequisite programs” such as sanitation and employee hygiene. Those prerequisite programs are the policies. The written SOPs (like the handwashing sequence) are the procedures that carry them out. The policy sets the requirement; the procedure delivers it on the floor.

The same pattern holds outside food. A data-security policy might state that customer records must be encrypted and access limited to authorized staff. The procedure is the step list for granting access and revoking a leaver’s credentials. Rule at the top, steps underneath.

The mapping is easiest to see across a few domains side by side.

Do you need both a policy and a procedure

Usually, yes, but not always at the same weight.

You need a policy when there is a rule, an obligation, or a risk that management wants to own explicitly. Auditors and regulators look for the stated position. Under ISO 9001:2015, a documented Quality Policy is one of the mandatory documents for the standard (clause 5.2), so for certified quality systems the policy layer is not optional.

You need a procedure wherever the work is repeatable, safety-critical, or done by more than one person, or where the task must survive turnover. A policy with no procedure gets interpreted differently by everyone. A procedure with no policy can drift, because no one remembers the rule it was built to enforce.

The exception is a task so trivial or so rarely performed that a full procedure would cost more than the mistake it prevents. Even there, the policy still belongs in the manual. In practice, most operational rules deserve both: the policy names the rule, and one or more procedures show how to keep it.

How to write a policy and procedure manual

Developing a policy and procedure manual is less about writing and more about structure and upkeep. A manual that no one can find or trust is worse than none. Here is a practical order.

1. Set up governance before you write

Decide who owns each policy, who approves changes, and how often documents are reviewed. Policy-management guidance is consistent on this: review policies on a set cadence, usually every one to two years, and trigger interim reviews when something material changes. Assign an owner to every document so nothing goes stale silently.

2. Write the policy first, then the procedures under it

Start with the rule. Keep each policy to roughly one page: the statement, the scope, the owner, and the reason. Then list the procedures that enforce it. One policy often points to several procedures. Do not merge them into a single wall of text, because they change at different speeds.

3. Write procedures at the level of the person doing the task

Use plain language and short, ordered steps. State the tools, the settings, and the checks. For guidance on the right level of detail, see what to include in an SOP. If you are starting from scratch, our walkthrough on how to create SOPs covers the full process.

4. Make procedures easy to follow and easy to update

This is where most manuals fail. A binder written once and never touched drifts out of date the moment a machine or a step changes. Video-first procedures hold up better on a physical floor, because a short clip on each step removes ambiguity that words alone leave open. SOPX turns a single phone or screen recording into a structured procedure with a trimmed clip, a title, and a description on every step, so you can build the “how” layer of your manual without writing it by hand. See video to SOP for how that works, or start from a free SOP template.

5. Control versions and keep the manual searchable

Track versions, keep an approval trail, and make the whole set searchable so people find the current procedure instead of a printout from two years ago. When a step changes, update the one procedure and republish, rather than reprinting a binder.

One honest limitation: a policy and procedure manual also needs the governance layer itself, the ownership, the review calendar, and the sign-offs. SOPX is built for the procedure layer, the actual step-by-step documentation of physical and operational work. It documents the work rather than defining board-level policy. For the operational half of your manual, though, that is exactly the point: the rule is easy to write, and the steps that enforce it are the hard part. See pricing or start free with no credit card.

The short version

A policy is the rule and the reason. A procedure is the ordered steps that make the rule real on the floor. Most operational rules need both, sitting at different levels: the policy short and stable, the procedure specific and kept current. Write the policy first, build the procedures underneath it, and make those procedures easy to update, because the steps are what keep the rule honest.