A founder running a health records platform in Auckland once described her compliance situation as "a layer cake where nobody told me how many layers there were." She had a privacy policy. She had a terms of service. She had completed a self-assessment checklist from a cloud provider. And she had never had a formal penetration test.
Her platform stored clinical notes, prescription histories, and referral records for several thousand patients across two district health networks. When a prospective enterprise client asked her for a penetration test report as part of their procurement due diligence, she had nothing to send them. The deal stalled. The test got booked. The first engagement found four findings that genuinely surprised her team, including one that allowed unauthenticated access to a patient data endpoint that had been live for eleven months.
That is the situation a meaningful number of healthcare SaaS companies in New Zealand and Australia are in right now. Not negligent. Not uninformed. Just operating in an environment where the compliance requirements are multiple, the liability is significant, and the practical path through it has never been clearly explained.
This post covers the compliance framework, what a well-scoped penetration test for a healthcare SaaS platform actually looks like, and what a realistic budget looks like for companies at different stages.
The Compliance Landscape for Healthcare SaaS in NZ and AU
Healthcare SaaS companies in New Zealand operate under the Health Information Privacy Code 2020, which applies specific rules to the collection, use, storage, and disclosure of health information. The Privacy Act 2020 sits beneath it as the broader legislative framework. The Health and Disability Commissioner Act creates a parallel accountability structure for services that touch patient care. New Zealand also follows the HISO 10029 standard for health information security, which references formal security testing as part of an organisation's security posture.
In Australia, the Privacy Act 1988 and the Australian Privacy Principles govern personal information broadly. For health information specifically, the My Health Records Act 2012 creates obligations for any organisation participating in or connected to the My Health Record system. The Notifiable Data Breaches scheme requires organisations to notify both the Australian Information Commissioner and affected individuals when a data breach is likely to result in serious harm. For healthcare SaaS companies with hospital, clinic, or health network clients, those clients frequently carry their own AHPRA obligations and contractual security requirements that flow downstream.
The practical effect of all of this is that a healthcare SaaS company in either market is likely subject to multiple overlapping compliance obligations simultaneously. A penetration test is not always explicitly mandated by name in every piece of legislation. But the security posture requirements, the data protection obligations, and the contractual expectations from enterprise health clients make it a functional necessity rather than an optional investment.
When an incident happens and a regulator asks what security testing the company had conducted, "we completed a self-assessment checklist" is not a position that holds well.
What a Well-Scoped Penetration Test Looks Like for Healthcare SaaS
The scope of a penetration test for a healthcare SaaS platform should reflect the specific architecture and data flows of the product, not a generic template applied to any web application.
For most healthcare SaaS companies in the NZ and AU market, the relevant scope covers the patient-facing application, the clinician or administrator portal, the APIs that connect the platform to third-party systems such as practice management software or laboratory systems, the authentication and access control layer, and any cloud infrastructure components that handle, process, or store health information.
The authentication and access control layer deserves particular attention. Healthcare platforms typically serve multiple user types with different permission levels. Patients, clinicians, administrators, and integration partners often operate within the same platform under different access rules. A penetration test that does not specifically probe whether those permission boundaries hold under adversarial conditions is not assessing the part of the system where the highest-impact failures tend to occur.
API security is the other area where healthcare SaaS platforms carry disproportionate risk. Clinical data increasingly moves through APIs connecting the core platform to referral networks, laboratory systems, pharmacy integrations, and telehealth interfaces. Many of these integrations were built quickly during periods of rapid feature development and have not been formally reviewed since. An engagement that covers the web application but does not include API testing is leaving the most active data pathways outside the scope of the assessment.
Capture The Bug structures the scope review for healthcare SaaS engagements at capturethebug.xyz/Services/penetration-testing around the specific data flows and integration architecture of each platform. The conversation before the engagement begins focuses on what has changed since the last test, where health information actually moves within and beyond the platform, and where the highest-risk exposure sits today.
Regulatory Expectations Around Testing Frequency
The compliance frameworks in both markets do not typically specify a mandatory annual penetration test cadence in explicit terms. What they do specify is that organisations maintain appropriate technical safeguards, respond to identified vulnerabilities, and demonstrate a proactive approach to information security.
In practice, enterprise health clients in New Zealand and Australia have moved ahead of the legislation on this point. Most hospital networks, district health services, and large clinic groups now require their SaaS vendors to provide evidence of penetration testing conducted within the previous twelve months as a condition of contract renewal or initial onboarding. Some are asking for CREST-certified testing specifically, because the certification provides an evidence standard that holds up under audit.
For healthcare SaaS companies that are actively selling into enterprise health, annual CREST-certified penetration testing has become a de facto commercial requirement regardless of what the legislation formally requires. Companies that are pre-enterprise, building toward that market, or seeking to demonstrate a defensible security posture to regulators should treat the same cadence as the relevant standard.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
What to Budget for a Penetration Test at Different Stages
Budget conversations around penetration testing tend to collapse into vague ranges that are not particularly useful for planning. The figures below reflect realistic investment levels for healthcare SaaS companies at different stages in the NZ and AU market, based on the typical scope and complexity of engagements in this category.
For an early-stage healthcare SaaS platform with a defined web application, a standard API layer, and a cloud-hosted infrastructure, a well-scoped engagement from a CREST-certified provider typically sits in the range of eight thousand to fifteen thousand dollars. This covers a full web application test, API testing across the primary integration points, and a structured report with remediation guidance and a retest.
For a growth-stage platform with multiple user types, multiple integration partners, a patient portal and a clinician portal operating as separate interfaces, and infrastructure spread across cloud environments, the engagement scope expands accordingly. Fifteen thousand to thirty thousand dollars is a realistic range for a thorough assessment at this level of complexity.
For an enterprise-tier healthcare SaaS platform with significant integration breadth, multiple product lines, and the need to produce compliance-grade evidence for multiple enterprise clients and regulators simultaneously, the investment is higher and the scope is typically agreed on a per-engagement basis.
These figures assume a CREST-certified provider conducting a genuine scope-specific assessment with remediation support and retest verification included. They do not reflect the cost of template-driven engagements from uncertified providers, which carry their own costs in the form of regulatory exposure, failed procurement conversations, and findings that surface later under worse conditions.
The Procurement Question That Changes Everything
The Auckland founder at the start of this post did not lose the enterprise deal permanently. She completed the penetration test, remediated the findings with the support of the testing team, and went back to the client with a CREST-certified report and a verified retest confirmation. The deal closed four months later than it would have without the gap.
The four months of delay cost more than the penetration test would have cost if it had been done before the procurement conversation started.
That arithmetic is the clearest way to explain why healthcare SaaS companies in New Zealand and Australia should treat penetration testing as a commercial investment rather than a compliance line item. The test does not just protect patient data. It keeps procurement conversations moving, it satisfies the regulatory expectations that are tightening across both markets, and it produces evidence that has real commercial value when enterprise health clients ask the question.
For healthcare SaaS companies ready to scope a formal engagement, Capture The Bug's approach at capturethebug.xyz/Services/penetration-testing begins with a scope conversation specific to the platform architecture, not a template applied to the category. The engagement covers the areas where health data actually moves, documents findings to the standard that regulators and enterprise clients expect, and closes with a verified retest that confirms the remediation held.
The layer cake has a defined number of layers. The path through it is clearer than most healthcare SaaS founders have been told.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Frequently Asked Questions
Is penetration testing legally required for healthcare SaaS companies in New Zealand?
The Health Information Privacy Code 2020 and Privacy Act 2020 require organisations to maintain appropriate technical safeguards for health information. While a penetration test is not named explicitly in every clause, the security posture obligations and the expectation of proactive risk management make formal security testing a functional requirement. Enterprise health clients in NZ routinely require penetration test evidence as a condition of contract, making it a commercial necessity regardless of the legislative wording.
What compliance frameworks apply to healthcare SaaS companies in Australia?
Australian healthcare SaaS companies typically operate under the Privacy Act 1988, the Australian Privacy Principles, the My Health Records Act 2012 if connected to the My Health Record system, and the Notifiable Data Breaches scheme. Clients in the hospital and health network sector frequently impose additional contractual security requirements, including CREST-certified penetration testing, as a condition of vendor onboarding.
What should be included in a penetration test scope for a healthcare SaaS platform?
A well-scoped engagement for a healthcare SaaS platform covers the patient-facing application, the clinician and administrator portal, the API layer connecting the platform to third-party clinical systems, the authentication and access control structure across all user types, and the cloud infrastructure handling health information. Any integration point where patient data moves should be within scope. Generic web application testing that excludes API and access control assessment misses the highest-risk areas of most healthcare SaaS architectures.
How often should a healthcare SaaS company conduct penetration testing in NZ or AU?
Annual CREST-certified penetration testing has become the de facto standard in both markets, driven by enterprise health client procurement requirements rather than legislative mandate. Engagements should be rescoped before each test to reflect changes to the platform, new integrations, and updated infrastructure. A scope that does not change year on year is not assessing the current risk profile of the business.
What does a penetration test for a healthcare SaaS platform cost in NZ or AU?
For an early-stage platform with a defined web application and standard API layer, a CREST-certified engagement typically sits between eight thousand and fifteen thousand dollars. For a growth-stage platform with multiple portals, user types, and integration partners, fifteen thousand to thirty thousand dollars is a realistic range. Enterprise-tier platforms with significant integration breadth are typically scoped on a per-engagement basis. These figures assume a provider offering remediation support and retest verification as part of the engagement.
Why do enterprise health clients in Australia and New Zealand require CREST-certified penetration testing specifically?
CREST certification provides an evidence standard that holds up under audit and regulatory review. It means the methodology, the individuals conducting the test, and the quality controls on the report all meet a defined benchmark. For enterprise health clients managing their own compliance obligations under APRA, AHPRA, or state-based health legislation, a CREST-certified report from a vendor provides defensible evidence that security standards were assessed by a qualified external party.
What happens if a healthcare SaaS company in ANZ has a data breach without a current penetration test on file?
Under the Notifiable Data Breaches scheme in Australia, the organisation must notify the Australian Information Commissioner and affected individuals when a breach is likely to cause serious harm. In a regulatory inquiry following a breach, the absence of formal penetration testing will be part of the record. In New Zealand, the Privacy Act 2020 creates similar notification obligations. The lack of a formal security testing programme does not create criminal liability in most cases, but it significantly weakens the organisation's position in any regulatory, legal, or reputational response to an incident.
