Policies and procedures are the operating system of any well-run organization - they define what's expected and how things get done. With Trupeer, you can save hours on writing policies and procedures by starting with free policy and procedure templates, customizing them with your brand guidelines, and turning dense policy documents into video walkthroughs employees actually watch.

What is the difference between a policy and a procedure?

A policy states a rule and a position. It says what must happen, what is not permitted, and who decides. It is written in the language of obligation, changes rarely, and is approved by whoever carries the risk.

A procedure describes how something is done, step by step, by whoever does it. It changes whenever the systems or the process change, and it is owned by the team performing the work rather than by governance.

A process, which appears alongside both in most guides, is the broader flow that a procedure sits inside, usually spanning several roles and several procedures.

The practical test is the verb. If you find yourself writing must, may not, or is required to, you are writing policy. If you are writing click, check, send or confirm, you are writing procedure. Documents containing large amounts of both are usually two documents that have been bound together, and our SOP template covers the procedural half properly.

Why most policy libraries contain documents nobody needs

Search for policy templates and you will be offered fifteen, thirty or a hundred and more. Every list is presented as a starting point, and most organisations treat it as a shopping list.

The result is predictable. A library assembled from templates and consultants' checklists, grown over a decade, containing policies nobody remembers commissioning, on subjects nobody has ever had a problem with, referencing job titles that no longer exist.

This is worse than having fewer policies, for a specific reason. A library people cannot trust stops being consulted at all. Staff learn that looking something up is slower and less reliable than asking a colleague, and once that habit forms, the policies that genuinely matter go unread alongside the ones that do not.

So the question is not which policies should we have. It is which policies can we justify, and the justification has to be nameable.

How to customize this template in Trupeer

Step 1: Open the Templates Section

Go to the Templates section from the main navigation.

Step 2: Select and Open a Template

Click on any template you want to work with to open it.

Step 3: Expand the Template View

If needed, expand the template view to see the full layout and details clearly.

Step 4: Edit the Template

Click on Edit to start modifying the selected template.

Within the editor, you can:

• Add new sections

• Define or update formatting rules

• Add a logo and adjust its position and related settings

Step 5: Save Your Customized Template

After making all necessary changes, click Save to store the updated template as your own.

Step 6: Preview and Fine-Tune the Template

When you want to see how your customized template looks, open the Preview.

From the preview screen, you can continue to make adjustments directly if needed, ensuring the template appears exactly as you want.

With policy and procedure templates you can:

• Save hours on writing: Skip the blank page with proven structures for any policy.

• Stay compliant: Built-in sections cover the elements regulators and auditors expect.

• Stay on-brand: Apply your logo, fonts and colors using Trupeer's brand kit.

• Improve adoption: Convert long PDFs into video walkthroughs employees actually finish.

• Standardize globally: Use the same templates across regions, with local adaptations.

• Reach every employee: Translate policies into 65+ languages with one click.

Every policy needs an origin you can name

Add one field at the top of every policy: why this exists. Not the purpose, which is always some version of ensuring consistency, but the origin.

There are three legitimate ones.

A legal or regulatory obligation. Name it. Data protection legislation, health and safety duties, sector regulation, employment law. If a specific statute or regulator requires this policy, the policy has an origin.

An external requirement short of law. A certification standard, an insurer's condition, a customer's contractual requirement, a funder's terms. These are real and they should be named specifically, including which clause.

An incident or a known risk. Something happened, or something nearly happened, and the organisation decided to prevent a recurrence. Record what it was and when.

A policy with none of the three exists because a template pack included it. That does not automatically make it worthless, but it does mean nobody will review it, nobody will enforce it, and it will sit in the library diluting everything around it.

The exercise of filling this field in retrospectively across an existing library is uncomfortable and it is the single most useful thing a governance function can do.

The verification test: who checks, how, and how often

The second field is the one that turns a policy from a statement into a control.

For every policy, answer three things. Who checks that it is being followed. By what method, meaning an audit, a sample, a system report, a manager sign-off. And at what frequency.

If you cannot answer all three, you do not have a policy. You have a stated preference, and the organisation has no way of knowing whether it is being followed.

That is not always a reason to delete it. Sometimes it is a reason to build the verification, particularly where the policy carries real risk. But it should be recorded as a finding rather than left implicit, because an unverifiable policy is a specific kind of exposure: you have told a regulator, an insurer or a customer that you do this, and you cannot demonstrate it.

Where a document is genuinely useful and genuinely unverifiable, relabel it. Call it guidance, give it a team owner rather than a governance approval route, and take it out of the policy library. Guidance is a legitimate and useful category, and pretending guidance is policy is what makes a library untrustworthy.

Free policy and procedure templates: the structure to copy

Copy from here. The two fields marked with an asterisk are the ones standard templates omit.

Header. Policy title. Reference number. Version. Approved by, and date. Effective date. Review date. Owner, as a role rather than a person.

Origin. The obligation, requirement or incident that requires this policy, named specifically.

Purpose. One paragraph. What this policy is for, in plain terms.

Scope. Who it applies to and where, including any group explicitly excluded. Contractors and agency staff are the most common omission.

Definitions. Only terms whose meaning changes the policy's effect. Not a glossary.

Policy statements. Numbered. Each one a single obligation, written with must, may or must not. Avoid should, which is not enforceable and appears in almost every weak policy.

Roles and responsibilities. Who does what under this policy, by role.

Verification. Who checks compliance, by what method, at what frequency, and where the evidence is kept.

Breaches. What happens when the policy is not followed, and who handles it.

Related documents. The procedures that implement this policy, by name and location, rather than restated here.

Revision history. Date, version, what changed, who approved.

Copy to here. Note what is not in the list: steps. If your policy contains numbered instructions for using a system, they belong in a separate procedure that this document references.

Which policies does your organisation actually need?

Work from obligations rather than from a template list.

Start with what the law requires for an organisation of your type, size and sector. In most jurisdictions that is a short and specific list covering health and safety, data protection, employment matters and anything sector specific. Your legal adviser can produce it in an hour and it is worth the hour.

Add what your certifications, insurers, funders and larger customers require. These arrive with clause references, so the origin field writes itself.

Add the ones your own history demands. Look at your incident log, your complaints, your near misses and your insurance claims from the last three years. Anything that happened twice deserves a policy or a procedure.

Then stop. Do not add policies because a list of thirty templates suggests them. The right number for a small organisation is often under fifteen, and for a mid-sized one rarely above sixty. Libraries of two hundred are almost always the accumulated residue of template packs rather than a considered set.

The housing association with 187 policies and 104 orphans

Ferndale Housing manages around nine thousand homes with four hundred and fifty staff. Its policy library held a hundred and eighty seven documents, built up over roughly fifteen years from template packs, consultants and successive compliance projects.

The governance lead ran a trace exercise: for each document, name the obligation or the event that requires it.

Forty one traced to a statutory or regulatory requirement. Twenty three traced to a certification, insurer or funder condition. Nineteen traced to a specific past incident. A hundred and four had no traceable origin at all.

Of those hundred and four, sixty eight had never been reviewed since the day they were created. Thirty one referenced job titles that no longer existed. Twelve contradicted another policy in the same library.

One contradiction had already cost them. Two policies gave different thresholds for when a repair becomes an emergency, one saying twenty four hours and one saying four hours for the same category of fault. Contact centre staff applied whichever they had been trained on. A complaint escalated to the ombudsman turned partly on which policy applied, and the resolution took three weeks of legal and executive time plus a compensation award.

The deeper cost showed up in a staff survey. Seventy one percent of frontline staff said that when they needed to know what the rule was, they would ask a colleague rather than look it up.

The clear-out took a quarter. Of the hundred and four orphans, twenty two turned out to have a genuine origin that nobody had recorded and were rewritten with it. Nineteen were reclassified as guidance, explicitly labelled, with a team owner and no approval route. Sixty three were withdrawn.

The library went from a hundred and eighty seven documents to a hundred and five.

Every surviving policy then had the origin and verification fields added. Fourteen could not answer the verification field at all, which was recorded as a governance finding rather than a documentation gap, because it meant the organisation had rules it had no way of knowing were being followed. Within a year, nine of those fourteen had a verification route and five had been downgraded to guidance.

Twelve months after the clear-out, the proportion of frontline staff who said they would look up a policy rather than ask a colleague had risen from twenty nine percent to fifty eight.

How to write a policy that people can follow

Write the policy statements first and everything else afterwards. The purpose, scope and definitions are easier to write once you know what you are actually requiring, and doing them first tends to produce a long preamble around a thin rule.

Use must and must not. Should is the word that appears when the author is uncomfortable committing, and a policy full of shoulds cannot be breached, which means it cannot be enforced.

Number every statement, one obligation per number. Statements containing two obligations joined by "and" get complied with halfway.

Write for the person who has to comply, not for the regulator who might read it. Both audiences are real, and the compliance audience is the one that determines whether anything actually happens. Where regulatory language is unavoidable, put it in an appendix.

Name roles rather than people, and check that every role named still exists.

Then test it: give it to someone who has to follow it and ask them what they would now do differently. If the answer is nothing, either the policy describes what already happens, which is fine but should be acknowledged, or it is too abstract to act on.

Language and tone that make a policy usable

Short sentences and the active voice. "Managers must approve expenses over £500" rather than "expenses in excess of £500 are subject to managerial approval".

Second person where the policy applies to individuals, third person where it applies to the organisation. Mixing them in one document is common and confusing.

Plain terms rather than legal ones, unless the legal term carries meaning the plain one does not. Where you must use a defined term, define it once and use it consistently, and resist the urge to vary the wording for elegance.

Concrete thresholds rather than judgements. "Within two working days" is enforceable. "Promptly" is not.

And avoid the passive constructions that hide the actor. "It is expected that" tells nobody what to do. If you cannot name who must act, the statement is not ready.

Should a policy and its procedure be one document?

Usually not, and the reason is maintenance rather than tidiness.

The two have different approval routes. A policy typically needs board, executive or committee approval. A procedure needs the operational owner. Bind them and every procedural change, including one caused by a system update, requires re-approval at the policy level. In practice the update does not happen, and the combined document quietly becomes wrong in its procedural half while remaining formally approved.

They also change at very different rates. A data protection policy might change every two or three years. The procedure for handling a subject access request changes whenever the case management system does.

Keep them separate and link them. The policy names the procedures that implement it. The procedure states which policy it serves. Where the procedure is a single high consequence change on live systems, a method of procedure is the right shape, and where it is a recurring operational task, an SOP or a job aid is.

Company policy templates and where each one belongs

The common company policy set divides into groups with different owners, which is worth knowing before you download anything.

Employment and conduct. Disciplinary, grievance, absence, equality and diversity, flexible working, whistleblowing. Owned by HR, approved with legal input, and heavily shaped by jurisdiction. These are the ones where a generic template is riskiest.

Health, safety and environment. Health and safety policy, risk assessment, incident reporting, and any sector specific duties. Frequently required by statute above a certain headcount, with a prescribed form.

Information and technology. Acceptable use, information security, data protection, remote working, and procurement. Our IT procurement policy template is a worked example of one of these written properly, including approval routing and thresholds.

Financial and commercial. Expenses, delegated authority, anti-bribery, conflicts of interest, procurement thresholds.

Operational and sector specific. Whatever your regulator, accreditation or service model requires.

Take templates from the third and fourth groups readily, adapt them and move on. Take templates from the first two with considerably more care, because the content is jurisdiction specific and the cost of getting them wrong is not a documentation problem.

Healthcare policy and procedure templates: what is different

Healthcare policies attract a lot of search traffic and they are genuinely a different discipline, so it is worth being direct about it.

Three things change. Clinical policies require clinical governance approval and clinical authorship, and a generic template cannot supply either. The content is tied to specific regulators and accreditation bodies, whose requirements are prescriptive and vary by country and by care setting. And retention, version control and evidence of staff acknowledgement are usually mandated rather than good practice, so the surrounding process matters as much as the document.

The structure on this page will work for the administrative and operational policies a healthcare organisation needs, meaning procurement, information governance, HR and facilities. It should not be used to draft clinical policy.

For clinical content, work from your regulator's requirements and your professional bodies' guidance, and have the policy authored and approved through clinical governance. This is one of the few cases where starting from a template is genuinely the wrong approach.

More generally, nothing on this page is legal or compliance advice. Employment, safety, data protection and sector regulation all vary by jurisdiction, and any policy in those areas should be reviewed by a qualified adviser before it takes effect.

Can I get a policy and procedure template in Word or PDF?

Word or Google Docs for drafting and for the working copy, since policies go through several rounds of comment and approval and the revision history matters.

PDF for the published version. A policy in force should be fixed, version stamped and dated, so that everybody is reading the same document and you can evidence which version applied on a given date. That last point matters more than it sounds when something is disputed.

Excel for the policy register rather than the policies. One row per document with title, reference, owner, approval date, review date, origin, verification method and last verified. That register is what makes a library manageable, and it is the artefact most organisations lack. Sorting it by review date and by origin will tell you more about your governance in ten minutes than reading any individual policy.

How to keep procedures current when policies change slowly

Separating the policy from the procedure solves the approval problem and creates a maintenance one: you now have more documents, and the procedural half changes constantly.

That half is where the effort goes, because updating a procedure means somebody re-screenshotting and rewriting steps for a system they already know how to use, and that work always loses to something urgent.

Trupeer AI removes most of it. Whoever performs the task records it once, and the output is a written procedure with the steps and screens already captured, ready to check rather than compose. The policy stays stable and approved, and the procedures underneath it can be refreshed in an afternoon when a system changes.

Record it. Brand it. Translate it. Trupeer it.

The SOP creator covers the procedures themselves, documentation keeps the policies and their linked procedures together, and where the policy set describes how a whole function runs, our operational manual template covers assembling that view without duplicating content. Setup instructions are in the document template setup guide.

Frequently Asked Questions

Is there a free policy and procedure template in Word?

The structure above pastes straight into Word or Google Docs, including the origin and verification fields that standard templates omit. There is no gated download and no form. Lock the header block when you save it as your house template, because the review date and owner fields are the ones most often left blank.

Is there a policy and procedure template in PDF?

Publish in PDF and draft in a document editor. The published version should be fixed and version stamped so that you can evidence which version was in force on a given date, which is the point at which a policy library either helps you or does not.

Is there a simple policy template for a small organisation?

Yes, and simpler is usually better. Header, origin, purpose, scope, numbered statements, responsibilities, verification, breaches, review date. That is one page and it is a complete policy. Small organisations get into difficulty by adopting large template packs rather than by writing policies that are too short.

Where can I find company policy templates to download?

Plenty of libraries offer them and the caution is about which groups you take from. Financial, commercial and operational templates adapt well. Employment, health and safety and data protection templates are jurisdiction specific and should be reviewed by an adviser before use, because the cost of an inherited error there is not a documentation cost.

Who should approve a policy?

Whoever carries the risk it addresses, which for most organisational policies means an executive or a board committee, and for operational ones the function head. The test is whether the approver could be held accountable if the policy turned out to be inadequate. If nobody could, the approval is administrative and the policy will not be enforced.

How often should policies be reviewed?

Annually for anything with a legal or regulatory origin, and every two to three years for the rest, plus a trigger review whenever the law changes, an incident occurs in that area, or the responsible role changes. Calendar reviews alone produce a lot of documents reissued unchanged, so the triggers matter more than the cycle.

How long should a policy be?

One to three pages for most. Longer usually means procedure has crept in, or that regulatory text has been reproduced rather than referenced. If a policy cannot be read in five minutes by the people it applies to, it will be read by nobody except an auditor.

What is the difference between a policy, a procedure and a process?

A policy is the rule and who decides. A procedure is the steps for one task, performed by one role. A process is the wider flow those procedures sit within, usually crossing several roles and ending in an outcome. Policies govern processes; procedures implement them.