Penetration Testing Requirements for Healthcare Software Developers in Australia
If you build software that touches patient data, prescriptions, medical devices, or practice-management systems in Australia, you’ve probably already been told “no” by someone — a platform that wouldn’t approve your integration, a hospital procurement team that wanted evidence you didn’t have, or a government digital health agency that wouldn’t switch you on without it.
That “no” almost always comes down to one thing: independent penetration testing.
Here’s what’s unusual about this requirement — there is no single Australian law that says, in plain words, “healthcare software must be penetration tested.” Instead, at least ten separate regulatory, contractual and platform-level frameworks all converge on the same expectation. That makes the requirement easy to miss and expensive to discover late — usually right when you’re trying to close a deal or go live.
This guide sets out exactly which frameworks apply, whether you genuinely need penetration testing, and why CREST accreditation specifically matters more in healthcare than almost any other sector.
Why healthcare software gets more security scrutiny than most
Health information sits in the highest-protection category under Australian privacy law — classed as “sensitive information,” alongside things like criminal records and biometric data. It’s also the most targeted: health remains the most-breached sector year after year in the Office of the Australian Information Commissioner’s (OAIC) Notifiable Data Breaches reporting.
Add to that a patient-safety dimension that most software categories don’t carry — a compromised prescribing system or a vulnerable medical device isn’t just a data problem, it’s a clinical one — and you get a sector where regulators, platform owners and government agencies all independently arrived at the same answer: prove your security, don’t just assert it.
The ten regulatory and contractual drivers behind penetration testing
None of these frameworks use the words “you must get a penetration test” as a blanket rule. What they actually say is more interesting — and more binding in practice.
1. Privacy Act 1988 (Cth) — Australian Privacy Principle 11
APP 11 requires “reasonable steps” to secure personal information, and health information carries the highest protection tier under the Act. The OAIC’s own guidance names penetration and vulnerability testing directly as an example of a reasonable step. It isn’t mandatory by name — but if your security is ever tested in a breach investigation, “we never checked” is not a position you want to defend from.
2. Notifiable Data Breaches scheme (Part IIIC, Privacy Act)
Mandatory reporting once you know, or suspect, a breach is likely to cause serious harm. Health is consistently the most-breached sector reported to the OAIC — which is exactly why regulators, customers and cyber insurers all scrutinise health software harder than most other categories.
3. State and territory Health Records legislation
Victoria’s Health Records Act 2001, NSW’s Health Records and Information Privacy Act 2002, and the ACT’s Health Records Act 1997 add further obligations if your software processes records on behalf of providers in those jurisdictions — generally reinforcing the same “adequate security” standard from a different legal angle.
4. My Health Record Act 2012 (Cth) + Australian Digital Health Agency conformance
Any software connecting to My Health Record or Electronic Prescribing infrastructure (the National Prescription Delivery Service, the Active Script List Registry) has to pass the Australian Digital Health Agency’s Conformance, Compliance and Assurance programme, which includes a published Security Conformance Profile. In practice: no independent security testing evidence, no approval to connect. See the Department of Health’s Electronic Prescribing overview.
5. Therapeutic Goods Administration — if your software is a medical device (SaMD)
If your product meets the “Software as a Medical Device” definition under the Therapeutic Goods (Medical Devices) Regulations 2002, Essential Principle 12.1(5) requires cybersecurity “best practice.” The TGA’s own guidance is unusually explicit for a regulator: it recommends penetration testing performed by a party independent of the development team, scaled to risk, covering authentication weaknesses, hard-coded credentials, and insecure function calls.
6. Platform and vendor gatekeeping (contractual, not statutory)
This is the one most developers hit first. Best Practice Software’s Partner Network (via Halo Connect), MedicalDirector, and similar practice-management or dispense platforms won’t approve a third-party integration without independent — often CREST-accredited — penetration test evidence. It isn’t law. It’s a commercial gate, and it’s absolute: no test, no integration, no access to that platform’s customer base.
7. State health department and government procurement requirements
Selling into public hospitals or state health systems almost always means independent security testing evidence is a contract or tender condition, entirely separate from any general legal obligation you might otherwise rely on.
8. PCI DSS — if you touch card payments
Patient billing or pharmacy point-of-sale integrations bring PCI DSS Requirement 11.3 into scope: mandatory annual penetration testing for anything storing, processing or transmitting cardholder data.
9. ISO 27001 — the contractual “passport”
Not a law, but increasingly a prerequisite for government and enterprise health customers before they’ll even open a procurement conversation. Maintaining certification typically requires periodic penetration testing to satisfy the Annex A technical vulnerability management controls.
10. Cyber Security Act 2024 (Cth) — adjacent, usually not the core driver
Australia’s first standalone cyber security law introduces mandatory ransomware-payment reporting above a turnover threshold, smart-device security standards, and a Cyber Incident Review Board. It’s mostly relevant if you’re a critical-infrastructure responsible entity or you’re hit by ransomware — worth knowing, but rarely the reason a typical health software vendor needs a pentest.
So — do you actually need penetration testing?
Not because any single regulator will fine you for skipping it. Because it’s the common currency across everything above:
- To connect to national infrastructure — My Health Record and e-prescribing both gate access behind ADHA’s conformance process.
- To integrate with the dominant platforms — Best Practice Software, MedicalDirector, Fred IT and Minfos all require it before they’ll approve you.
- To sell as a medical device — the TGA names it directly as how you demonstrate Essential Principle compliance.
- To defend your Privacy Act position — the OAIC names it as a “reasonable step,” in the sector it scrutinises most.
- To win government and hospital contracts — it’s a standard tender condition, independent of every other driver on this list.
The honest framing: no single regulator will fine you purely for skipping a penetration test. But you will very likely be blocked from connecting, integrating, or selling — and left exposed in a breach investigation — without one. That’s a stronger reason than “it’s the law,” because it’s true at every gate on the way to market, not just one.
What “CREST-accredited” actually means — and why it matters more in healthcare
CREST accreditation is an independent, internationally recognised certification of a penetration testing provider’s methodology, technical competence and quality assurance. It matters everywhere, but it matters more in healthcare for a specific reason: several of the gatekeepers above — platform partner programmes, government conformance processes, hospital procurement panels — either name CREST accreditation explicitly or treat it as the default evidence of “independent” testing performed to a defensible standard.
A generic vulnerability scan, or a test from a provider without third-party accreditation, often won’t satisfy these gates at all. You end up doing the work twice — once to tick a box, and again properly when a platform or agency rejects the first report.
Why healthcare software developers choose Borderless CS
- CREST ANZ accredited, with a Borderless CS director sitting on the CREST ANZ Board — accreditation isn’t outsourced knowledge for us, it’s governed from inside the standard-setting body.
- Direct experience with the exact gates above — including Best Practice Software / Halo Connect integration approvals and Australian digital-health infrastructure conformance requirements for prescribing and dispense software.
- ISO 27001:2022, ISO 9001 and ISO 45001 certified, SOC 2 Type II, GDPR-aligned, and an ACSC Partner — the same accreditation stack your enterprise and government customers will ask you to evidence.
- AUD $20M public/products liability, $10M professional indemnity and $5M cyber insurance — the kind of cover procurement teams check for before they’ll sign.
- Melbourne-based, servicing Australia and the Asia-Pacific region, with reporting built for both technical remediation teams and the compliance officer who has to prove the assessment happened.
Quick self-assessment: do these apply to you?
- My software stores, processes or transmits any patient or health information
- My software connects to, or is trying to connect to, My Health Record or e-prescribing infrastructure
- My software integrates with a practice-management or pharmacy dispense platform (Best Practice Software, MedicalDirector, Fred IT, Minfos, or similar)
- My software could plausibly meet the definition of “Software as a Medical Device”
- My customers include public hospitals, state health departments, or government health agencies
- My software processes card payments (billing, pharmacy POS)
- My customers or procurement panels have asked for ISO 27001, SOC 2, or “independent security testing evidence”
If you checked even one box, an independent penetration test isn’t a nice-to-have — it’s the thing standing between you and your next integration, contract, or regulatory conversation.
Secure Your Business with Borderless CS
Cyber threats won’t wait. Neither should your protection.
🌐 Website: https://borderlesscs.com.au
📧 Email: [email protected]
This article was reviewed by cybersecurity professionals experienced in penetration testing, compliance frameworks, and Australian cyber security regulations.
Frequently Asked Questions
1. What is CREST-accredited penetration testing?
It’s penetration testing delivered by a provider independently certified by CREST (the Council of Registered Ethical Security Testers) against defined standards for methodology, technical skill and quality assurance — the accreditation most platform and government gatekeepers in Australia recognise as evidence of genuinely independent testing.
2. Does the Privacy Act require penetration testing?
Not by name. APP 11 requires “reasonable steps” to secure personal information, and the OAIC’s own guidance names penetration testing as an example of such a step — particularly relevant given health information’s higher protection tier.
3. Does the TGA require penetration testing for medical device software?
If your product is classified as Software as a Medical Device, TGA guidance on Essential Principle 12.1(5) explicitly recommends independent penetration testing, scaled to risk, as evidence of cybersecurity best practice.
4. What is the ADHA Conformance, Compliance and Assurance (CCA) programme?
It’s the Australian Digital Health Agency’s process for approving software that connects to national digital health infrastructure — My Health Record, electronic prescribing and the Active Script List Registry — including a published Security Conformance Profile that vendors must satisfy.
5. Do I need penetration testing to integrate with Best Practice Software?
Best Practice Software’s Partner Network, accessed via Halo Connect, requires technology partners to demonstrate their applications have undergone an independent security assessment before integration or approval is granted.
6. What is Software as a Medical Device (SaMD)?
Software intended for a medical purpose — diagnosis, monitoring, treatment support — that meets the definition of a medical device under the Therapeutic Goods (Medical Devices) Regulations 2002, regardless of whether it runs on dedicated hardware.
7. How much does penetration testing cost for healthcare software in Australia?
It depends on the size and complexity of the application, the number of user roles and integrations, and whether it’s a first test or a scheduled retest — costs vary widely between a single API/web app engagement and a full-scope platform assessment. The only reliable way to get an accurate figure is a short scoping conversation against your actual architecture.
8. What's the difference between vulnerability scanning and penetration testing?
Vulnerability scanning is automated and finds known, catalogued weaknesses. Penetration testing is manual, human-led testing that actively attempts to exploit weaknesses — including business-logic flaws automated tools can’t see — which is why regulators and platforms consistently ask for the latter, not the former.