Policy and procedure template: what to include and how to make it stick
A simple policy and procedure template — with examples, a "new person test" to check if it works, and the most common reasons teams stop following their own documents.
Most teams postpone writing policies until something breaks. By then it has already cost them: a confused new hire, a missed approval, a repeated mistake. A clear policy and procedure template stops that pattern before it starts.
Policy vs. procedure: what’s the difference?
Teams often write one without the other. That is usually why the document stops working in practice.
A policy sets the rule. It answers: what must happen, or what is allowed? Example: “All employees must complete security training annually.”
A procedure shows how to follow it. It answers: what are the steps? Example: the sequence for submitting a vacation request.
Both belong in the same document. A policy without a procedure leaves people guessing how to comply. A procedure without a policy has no authority behind it.
What should a policy and procedure template include?
One test: can a new person follow this document on day one without asking anyone? If yes — it works. If not — something is missing.
A strong template covers eight fields:
- Title — the name of the policy or procedure
- Purpose — why this document exists, in one or two sentences
- Scope — who it applies to: teams, roles, or situations
- Policy statement — the rule, written clearly and directly
- Procedure / Steps — the sequence that explains how to do it
- Responsibilities — who owns each part
- Related documents — links to related policies or SOPs
- Version and review date — when it was created and when it gets reviewed
The review date is the most underused field. Set it when you create the document. A policy nobody reviews becomes a policy nobody follows.
Policy and procedure template
Copy this and fill it in. Keep the policy and procedure sections separate — that split is what makes the document scannable.
Policy title: [Name of the policy]
Purpose: [Why this policy exists — 1–2 sentences]
Scope: [Who this applies to — teams, roles, situations]
Policy statement: [The rule or requirement — clear and direct]
Procedure:
1. [First step]
2. [Second step]
3. [Continue as needed]
Responsibilities: [Who does what]
Related documents: [Links to related policies or SOPs]
Version: [1.0] — Last reviewed: [Date]
If the document grows past one page, it probably covers two separate policies. Split it.
Policy and procedure examples
Two examples — one for HR, one for finance. Same structure, different rules.
Example 1: remote work policy
Policy title: Remote work policy
Purpose: To define expectations for employees working outside the office.
Scope: All full-time employees eligible for remote work after 90-day onboarding.
Policy statement: Employees may work remotely up to three days per week with manager approval.
Procedure:
1. Submit remote work request to manager via task system.
2. Manager approves or declines within 2 business days.
3. Approved requests are logged in the team calendar.
Responsibilities: Employee — submit request. Manager — approve and log.
Version: 1.0 — Last reviewed: [Date]
Why it works: the rule and the steps are separate. The timeline and owners are specific. No guessing.
Example 2: expense approval procedure
Policy title: Expense approval policy
Purpose: To ensure business expenses are reviewed before reimbursement.
Scope: All employees submitting expense reports.
Policy statement: Expenses over $100 require manager approval before purchase.
Procedure:
1. Employee submits expense form with receipt.
2. Manager reviews within 3 days.
3. Finance processes approved expenses on the 15th and last day of the month.
Responsibilities: Employee — submit with receipt. Manager — approve. Finance — process.
Version: 1.0 — Last reviewed: [Date]
Why it works: the $100 threshold removes ambiguity. The deadlines are exact. The chain of responsibility has no gaps.
When this template doesn’t work
The structure is simple. The failure modes are predictable.
Nobody approved it. A document without sign-off has no authority. If the policy came from one person without team input, people will treat it as a suggestion.
The procedure is too detailed. Step-by-step instructions that cover every edge case become outdated the moment the process changes. Keep steps high-level — details belong in a separate SOP.
The other two problems are simpler: no named owner means nobody updates it, and a document that covers five scenarios at once becomes unreadable. One policy, one situation. If the scope runs longer than two sentences, split it.
How to create a policy and procedure document in Vaiz
In Vaiz, the document lives inside the same project as the work it supports. That keeps it visible when the team needs it — not buried in a shared drive.
- Open a project and create a new document.
- Paste the template above and fill in the fields.
- Share the document with the relevant team.
- Create a task with a due date set to the review date.
Conclusion
The hardest part is not writing the policy — it is keeping it current. Most teams write the document and move on. Six months later the process has changed and the document has not. Set the review date on day one and treat it as a real deadline. For teams documenting repeatable processes, this guide to building a project management workflow is a useful next step.