The healthcare attack surface
Health data cannot be re-issued. A bank can cancel a card number and post a new one; nobody can reissue a diagnosis, a mental health note or a Medicare number. That permanence is what makes health services attractive to attackers, and it is why testing in this sector has to be both thorough and careful.
The technical picture is harder than most industries. A single service can run a modern cloud-hosted patient portal alongside clinical applications that have barely changed in a decade, on networks that also carry imaging systems, pathology interfaces, nurse-call systems and networked biomedical equipment. Availability is a clinical concern, not a commercial one: a test that disrupts a system during theatre lists is a patient-safety issue.
Attackers rarely need anything exotic. Most intrusions into health environments follow paths that are visible in advance if somebody goes looking:
- Remote access, referral portals and telehealth endpoints stood up quickly during a service change and never re-reviewed.
- Patient portals and booking applications with authorisation flaws that let one patient's session reach another patient's record.
- Flat internal networks where one compromised workstation can reach clinical servers, imaging shares and domain controllers.
- Legacy clinical systems that cannot follow a normal patch cycle because the vendor certifies a fixed configuration.
- Standing credentials held by pathology, radiology, e-prescribing and practice-management integrations.
- Shared and stale directory accounts created for a rostered team rather than a named person, often with more privilege than the role needs.
What drives security testing in healthcare
Health services rarely test because one rule tells them to. The requirement usually arrives from several directions at once: privacy law, funder and insurer expectations, board or health-network policy, and the security questionnaire that lands with every new integration partner.
In Australia, the Privacy Act and the Australian Privacy Principles govern how health information is collected, held and disclosed, and the Notifiable Data Breaches scheme obliges organisations to assess and report eligible breaches. Services connected to My Health Records carry additional obligations. Providers who treat United States patients, or who act as business associates to United States covered entities, also work under HIPAA, whose Security Rule expects periodic technical evaluation of the safeguards protecting electronic health information.
PentestOps does not certify you against any of these. What it produces is evidence. Reports map each finding to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. The mapping shows an assessor where a finding sits against a framework; it is not a statement that your organisation is compliant.
| Driver | What it looks for | Where PentestOps helps |
|---|---|---|
| Privacy Act and Australian Privacy Principles | Reasonable steps to protect health information from misuse, interference and unauthorised access | Evidence-backed testing of the systems that hold patient data, with a full audit trail per scan |
| HIPAA (where United States exposure exists) | Periodic technical evaluation of safeguards around electronic protected health information | Findings mapped to HIPAA in every report, with prioritised remediation guidance per finding |
| PCI DSS v4.0 (patient payments) | Testing of the systems in and around the cardholder data environment | External, internal, web and API testing with PCI DSS v4.0 mapping in the same report |
| ISO 27001 programmes and internal audit | A repeatable, tested security programme rather than a one-off review | Scheduled assessments with scan comparison so improvement is demonstrable between cycles |
| Partner and insurer questionnaires | Proof that testing happened, what was found and what was fixed | Exportable reports in PDF, CSV and JSON/API, retained for 1 year on Starter, 3 on Professional and up to 7 on Enterprise |
Regulatory landscape
Four bodies of rules sit behind most Australian health security programmes, and not one of them is satisfied by buying a platform. Each expects something of your organisation; a security test can produce evidence about part of it. The table below keeps that split explicit, obligation by obligation.
Read it as evidence, not as certification. PentestOps does not make your organisation compliant with anything listed here, and no product can. Reports map findings to 8 compliance reporting frameworks plus CIS Benchmarks so an assessor can see where a technical finding sits. The judgement about whether an obligation is met stays with you, your privacy officer and your assessor.
| Obligation | What it expects of you | Evidence a security test provides |
|---|---|---|
| My Health Records Act | A security and access policy governing who may access the My Health Record system, from which devices, and how that access is recorded | Whether that policy holds technically: which accounts and hosts can actually reach the clinical software that connects, and what a compromised workstation reaches from there |
| Privacy Act 1988 and Australian Privacy Principle 11 | Reasonable steps to protect health information from misuse, interference, loss and unauthorised access or disclosure | Which of those steps hold in practice: exploit-validated proof of the paths that reach systems holding health information, with a dated audit trail behind every scan |
| Notifiable Data Breaches scheme | Suspected eligible breaches assessed, with the OAIC and affected individuals notified where serious harm is likely | The technical facts that assessment depends on, established before an incident: what an exposure actually exposes, and how far the access reaches once it is used |
| HIPAA Security Rule risk analysis, where you operate in the US | An accurate assessment of risk to the confidentiality, integrity and availability of electronic protected health information | The technical half of that input: validated findings against the systems holding that data, scored with CVSS v3.1 and mapped to HIPAA in the report |
| HIPAA Security Rule evaluation standard | Periodic technical evaluation of the safeguards protecting electronic protected health information, particularly after environmental or operational change | Scheduled assessments plus targeted re-tests after change, with scan comparison showing what was closed between cycles |
How PentestOps maps to a health service
PentestOps covers the layers a health service actually exposes, from one platform and one asset-wise subscription. If you are new to the discipline, start with what penetration testing is and then match the layers below to your environment.
- Internal clinical networks. An on-premise agent deploys in about 5 minutes, needs 0 inbound firewall rules and runs internal testing natively on the LAN instead of tunnelling every packet out to a remote scanner.
- Patient-facing applications. Web application testing for portals, booking systems and telehealth front ends, covering OWASP Top 10 risks including access-control and authentication flaws.
- Integration APIs. API testing across REST and GraphQL against OWASP API Top 10 risks, which is where most third-party clinical integrations live.
- The perimeter. 24+ external recon modules map what the internet can see, and external testing runs without an agent at all.
- Identity. Active Directory testing covers enumeration, password-policy auditing and the stale or over-privileged accounts that turn one phished login into a domain problem.
- Cloud and M365. Cloud posture auditing runs 800+ automated checks across AWS, Azure, GCP and M365 using read-only credentials, with no agent to deploy.
Testing safely around clinical systems
Safety in this sector is a scoping and control problem, not a marketing promise. Every scan and every exploitation attempt is tied to your signed rules of engagement, and scope enforcement automatically stops activity outside authorised assets. Stealth, Balanced and Aggressive profiles let you reduce intensity where clinical systems are involved, schedule testing outside care hours, and exclude named hosts entirely.
Be equally clear about what this is not. PentestOps tests IT: networks, servers, applications, APIs, identity and cloud. It is not a medical device testing service. It does not assess device firmware, clinical software safety or the regulatory approval status of equipment. Where networked biomedical devices share a clinical network, the platform can report that a device is present and reachable and describe the exposed services around it, which is usually the segmentation question you needed answered anyway.
Credentials discovered during internal testing are redacted before findings leave the agent, and exploitation is used to prove impact rather than to cause it. Our methodology sets out the seven phases each assessment follows, from pre-engagement scoping to reporting.
Typical use cases
- Hospitals and health networks validating that segmentation between corporate, clinical and imaging networks actually holds.
- Specialist clinics and day surgeries with no in-house security team who need a defensible testing programme they can run themselves.
- Digital health and health-tech vendors testing the patient portal and its APIs before each customer security review.
- Aged care and community health providers with many small sites and one thin IT function covering all of them.
- Pathology, imaging and allied health practices carrying heavy third-party integration and standing vendor access.
- IT providers supporting several health clients from one console, using the MSP security platform for per-client isolation.
Why health services choose PentestOps
Detection alone creates work. Health IT teams are small, and a list of theoretical issues without proof of impact is impossible to prioritise against a clinical backlog.
- Proof, not guesswork: safe automated exploitation validates which findings are genuinely reachable, with a full evidence trail.
- Prioritisation that survives contact with reality: CVSS v3.1 scoring, exploit-availability indicators and CISA KEV prioritisation.
- Continuous rather than annual: continuous testing adds scheduled scans, 7-day asset re-verification and drift detection between assessments.
- Self-hosted AI by default, so patient-adjacent scan data is analysed on infrastructure Extranet Systems operates rather than being sent to third-party model providers. External providers are opt-in per tenant.
- Australian-built and operated, with customer data stored in Australia and specific data-residency arrangements available to Enterprise customers on request.
- Extranet Systems Pty Ltd is ISO/IEC 27001:2022 certified, independently audited by Atom Assurances. Platform posture is set out in the Trust Centre.
- Asset-wise pricing: you pay for the assets in scope, and scans against them are unlimited within fair use.