Writing a compliance policy that survives an audit: structure, approval and version control

What makes a policy auditable

A policy is auditable when a third party can read it, identify the obligation it discharges, find the approval that gave it authority, confirm which version was in force on a given date, and locate the records proving people were told about it. Everything else is drafting quality.

That test defeats most policy suites. The document itself is usually fine. What fails is the surrounding apparatus: no approval record, no version history, no distribution evidence, no owner, and no way to establish what the policy said eighteen months ago when the conduct in question occurred.

Some Australian policies have prescribed content. A privacy policy must contain the matters set out in Australian Privacy Principle 1.3 — covered in what an APP entity's privacy policy must contain. A whistleblower policy for a public company, large proprietary company or corporate trustee of a registrable superannuation entity must address the matters listed in Part 9.4AAA of the Corporations Act, and the whistleblower policy builder generates a draft against those headings. Where content is prescribed, drafting to the statutory list is the first test an auditor runs.

Policy, standard, procedure: which document are you writing

Most audit findings labelled "policy weakness" are actually document-hierarchy failures — the policy contains procedural detail that changes every quarter, so it is either constantly out of date or never updated.

Write the policy so it survives a system change. If replacing a payroll platform requires a board-approved policy amendment, the detail sat at the wrong level.

The standard policy structure

A compliance policy that reads well to an auditor carries these sections, in this order:

1. Purpose. One paragraph. What outcome this policy exists to achieve.
2. Scope. Which entities, which people (including contractors and labour hire), which activities, which jurisdictions. Scope gaps are where breaches live.
3. Obligation basis. The specific Acts, rules, codes, licence conditions or contractual commitments discharged, cited by name and section. This is the field that links the policy to the obligations register.
4. Policy statements. Numbered, each expressed as a requirement using "must". Avoid "should", "endeavour" and "where practicable" unless the underlying law uses that formulation.
5. Roles and responsibilities. Named roles against each requirement, including who approves exceptions.
6. Exceptions and escalation. How an exception is requested, who may grant it, how long it lasts, where it is recorded. A policy with no exception route generates undocumented non-compliance.
7. Breach and consequence. What happens when the policy is not followed, and the link into the incident and breach register.
8. Related documents. Standards, procedures, forms and registers this policy sits above.
9. Definitions. Only terms used in the policy statements.
10. Document control block. Owner role, approver, approval date, effective date, version, next review date, classification.

Length is not a virtue. A four-page policy that is followed beats a twenty-page policy that is not.

Approval: who signs and what the minute records

Approval authority should be documented before drafting starts, in a policy-on-policies or a delegations schedule. As a default:

• Board approval for policies that discharge a director-level duty or a prescribed statutory requirement — anti-money laundering program documents, whistleblower policy, risk management framework, code of conduct.
• Committee approval where the board has delegated, with the delegation recorded.
• Executive approval for standards and procedures beneath an approved policy.

The minute matters as much as the signature. A usable minute records the document title, the version number approved, the effective date, any conditions attached, and confirmation that the approving body considered the material change from the previous version. "The board approved the updated policy" is a weak record; it does not establish which version was approved.

For charities, ACNC Governance Standard 5 places duties on Responsible People, and policy approval is a routine way those duties are evidenced. Where a regime requires the governing body to approve a program — anti-money laundering being the clearest Australian example, see AUSTRAC's guidance on your AML/CTF program — approval by an executive instead of the board is a finding regardless of drafting quality.

Version control and the document register

Version control exists to answer one question: what was in force on the date the conduct occurred. Practical minimums:

• Sequential versioning. Major version on substantive change, minor on editorial. Never reuse a number.
• A change log inside the document. Version, date, summary of change, approver. Three lines per version is enough.
• Superseded versions retained, not deleted, for at least the retention period applying to the underlying records — commonly seven years for corporate and tax-adjacent documents.
• A single controlled location. One published source, read-only to everyone except the owner. Copies in shared drives and email attachments are how two versions end up in force at once.
• A document register listing every policy, its owner, approver, current version, approval date and next review date. This register is itself an audit artefact and pairs directly with the obligations register.

Publication, attestation and training records

A policy nobody was told about is not a control. The evidence chain has three links:

Scope determines the population. If the policy binds contractors and labour hire workers, the acknowledgement population must include them — a point that recurs in contractor and supplier compliance.

Review cadence and out-of-cycle triggers

Set a scheduled review cycle per policy, and define the events that force a review out of cycle:

• The underlying law or rule is amended, or a new instrument commences.
• A regulator issues guidance materially changing expectations.
• An incident, near miss or complaint reveals the policy did not cover the situation.
• Monitoring or assurance testing finds the control ineffective as designed — see compliance monitoring and assurance plans.
• A material business change: new product, new jurisdiction, acquisition, new material outsourcing arrangement.

Record the review even when nothing changes. A file note reading "reviewed 12 August 2026, no change required, owner and approver confirmed" restarts the clock and closes the gap an auditor would otherwise find.

Findings that recur

• No obligation basis. The policy does not say which duty it discharges, so nobody can test whether it discharges it.
• Effective date missing. Approval date and effective date are different fields and both are needed.
• Aspirational language in a mandatory control. "Staff should consider" is not a control.
• Scope excludes the people who do the work. Contractors, agency staff and offshore service providers omitted from scope.
• Exception process undocumented, so exceptions are granted informally and never expire.
• Review date passed. The single most common finding in Australian policy reviews, and the easiest to avoid by putting review dates in the compliance calendar.