At a glance
| Document type | HR policy template |
|---|---|
| Issued by | Employer |
| Templates included | 3 ready to use versions |
| Download format | Word (.docx) |
| Statutory reference | None cited on this page |
| Last reviewed | 26 August 2026 |
| Maintained by | Engage HR editorial team |
Policy, procedure, handbook and contract
These four get used interchangeably in conversation and are frequently merged in practice. Merging them is why policy documents become long and unusable.
| Policy | Procedure | Handbook | Contract | |
|---|---|---|---|---|
| Answers | What the rule is, and why. | How the rule is carried out, step by step. | What applies to me, across all subjects. | What was agreed with this individual. |
| Audience | Managers applying it and employees subject to it. | Whoever operates the process, often one function. | Every employee. | One employee. |
| Changes | Rarely, and deliberately. | Often, as systems and steps change. | On reissue. | By agreement only. |
| Where it goes wrong | Written as a description of intent rather than a usable rule. | Folded into the policy, so a system change requires a policy revision. | Reproducing contractual terms. | Reproducing policy text, which then dates. |
The nine sections every policy needs
This skeleton works for leave, travel, conduct, remote working or anything else. Sections that do not apply are removed rather than left with placeholder text.
- Header block. Policy name, version, effective date, owner, approving authority, next review date, and what it supersedes.
- Purpose. Two or three sentences on what the policy is for. Not a mission statement.
- Scope. Who it applies to, and expressly who it does not. Say whether contract staff, interns and consultants are covered, because that is the question that gets asked.
- Definitions. Only terms whose meaning is contested or specific to this policy. Three or four at most.
- The policy. The rule itself, stated so a manager can apply it. This is the section everything else exists to support.
- Exceptions and approvals. How to depart from the rule, who may approve it, and whether the approval is recorded. Its absence is why policies get quietly ignored.
- Responsibilities. What the employee, the manager and the owning function each have to do.
- Non-compliance. What follows from a breach, cross referring to the disciplinary policy rather than restating it.
- Related documents and review. What else to read, and when this will next be looked at.
The one section people add that they should not is a long background narrative. If the purpose needs more than three sentences, the policy is probably covering two subjects.
3 policy templates
HR Policy Template for blank policy template
The skeleton to start any policy from. Fill it in and delete what does not apply, rather than adapting a policy written for a different subject.
[Company Name] [Policy Name] POLICY Policy owner: [Owner Designation] Approved by: [Approving Authority] Version: [Version Number] Effective from: [Effective Date] Supersedes: [Previous Version and Date, or "None"] Next review: [Review Date] 1. PURPOSE [Two or three sentences on what this policy is for and what it is intended to achieve. State the problem it addresses, not the organisation's values.] 2. SCOPE This policy applies to [Categories Covered, for example all employees of [Company Name] at [Locations]]. It [also applies / does not apply] to [Categories, for example contract staff, consultants, interns and trainees]. [Where relevant: This policy does not apply to [Excluded Category], who are covered by [Other Policy Name].] 3. DEFINITIONS [Defined Term]: [Meaning as used in this policy.] [Defined Term]: [Meaning as used in this policy.] [Include only terms whose meaning is contested or specific to this policy. Delete this section if there are none.] 4. POLICY 4.1 [The rule, stated so a manager can apply it without asking.] 4.2 [Entitlement, limit, threshold or standard, with the figure or period stated.] 4.3 [How it operates in the ordinary case: what the employee does, what happens next, within what period.] 4.4 [Any variation by category, grade or location.] 5. EXCEPTIONS AND APPROVALS 5.1 A departure from this policy requires the prior written approval of [Approving Role]. 5.2 Requests for an exception are made to [Contact] with reasons, and are decided within [Decision Period]. 5.3 Approved exceptions are recorded by [Recording Owner] and do not create a precedent. 6. RESPONSIBILITIES Employees: [What the employee must do.] Managers: [What the reporting manager must do, including what they may and may not approve.] [Owning Function]: [What the owning function does, including maintaining records.] 7. NON-COMPLIANCE Failure to comply with this policy may be dealt with under the [Disciplinary Policy Name] at [Policy Location]. 8. RELATED DOCUMENTS [Related Policy Name] at [Location] [Related Policy Name] at [Location] [Form or System Name] at [Location] 9. REVIEW This policy is reviewed by [Owner Designation] every [Review Frequency], and earlier where [Trigger for Earlier Review, for example a change in law or in the systems referred to]. Approved: [Approving Authority] Date: [Date] VERSION HISTORY [Version] | [Date] | [What changed] | [Approved by]
HR Policy Template for worked example, short policy
The same skeleton filled in for a straightforward subject, to show how short a complete policy can be when the rule is clear.
[Company Name] MOBILE PHONE AND DEVICE ALLOWANCE POLICY Policy owner: [Owner Designation] Approved by: [Approving Authority] Version: [Version Number] Effective from: [Effective Date] Supersedes: [Previous Version and Date] Next review: [Review Date] 1. PURPOSE Some roles at [Company Name] require a work phone or a data connection to do the job. This policy sets out who is eligible, what is reimbursed, and how to claim it, so the position is the same across teams. 2. SCOPE This policy applies to all employees of [Company Name] at [Locations] whose role is listed as eligible in Annexure A. It does not apply to contract or outsourced staff, whose devices are provided under their engagement with [Contractor Name]. 3. DEFINITIONS Eligible role: a role listed in Annexure A, as revised from time to time by [Owner Designation]. Claim period: the calendar month to which the expense relates. 4. POLICY 4.1 Employees in an eligible role may claim reimbursement of mobile and data charges up to the monthly limit set for their grade in Annexure A. 4.2 Reimbursement is against an itemised bill in the employee's own name for the claim period. Prepaid recharges are reimbursed against the recharge receipt. 4.3 Claims are submitted through [Expense System] within [Claim Period] of the end of the month to which they relate. Claims submitted after that are not reimbursed. 4.4 Where [Company Name] issues a device or a corporate connection, no reimbursement is payable in addition. 4.5 The device and connection are for work use. Reasonable personal use is accepted. [Company Name] does not monitor the content of personal calls or messages. 5. EXCEPTIONS AND APPROVALS 5.1 A claim above the grade limit, or by an employee not in an eligible role, requires the prior written approval of [Approving Role]. 5.2 Requests are made to [Contact] with reasons, and decided within [Decision Period]. 5.3 Approved exceptions are recorded by [Recording Owner] and do not create a precedent. 6. RESPONSIBILITIES Employees: submit claims within the period with a valid bill, and tell [Contact] if the role or number changes. Managers: confirm the claim relates to work use before approving. [Owning Function]: maintain Annexure A, process approved claims in the [Payroll Cycle], and report spend to [Reviewing Body] every [Reporting Frequency]. 7. NON-COMPLIANCE Submitting a claim that is not genuine may be dealt with under the [Disciplinary Policy Name] at [Policy Location]. 8. RELATED DOCUMENTS [Expense Reimbursement Policy Name] at [Location] [Acceptable Use Policy Name] at [Location] Annexure A: eligible roles and monthly limits 9. REVIEW Reviewed by [Owner Designation] every [Review Frequency], and earlier if tariffs or the eligible role list change materially. Approved: [Approving Authority] Date: [Date]
HR Policy Template for policy register
The document that stops a policy set decaying. One row per policy, reviewed as a whole rather than one document at a time.
[Company Name] HR POLICY REGISTER Maintained by: [Owner Designation] Last reviewed: [Review Date] Next review of this register: [Next Register Review Date] HOW TO USE THIS REGISTER Every HR policy in force at [Company Name] has a row here. A policy not on this register is not in force. When a policy is created, revised or withdrawn, this register is updated in the same action. Columns: policy name | owner | approved by | version | effective from | last reviewed | next review | location | status TIER 1: REQUIRED OR EFFECTIVELY REQUIRED Prevention of Sexual Harassment | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Internal Committee constitution order | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Leave | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Attendance and hours of work | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Disciplinary and misconduct | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Grievance | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] TIER 2: NEEDED ONCE THERE ARE MANAGERS BETWEEN YOU AND THE WORK Code of conduct | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Travel and expense | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Remote and hybrid working | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Performance review | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Exit and separation | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Information security and acceptable use | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] TIER 3: ADD AS THE ORGANISATION GROWS Whistleblower | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Conflict of interest and gifts | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Referral | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Learning and development | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Diversity and inclusion | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] Asset issue and return | [Owner] | [Approver] | [Version] | [Effective Date] | [Last Reviewed] | [Next Review] | [Location] | [Status] WITHDRAWN POLICIES [Policy Name] | withdrawn [Date] | superseded by [Policy Name] | archived at [Location] REVIEW NOTES Policies overdue for review as at [Review Date]: [List] Policies naming a contact who has left: [List] Policies referring to a system no longer in use: [List]
What it has to contain
| Element | Why it matters |
|---|---|
| A named owner | A policy owned by the organisation in general is owned by nobody. When it needs revising, or someone asks how it applies, there has to be a person whose job that is. |
| A version number and effective date | Policies get revised and old copies circulate. Without a version and a date, the rule in force when the thing being argued about happened. |
| An explicit scope, including who is not covered | The question managers actually ask is whether it applies to contract staff, interns and consultants. A scope that lists only the included categories leaves that unanswered and every manager answers it differently. |
| The rule stated so it can be applied | A policy describing an intention rather than a rule leaves the decision with the manager, which is what the policy existed to prevent. If two managers reading it would decide the same case differently, it is not finished. |
| An exceptions route with a named approver | Every rule meets a case it does not fit. Where there is no stated way to depart from it, departures happen informally and unevenly, and the policy stops describing what the organisation does. |
| A review date | Policies decay quietly: contacts leave, systems are replaced, thresholds move. A review date is what turns maintenance into a scheduled task rather than something triggered by a complaint. |
| A cross reference rather than a restatement | Where a policy needs to refer to discipline, leave or another policy, it should point rather than repeat. Repeated text is a second version that will eventually disagree with the first. |
How to write one
- Start from the decision, not the subject. Write down the actual decision a manager has to make and cannot currently make confidently. That decision is the policy. Starting from the subject produces a document that covers everything about travel and still does not say whether a particular booking is allowed.
- Check what the contract already says. Anything fixed in the appointment letter should not be restated in a policy. Where the two overlap, decide which instrument owns the term and remove it from the other.
- Write the rule before the framing. Draft section 4 first, in as few sentences as the rule needs. Then work outward to scope, definitions and responsibilities. Policies drafted front to back accumulate preamble and arrive at the rule exhausted.
- Decide the exception route deliberately. Name who can approve a departure and whether it is recorded. This is the section that determines whether the policy survives contact with real cases, and it is the one most often left out.
- Test it against three real cases. Take three situations that actually happened and apply the draft. If it does not resolve them, or resolves them in a way nobody would accept, revise before approving rather than after the first complaint.
- Put it in the register when you approve it. Add the row in the same action as the approval. A policy set without a register becomes a folder of documents whose currency cannot be confirmed.
- Review the register, not the policies. Reviewing twenty policies individually never happens. Reviewing one register quarterly, and pulling the rows that are overdue or name someone who has left, does.
What order to build a policy set in
Template packs list policies alphabetically, which is the least useful order. The order worth following is what causes trouble first.
First, the ones that are required or effectively required. A policy on prevention of sexual harassment, alongside a constituted Internal Committee, is not optional. Leave and attendance come next because they generate the most day to day questions and the most inconsistency between managers. Then discipline and grievance, because those are the ones you cannot draft calmly once you need them.
Second, the ones that matter once there are managers between you and the work. Code of conduct, travel and expense, remote or hybrid working, performance review, exit, and acceptable use of systems. The common thread is that each of these is a decision managers are currently making differently from one another.
Third, the ones that come with size. Whistleblower, conflict of interest and gifts, referral, learning and development, diversity and inclusion, asset issue and return. Several become obligations at particular thresholds, so these are the ones to revisit as the organisation crosses them.
The test for whether a policy is needed yet: has this decision been made inconsistently, or has someone had to escalate it more than once? If not, the policy can wait, and writing it now means approving a rule nobody has tested.
Writing a rule a manager can actually apply
Most policies fail not because the rule is wrong but because it is not a rule. It is a description of an intention, and it leaves the decision exactly where it was.
Compare two versions of the same clause. The first says the organisation supports flexible working arrangements where business needs permit. The second says an employee may work remotely up to two days a week, chosen with their manager, provided the team maintains its agreed coverage, and that a request for more requires the approval of the function head. Only the second resolves a case.
The diagnostic is straightforward: give the draft to two managers with the same scenario and see whether they reach the same answer. Where they do not, the clause is doing less work than it appears to.
Three habits produce applicable rules. State thresholds as numbers rather than as reasonableness. Say who decides where a judgement is required, rather than leaving it unattributed. And write the ordinary case fully before adding qualifications, since a rule that opens with its exceptions is read as optional.
Keeping the set alive
The failure mode for a policy set is not that a policy is wrong. It is that the set gradually stops describing the organisation, and everyone quietly learns not to rely on it.
The decay is almost never about the rule. It is that the named contact left eighteen months ago, the expense system was replaced, the office in the scope section closed, or a threshold moved and only one of four policies referring to it was updated. Each is trivial in isolation. Together they teach people that the documents are out of date, after which they stop consulting any of them.
A register handles this at a cost that is actually sustainable. One row per policy, with owner, version, effective date, review date and location. Reviewing twenty policies individually never happens; pulling the overdue rows from one register quarterly does.
Three checks at each review catch most of the decay: which policies are past their review date, which name a person who has left, and which refer to a system no longer in use. None requires reading the policies in full, and all three are the things that make a policy set look abandoned.
Common mistakes
| Mistake | Why it causes trouble | What to do instead |
|---|---|---|
| Adopting a template pack without editing it | The policies refer to roles, systems and thresholds the organisation does not have. Managers notice quickly that the documents do not describe the place they work, and stop consulting any of them. | Take the skeleton, write the rule yourself against your own decisions, and delete every section that does not apply rather than leaving placeholder text. |
| Folding procedure into policy | The policy now contains the steps for a particular system, so replacing the system means revising and re-approving the policy. In practice the policy is not revised and goes stale instead. | State the rule in the policy and point to the procedure separately, so operational change does not require policy approval. |
| No exceptions section | The first case the rule does not fit is handled informally by whoever is asked. That becomes the precedent, applied unevenly, and the written policy stops describing what actually happens. | Name an approver, a route and a record for exceptions, and state that an approved exception does not create a precedent. |
| Restating contractual terms | Notice periods, probation or pay structure now exist in a policy as well as the appointment letter. When one is updated, the employee relies on whichever is better for them. | Keep individual terms in the appointment letter and have policies cross refer rather than repeat. |
| No register | Nobody can say how many policies are in force, which are current, or whether the copy someone is quoting is the latest. Withdrawn policies keep circulating. | Maintain a register with one row per policy, updated in the same action as any approval or withdrawal, and review the register on a schedule. |
| Writing every policy at once | A set of twenty policies drafted in one exercise is approved without anyone having applied them, and most describe situations the organisation has not yet encountered. | Write the ones covering what already causes trouble, and add the rest as the need appears. |
Frequently asked questions
What should an HR policy include?
A header block with owner, version, effective date and review date. The purpose in two or three sentences, the scope including who is not covered, and any definitions specific to the policy. The rule itself, stated so a manager can apply it, with an exceptions route and a named approver. Then responsibilities, what follows from non-compliance by cross reference, and related documents.
Which HR policies does a company need first?
The ones that are required or effectively required, then the ones already causing inconsistency. In practice that means prevention of sexual harassment with a constituted committee, leave, attendance and hours, discipline and grievance. Code of conduct, travel and expense, remote working, performance and exit follow once there are managers between the founders and the work.
What is the difference between an HR policy and a procedure?
The policy states the rule and why it exists; the procedure states the steps for carrying it out. Keeping them separate matters practically, because procedures change whenever a system or a form changes, and folding them into the policy means every operational change needs a policy revision and re-approval.
How long should an HR policy be?
As long as the rule needs and no longer. A complete policy on a straightforward subject fits comfortably on two pages. Length usually comes from preamble, from restating other policies, or from the policy covering two subjects that should be separated.
Who should approve HR policies?
Set it by significance rather than approving everything at the same level. Policies with legal exposure or organisation-wide cost warrant approval at board or leadership level; operational policies can sit with the function head. Record the approving authority on the policy itself so the question is not reopened at each revision.
How often should HR policies be reviewed?
Set a review date on each policy, and review the register at least quarterly. The common decay is not the rule going wrong but the detail around it: contacts who have left, systems replaced, locations closed, thresholds moved in one policy and not the others.
Can we use a downloaded HR policy template as it is?
As a skeleton, yes. As finished text, no. Adopted packs refer to roles, systems and thresholds the organisation does not have, and managers notice immediately that the documents do not describe where they work. Take the structure, write the rule against your own decisions, and delete what does not apply.
Should HR policies be in the employee handbook?
The handbook should summarise them and point to them, not contain them. Policies revised on their own cycles will diverge from any copy reproduced in the handbook, and reproducing them means every revision requires reissuing the handbook and re-obtaining acknowledgements.
The policy register in Engage
Engage holds each policy with its owner, version, effective date and review date as fields rather than as text inside the document, so the overdue list is a query rather than a manual audit. Acknowledgements are recorded per employee against the version they received, and reissuing a version raises acknowledgement requests to everyone in scope.
Book a demo