Penetration Testing for Healthtech

Healthtech companies sit on a specific kind of pressure. You are holding protected health information, often payment data too, and you are selling into an industry where a single breach disclosure can end a partnership before it starts. Hospital systems, insurers, and health networks now ask vendors for proof of security before they will even schedule a demo. That proof usually starts with a penetration test.

Penetration testing for healthtech is not the same exercise as testing a generic SaaS app. The stakes are different, the regulatory backdrop is different, and the systems under test are usually messier: patient portals, HL7 or FHIR integrations, third-party lab and pharmacy APIs, legacy EHR connectors, and mobile apps that touch clinical data. A test that only checks the login page and calls it done misses where the real risk lives.

Why healthtech is a harder target than most

A few things make health platforms attractive to attackers and unforgiving when something goes wrong.

• PHI is worth more on the black market than card data. Medical records carry enough personal detail to support identity theft and insurance fraud long after a stolen credit card has been cancelled. That makes health data a durable target, not a one-time payout.
• Integrations multiply the attack surface. Most healthtech products are not closed systems. They pull from EHRs, push to pharmacy networks, sync with insurance clearinghouses, and often expose APIs to partner apps. Every integration point is a potential entry.
• Downtime has clinical consequences. A denial-of-service issue in a scheduling or e-prescribing platform is not just a revenue problem, it is a patient care problem. Buyers know this and test for it accordingly.
• Regulatory exposure stacks up. Depending on where you operate and who your customers are, you may be answering to PIPEDA, HIPAA, state privacy laws, and your enterprise customers' own vendor security questionnaires, often all at once.

None of this means healthtech founders need to panic. It means the testing has to be scoped by people who understand where clinical software actually breaks, not a generic checklist run against a generic web app.

What a real test looks like

A penetration test worth paying for is human-led. Automated scanners are useful for catching known vulnerabilities and misconfigurations, but they will not find a broken authorization check that lets one clinic's staff pull another clinic's patient records, or a business logic flaw in how your app handles insurance eligibility lookups. Those require a person thinking like an attacker, not a script matching signatures. At traztech, testing is led by Jacob Masse, a published security researcher with five CVEs to his name, including a CVSS 9.1 finding that functioned as a kill-switch against the Mirai botnet. That is the calibre of researcher looking at your codebase, not a junior analyst working through a template. Engagements are delivered with Lorikeet, our offensive-security partner, which means healthtech clients get two sets of experienced eyes rather than one generalist running a tool.

Scoping typically covers three layers, tailored to what the platform actually does:

• Web application testing. Patient portals, provider dashboards, and admin consoles get tested for the OWASP Top 10 plus healthtech-specific issues like broken object-level authorization between patient records, insecure direct object references in appointment or lab result endpoints, and session handling around multi-factor authentication for clinical staff.
• API and integration testing. HL7/FHIR endpoints, third-party lab connectors, and partner-facing APIs get scrutinized for authentication gaps, data leakage between tenants, and improper input validation on clinical data fields.
• Network and cloud testing. Cloud infrastructure hosting PHI gets reviewed for misconfigurations, exposed storage, over-permissioned service accounts, and network segmentation between production and non-production environments.

This is the same rigour we apply across our broader security testing practice, adapted to the specific risks a health platform carries. The goal is not a long list of low-severity findings that pad a report. It is a clear picture of what an attacker could actually do with access to your system, ranked by real business impact.

One test, two purposes

Healthtech companies are usually being asked for a penetration test for one of two reasons: a customer's security questionnaire requires it, or they are working toward a certification like SOC 2. The good news is these do not have to be separate exercises. A properly scoped test doubles as evidence for both. The report format, the remediation timeline, and the retest documentation are built to satisfy an enterprise buyer's due diligence and to serve as an artifact in your SOC 2 or PCI evidence package. That matters because healthtech deals often get stuck exactly here. A CTO or founder has product-market fit, the sale is verbally agreed, and then procurement or a hospital security team asks for a current pentest report and the deal stalls for weeks while someone scrambles to book one. Having this done proactively, before it is the thing blocking a signature, keeps deals moving instead of sitting in a compliance queue.

What to expect from an engagement

A typical engagement runs in a few phases: scoping and rules of engagement, active testing (usually one to three weeks depending on the size of the environment), a findings review, and a written report with severity ratings, reproduction steps, and remediation guidance. We also offer a retest once fixes are in place, since a report full of open findings does not satisfy a customer's security team, a closed-out one does. If you are further along and thinking about the full compliance picture rather than a single test, our compliance services cover how penetration testing fits into a broader SOC 2 or PCI program, including the policies and controls that need to exist alongside the technical evidence.

Getting started

If you run a healthtech platform and a customer, investor, or partner is asking for a penetration test, or you know one is coming and want to get ahead of it, the right move is to scope it properly before you book anything. Every health platform is architected differently, and a test that ignores your specific integrations and data flows will miss the risks that matter most. Get in touch and we will walk through your architecture, figure out what needs testing, and give you a straight answer on timeline and cost before any work starts.

Rules of engagement for systems that touch patient care

The paperwork before a healthtech test is heavier than for a generic SaaS engagement, and skipping it causes real problems. Three documents matter.

The authorisation letter. Standard for any test, but in health environments it needs to name the specific systems, the source addresses testing will originate from, and the window. If any component is hosted by a hospital, a clearinghouse, or a partner rather than by you, you need their written authorisation as well. Testing a FHIR endpoint that turns out to be operated by your customer's health system, without their sign-off, is a contractual problem and potentially a legal one.

A business associate agreement, or its Canadian equivalent. If the testers will foreseeably encounter protected health information, a BAA needs to be in place before testing starts under HIPAA. In Ontario, PHIPA's agent provisions do similar work, and Quebec's Law 25 and PIPEDA sit alongside. Any tester who tells you the paperwork is unnecessary because they will avoid looking at real records is telling you they have not done this in health before. Access control failures are the whole point of the test, and finding one means seeing data you were not meant to see.

Kill criteria and the PHI handling clause. Agree in advance what happens the moment a tester pulls a record belonging to a real patient. The sensible protocol is to stop enumerating immediately, capture the minimum proof needed to demonstrate the flaw, record the identifiers involved so you can assess notification obligations, and notify your named contact the same day rather than waiting for the report. Agree also that no PHI leaves the tester's controlled environment, that screenshots are redacted in the deliverable, and that all evidence is destroyed on a defined schedule after retest.

On the operational side, name the systems that must never be stress tested. E-prescribing, scheduling, and anything in a clinical workflow should be excluded from denial-of-service testing outright, and account lockout testing on a provider portal at 8am on a Monday is a bad idea even though it is technically in scope. Testing windows in health tend to land on weekends and overnight for exactly this reason.

Testing against staging, and why it usually undercuts the result

Most healthtech companies want the test run against staging, which is understandable. The problem is that staging in health platforms diverges from production more than in almost any other sector, because the expensive integrations are stubbed. If your staging environment mocks the EHR connector, the pharmacy network, and the eligibility service, then the three highest-risk surfaces on the platform are not being tested at all.

The workable compromise looks like this. Run authenticated application and API testing against a staging environment that is a faithful clone of production configuration, seeded with realistic synthetic patient records rather than an empty database, and with the integrations pointed at vendor sandboxes rather than mocked out. Run unauthenticated external testing, cloud configuration review, and network work against production, since those are read-heavy and low-risk. Then, with a tight window and agreed limits, verify a short list of high-severity findings against production, because a broken authorisation check that exists only in staging config proves nothing to a hospital security reviewer.

Seeding synthetic data properly is worth the day it takes. A tenant isolation flaw is invisible if there is only one tenant in staging, and half of what makes healthtech risky is cross-tenant leakage. Create at least three synthetic clinics with overlapping patient names and dates of birth, and staff accounts at each with different role levels.

The findings that actually show up in health platforms

Across the penetration tests we have delivered, the pattern in health products is consistent and it is rarely a memory-corruption bug or an exotic exploit chain. It is authorisation.

Broken object-level authorisation on clinical identifiers. The endpoint checks that you are logged in and forgets to check that the record belongs to your clinic. Sequential or predictable record identifiers turn this from a flaw into a bulk extraction path. Lab results, imaging references, and appointment endpoints are the usual offenders, because they are often built later than the core patient record and inherit less of the access control scaffolding.

FHIR search parameters that bypass the tenant filter. A well-built FHIR facade scopes every query to the requesting organisation. A partially-built one applies the scope in the common path and misses it on chained searches, _include parameters, or the batch endpoint. This is one of the more common serious findings and it is almost never caught by scanners, because the request looks entirely legitimate.

SMART on FHIR scope handling. Applications that request patient-level scopes but are granted user-level or system-level ones, refresh tokens that outlive the clinical session, and launch context that can be manipulated to attach a different patient to the session.

HL7 v2 interfaces with no authentication at all. Legacy message feeds over MLLP were designed for a trusted network and frequently still run that way, reachable from further inside your environment than anyone assumed. If a compromised web server can reach the interface engine, it can inject or read clinical messages.

Patient enumeration through side channels. Password reset flows, appointment booking lookups, and eligibility checks that respond differently for a known versus unknown patient. The information disclosure looks minor in isolation and matters enormously when the identifier is a health card number.

Mobile clients caching PHI locally. Clinical data written to unencrypted local storage, PHI visible in the app switcher snapshot, and no certificate pinning on the API client. On shared or personal devices in clinical settings this is a realistic exposure rather than a theoretical one.

What the report has to do after testing ends

A hospital security team, an insurer's vendor risk group, and a SOC 2 auditor all want different things from the same engagement, and a report built for only one of them creates work later.

The auditor wants an artifact showing that a test occurred within the period, that findings were tracked, and that remediation followed a defined process. The enterprise buyer's security team usually wants an executive summary or attestation letter rather than the full technical report, because handing over a document containing reproduction steps for live vulnerabilities is itself a risk. Ask for both deliverables up front: the full report for your engineering team, and a one to two page attestation letter naming the scope, dates, methodology, and current remediation status that you can share freely under NDA or sometimes without one.

Severity ratings deserve a second look before you accept them. A CVSS score describes technical characteristics, not your business exposure. A medium-rated information disclosure that reveals patient names is more serious in a health context than a high-rated issue on an internal admin tool that only three staff can reach. Insist that the report ranks by realistic impact in your environment and explains the reasoning, because that ranking is what your engineering team will work from and what a buyer will judge you on.

Then treat remediation as a tracked programme with dated commitments rather than a backlog. Critical findings closed inside days, high inside weeks, and a documented risk acceptance with an owner for anything you are not fixing. Retest matters because an open findings list satisfies nobody: a report showing eleven findings with nine closed and two accepted with justification reads far better to a hospital reviewer than a report showing eleven findings and no follow-up. Ongoing tracking of this is what our retained work is for if you do not have someone owning it internally.

What changes the price

Testing starts from $1,000 for a genuinely small scope, and the drivers that move it are predictable. The number of distinct applications and the number of privilege levels within each, since testing four roles against each other is four times the authorisation matrix of testing one. The number of live integrations in scope, because each partner API needs its own credentials, its own sandbox, and its own understanding. Whether mobile clients are included, and whether that means one platform or two. Whether cloud configuration review is bundled in. And whether production access is needed, which adds coordination time rather than testing time.

The things that do not usefully drive price are lines of code and user count. A platform with two hundred thousand patients and one clean multi-tenant model is a smaller test than a platform with four hundred patients spread across three acquired codebases with different authentication systems. If a provider quotes purely off your headcount or revenue, they have not scoped the work.

One cost driver worth planning around: retest is not always included. Confirm before signing whether the quoted price covers verification of fixes, and how long you have to use it. A retest window that expires in thirty days is unhelpful when a serious finding needs an architecture change.

When a penetration test is not what you should be buying

Three situations where we will tell you to spend the money elsewhere.

You have never run a scanner or a dependency check. If nobody has run an authenticated vulnerability scan, reviewed your dependency alerts, or checked your cloud posture, a penetration test will spend its first days rediscovering things free tooling would have handed you. Close that tier first. It is cheaper, and it means the testers spend their time on the authorisation logic that tooling genuinely cannot reach. The same argument applies to basic cloud configuration, which should be tidy before anyone bills you to look at it.

Your buyer asked for something narrower. Read the actual request. Some hospital vendor forms ask whether you conduct regular security testing, which a scanning programme plus a documented process can satisfy. Some ask for a HITRUST certification, which a penetration test does not provide. Some ask for evidence of a secure development lifecycle, which is a process question. Buying a full test to answer a question that did not require one is a common and expensive mistake, and confirming the requirement in writing takes one email.

You are pre-launch with no real users. Testing an architecture that will change substantially before your first clinical customer means paying twice. A threat model and a design review at that stage costs less and changes more, because the findings land while the code is still cheap to change. Once you have a live integration and real PHI moving through it, the calculation flips.

There is also a timing point worth being blunt about. Annual testing is the common cadence and it is fine as a baseline, but the trigger that matters more is material change: a new EHR integration, a new partner API, a significant authentication change, or an acquisition. A test performed eleven months ago against an architecture you have since rebuilt is a compliance artifact rather than a security control, and a sophisticated hospital security team will notice the gap between the test date and your last major release. If you want to talk through which of these applies to you, get in touch and we will say so plainly, including when the answer is that you do not need us yet.