How to Write an Effective Organisational Policy: Structure, Process & Examples
July 31, 2026 · Professional Development · 6 min read
An organisational policy should make a rule, expectation or decision framework clear enough that the people affected can understand what applies, who is responsible and what happens next. It should not be written merely to make the organisation look formal. A policy that is difficult to interpret is difficult to apply consistently.
Good policy writing therefore combines governance, subject-matter accuracy, plain language, consultation and implementation. The exact legal requirements vary by jurisdiction and subject, so an internal policy template should never replace local legal review where the policy creates or reflects legal obligations.
Policy, procedure and guideline are not the same thing
| Document | Primary purpose |
|---|---|
| Policy | States the organisation’s rule, position, principle or required standard |
| Procedure | Explains the steps used to carry out a process |
| Guideline | Provides recommended practice where some judgement or flexibility is expected |
| Form or checklist | Captures information or helps users complete a defined process |
These documents can work together. A leave policy might state eligibility and responsibilities, while a separate procedure explains how an employee submits a request.
Start with the problem the policy needs to solve
Before drafting, answer:
- What decision, risk or inconsistency is this policy intended to address?
- Who is affected?
- Which laws, contracts, regulations or existing policies constrain the content?
- Who owns the policy?
- Which managers or teams will need to implement it?
- What procedure, form or training will be needed alongside it?
If the purpose is unclear, the document often becomes a collection of generic statements rather than an operational policy.
A practical organisational policy structure
| Section | What it should answer |
|---|---|
| Purpose | Why does the policy exist? |
| Scope | Who and what does it apply to? |
| Definitions | Which terms need a specific meaning? |
| Policy statements | What is required, permitted, prohibited or recommended? |
| Responsibilities | Who must do what? |
| Related procedures | How is the policy put into practice? |
| Exceptions and escalation | Who can approve exceptions and how are questions resolved? |
| Records | What evidence or documentation must be retained? |
| Owner and approval | Who owns and formally approves the policy? |
| Version and review | When was it approved and when will it be reviewed? |
Write requirements precisely
The UK Cabinet Office Functional Standards writing guide recommends plain English and careful distinction between requirements, recommendations, permissions and possibilities. An organisation does not need to copy that exact terminology, but it should choose its own conventions and use them consistently.
Source: UK Cabinet Office, Functional Standards writing style guide
For example, avoid:
“Managers should ensure appropriate action is taken promptly.”
Prefer wording that identifies the actor, action and timing:
“The line manager must record the incident in the case system within two working days.”
Where a requirement comes from law, regulation or contract, confirm the wording with the relevant legal or compliance owner rather than turning an assumption into a mandatory internal rule.
Use plain language without removing necessary precision
GOV.UK guidance requires clear language because people need to understand what they are expected to do. The same principle is useful inside organisations: short sentences, meaningful headings, active voice and defined technical terms make policies easier to use.
Source: GOV.UK, Use clear language
Plain language does not mean removing legal or technical terms that are genuinely required. Define them when necessary and use them consistently.
Consult the people who will apply the policy
Consultation can reveal implementation problems before the document is approved. Acas guidance on workplace rules and procedures emphasises clarity, accessibility, consistency and employee involvement where appropriate.
Source: Acas, Code of Practice on disciplinary and grievance procedures
Depending on the subject, useful reviewers can include:
- employees or representatives affected by the policy;
- line managers who will apply it;
- HR or people teams;
- legal, compliance, risk or information-security specialists;
- operations teams who own the underlying process;
- accessibility or inclusion specialists.
Check accessibility as well as legal accuracy
A technically correct policy can still fail if employees cannot find or understand it. GOV.UK accessibility guidance recommends meaningful headings, simple structure, clear language and accessible document formats.
Source: GOV.UK, Publishing accessible documents
Policies should also be available through a reliable location such as the intranet or document-management system, with obsolete versions clearly superseded.
Approval is not implementation
Once approved, decide how the policy becomes part of normal work. That can include:
- manager briefings;
- employee communications;
- training for roles with specific responsibilities;
- updated forms or systems;
- linked procedures and checklists;
- monitoring of recurring questions, exceptions or breaches.
If managers interpret the policy differently, the solution may be clearer wording, better training or a better procedure, not simply another reminder email.
Control versions and review intelligently
A review date is useful, but policies should also be reviewed when something material changes, such as:
- law or regulation;
- organisation structure;
- technology or systems;
- new operating risks;
- employee feedback showing that the policy is unclear;
- repeated exceptions or implementation failures.
Record the version, approval date, owner and material changes so people can see which policy is current.
Writing policies across GCC and African organisations
Do not copy a policy from another jurisdiction and assume the legal obligations transfer. Employment, data protection, health and safety, whistleblowing, discrimination, working time and other requirements vary significantly by country.
A regional organisation may use one policy framework but maintain country-specific schedules, procedures or legal notes where local requirements differ. Legal review should focus on the jurisdictions where the organisation actually operates.
A policy-drafting checklist
- Purpose is clear.
- Scope is explicit.
- Definitions are used only where needed.
- Mandatory and recommended language is distinguishable.
- Responsibilities have named owners or roles.
- Related procedures are linked.
- Exceptions and escalation are defined.
- Legal and compliance review has been completed where required.
- Employees and implementers have been consulted appropriately.
- The document is accessible and written clearly.
- Version, owner, approval date and review trigger are recorded.
- Implementation and training are planned.
Frequently asked questions
What should an organisational policy contain?
At minimum, enough information to explain its purpose, scope, requirements, responsibilities and ownership. Additional sections depend on the subject and risk.
What is the difference between a policy and a procedure?
A policy states the rule or organisational position. A procedure explains the steps used to carry it out.
How often should a policy be reviewed?
Use a planned review cycle, but also review when legal, organisational or operational changes make the current version unreliable.
Should every policy be legally reviewed?
Not necessarily. The level of review should match the subject and risk. Policies involving employment law, regulated activity, contractual rights or other legal obligations may need specialist review.
Related MATSH training
For teams that need structured practice in drafting, consultation and implementation, see the MATSH Policy Writing Course.
Sources
Need In-House Training?
We run all our courses as private programmes for organisations across the GCC and Africa.
Request In-House →