225 Health Breaches in 2025: The Website Causes
Health service providers reported 225 data breach notifications in 2025, more than any other sector, according to the OAIC. Here is where a clinic or dental practice website creates that exposure and what to fix in the build.

On this page 12
- Key Takeaways
- What the OAIC’s 2025 Figures Actually Say
- What “Malicious or Criminal Activity” Means for a Website
- Where Website-Side Exposure Actually Starts
- A Worked Example: Two Clinic Builds
- What to Check on Your Own Site
- Does the OAIC Actually Enforce This?
- Where This Gets Hard
- Status
- Frequently Asked Questions
- Get Your Booking Stack Checked
- Sources
Health service providers reported 225 data breach notifications to the OAIC in 2025, more than any other sector, out of 1,205 notifications overall, an all-time high since the scheme began in 2018. That figure sits inside a wider trend: notifications rose 8% year on year, and 716 of the 1,205 were attributed to malicious or criminal activity rather than accident. For a cosmetic clinic or cosmetic dental practice, the number that matters is not the national total. It is where the exposure actually lives on your own website and booking stack, and how far a fix goes toward closing it.
Key Takeaways
- Health service providers filed 225 data breach notifications in 2025, the highest of any sector, out of 1,205 total notifications reported to the OAIC
- Total notifications rose 8% year on year, up from 1,112 in 2024, the highest count since the Notifiable Data Breaches scheme began in 2018
- 716 of the 1,205 notifications, the majority, were attributed to malicious or criminal activity rather than human error or a system fault
- Financial services (157), Australian Government agencies (118) and business or professional associations (103) were the next three highest-reporting sectors
- Health service providers are covered by the Privacy Act regardless of annual turnover, unlike most small businesses in other sectors
- The OAIC’s own 2026 Community Attitudes to Privacy Survey found 82% of Australians are concerned about data breaches
- A regulated entity has 30 days to assess a suspected eligible data breach, then must notify as soon as practicable
What the OAIC’s 2025 Figures Actually Say
The OAIC’s 6 July 2026 statistics release reports 1,205 data breach notifications for calendar year 2025, up 8% from 1,112 in 2024, and describes it as the highest number reported since the mandatory scheme started in 2018. Health service providers top the sector table at 225 notifications, ahead of financial services on 157, Australian Government agencies on 118, and business or professional associations on 103. Of the 1,205 total, 716 notifications were attributed to malicious or criminal activity, meaning the remaining 489 came from human error or a system fault.
| Sector | Notifications, 2025 | Share of total |
|---|---|---|
| Health service providers | 225 | 19% |
| Financial services | 157 | 13% |
| Australian Government | 118 | 10% |
| Business/professional associations | 103 | 9% |
| All other sectors | 602 | 50% |
That release also points to the OAIC’s 2026 Community Attitudes to Privacy Survey, which found 82% of Australians are concerned about data breaches. Patients notice when a clinic loses control of their appointment history or before-and-after photos, and a health provider’s notification obligations under the Privacy Act apply regardless of the practice’s annual turnover: health service providers do not get the small business exemption most other small operators rely on. That is existing law, not the separate, unlegislated proposal to remove the general small business exemption for everyone else, which the Attorney-General’s Department describes only as “progressing” with no Bill passed and no commencement date.
Takeaway: health providers reported more breaches than any other sector in 2025, and most of those breaches trace to a deliberate attack rather than a stray email.
What “Malicious or Criminal Activity” Means for a Website
The OAIC’s release does not break the 716 malicious or criminal notifications down by attack type or by industry, and it does not publish a website-specific cause code at all. Nobody can cite an official OAIC figure for “breaches caused by clinic websites” because that category does not exist in the published data. What the figure does confirm is the shape of the problem: most 2025 health-sector notifications almost certainly trace back to someone getting in, not to someone slipping up. For a clinic or dental practice, “getting in” usually means one of a small number of entry points that live inside the website and booking stack, not the practice management system itself.
Where Website-Side Exposure Actually Starts
These four mechanisms are the ones that turn an ordinary clinic or dental website into the entry point for an eligible data breach. None of them are OAIC-published cause codes; they are the build patterns most consistent with how a public-facing health website exposes patient data, and each maps to a concrete fix.
| Mechanism | Where it lives | Build fix | Maps to |
|---|---|---|---|
| Compromised admin credentials | CMS, booking platform, or hosting control panel login | Enforce MFA on every admin account, disable password-only login, rotate on staff exit | Malicious/criminal, 716 notifications |
| Booking form relayed via unvetted webhook | Zapier, Make, or similar automation forwarding form submissions | Confirm data residency of the automation vendor, restrict the webhook to fields actually needed, add a data processing note to the privacy policy | APP 8 cross-border disclosure |
| Marketing pixels firing on confirmation pages | Meta Pixel, Google Ads tag on the post-booking thank-you page | Strip treatment type, appointment reason, and patient name from any event fired after a booking; fire generic conversion events only | Human error/system fault, 489 notifications |
| Misconfigured cloud export or admin panel | Publicly reachable CSV export, open database admin tool, unauthenticated API endpoint | Put every admin path behind authentication, disable directory listing, audit exposed endpoints with a scanner before launch | Human error/system fault, 489 notifications |
The webhook and pixel rows connect directly to the OAIC’s APP Guidelines Chapter 8 on cross-border disclosure. Under APP 8 and the accountability provision in section 16C of the Privacy Act, a practice that discloses personal information to an overseas recipient, including a booking automation tool or an ad platform’s servers, stays accountable for what happens to that information afterwards. Sending a patient’s name and treatment interest to a marketing pixel hosted overseas is a disclosure under the Act whether or not the practice ever thinks of it that way.
Takeaway: the entry points that matter most are the ones a developer configures once and nobody checks again, not the ones a receptionist might mistype.
A Worked Example: Two Clinic Builds
A cosmetic injectables clinic
Picture a Perth cosmetic clinic whose booking form posts patient name, phone number, email, and requested treatment straight to a Zapier automation that files the submission into a shared spreadsheet and pings the clinic’s Slack. This is a common, low-cost setup, and it is not inherently unsafe. The exposure sits in three unchecked defaults: the Zapier account uses a single shared login with no MFA, the spreadsheet is set to “anyone with the link can view” rather than restricted to specific staff, and nobody has confirmed which country Zapier processes and stores that data in. Fixing it does not mean abandoning the automation. It means turning on MFA on the automation account, switching the spreadsheet to restricted access, and adding a line to the privacy policy naming the vendor and its data location, which is exactly what APP 8 accountability requires when personal information moves to a third party.
A cosmetic dental practice
A cosmetic dental practice runs Meta Pixel and Google Ads conversion tracking on its site, including on the post-booking “thank you for your enquiry” page. The pixel fires a standard event that, by default, can pick up the URL parameters and page content around it, which in this case includes the treatment type the patient just enquired about, for example “veneers consultation confirmed.” That is a health-related inference tied to a specific visitor, sent to an advertising platform, without the practice ever writing a line of code that says “send treatment data to Meta.” The fix is to fire a generic conversion event with no treatment-specific parameters on that page, and to audit every existing pixel and tag for what data it actually captures, not just what the developer intended it to capture.
Takeaway: in both examples, the practice did not choose to expose patient data. A vendor’s default setting did it for them, and nobody had checked.
What to Check on Your Own Site
- Confirm MFA is enabled on every admin login: CMS, booking platform, hosting control panel, and any automation tool connected to your booking form
- List every third-party tool your booking or contact form data flows through, and confirm where each one stores and processes that data
- Check every tracking pixel and conversion tag on your confirmation and thank-you pages for what data it actually sends, not just what it was set up to send
- Search for publicly reachable admin panels, CSV exports, or API endpoints using a basic scanner before assuming none exist
- Confirm your privacy policy names the third-party vendors your patient data passes through, matching what APP 8 requires for cross-border disclosure
- Have a written, tested process for the 30-day assessment window if you suspect an eligible data breach, so the clock does not start on the day you first have to look one up
Does the OAIC Actually Enforce This?
The OAIC publishes a determinations register for privacy complaints and investigations, and the Commissioner has formal powers to investigate and determine cases under the Privacy Act. A search of that register and recent OAIC media releases did not turn up a published determination naming a cosmetic clinic or dental practice specifically for a website-caused breach at the time of writing. That is worth saying plainly rather than dressing up an unrelated case as an anchor: the enforcement record most relevant to this exact scenario has not been made public yet, if it exists at all. The regulator says health providers must notify and remain accountable for third-party disclosures; the build consequence is that your booking stack needs the checks above regardless of whether a determination has been published against a practice like yours. Whether a specific incident on your site would meet the “eligible data breach” threshold is a question for your medical defence organisation or your lawyer.
Where This Gets Hard
The OAIC’s published statistics do not break health-sector breaches down by cause, so nobody, including RockingWeb, can say what proportion of the 225 health-sector notifications in 2025 actually originated on a website versus a practice management system, a lost device, or an internal email error. The mechanisms in this post are the ones most consistent with how a public health website exposes data, built from APP guidance and general breach patterns, not from an OAIC breakdown that names websites specifically. A practice that fixes every item on the checklist above still has exposure through its practice management software, its reception desk, and its staff, none of which this post covers.
Status
The Notifiable Data Breaches scheme and the APP 8 cross-border disclosure obligation are both in force now, and have been since well before 2025. The 2025 statistics referenced in this post are current as of the OAIC’s 6 July 2026 release. As at 15 August 2026, no Bill removing the general small business exemption has passed, so that separate proposal remains just that, a proposal.
Frequently Asked Questions
How many data breaches did Australian health providers report in 2025?
225, more than any other sector, out of 1,205 total notifications under the Notifiable Data Breaches scheme, according to the OAIC’s 6 July 2026 statistics release covering calendar year 2025.
Does the Privacy Act apply to a small clinic or a single-dentist practice?
Yes. Health service providers are covered by the Privacy Act regardless of annual turnover, unlike most small businesses. This is existing law, separate from the unlegislated proposal to remove the general small business exemption for everyone else.
What counts as a notifiable data breach on a clinic website?
Unauthorised access to, or disclosure of, personal information that a reasonable person would conclude is likely to result in serious harm. A regulated entity has 30 days to complete a reasonable assessment once it suspects an eligible breach, then must notify the OAIC and affected individuals as soon as practicable.
Get Your Booking Stack Checked
Get in touch with RockingWeb and we will trace every third-party tool your booking and contact forms connect to, check what your tracking pixels actually send, and return a written list of what to fix first. If you would rather start with the platform, create a RockingWeb account.
Sources
- OAIC - Data breach notifications increase to all-time high in 2025, new NDB stats show, 6 July 2026. Checked 15 August 2026.
- OAIC - APP Guidelines Chapter 8, Cross-border disclosure of personal information, October 2025 v1.3. Checked 15 August 2026.
- OAIC - Notifiable Data Breaches scheme guidance and determinations register. Checked 15 August 2026.
- Federal Register of Legislation - Privacy Act 1988, sections 6D, 6FB and 16C. Checked 15 August 2026.
Last reviewed: 15 August 2026.

Vikas Thakur
Founder of RockingWeb. 16 years building for companies like TPG, iiNet and Monadelphous, now focused on websites and marketing that comply with AHPRA's advertising guidelines and still book patients.




