Most practices fail an indicator not because the policy is wrong, but because the document and the day-to-day reality do not match. This guide walks how to write a policy and procedure that holds up: one that maps to a real requirement, reads clearly, and is backed by the records that show it runs. For how policies fit the wider accreditation picture, see the RACGP accreditation pillar; this is the procedure for writing one.
Before you begin
Decide which requirement you are writing for and gather what already exists. You almost never start from nothing: there is usually an old version, a template, or an informal practice that staff already follow. If you are not sure which policies you need, the template recommender maps your framework to the documents that apply, so you write the ones that count rather than guessing.
Step 1: Identify the requirement the policy must satisfy
Start from the standard, not the topic. Find the specific indicator, regulation, or obligation the policy exists to meet (a RACGP indicator, a Privacy Act requirement, an NDIS Practice Standard) and write it down. A policy that is not tied to a requirement is hard to assess and easy to get wrong.
Knowing the source requirement also tells you the scope: what the document must cover to be compliant, and what is optional detail. Write to the requirement first, then add practice-specific detail.
Step 2: Start from a template, not a blank page
Work from a proven structure rather than inventing one. A template gives you the headings an assessor expects (purpose, scope, responsibilities, the procedure, related documents) and stops you from leaving out a required section. Our template library covers the common practice policies; the complaints handling policy is a worked example of the shape a good policy takes.
Adapt the template to your practice rather than dropping it in unchanged. An assessor can spot a generic document that names systems you do not actually run, so make every clause describe what your practice really does.
Step 3: Write the policy and the procedure as two distinct parts
Keep the two jobs separate, because they answer different questions. The policy states what your practice does and why (the position, the principle, the obligation it meets). The procedure states who does what, in what order, with what tools, to carry the policy out. A reader should be able to follow the procedure as a set of steps.
Name real roles, not people, so the document survives staff turnover (write "the practice manager", not a person's name). Where a step produces a record, say so: that record is the evidence that the system runs, and naming it here is what ties the document to its proof.
Step 4: Add version control and a review date
Make the document auditable. Add a version number, the approval date, who approved it, and the next review date, usually in a small table in the header or footer. An assessor checks that a policy is current and has been reviewed on schedule, so an undated or unversioned document is a finding on its own.
Set a realistic review cycle (commonly annually, or sooner if the law or your systems change) and record it where you will see it. A policy that was right three years ago but was never reviewed is treated as out of date.
Step 5: Implement it, then capture the records that prove it runs
A signed policy that no one follows is worse than none, because it documents the gap. Brief the staff who are bound by it, make it findable (not in a drawer), and build the procedure into the actual workflow. Training staff on a new or changed policy is itself a record worth keeping.
From here on, the procedure should generate evidence as a by-product: the log, the register, the completed checklist. That running evidence, not the document alone, is what an assessor wants to see, so design the procedure so the proof falls out of doing the work.
What good looks like
- The policy names the exact requirement it satisfies.
- Policy (what and why) and procedure (who does what, in order) are clearly separated.
- Roles are named, not individuals, so it survives staff changes.
- A version number, approval date, and review date are on the document.
- The procedure produces records, and those records exist.
Common mistakes: copying a generic template that describes systems you do not run, blending policy and procedure into one vague block, leaving off version control and review dates, and writing a document no one is trained on or follows.
Frequently asked questions
What is the difference between a policy and a procedure?
A policy states what your practice does and why (the position and the obligation it meets). A procedure states how it is done: who does what, in what order, with what tools. Assessors expect both, and the common mistake is writing the policy but not the step-by-step procedure that makes it real.
Can I just download a template and use it as is?
A template is the right starting point, but it must be adapted to your practice. An assessor can tell when a document names systems or roles you do not actually have. Use the template for structure, then rewrite the content to describe what your practice really does.
How often should a policy be reviewed?
Most practices review policies annually, and sooner whenever the underlying law, standard, or system changes. The key is that the review actually happens on the schedule the document states, because an unreviewed policy past its review date is treated as out of date.
Who should approve a practice policy?
Approval should sit with someone accountable for that area, usually the practice owner, principal, or practice manager, and the document should record who approved it and when. That approval line is part of the version control an assessor checks.
How do I prove a policy is actually being followed?
Through the records the procedure generates: training logs, registers, completed checklists, audit results. The document shows the system exists; the records show it runs. Design each procedure so that doing the work leaves behind the evidence.
Key terms
Part of
RACGP AccreditationLast reviewed