Policy vs Procedure: Writing IT Policies People Follow

Updated: October 2026

A policy nobody follows is usually a procedure in the wrong place, or a procedure that was never written. IT teams mix the two because both live in the same shared drive and both open with "all staff must". This guide sorts policy and procedure into their layers, follows one rule from the page to the checklist, and shows how to write the documents people follow.

Policy vs Procedure: What Each Document Answers

A policy answers "what do we require, and why". NIST defines an information security policy as an "aggregate of directives, regulations, rules, and practices that prescribes how an organization manages, protects, and distributes information" (SP 800-12 Rev. 1). It is written for leadership, auditors and every employee who has to live with it.

A procedure answers "who does what, in what order". It is written for the person doing the task, and it should read like instructions, not like law.

Two more layers sit between them. A standard sets the measurable bar that makes a policy testable. A guideline gives advice where people have a choice. Many arguments about policy vs procedure end once those two layers exist, because the sentence nobody could place now has somewhere to go.

The frameworks agree on the split. The Govern function in NIST's Cybersecurity Framework 2.0 has a Policy category (GV.PO) with two jobs: policy is established, communicated and enforced, then "reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission". Notice what is missing: nothing in that category says to write the click path. Our guide to an IT governance framework covers where policy sits in the wider structure.

One Rule, Four Layers

Take a rule every IT team writes: leavers lose access. Here is how it reads at each layer. The numbers are example values, so set your own.

Policy: Access to company systems ends when employment ends.

Standard: Leaver accounts are disabled within four hours of the HR notice, and mailbox and file ownership move to the manager before anything is deleted.

Guideline: Prefer converting the mailbox to shared over setting up forwarding.

Procedure:

1. Confirm the leaver ticket and the end date from HR.
2. Disable the account and revoke active sessions and tokens.
3. Remove MFA methods and registered devices.
4. Convert or delegate the mailbox, then transfer file ownership.
5. Collect hardware and record the asset tags.
6. Close the ticket with the time of each step.

Each layer moves at its own speed. The policy survives for years. The standard changes when your risk appetite does. The procedure changes every time a vendor renames a menu. Put step 2 inside the policy and a menu change forces a leadership sign-off, so people stop updating it, and the document starts being wrong. The template and review habits for the procedure layer live in our guide to what SOPs are.

Patching is the other place where the layers blur. The cadence is a standard, the approval path is policy and the deployment steps are procedure. Read the r/msp thread titled "Patch Policy" below with the table above open, and sort each reply into a layer.

Ask the same question of every rule you own: where does the "why" sit, where does the number sit, where do the steps sit? Three different documents is the right answer.

Why IT Policies Get Ignored

Staff skip policies for predictable reasons, and each one has a fix on the writing side.

Steps hiding inside the policy. A policy that tells people which menu to open is out of date by the next vendor update. Readers learn the document is wrong and stop trusting the rest of it. Move the steps to a procedure and link them.

A template that describes someone else's company. A borrowed policy names tools you do not own, roles nobody holds and approvals that do not exist. Cut every sentence you cannot check against how the team works today.

No owner, no date. A policy with no named owner has nobody to ask and nobody to fix it. Give every document one owner, a version and a review date.

No way to say no. When a rule has no exception route, people route around the rule. A short path (who approves, for how long, and where it is logged) keeps the exceptions visible instead of hidden.

A rule with no check. "Devices must be encrypted" is a wish until something reports encryption status per device. The standard supplies the threshold, and the check supplies the evidence.

Sorting Sentences Into the Right Layer

Every rewrite starts with a document that already exists and mixes everything. Read it one sentence at a time and ask four questions in this order. Does it name a tool, menu, command or click? It belongs in a procedure. Does it contain a number, version or setting someone could check? It belongs in a standard. Is it advice with room to choose? It belongs in a guideline. Is it a requirement with a reason? That is the policy, and it should be short.

Run "Staff must use MFA" through the gates and it lands in policy. "MFA uses an authenticator app or security key, not SMS" is a standard. "Open Security info and add a method" is a procedure. "Prefer the authenticator app on managed phones" is a guideline. The same topic needs all three, and each one is shorter than the document that tried to be all of them.

Writing a Policy People Follow

The policies that get followed are short enough to read in a minute and specific enough to check. Seven parts cover it:

• Purpose: one sentence on the risk the policy exists to reduce.
• Scope: who and what it covers, including contractors and personal devices.
• Rules: three to seven "must" statements, each one testable.
• Owner: a named person, not a team alias.
• Exceptions: who approves, for how long, and where it is recorded.
• Review date: the next date, written on the page.
• Links: the standards and procedures that carry the detail.

Skip the legal padding unless a lawyer asks for it. Our BYOD policy template is a worked example of a single-topic policy.

Then make the policy reachable. Put it where staff already look, link it from onboarding and ask for an acknowledgment when it changes, not once at hire. An r/msp thread, "Where Should Your AI Policy Reside?", asks that question for an AI policy.

Keeping Policy and Procedure Current

Review each layer on its own clock. Policies get an annual check, standards get a check when the tooling changes, and procedures get a check after any incident where the steps were followed and the result was still wrong. Write the review date on the document and the owner's name next to it.

Short explainers help new hires place the layers quickly, and this one covers the four-way split in a few minutes:

A standard also needs a way to be tested. If you run OpenFrame, that check can be a script run across a client's devices with the output collected, so the standard returns a result instead of a promise.

Start small. Pick the one rule that causes the most arguments on your team, split it into policy, standard and procedure, and publish all three on the same day. If your documentation is scattered, our guide to IT documentation tools is the next read.