Policy vs Procedure: The Difference, With Examples

Someone on your team opens the "Travel Policy" to find out how to file a hotel receipt. They scroll past three pages about who may travel and why. Then they give up and message finance. This is what happens when policies and procedures are mixed into one document: the rule and the steps get in each other's way.

This guide explains the policy vs procedure difference in plain terms. It shows where standards, guidelines, and work instructions fit, and gives you a quick test for sorting any statement into the right document.

Policy vs procedure: the short answer

A policy states what your organization requires and why. A procedure explains how to carry that policy out, step by step: who does what, and when. The policy sets the rule. The procedure makes it happen the same way every time.

The University of Connecticut's policy office puts it well. A policy is "a formal, high-level statement" that sets the organization's position on an issue. A procedure is "detailed step-by-step instructions on how to implement a policy or operationalize a process."

The difference between policy and procedure at a glance

The University of California's guidance for policy writers sums up the contrast in a simple table. Here is the same idea, slightly expanded:

The change-rate row matters most in practice. A policy can stay stable for years. Its procedure might change every time you switch software, reorganize a team, or find a faster way to do the work.

What is a policy?

A policy is a guiding rule. It expresses your organization's position and sets the limits people work within. Good policies are short, stable, and easy to point to.

A policy usually covers:

• Purpose: why the rule exists (compliance, safety, cost control, fairness).
• Scope: who and what it applies to.
• The rule itself: what is required, allowed, or prohibited.
• Ownership: who is responsible for the policy and its review.

Example (expense policy): "Employees are reimbursed for reasonable business travel costs that were approved in advance by their manager. Personal expenses are not reimbursed."

Notice what's missing: no forms, no app names, no deadlines in days. Those details change. The principle doesn't.

What is a procedure?

A procedure turns a policy into action. It lists the steps in order, names who owns each step, and says when things must happen. UConn's guidance says procedures should be "specific and actionable, detailing who does what, when and how."

Example (expense procedure):

1. Before booking, submit a travel request to your manager.
2. Keep itemized receipts for every cost you plan to claim.
3. Within the claim window set by finance, submit your expense report with receipts attached.
4. Your manager reviews and approves the report.
5. Finance checks the report against the policy and processes payment.

If finance moves to a new expense tool next year, you update this procedure. The policy above doesn't need to change at all.

Where standards, guidelines, and work instructions fit

"Policy vs procedure" is often really a question about the whole document family. Most organizations use some version of this hierarchy, from the broadest document to the most detailed:

1. Policy: the rule and the reason for it.
2. Standard: specific, mandatory requirements that support the policy.
3. Procedure: the ordered steps to meet the policy and standards.
4. Work instruction: detailed, task-level directions for one part of a procedure.
5. Guideline: recommended good practice, which people are encouraged but not required to follow.

You don't need every level for every topic. A small team might only need a policy and a procedure. A regulated manufacturer might use all five.

Policy vs procedure vs standard

A standard sits between the "what" and the "how." It turns a policy principle into specific requirements that everyone must meet. Otis College's information systems office groups standards with procedures as "requirements that must be met by everyone."

If your security policy says "systems must be protected by strong authentication," the standard defines what strong means: minimum password length, multi-factor sign-in, and so on. The procedure then explains how to set it up.

Policy vs guideline

The key difference is obligation. A policy must be followed. A guideline is advice. Otis College describes guidelines as "suggestions" for best practice.

Example: "Book economy class for flights" belongs in a policy or standard. "Booking two weeks ahead usually gets better fares" is a guideline. It's helpful, but nobody breaks a rule by ignoring it.

Keep guidelines clearly labeled. If readers can't tell a suggestion from a requirement, they'll either ignore the rules or treat every tip as mandatory.

Work instructions vs SOP

A standard operating procedure (SOP) describes how a whole process runs from start to finish, often across several roles. A work instruction zooms in on one task within that process, written for the person doing it.

Quality management guidance follows the same pattern. As QMS UK explains it, a procedure details "how a process should be carried out," while a work instruction "details how a procedure should be carried out," with enough detail that the person doing the work "know[s] exactly what is required." It also notes that ISO 9001 doesn't prescribe a fixed documentation structure. You can adapt the levels to suit your business.

Example: The SOP covers "processing a customer return." A work instruction covers "inspecting a returned item for damage," with photos of what to look for.

Policy vs SOP and policy vs process

People often ask about "policy vs SOP" or "policy vs process" as separate questions, but the answer is the same idea. A process describes what needs to happen and why, at a high level. An SOP is a formal, standardized procedure for carrying out that process. Neither replaces the policy. The policy is the rule they both serve.

A simple test: is this a policy or a procedure?

When you're reviewing a draft, read each statement and ask:

1. Does it say what is required or why? That's policy language.
2. Does it say how, when, or who, in a sequence? That's procedure language.
3. Would this sentence change if you switched tools or reorganized a team? If yes, it belongs in a procedure (or work instruction), not the policy.
4. Is it mandatory? If it's only a recommendation, move it to a guideline and label it.

Question 3 does most of the work. Any sentence that names a specific system, form, or job title is probably procedure detail hiding inside a policy.

Why keeping policies and procedures separate matters

It's tempting to put everything in one document. It feels complete. But separating them pays off in three ways.

Approvals stay manageable. The University of California advises policy writers to separate policies from procedures. The reason is that policies usually need "extensive review and executive-level approval." If a minor process tweak sits inside the policy, every small change triggers a full sign-off cycle. Separate the two, and the people who own the process can update the steps without waiting on the board.

Readers find answers faster. Shawnee State University notes that its policies "change infrequently, and set the course for the foreseeable future." Procedures are what people use day to day. When each type lives in its own place, an employee who needs the steps can go straight to them.

Audits get easier. When a reviewer asks how a policy is enforced, you can point to the linked procedure and its version history. You don't have to untangle a single document that mixes intent with instructions.

How to structure policies and procedures in your documentation

Separate doesn't mean disconnected. The goal is a clear chain from rule to steps:

• Give each policy its own short page. Purpose, scope, the rule, the owner, and the review date.
• Link every policy to its procedures. Add a "How to follow this policy" section that points to the procedure pages.
• Link each procedure back to its policy. Readers should always be able to see why a step exists.
• Use consistent templates. The same headings in the same order make every document easier to scan.
• Version and approve each level on its own schedule. Policies go through leadership sign-off. Procedures go through their process owner.
• Publish in one searchable place. If people have to hunt through shared drives, they'll follow whichever copy they find first, and it may be out of date.

This is where a documentation platform helps. In Sonat, you can draft policies in Google Docs, send them through approval workflows, keep a full version history of every topic, and publish policies and procedures as one connected, searchable site. Viewers are free, so everyone who needs to read the rules can.

Conclusion

The policy vs procedure distinction comes down to one idea: policies set the rule, procedures deliver it. Keep policies short and stable. Put the changing, step-by-step detail in procedures and work instructions. Label guidelines as advice. Then link everything together so readers can always move from "why" to "how."

Start with your most-read policy. Pull the step-by-step detail out into its own procedure, link the two, and watch how much easier both become to maintain.