What an NDIS auditor asks for, and where it should already be

Auditors don’t just want to see that an incident was logged. They want to see when it happened, when someone became aware of it, and whether the reportable-incident clock was met — 24 hours for the most serious categories, five business days for others. If your incident record is a document with a date typed into it, you are relying on memory to reconstruct the timeline under pressure.

What should exist: an incident record with the reportable-incident timer attached at the moment it is raised, not calculated afterwards. If the incident escalated from a risk that had already been flagged, that link should be visible too — auditors increasingly ask not just whether you reported it, but whether you saw it coming and what you did before it happened.

This is one of the more heavily scrutinised areas, because it sits across two obligations at once: the behaviour support plan itself, and the periodic reporting of restrictive practice use to the NDIS Commission. An auditor will ask for a specific client’s BSP, then ask you to show every instance of restrictive practice used against that plan, then ask how that gets reported.

The record chain that should exist: the BSP attached to the client’s file, each use of a restrictive practice logged against that plan rather than as free text somewhere else, and an export in the format the Commission actually wants — not a manual re-entry job the night before it is due. If your restrictive practice log and your BSP live in different systems, or in different tabs of different spreadsheets, that is the gap an auditor will find first.

This is where a lot of providers get caught out, because they have done client-level risk assessment well and forgotten that a group program is a risk subject in its own right. A community bus outing has its own hazards — the vehicle, the route, the ratio of staff to participants, the activity itself — separate from any individual participant’s personal risk profile.

An auditor may ask for a general risk assessment, an environmental one, a transport-specific one, one adjacent to positive behaviour support, or a provider-impact assessment covering what happens to your service if a key risk materialises. And they may ask for the same category against a program, not a person. If your risk register only has a folder per client, you have no answer to “who assessed the risk of this excursion, independent of any one participant’s file”.

The fix is not more paperwork. It is making sure a risk assessment has a subject field that can be a client or a program, so a group activity’s risk assessment does not end up buried inside one participant’s notes because that is where somebody happened to save it.

Working With Children Checks, police checks, first aid, manual handling, professional registration — auditors do not ask whether you collect these. They ask whether this specific worker’s specific check was current on this specific date. That is a harder question than it sounds, because a document can be uploaded once and quietly expire eighteen months later while the worker keeps getting rostered.

What should exist: a documents library with an expiry date attached to each credential, an alert that fires before it lapses rather than after, and — critically — a way to show the right people could see it was current. If a coordinator rostered somebody whose check had expired the week before, that is not only a documentation gap, it is a practice standard breach. The document needs to be visible to whoever books the shift, not archived where only HR can see it.

Sending a PDF is evidence of nothing except that you sent a PDF. Auditors are increasingly asking for proof that staff engaged with a policy — infection control, restrictive practices, incident escalation, whatever is relevant — rather than proof it was distributed.

What should exist: a read-and-acknowledge record per document per staff member, with a version or document code against it, so you can prove which version somebody acknowledged when the policy is updated six months later. If you update a policy and cannot tell an auditor whether staff acknowledged the old version or the new one, you have lost the point of collecting the acknowledgement at all.

A complaints register in isolation looks fine until an auditor asks whether a complaint ever triggered an incident review, a risk reassessment, or a change to a behaviour support plan. The standards care about the connections between records almost as much as the records themselves — does a pattern of complaints about the same activity show up anywhere near the risk assessment for that activity?

If you run a vehicle for client transport, expect your vehicle and asset register to be checked alongside your transport risk assessment — registration currency, maintenance, and whether the risk assessment for that route or vehicle was actually reviewed rather than filed once and forgotten.

Corella keeps these records attached to the thing they are actually about: incidents with reportable timers, restrictive practices linked to the behaviour support plan with a Commission CSV export, risk assessments that can take a client or a program as their subject, and a documents library with expiry alerts, carer visibility and read-and-acknowledge tracking against a document code and version.

It does not run the audit for you, and it will not tell you which practice standard applies to your service — that judgement stays with your quality lead. What it does is make sure the record an auditor asks for is already sitting where it should be, rather than scattered across three systems and somebody’s memory.

For the reasoning behind holding evidence this way, rather than the question-by-question map, getting audit-ready without a fortnight of filing covers it, and the compliance pillar shows the records themselves.