Pain points
Why Google Drive fails an NDIS audit
The three things every Tier 1 auditor asks for that a folder of PDFs cannot deliver: proactive alerting, defensible version control, and a queryable audit log. The post that explains why "we have everything in Drive" is not a compliance position.
Most NDIS providers preparing for their first Tier 1 certification audit have a folder of PDFs in Google Drive (or Dropbox, or SharePoint, or - heroically - in a shared inbox) that they intend to use as the audit evidence base. It looks organised. There's a folder per worker, a folder per participant, sub-folders by document type. Everyone with access can see what's there.
And then the auditor asks the questions that a folder of PDFs cannot answer. This post is about the three of them that come up at every audit - and why "we have everything in Drive" is not, by itself, a compliance position.
To be clear: this is not a "our software is better than Google" post. Drive is excellent at the thing it's designed for - storing files. NDIS audits ask for something else.
The three things every auditor asks for
Tier 1 audits don't test whether you have documents. Of course you have documents - everyone has documents. Tier 1 audits test whether the documents tell the auditor about your continuous compliance posture. Three things are sampled at every audit, and all three are about the system, not the file:
- Proactive alerting. Auditors ask "how do you know a clearance is about to expire?" They expect to see the alerting mechanism, the people on the distribution list, and at least one example of a renewal being initiated in advance of expiry.
- Defensible version control. Auditors ask "when was the service agreement last reviewed and what changed?" They expect to see review dates, reviewer names, and a change log - not a single PDF that someone re-uploaded last Tuesday.
- A queryable audit log. Auditors ask "walk me through the chain of custody for this incident." They expect a timestamped, attributed log - not a folder of files with creation dates that reflect the day Drive synced them.
What "continuous compliance" means in practice
The phrase that keeps coming up in NDIS Commission communications is "continuous compliance". It means the auditor isn't there to verify that documents exist on the day of audit. They are there to verify that documents have been kept current throughout the audit cycle - and that the system you used to keep them current is itself working.
A folder of PDFs is a point-in-time snapshot. Continuous compliance is a stream. The two don't map.
Three auditor questions, two answers each
- 01
"Show me a CPR certificate that's about to expire."
In Google Drive
Search "CPR" in the Drive folder. Scroll through 40 PDFs. Open each one. Read the expiry date inside the PDF. Hope someone named the file correctly.
In a compliance system
Filter the worker list by expiring this month. The four about-to-expire records surface. Each links to its certificate PDF and to the renewal task assigned 60 days ago.
- 02
"When was this service agreement last reviewed?"
In Google Drive
Right-click the file → "version history." See "edited by Sam last Tuesday." Nothing about whether that edit was a typo fix, a re-signing, or a substantive change to supports.
In a compliance system
The record shows the most recent reviewed-on date, the reviewer, and a row for each prior version with a one-line change note. The auditor's question is answered by reading one screen.
- 03
"Walk me through the chain of custody for this incident report."
In Google Drive
Open the incident folder. Find the report. Notice the file name says "v2_final_REAL_signed." Try to find v1. Can't. Notice the timestamp is from Drive's last sync, not the actual moment the report was filed.
In a compliance system
The incident record shows when it was filed, by whom, who reviewed it, when the Commission notification was lodged, and a timestamped log of every subsequent action. No file names. No "_final_REAL." An audit trail.
The "I emailed it to myself" anti-pattern
The most common pre-audit panic move is some variation of: the operations manager emails herself the most recent versions of every document she can find, then forwards the whole thing to the auditor an hour before the meeting. The documents technically exist. Many of them are even current. But the act of assembling them defensively - in a panic, the morning of the audit - is itself the problem.
Auditors notice. The metadata gives it away. Drive's "last modified" dates cluster suspiciously within the same 24-hour window. The file names start to drift - "Aroha-CPR-final.pdf" sits next to "Aroha CPR (1).pdf" sits next to "Aroha_CPR_correct.pdf". One of the PDFs is rotated 90 degrees. Two of them are scans of phone-camera photos.
The non-conformity isn't the absence of evidence. The non-conformity is the absence of a system that produces evidence on demand. The auditor records it as such.
The pattern from the field: providers who fail their first Tier 1 audit almost always pass the second. Not because they bought a new tool. Because the non-conformity exposed the absence of a system, and the system - software, or otherwise - had to exist for the re-audit. The first attempt was the expensive lesson.
What the migration path actually looks like
For most providers moving off Drive, the migration is less scary than they expect. The documents themselves stay documents. What changes is where the metadata lives - the expiry dates, the reviewer names, the version notes, the renewal tasks - and how the system surfaces what needs attention.
- Workers first. The single highest-leverage migration is staff records - because they have the clearest expiry windows and the highest audit-sample rate. Move workers in the first week.
- Active participants next. Migrate active participant files in the second week. Archived participants can come later (and many never need to migrate at all - they can stay in a read-only archive).
- SIL houses and organisational documents last. Behaviour-support plans, incident logs, training records, and house-specific documentation in week three.
By week four you're running off the new system, with the old Drive folder kept as a frozen archive (don't delete it - keep it as a backup until the next audit confirms the new system passes inspection).
A detailed walkthrough lives in our Tier 1 audit checklist guide - the 38 artefacts an auditor samples, mapped to where each sits in a properly structured compliance system.
The harder question: should you migrate at all?
Honest answer: it depends on your size and the audit cycle.
If you're a 2-staff provider with three participants and your next audit is two years away, Drive plus disciplined naming conventions plus a calendar of expiry dates might get you through. You can write the alerting yourself.
If you're a 10-staff provider with twenty participants and a Tier 1 audit in the next twelve months - or you're a SIL provider racing the 1 July 2026 mandatory-registration deadline - you should have moved off Drive six months ago. Every week you keep the "we'll migrate after the audit" position is a week the system is one badly-named PDF away from a non-conformity.
What we do
Checkbase is the compliance system the auditor expects to see when they ask the three questions above. Staff records, participant files, SIL house evidence, governance documents, and a timestamped audit log all live in one place. Expiry alerts fire on a schedule. The auditor portal gives read-only scoped access without exposing the rest of your data.
From Checkbase
Background reading: the audit-preparation pillar covers what auditors sample at every Tier 1 audit. The companion post on why spreadsheets fail at expiry tracking covers the staff-side version of the same problem.
See Checkbase in action
Book a personalised demo or start your free 14-day trial today.
Plain-English reform updates, when they happen.
No spam, no weekly newsletter for the sake of it. Just the bits NDIS providers actually need to know.