How to Write Policies and Procedures That People Actually Follow

Every organisation has policies. Most of them sit in a shared drive, unread, until someone gets in trouble and HR pulls up the document to prove "we told them." That's not a policy — it's a liability shield that nobody follows because nobody reads it.

The problem isn't that employees are negligent. The problem is that most policies are badly written: too long, too vague, full of legal language nobody understands, and disconnected from how work actually gets done.

A well-written policy is clear, specific, and actionable. People follow it because they understand it, not because they're afraid of it.

Policy vs Procedure: The Critical Distinction

Policies and procedures serve different purposes and should be written differently:

A common mistake is combining policies and procedures into one document. This creates long, dense documents that try to serve two audiences. Keep them separate. The policy states the rule; the procedure explains how to follow it.

Essential Policy Sections

Every policy should include these sections:

1. Title

Clear and specific. "Social Media Policy" is better than "Policy 47" or "Communications and Digital Engagement Framework."

2. Purpose

Why this policy exists — in 2-3 sentences. Connect it to a business need, not just a compliance requirement.

Weak: "This policy exists to comply with relevant legislation." Strong: "This policy ensures that all company social media activity protects our brand reputation, maintains client confidentiality, and complies with advertising standards."

3. Scope

Who the policy applies to and in what circumstances. Be explicit about inclusions AND exclusions.

Example: "This policy applies to all employees, contractors, and agency staff who post on social media in a professional capacity or who reference the company on personal accounts. It does not apply to personal social media activity that does not mention or reference the company."

4. Definitions

Define every term that could be interpreted differently by different readers.

5. Policy Statements

The core rules. Each statement should be:

• Clear — one interpretation possible
• Specific — not open to "reasonable person" debates
• Actionable — the reader knows exactly what to do (or not do)
• Enforceable — you can verify compliance

Vague policy statement:

"Employees should use good judgment when posting on social media."

"Good judgment" means different things to different people. This is unenforceable.

Clear policy statement:

"Employees must not share client names, project details, or financial information on any social media platform without written approval from the Communications Manager. Employees must include a disclaimer ('Views are my own') when discussing industry topics on personal accounts where their employer is identified."

6. Responsibilities

Who is responsible for what. Name roles, not individuals.

7. Compliance and Consequences

What happens if the policy is breached. Be specific about the escalation path.

Example: "Non-compliance with this policy may result in disciplinary action in accordance with the Disciplinary Policy (POL-005), up to and including termination of employment. Breaches involving disclosure of confidential information will be reported to the Information Security team for investigation."

8. Related Documents

Link to related policies, procedures, guidelines, and forms. A policy doesn't exist in isolation.

9. Version Control and Review

Writing Style for Policies

Use Plain Language

Policies written in legal language don't get read. Plain language policies do.

The test: if someone needs a law degree to understand your policy, rewrite it.

Use Consistent Terminology

Pick one term and stick with it throughout the document. Don't switch between "employees," "staff," "workers," "personnel," and "team members" — it creates confusion about whether different groups have different obligations.

Be Specific About Requirements

Using "should" for mandatory requirements is a common and dangerous mistake. If it's required, say "must."

Avoid Weasel Words

Writing Procedures

Procedures accompany policies — they explain HOW to comply. Procedure writing follows different conventions:

Use Imperative Mood

Procedures tell people what to do. Write direct commands.

Don't write: "The employee should submit the form to their manager." Write: "Submit the form to your manager."

Number Every Step

Numbered steps create a clear sequence and make it easy to reference specific steps ("see Step 7").

Include Decision Points

When a procedure involves choices, make the conditions explicit:

5. Check the invoice amount
6. If the invoice is under $1,000: approve and process (proceed to Step 8)
7. If the invoice is $1,000 or over: forward to the Finance Manager for approval (proceed to Step 9)

Specify Systems and Tools

Don't say "enter it in the system." Say "enter it in SAP (transaction code: ME21N)." Specificity eliminates guesswork.

Include Expected Timeframes

3. Submit the completed form within 5 business days of the incident
4. The HR Manager reviews the form within 2 business days of receipt
5. The HR Manager notifies the employee of the outcome within 3 business days of the review

Common Policy Writing Mistakes

Mistake 1: Too Long

A 20-page policy on desk cleanliness signals that the organisation has lost perspective. If the policy can be stated in 2 pages, use 2 pages. Long policies don't get read.

Guideline by policy type:

Mistake 2: No Review Date

Policies without review dates become outdated. Processes change, regulations update, systems evolve. An outdated policy is worse than no policy — it creates a false sense of compliance.

Mistake 3: Inconsistent With Other Policies

Policies should reference and align with each other. If the Travel Policy says expenses over $500 need pre-approval but the Expense Policy says the threshold is $1,000, you have a conflict that undermines both policies.

Mistake 4: Written Once, Never Updated

A policy is a living document. It should be reviewed at least annually and updated whenever:

• Regulations change
• Business processes change
• An incident reveals a gap
• Technology systems are upgraded
• Organisational structure changes

Mistake 5: No Consultation

Policies written without input from the people they affect are policies that don't reflect reality. Consult with managers and team members before finalising. They'll identify gaps, ambiguities, and impractical requirements that a policy writer sitting in head office wouldn't see.

Reviewing Policies Before Rollout

Configure a policy reviewer with these criteria:

Review process:

1. Draft the policy with input from stakeholders
2. AI review for plain language, completeness, and specificity
3. Legal/compliance review for regulatory alignment
4. Stakeholder review (managers and affected staff) for practicality
5. Final approval by policy owner
6. Communicate to all affected staff with a summary of key requirements
7. Set the review date and calendar reminder

Maintaining a Policy Library

As your policy library grows, maintain it systematically:

Frequently Asked Questions

How often should policies be reviewed?

At minimum, annually. High-risk or regulatory policies (data protection, health and safety, anti-money laundering) should be reviewed every 6 months or whenever regulations change. Set calendar reminders for every review date.

Who should approve policies?

The policy owner (typically a department head or functional leader) drafts and owns the policy. Approval should come from one level above the policy owner. Organisation-wide policies may require executive or board approval.

How do I communicate a new policy to staff?

Don't just email it. Summarise the key points in plain language, explain why the policy exists, highlight what's changed (for updates), and provide a link to the full document. For significant policies, hold a brief team session to walk through the key requirements and answer questions.

What's the difference between a policy and a guideline?

A policy is mandatory — compliance is required and non-compliance has consequences. A guideline is recommended — it suggests best practice but allows flexibility. Use policies for requirements and guidelines for recommendations. Don't label something a "guideline" if you intend to enforce it.

How do I handle policy conflicts?

When two policies conflict, the more specific policy typically takes precedence over the more general one. Document the hierarchy explicitly: "Where this policy conflicts with the Information Security Policy, the Information Security Policy takes precedence." Then fix the conflict in the next review cycle.

Key Takeaways

• Policies state what and why. Procedures explain how. Keep them separate.
• Use plain language. If someone needs a law degree to understand it, rewrite it.
• Be specific. Replace "appropriate," "reasonable," and "timely" with defined standards and timeframes.
• Use "must" for mandatory requirements, "should" for recommendations. Don't mix them.
• Every policy needs a review date. Outdated policies create false compliance.
• Consult stakeholders before finalising — the people affected will identify gaps the writer won't see.
• Review before rollout — check for plain language, completeness, specificity, and consistency with related policies.
• Maintain a central policy library with version control, consistent numbering, and a review schedule.

---

This article is for informational purposes. Policy requirements vary by industry, jurisdiction, and organisation. Always ensure policies comply with relevant legislation and seek legal advice for policies with regulatory implications.