Guide · NDIS audit

Evidence of control: what auditors mean, and why providers fail on it

Updated 28 July 2026 Ricardo Santos · AI Systems Engineer 8 min read
The short answer

Evidence of control is the ability to demonstrate that a risk was being managed at the time, not that it was addressed once someone noticed. In practice an auditor is testing whether you knew, whether the right person knew, and whether you can show when.

Most providers can produce evidence that a task was completed. Far fewer can produce evidence that the task was under control between completions, and that gap is where non-conformities concentrate.

Completion is not control

A completed incident report proves an incident was reported. It does not prove that incidents are reported reliably, that the reporting deadline was met, that the review actually occurred, or that anyone with authority saw it. Control is a property of the system across time; completion is a property of one record.

What you can usually showWhat control requires
The plan was lodgedIt was lodged before the deadline, and you knew the deadline was approaching
Supervision occurredWho supervised whom, when, and against which requirement
The worker was screenedScreening was valid on every day the worker delivered support
The restrictive practice was authorisedAuthorisation was current for the whole period of use
The policy existsIt was reviewed on schedule, and the schedule is enforced

The three questions behind every finding

  • What was known? Not what is knowable now by assembling records, but what was actually visible to the organisation at the time.
  • Who knew it? Information sitting in one practitioner's inbox is not organisational knowledge.
  • When? The hardest of the three, and the one spreadsheets cannot answer. A modification history shows a cell changed. It does not show what the state was on a given date.
The difference in one sentence

A spreadsheet can tell you what it says today and that it was edited. An evidence trail can tell you what it said on 14 March and who put it there. Auditors increasingly know the difference, and increasingly ask.

Why retrospective assembly is a losing strategy

The common response to an upcoming audit is to assemble evidence: pull records together, fill gaps, tidy the file. It often works once. It fails on the second audit, because the assembly is visible. Records created in a cluster shortly before an audit, for events months apart, are a pattern auditors are trained to notice.

It also costs the most at the worst time, and it produces nothing durable. The same work happens again next cycle.

What controlled looks like as a system property

  • Obligations derived, not typed. A due date calculated from an engagement event cannot drift or be forgotten; one entered by hand can be both.
  • State with a history. Every status can answer what it was calculated from, so "we were compliant in March" is a query rather than a claim.
  • Expiry surfaced before it lapses. Worker screening and restrictive practice authorisations both expire on their own schedules, independent of the records they attach to.
  • Attribution captured at the point of action, not added afterwards, which is also what makes it credible.

None of this requires a large system. It requires that evidence be a by-product of doing the work rather than a separate act of recording that the work was done. That single design decision is most of the difference between a provider that is audit-ready and one that prepares for audits.

Common questions

What is the difference between evidence and evidence of control?

Evidence shows something happened. Evidence of control shows it was being managed across time: that the obligation was visible, owned and current, not just that it was eventually satisfied.

Can a spreadsheet provide evidence of control?

For small volumes with disciplined use, sometimes. The structural limit is that a spreadsheet records its current state and a modification history, not what it asserted on a particular date, which is usually the question being asked.

We passed our last audit doing this manually. Why change?

If it is working and the volume is stable, do not change it. The pressure usually comes from growth, from a new registration group, or from a second audit where retrospective assembly starts being visible.

This guide is general information about how Australian regulatory obligations apply in practice. It is not legal advice, and requirements vary by registration group, jurisdiction and the supports you deliver.

Related

Carrying an obligation your software does not represent?

Two weeks inside your workflow produces a build plan, an accuracy baseline and a risk register. You keep all three either way.

Start a conversation