NDIS Data Risks: Privacy, Vendors, and Breach Response

Will, EnableUs Community

So you can have, um, a completely perfect privacy policy on paper, like totally flawless, but if your roster app or your cloud notes app is saving data to a server in, say, Oregon instead of Sydney, you are looking at a direct non conformance finding under NDIS Practice Standard Outcome 2.4 and APP 12.

Winter, EnableUs Community

Wait, Oregon? Just, just from using a standard plug and play scheduling app?

Will, EnableUs Community

Yeah, exactly. People forget that, um, disability records contain really sensitive health details, behavioural history, support needs, and under Australian Privacy Principle 12 of the Privacy Act 1988, that is all classified as sensitive health information. So it gets the highest level of protection under law.

Winter, EnableUs Community

Right, right, sensitive health information. And it is not just the Privacy Act, is it? There are, er, three distinct layers here that providers have to balance at the same time.

Will, EnableUs Community

Three layers, yeah. First you have APP 12 in the Privacy Act 1988. Then you have the NDIS Code of Conduct, which binds literally every single worker, not just your office staff, but every support worker who sees a chart or an email. And third, you have Practice Standard Outcome 2.4 on Information Management, which is what auditors directly test during your certification and mid term audits.

Winter, EnableUs Community

And auditors don't just look at whether you have a document saved, do they? They, they actually test how you retrieve it, who can see it, and where that data physically goes when you use a third party software.

Will, EnableUs Community

That is the big supply chain trap! A lot of small providers set up, you know, third party tools for telehealth, or payroll, or casual shift rostering, and they assume because it is a big platform, it automatically meets Australian standards. But if that vendor stores data overseas and you haven't executed a proper Data Processing Agreement or verified Australian server regions, you are vulnerable.

Winter, EnableUs Community

I mean, I, I think back to when I first looked at cloud tools, and honestly you just assume if it works on your phone, it is fine! But it really comes down to asking vendors two very simple questions before signing up. Question one: where is the data physically stored? And question two: who holds the encryption keys?

Will, EnableUs Community

Those two questions right there! If the answer to number one isn't an Australian region like Sydney or Melbourne, or if the vendor cannot confirm end to end protection in line with Australian Privacy Principles, you simply cannot put participant details into that system.

Winter, EnableUs Community

It makes you realize how easily a innocent mistake by a support worker or a quick tech signup can blow a huge hole in your compliance.

Will, EnableUs Community

It really does. And the data doesn't just sit there forever either, which brings up another whole set of rules around how long you keep it and how you eventually throw it out.

Winter, EnableUs Community

Because simply clicking delete on an old digital folder or throwing paper shift notes into a blue recycling bin after a few years is actually a major data security breach waiting to happen.

Will, EnableUs Community

Recycling bins! People throw participant progress notes into general recycling bins thinking, oh, paper gets recycled so it is gone. But standard recycling is not secure destruction. Physical files have to be certified cross cut shredded, and digital files need secure overwriting so the data cannot be recovered by recovery tools.

Winter, EnableUs Community

And the timeframe isn't arbitrary either. Under NDIS rules, you have to retain participant records for a minimum of seven years after the very last service was delivered. That includes support plans, incident reports, consent forms, progress notes, financial invoices, everything.

Will, EnableUs Community

Seven full years after the last service date. And if during those seven years, or while you are storing them, an accidental disclosure happens, say, a worker sends a group email with twenty participant email addresses in the To field instead of the Bcc field, or a laptop gets taken from a car, then you enter the Notifiable Data Breaches scheme.

Winter, EnableUs Community

The NDB scheme under the Privacy Act 1988. That is where, if a breach is likely to cause serious harm, you are legally required to notify the affected participants and report the event to the Office of the Australian Information Commissioner, the OAIC.

Will, EnableUs Community

Exactly. And you cannot sit on it for weeks while you figure out what to do. You need a clear, tested emergency workflow ready to go before an incident occurs. It comes down to four basic steps every staff member should know: Contain, Assess, Notify, Fix.

Winter, EnableUs Community

Contain, Assess, Notify, Fix. So, first, contain the leak, like revoking an email or locking an account. Second, assess whether serious harm is likely. Third, notify both the participant and the OAIC as soon as practicable if it hits that threshold. And fourth, fix the underlying gap so it never happens again.

Will, EnableUs Community

That four step sequence takes the panic out of the room. When a team has a simple one page response plan that they have actually rehearsed, a misplaced file or email mistake becomes a managed incident rather than an organizational disaster.

Winter, EnableUs Community

It shifts data security from being this abstract legal headache into just a normal daily habit that protects the people we support.

Will, EnableUs Community

Spot on. Keep your server regions local, hold records for seven years securely, and know your four steps if things go sideways. Good chat today, Winter.

Winter, EnableUs Community

Yeah, good chat, see you next time.