Audit evidence

The NDIS Worker File: What Has to Be On It, Indicator by Indicator

An NDIS worker file needs four things: proof of identity, proof of the right to work in Australia, current contact details, and a record of any secondary employment. Pick any worker at random and open their file. That's roughly what a Certification assessor does, minus the randomness, because they'll usually ask for a file by name. A provider who's covered three of the four is going to be asked about the missing one specifically.

Your CRM runs the participant side of the business. The worker file is the workforce side of it: one record per person, holding everything about their employment in a place a provider can actually produce.

The four records the Standard asks for

Two apply whichever audit you're facing. Two are Certification additions. All four sit under Human Resource Management, part of Provider Governance and Operational Management in the Core Module: proof of identity, on file; proof of the right to work in Australia, on file; worker contact details, recorded and kept up to date; and secondary employment, if any, recorded and kept up to date.

Proof of identity and the right to work, held in a vault

Both sit under the same indicator:

"Records of worker pre-employment checks, qualifications and experience are maintained"

Proof of identity is satisfied by a passport, driver licence or birth certificate somebody has sighted. Proof of the right to work is satisfied by citizenship, permanent residency, or a visa carrying work rights. CORA holds both as their own named slots in a private document vault on the worker's file, so a provider can answer "which files actually have proof of identity on them" directly, rather than searching through a folder of documents labelled "other."

Worker screening currency, the NDIS Worker Screening Check clearance, is the third pre-employment artefact this indicator names, held in Credentials with its own expiry tracked. See how to hold screening renewals across a whole team.

The access log: append-only at the database grant level

Every time somebody opens a document in that vault, worker or admin, CORA logs who and when. This isn't a setting that happens to be switched on. The database itself grants the application permission to write a new row to that log and to read the history back. It does not grant permission to delete a row from it.

That's a precise, checkable claim rather than a general assurance of "secure": the application was never given the ability to remove an entry from the access log, only to add one. Nobody can quietly tidy up who looked at a worker's proof of identity, not an admin, not a bug, not a support request, because the permission to do that doesn't exist at the database level in the first place.

Contact details that are actually current

"Worker contact details are recorded and kept up to date"

This one is Certification-only. It's satisfied by a worker register that gets regularly reviewed, and CORA records the review as a date, stamped only when an admin actually confirms the file is current, not automatically every time somebody edits an unrelated field. A staff register showing which files have never been confirmed makes the question answerable across a whole roster at once, rather than one record at a time.

Secondary employment, asked as a real question

"Details of worker secondary employment, if any, are recorded and kept up to date"

This is where most registers quietly fail, because a blank box and a confirmed "none" look identical on the page. CORA asks it as a genuine three-state question. A worker can be not yet asked, asked and confirmed to hold no secondary employment, or asked and declared what they hold. Those are three different facts, and an auditor reading "declared none" against a name is looking at real evidence. An empty box tells them nothing at all.

Every claim on this page is written the same way every claim on the site is written: about a named artefact, checkable in a demo. See the standard CORA holds every claim to.

Which parts apply to which audit

Proof of identity and the right to work are asked of every registered provider, whichever audit applies. Contact detail currency and secondary employment are two of the seven extra requirements Certification adds on top of Verification, alongside position descriptions, performance reviews and the workforce disruption plan.

A worker's outstanding policy acknowledgements sit on the same file too, tracked as their own register. See what an acknowledgement actually records.

Common questions

What four things need to be on a worker's file for an NDIS audit?

Proof of identity, proof of the right to work in Australia, current contact details, and a record of secondary employment if any exists. Proof of identity and right to work apply to every audit type. Current contact details and secondary employment are Certification requirements.

Does a Verification audit ask for the same worker file as Certification?

Proof of identity and the right to work are asked of every registered provider. Certification adds current contact details and secondary employment on top, along with position descriptions, performance reviews and emergency capability at the organisation level.

What counts as proof of the right to work in Australia?

Citizenship, permanent residency, or a visa carrying work rights, sighted and held on the worker's file.

Who can see who has opened a worker's private documents?

An admin can view the access log for a worker's vault at any time. What nobody, including an admin, can do is delete an entry from it, because the database only grants the application permission to add rows to that log, never to remove one.