How to Write a Policy: A 10-Step Guide With Template and Example

Published: November 9, 2026

To write a policy, confirm a policy is needed, name an owner, research the laws and standards that apply, define the purpose and scope, then draft clear rules in plain language using a standard template. Keep procedures separate, get the draft reviewed and approved, publish one controlled version, make sure the right people read it, and schedule regular reviews.

This guide walks through each of those 10 steps, shows which sections every policy needs, and includes a short example. It also covers a step most policy-writing guides skip: writing the policy so you can later prove who read which version. That matters when an auditor, regulator or tribunal asks.

What is a policy, and when do you need one?

A policy is a formal statement of what an organization requires, allows or prohibits, and why. It sets the rule. A procedure explains how to follow the rule, step by step. For a fuller explanation with examples, see what policies are and why they matter.

Write a policy when one or more of these is true:

• A law, regulation, standard or contract requires you to have written rules (for example, information security, data protection, health and safety or anti-harassment).
• The same decision keeps being made differently across teams or sites.
• A mistake would cause real harm: to people, data, money or your reputation.
• Employees need to know where the boundaries are and what happens if they cross them.

If you only need to explain how to complete a task, you probably need a procedure or work instruction, not a new policy.

How to write a policy in 10 steps

1. Confirm the need and define the problem

Write one or two sentences on what the policy must achieve and what goes wrong without it. Check that no existing policy already covers the topic. Two overlapping policies with different rules are worse than none. If one exists, update it instead.

2. Name an owner, an approver and the people to consult

Every policy needs a single owner who is accountable for its content and reviews, usually the head of the function it affects. Decide who approves it (an executive, a committee or the board) and who must be consulted: HR, legal, compliance, IT, unions or works councils where relevant, and a few of the people who will have to follow it.

3. Research the requirements

List every law, regulation, standard and contract that applies, and note exactly what each one requires. Look at your current practice, past incidents and audit findings, and at how comparable organizations handle the same issue. This research makes the policy defensible, and it gives you the “authority” references to cite in the document.

4. Define the purpose and scope

The purpose explains why the policy exists in a sentence or two. The scope says exactly who and what it covers (employees, contractors, volunteers, specific sites, systems or activities) and what it doesn’t cover. A clear scope prevents the most common question after launch: “Does this apply to me?”

5. Outline it with a standard policy template

Use the same structure for every policy so readers always know where to look. A typical structure:

You can start from our free policy template for Word. For more detail on each section, see the essential information every policy should include.

6. Write the policy statement in plain language

The policy statement is the heart of the document. Write it for the people who must follow it, not for lawyers:

• Use active voice. Say who does what: “Managers must approve overtime before it is worked,” not “Overtime must be approved.”
• Be consistent with obligation words. Use “must” for requirements, “must not” for prohibitions and “may” for permissions. Pick one word for each and use it throughout.
• Keep sentences short. One rule per sentence, and one topic per paragraph.
• Define terms once. Then use the same term every time.
• Avoid vague words. Replace “promptly” or “where appropriate” with a time limit or a clear condition.
• State the rule, not the steps. Steps belong in the procedure.

The US government’s plain language guide on digital.gov is a good free reference for writing clearly.

7. Separate the procedures

If the draft starts listing click-by-click steps, forms or system names, move them into a linked procedure. Policies change rarely and need formal approval. Procedures change more often and can usually be updated by the process owner. Keeping them apart means a new form or system doesn’t force the whole policy back through approval.

8. Review, consult and approve

Circulate the draft to the people you listed in step 2 and give them a deadline. Record the comments and what you did with each one. Have legal or compliance check it against the requirements from step 3, then get formal approval and record who approved it and when.

9. Publish one controlled version and make sure people read it

Publish the approved policy in one place, such as a SharePoint document library with version history turned on, and remove old copies from shared drives and intranet pages. Then tell the people in scope, explain what has changed, and give them a deadline to read it. For high-risk policies, ask each person to confirm they have read and understood it.

10. Schedule reviews and keep the history

Set a next review date based on risk. Many organizations review high-risk policies every year and lower-risk ones every two or three years. Review early when a law, system or incident makes the policy out of date. Each review should produce a new version, a version history entry and, if the change is material, a fresh round of acknowledgments. Our guide to policy reviews explains how to run each review and when staff need to accept the policy again.

Example: a short policy statement

Here is how the template and plain-language rules come together in a short policy statement for a remote working policy:

How to write policies and procedures together

When you are writing policies and procedures as a set, write the policy first and get it approved. Then write one procedure for each process the policy requires, and link them both ways. Each procedure should name the policy it supports, list the roles involved and give numbered steps. A policy and procedure manual can then group them by topic. See our guide to the policy and procedure manual for how to structure one.

Write it so you can prove it

Most policy-writing guides stop at approval. In regulated industries, the harder question comes later: can you show that a specific person had access to, read and accepted a specific version of the policy on a specific date? Plan for that while you write:

• Give every policy a version number and an effective date in the document itself, not just in the file name.
• Keep the old versions. Some rules set a retention period. For example, the HIPAA Security Rule requires covered entities and business associates to keep their written security policies and procedures for 6 years from the date of creation or the date they were last in effect, whichever is later. It also requires them to make the documents available to the people responsible for implementing them and to review them periodically (45 CFR 164.316(b)).
• Decide who must acknowledge the policy and by when, and write that into the roles and responsibilities section.
• Record acknowledgment against the version. A list of names in an email or a spreadsheet won’t show which version someone accepted after the policy changes.

Running policy writing in SharePoint

SharePoint document libraries give you co-authoring, approval, major and minor versions and version history, so drafts stay separate from the published policy. What SharePoint doesn’t do on its own is assign a policy to the people in scope, set a reading deadline, chase people who haven’t read it or record a time-stamped acknowledgment of the exact version. Our policy and procedure management software, DocRead, adds that inside SharePoint and Microsoft 365. It assigns policies to SharePoint or Microsoft Entra ID groups, sends reminders, escalates overdue readers to their managers and produces acknowledgment reports that export for auditors.

Policy writing checklist

• The need is defined and no existing policy already covers it.
• An owner, an approver and the consultees are named.
• The laws, regulations, standards and contracts are listed and addressed.
• The purpose and scope are clear, with exclusions stated.
• The standard template is used, with every section completed.
• Rules are written in plain language with consistent “must”, “must not” and “may”.
• Procedures are separated out and linked.
• Review comments are recorded and approval is documented.
• One controlled version is published and old copies are removed.
• Readers, deadline and acknowledgment requirements are set.
• The next review date and version history are recorded.

Frequently asked questions about writing a policy

How do I write a policy?

Confirm a policy is needed, name an owner, research the requirements, and define the purpose and scope. Draft the rules in plain language using a standard template, keep procedures separate, then get the draft reviewed and approved. Finally, publish one controlled version, make sure the right people read it and schedule a review.

What should a policy include?

Most policies include a title and version, purpose, scope, definitions, the policy statement, roles and responsibilities, compliance and exceptions, related documents, the authority it supports, the owner and approver, the effective and review dates, and a version history.

What is the difference between writing a policy and a procedure?

A policy states the rule and why it exists. A procedure explains how to follow the rule, step by step. Write and approve the policy first, then write procedures for each process it requires and link the two.

How long should a policy be?

As short as it can be while still covering the rules, scope and responsibilities. Many policies fit on two to five pages. If a policy grows much longer, the detail usually belongs in separate procedures.

Who should write and approve a policy?

The policy owner, usually the head of the function it affects, writes or leads the drafting with subject-matter experts. HR, legal and compliance review it, and a senior leader, committee or board approves it according to your governance rules.

What are the steps in developing a policy?

Developing a policy usually runs through: identify the need, assign ownership, research requirements, draft, consult, approve, publish and communicate, confirm people have read it, monitor compliance and review it on a schedule.

How often should a policy be reviewed?

Set the cycle by risk. Many organizations review high-risk policies every year and lower-risk ones every two or three years, and review early whenever a law, system or process changes.