This article sets out what actually counts as a data breach in a care setting, how the Notifiable Data Breaches scheme and the NDIS Quality and Safeguards Commission's incident obligations fit together at a plain-English level, and what a workable response plan looks like in practice. It is general information, not legal advice, and every real incident needs its own qualified legal assessment.
A data breach is not only a hacker breaking into a server. In care organisations, most breaches are far more mundane, and that is exactly why they are easy to miss until it is too late. Common examples include:
What links these examples is that none of them require a sophisticated attacker. Most start with a routine mistake, a missed offboarding step or an unremarkable click on a bad link. A response plan built only around "what if we get hacked" will miss the incidents that are actually most likely to happen.
Under the Privacy Act, the Notifiable Data Breaches (NDB) scheme requires organisations covered by the Act to notify the Office of the Australian Information Commissioner (OAIC) and affected individuals when an "eligible data breach" occurs. In broad, non-legal terms, an eligible data breach generally involves:
Not every incident meets that bar. A laptop that goes missing but was fully encrypted and remotely wiped within the hour is a very different situation, from a notification standpoint, to a stolen laptop holding unencrypted participant records with no ability to remotely secure it. The judgement about whether serious harm is likely depends on the type of information involved, how sensitive it is, who could access it, and what could realistically be done with it.
Whether a specific incident meets the "eligible data breach" threshold is a legal judgement that depends on the exact facts. It should be made with input from a lawyer or qualified privacy adviser, not decided informally by whoever happens to be dealing with the incident on the day. Build that step into your plan rather than treating it as optional.
Health information, which many NDIS and aged care providers hold, is treated as sensitive information under the Act, and breaches involving it are more likely to be assessed as capable of causing serious harm than breaches of, say, a name and phone number alone. That is one reason care providers need a lower trigger point for taking a suspected incident seriously than a business that only holds basic contact details.
Registered NDIS providers have incident management obligations to the NDIS Quality and Safeguards Commission that exist alongside, not instead of, the Notifiable Data Breaches scheme. The Commission's focus is participant safety and wellbeing rather than privacy law specifically, but a data breach that affects participants can easily trigger both pathways at once. A stolen device holding support plans and behaviour support information, for example, is potentially both a privacy breach requiring OAIC assessment and an incident affecting participants that the NDIS Commission expects to know about, depending on the nature and risk of the event.
A well-built response plan treats these as two separate checklists to run through for the same incident, not one combined judgement call. Aged care providers should similarly check their own sector-specific incident and reporting obligations, since these evolve and a general blog post cannot substitute for checking current requirements for your service type.
A workable plan is built around six stages. Each one needs an owner, not just a description.
Someone has to notice, a worker reporting a lost phone, an alert from your email or IT provider, a participant or family member flagging something odd. The plan needs a single, well-known first point of contact so a suspicion does not sit in someone's inbox for three days before anyone acts on it.
Stop the bleeding, disable a compromised account, remotely wipe a lost device, isolate an infected machine from the network. Containment decisions often need to happen within minutes, which means the authority to act cannot wait for a committee.
Work out what happened, what information was involved, how many people are affected, and whether the NDB scheme and NDIS Commission thresholds are likely to be triggered. This is where legal input matters most.
Tell the people and bodies who need to know, the OAIC, the NDIS Commission where relevant, affected participants and families, and sometimes insurers or the police. Notifications need to be accurate, so this step follows assessment rather than happening in a panic before the facts are clear.
Restore systems, reset access, confirm nothing is still compromised, and make sure participant supports were not disrupted in the process, or were disrupted as little as possible with a plan for continuity while systems were down.
Review what happened and why, and change something, a process, a control, a piece of training, so the same gap does not cause the next incident. A breach that produces no change in practice was a wasted, expensive lesson.
The first hour after something is discovered sets the tone for everything that follows. A short, memorised checklist beats a long document nobody has read recently.
| Time | Action | Who |
|---|---|---|
| 0-5 min | Report the suspected incident to the named first contact; do not wait for certainty | Any staff member |
| 5-15 min | Confirm the report is credible and decide whether immediate containment is needed | IT/security lead or managed IT provider |
| 15-30 min | Contain: disable compromised accounts, remotely lock or wipe lost devices, isolate affected systems from the network | IT/security lead, with authority to act without further sign-off |
| 30-45 min | Brief senior leadership and the designated privacy officer; open an incident log | IT/security lead + senior manager |
| 45-60 min | Start the fact-finding needed for the NDB and NDIS Commission assessment; decide if legal advice is needed now or once more facts are known | Privacy officer / senior manager |
Notice what is deliberately not in that first hour: public statements, notifying participants, or declaring whether the incident is reportable. Those decisions need facts and, usually, legal input, and rushing them before the picture is clear tends to create a second problem on top of the first.
Every provider believes, before an incident happens, that their team would handle it sensibly. In practice, an unplanned response usually looks like this: the first person to notice is not sure who to tell, so they mention it to a colleague instead of escalating. Someone eventually alerts a manager, who is not sure whether they have the authority to disable a system or shut off email access, so they wait for someone more senior. By the time containment happens, hours have passed and the exposure has grown. Meanwhile nobody has started the clock on the assessment, because nobody was clearly assigned to do it.
A written plan fixes the two things that go wrong under pressure: ambiguity about who decides, and ambiguity about what happens next. A short annual walkthrough, even just talking through a hypothetical scenario for thirty minutes with the people who would actually be involved, surfaces the gaps far more cheaply than discovering them mid-incident. Rehearsal also matters because plans go stale, staff change, systems change, and a plan written two years ago may name someone who no longer works there.
A twenty-page policy document is not an incident response plan, it is a reference for writing one. What people need in the moment is a one- or two-page checklist with names, phone numbers and clear authority, plus a short list of who to call for legal, technical and regulatory support. Keep the long version for context and audits, and keep the short version pinned somewhere everyone can find it fast.
Vague responsibility is one of the most common failure points. Every plan should name, by role rather than just by person (people change jobs), who holds each of the following:
Splitting the "talks to participants and families" role from the technical response matters more than it might seem. The person best placed to isolate a compromised server is rarely the person best placed to have a calm, reassuring conversation with an anxious family member, and asking one person to do both under pressure tends to produce a worse outcome on both fronts.
No. Only an "eligible data breach" under the Notifiable Data Breaches scheme has to be reported, broadly one that is likely to result in serious harm to the people whose information was involved and that you have not been able to prevent through prompt remedial action. Whether a specific incident crosses that line is a legal judgement that depends on the facts, so treat this as general information and get qualified legal advice when you are assessing a real incident.
The OAIC administers the Notifiable Data Breaches scheme under the Privacy Act and is concerned with breaches likely to cause serious harm to individuals' privacy. The NDIS Quality and Safeguards Commission has separate incident management obligations for registered providers focused on participant safety and wellbeing. A single event, such as a stolen laptop with participant files on it, can trigger obligations to both bodies at once, so your plan needs to check each pathway rather than assuming one covers the other.
Once you have confirmed an eligible data breach, notification should happen as soon as practicable. There is no fixed number of hours set out in the legislation, but delay is viewed unfavourably. In practice that means participants and families are usually told within days of confirmation, not weeks, and always after you have enough information to tell them accurately what happened and what to do. Get this timing checked against current guidance for your specific situation.
This should be a defined decision point in your plan, usually a senior leader or delegated privacy officer, working from a documented assessment of what information was involved, how many people are affected and how likely serious harm is. Because the threshold is a legal test, that decision should be supported by legal advice rather than made alone by IT or operations staff under time pressure.
At minimum: a clear first-contact point when something is suspected, named roles for who can isolate systems, who assesses the privacy and NDIS obligations, who talks to the regulator and who talks to participants and families, a containment and recovery checklist, and a short rehearsal at least once a year. Start simple and specific rather than waiting to build something exhaustive.
Most providers do not have an in-house security team to write, test and run an incident response plan, and trying to build one from scratch while also running rosters, supports and compliance is a hard ask. This is the core of what CareIQ IT does: our managed IT and cyber security team helps care providers build a data breach response plan that actually matches how their organisation runs, put the technical containment controls in place before an incident happens (account monitoring, MFA, endpoint protection, remote wipe capability), and provide hands-on incident response support if something does go wrong, including the technical detail needed to feed into your privacy and NDIS Commission assessment. See our cyber security services for the detail.
Separately, and worth a brief mention, keeping participant records in one access-controlled system rather than scattered across personal devices, spreadsheets and inboxes reduces the number of places a breach can start in the first place. That is one of the underlying benefits of running your service on a single platform like CareIQ, though it is a smaller piece of the picture next to having an actual response plan and the IT controls to back it up.
CareIQ IT helps NDIS and aged care providers build, test and run a data breach response plan, and provides hands-on incident response support when you need it most.
Talk to CareIQ ITGeneral information only, not legal advice. Whether a specific incident is an "eligible data breach" requiring notification, and what your NDIS Commission or aged care reporting obligations are, depends on the exact facts and current law. Seek qualified legal advice before making notification decisions, and recheck current OAIC and NDIS Commission guidance regularly, as requirements evolve.