NDIS policies pass audits when they do five things: explicitly reference the relevant Practice Standard, describe a process the team actually follows, include record-keeping requirements, name responsible roles, and have an annual review cycle with version history. Policies that fail audits typically miss two or more of these. The fix isn't legal-style writing - it's plain English with the right structural elements.

The five audit-failure patterns

Most NDIS policy fail-points trace back to one of five structural problems. Once you know what auditors look for, fixing them takes minutes per policy:

  1. No Practice Standard reference. The policy doesn't explicitly name the NDIS Practice Standard it satisfies. Auditors can't connect your documentation to compliance.
  2. Generic template language. Copy-pasted policy templates that describe processes you don't actually follow. The auditor talks to your team, hears different answers, the gap is obvious.
  3. No record-keeping section. Says what you do but not what records you keep, where, or for how long. Auditors then can't verify the process happens.
  4. No named responsible roles. Says "the organisation will" instead of "the Service Manager will." When the auditor asks who owns this, your team can't answer.
  5. No review cycle or version history. The policy isn't dated, doesn't show when it was last reviewed, has no version number. Even good content fails on this alone.

Anatomy of a policy that passes

An audit-ready NDIS policy has six sections, in this order:

  1. Purpose - one to two sentences saying what the policy is for and which Practice Standard(s) it relates to.
  2. Scope - who and what the policy applies to (all staff, contractors, volunteers; all services or just specific ones).
  3. Definitions - any terms that need clarity. Keep this short and only include terms that genuinely need defining.
  4. Procedure - the step-by-step process. Use numbered steps. Name the responsible role at each step. Be specific about timing.
  5. Record-keeping - what records are kept, where, by whom, for how long. Specifically mentions the location (e.g. "in the Quality Management System under Incidents folder").
  6. Review - review date, version number, version history. Annual review minimum. Owner of the policy named.
"Auditors don't fail you for using plain English. They fail you for vague processes that nobody actually follows. Specificity beats sophistication."

Mapping policies to Practice Standards

The NDIS Practice Standards are the auditor's checklist. Every policy in your pack should map to one or more Practice Standards. The four core modules each have specific Standards:

If your policy doesn't reference a specific Practice Standard, the auditor can't tick the corresponding box. Even if the content is strong.

A worked example: complaints handling

Most providers have a complaints handling policy. Most fail their audit on it. Here's the difference between a failing version and a passing version:

Failing version (paraphrased): "The organisation values feedback and complaints from participants. Complaints will be addressed promptly and fairly. Participants can submit complaints in writing or verbally. The organisation will investigate complaints and respond appropriately. Records will be kept of all complaints."

Why it fails: No Practice Standard reference. No specific timeframes. No named responsible role. No record location. Generic template language.

Passing version (paraphrased):

The passing version isn't longer or more sophisticated. It's specific in the right places.

Common mistakes to avoid

Setting up an annual review cycle

The simplest review cycle: pick one month per year (e.g. March), block two days, review every policy in your pack. Update version numbers, refresh the "last reviewed" date, fix anything that's drifted from actual practice. Done.

Don't over-engineer this. A simple annual cycle that actually happens beats a quarterly cycle that doesn't. The auditor checks whether reviews are documented - not how frequent they are.

If you're starting from zero, our free Registration Readiness Checklist includes the full 80+ document inventory and which Practice Standards they each map to.

Want help applying this?

Book a free 30-minute strategy call. No pitch, no pressure - we'll tell you honestly whether this is something you can DIY or whether you'd benefit from a partner.

Book Your Free Call →
ST

Provider Scale · Built by NDIS Operators

This article was written by the team behind the NDIS company we operated, a live Australian NDIS provider with 14 active support workers and 60+ participants. Every framework here has been tested in a real operating business, not invented in a slide deck.

Frequently Asked Questions

Typically 60-80+ documents depending on your service mix. Verification module providers can get away with fewer (40-50). Core module providers need the full set including incident management, restrictive practices, medication management, and worker screening. SDA and Specialist add module-specific policies on top.

You can start with templates, but you must customise them to describe processes you actually follow. The auditor will interview your staff. If staff describe a different process than the policy, you fail. Templates are scaffolding - they don't substitute for tailoring.

Annually as a minimum. Some policies (incident management, restrictive practices) benefit from more frequent review when triggered by an event. The auditor checks for documented review cycles, not maximum frequency. Annual is sufficient if it actually happens.

Incident management. Most providers describe a process that sounds reasonable but don't keep the records to prove it happens. The fix is a simple incident register stored consistently with the policy reference, owner, dates, and outcomes for every event.

No - one policy can satisfy multiple Practice Standards. A complaints policy satisfies feedback management, participant rights, and continuous improvement standards simultaneously. Map your policies to Standards in your Registration Checklist.