Policy vs Procedure: One Says Why, One Says How

A new ops manager I worked with sent the whole company a two-page document titled "Remote Work Policy." It listed core hours, a rule that laptops stay on the VPN, and a line about who approves exceptions. All reasonable. Within a day the questions started landing in the team channel: How do I actually request a remote day? Where's the form? Who do I send it to? The policy answered none of that, because that isn't a policy's job. She'd written half of what people needed and called it finished.

This mix-up is everywhere. Teams write a policy when they needed a procedure, or they bury six steps inside a rule nobody can act on, then wonder why nothing gets followed. Policy vs procedure isn't a pedantic distinction. Get the two confused and you either hand people rules with no way to obey them, or steps with no idea why they matter. Both get ignored.

So let's draw the line clearly, show where a "process" fits, and walk through a real pair you can copy.

The difference in one line

A policy is the rule. A procedure is the steps. A policy states what's expected and why; a procedure says how to do it, in order.

Most teams also have a third thing sitting between the two: a process. A process is the path a piece of work travels from start to finish, usually across more than one person or team. Stack all three and they each answer a different question.

Read top to bottom, each layer gets more specific. The policy sets the boundary. The process shows the journey. The procedure is the hands-on instructions for one stop on that journey. An SOP, if your team uses the term, is just a procedure written to a higher standard of precision, with a fixed structure, an owner, and a review date.

Policy, process, procedure: what each one actually does

The one-liner gets you 80 percent of the way. Here's the rest, with examples from the teams that ask about this most.

Policy: the rule and the reason

A policy answers "what's the rule, and why does it exist?" It sets expectations and boundaries, and it usually leaves some room for judgment. An HR paid-leave policy says employees get 20 days a year and should request time off in advance. An IT acceptable-use policy says company devices are for work and must stay patched. A support team might have a refund policy that says refunds over a certain amount need a manager's sign-off.

Notice what policies don't do: they don't tell you which button to press. They change rarely, they're usually owned by leadership, HR, legal, or security, and they're the document an auditor wants to see.

Process: the journey across teams

A process answers "what happens, in what order, and who hands off to whom?" Hiring is a good example: it runs from a recruiter screening candidates, to a hiring manager interviewing, to IT provisioning a laptop, to finance setting up payroll. No single procedure covers all of that, because it crosses four teams. The process is the map that shows how the work moves between them. If you want to get this part right, we've written a full guide on how to document a process and a deeper process documentation guide.

Procedure: the steps for one task

A procedure answers "how do I do this, exactly?" It's written for one person doing one task, with the steps in order and nothing left to guess. "To request remote work: open the HR portal, fill out form HR-12, submit it at least 48 hours ahead, wait for your manager's approval." That's a procedure. It's owned by the person who actually does the task, it changes whenever the tool or the steps change, and it should read cleanly enough that a first-timer can follow it without asking anyone. When a procedure gets formal structure and a review schedule, you've got an SOP; when it's a single short task, it's often called a work instruction. Same family.

A real example, side by side

Theory is easy to nod along to and hard to apply, so here's one topic written both ways. Remote work, the thing that tripped up the ops manager at the top.

The policy is the rulebook. It says the company supports remote work to give people flexibility, that everyone is expected online during core hours of 10 to 4, that staff can work remotely up to three days a week, and that anything beyond that needs director approval. It explains the why and sets the limits. It does not mention a form, a portal, or a button. That's deliberate.

The procedure is the instruction manual for one task inside that policy: requesting a remote day. Open the HR portal. Click "Time & Location." Choose the dates. Pick "Remote" from the dropdown. Add a one-line reason. Submit at least 48 hours ahead. Your manager gets a notification and approves or declines in the same tool. Done.

Same subject. The policy tells you what's allowed and why; the procedure gets you through the task. Put both in one document and you get a mess: the moment the HR portal renames a button, you'd have to reissue the entire remote-work policy to fix one step. Keep them as two linked docs and each updates on its own clock.

A policy + procedure template

Steal this. It's two short blocks, one for each job, with the procedure linked from the policy so they stay independent. Fill in the brackets and delete what you don't need.

The policy block points at the procedure; the procedure block never repeats the rule. Each one does its single job.

Which one do you need to write?

When someone asks you to "document the remote work thing," they rarely say which layer they mean. Three questions sort it fast.

Are you stating a rule or describing an action? A rule ("staff may work remotely three days a week") is policy. An action ("click Submit") is procedure. If you catch yourself writing both in the same breath, you're holding two documents, not one.

Does the work cross more than one team? If yes, and people keep losing track of who picks it up next, you probably need a process map on top of the individual procedures. If it's one person doing one task start to finish, a procedure is enough.

Could a first-timer do it from what you wrote? If not, you wrote a policy and called it a procedure. The fix is to add the missing steps as their own doc, the way the ops manager eventually did once the questions piled up.

For most teams the gap isn't policies. Leadership tends to have those. The gap is procedures: the actual steps live in someone's head, never written down, and walk out the door when that person does. If you've felt that, our piece on capturing tribal knowledge goes deeper, and IT teams will recognize the same pattern in SOPs and runbooks.

Keep the pair in sync

Here's the part nobody warns you about. Policies age slowly; procedures age fast. A vacation policy can sit untouched for two years. The procedure for booking vacation breaks the week HR switches portals. So the failure mode is almost always a stale procedure hanging off a perfectly good policy, sending people to a button that moved.

Two habits keep the pair honest. First, give each layer its own owner and review date, and never reissue the whole policy just to fix a step. Second, make the steps cheap to update, because the expensive part of a procedure is the screenshots. Every time a screen changes, someone has to recapture, crop, and re-annotate, and that chore is exactly why so many procedures quietly rot.

This is where a tool earns its place. With WriteHow, you record yourself doing the task once and AI drafts the procedure for you: ordered steps with screenshots and annotations already in place, ready for you to review and approve before it goes live. When the screen changes, you re-record instead of rebuilding by hand, and you can publish the same steps in 50+ languages for a global team. The policy stays where it lives; the steps stay current without becoming a second job. AI does the first draft, you keep the final say.

Get the layers straight and the rest falls into place. Write the rule as a policy, the journey as a process when the work crosses teams, and the task as a procedure a tired first-timer can follow. Then keep the steps fresh, because a procedure that lies is worse than no procedure at all.