If you have been a CTO at a HealthTech company for more than a year, you have probably already been through at least one pentest. You know the drill — scoping call, NDA, test credentials, findings report, retest. You have seen what a good engagement looks like and what a bad one looks like. You are not buying on price and you are not impressed by a vendor’s marketing page.
What you are trying to figure out is whether this firm actually understands healthcare SaaS specifically — the PHI handling, the API surface, the compliance mapping, the operational constraints around testing in environments where patient data is live. Generic security firms often do not. And a generic pentest produces findings that your team already knows about and a report that does not map cleanly to the HIPAA controls your auditor is going to ask about.
Here is what to actually demand from a pentest vendor before you sign anything.
Healthcare-Specific Scope, Not a Generic Web App Test
The most common mistake HealthTech companies make when buying a pentest is letting the vendor define the scope based on their standard methodology rather than defining it themselves based on where their actual risk is.
For a HealthTech SaaS platform, the scope needs to reflect the specific characteristics of healthcare applications — multi-tenant architectures where one customer must never access another’s data, APIs that integrate with EHR systems or handle HL7 or FHIR payloads, authentication flows that manage access to PHI, and cloud infrastructure configurations that determine which data is accessible and to whom.
A generic web application pentest covering OWASP Top 10 vulnerabilities across your main application URLs is a starting point, not a complete healthcare pentest. If the vendor’s scoping call does not include questions about your data flows, your API integrations, your tenant isolation model, and which environments contain live PHI, they are not scoping a healthcare pentest — they are scoping a standard web app test and calling it healthcare.
The scope you should expect includes authenticated testing across multiple user roles including both standard users and administrative accounts, explicit testing of your API endpoints with a focus on authorization failures and data exposure between tenants, your external network perimeter covering any public-facing infrastructure that could provide a path to PHI, and cloud configuration review of the IAM policies, storage bucket permissions, and logging configurations in your environment.
If your product integrates with EHR systems via HL7 or FHIR APIs, those integration points are part of your attack surface and should be explicitly discussed during scoping. A vendor who is unfamiliar with those protocols or who treats them as out of scope by default is signaling a gap in their healthcare domain knowledge.
Manual Testing by Credentialed Testers, Not Automated Scans
This distinction matters more in healthcare than in almost any other vertical. Automated scanning tools are good at identifying known vulnerability patterns — outdated software versions, missing security headers, common misconfigurations. They are poor at identifying the vulnerabilities that actually expose PHI in production HealthTech environments.
Business logic vulnerabilities — the kind where a clinician can access another organization’s patient records by manipulating an ID parameter, or where a user can escalate their own permissions through a sequence of API calls that individually appear benign — require a human tester who understands how your application is supposed to work and who can reason about how to make it do something it is not supposed to.
Tenant isolation failures in multi-tenant SaaS platforms are almost always business logic issues. They are not in any scanner’s signature database. They require a tester to think like an attacker who is also a legitimate user of your platform — someone who has valid credentials in one tenant and is attempting to access data belonging to another. That is a manual testing exercise and it is the most important thing a HealthTech pentest needs to get right.
Ask the vendor directly: how many hours of manual testing are allocated to this engagement? Who specifically will be doing the testing? What are their credentials — OSCP, OSWE, or equivalent? Can you speak with the tester before the engagement begins?
If the answer to the manual testing hours question is vague, or if the tester credentials are thin, or if the vendor cannot tell you who specifically will be on your engagement, those are signals to keep looking.
Data Handling and PHI Exposure During Testing
This is the area most CTOs do not think about until something goes wrong. During a pentest, your tester may encounter real PHI — in API responses, in error messages, in database outputs. How they handle that data matters.
Before signing, ask the vendor specifically: what is your process if you encounter PHI during testing? Do you have a documented data handling policy? How is test evidence stored and for how long? How is it destroyed after the engagement closes?
A well-run pentest firm will have clear answers to all of these. They should be using dedicated, isolated testing infrastructure rather than shared environments. They should have a defined data retention and destruction policy for any artifacts they collect during the engagement. They should be willing to put this in writing.
On the question of Business Associate Agreements: a BAA is not automatically required from a pentest vendor in every situation. Whether one is needed depends on whether the tester will actually encounter or handle PHI — a pentest against a staging environment with properly anonymized data is different from testing a production system where real patient records could appear in API responses. The standard answer from healthcare-experienced firms is to discuss this during scoping, assess the actual PHI exposure risk in the specific engagement, and sign a BAA when warranted. A vendor who has never been asked this question and does not have a clear position on it is not a healthcare-experienced firm.
Findings Mapped to HIPAA Controls, Not Just CVSS Scores
A pentest report that is useful for a HealthTech company is not just a list of findings ranked by CVSS score. CVSS scores measure technical severity in isolation. They do not tell you which findings are going to matter most to your HIPAA auditor, which ones represent the highest risk to PHI confidentiality or integrity, or how to communicate the findings to a healthcare enterprise customer reviewing your security posture as part of their vendor risk program.
The report you should expect from a healthcare-specific pentest firm maps each finding to the relevant HIPAA Security Rule safeguards — the specific administrative, physical, or technical requirements the finding implicates. A SQL injection vulnerability in a PHI endpoint is not just a High CVSS finding — it is a failure of the technical safeguard requirements under 45 CFR 164.312 for access control and integrity. A tester who can make that mapping produces a report that directly supports your HIPAA risk analysis documentation and your auditor’s evidence review.
The report should also include proof-of-concept evidence for every exploitable finding — not a description of what could theoretically happen, but documentation of what the tester actually achieved. A finding described as “SQL injection may be possible in the login endpoint” without exploitation evidence is not a validated finding — it is a theoretical concern that may or may not be real. Validated, evidenced findings are the ones your remediation team can act on with confidence and your auditor can treat as documented risk.
WAF Testing in Production Conditions
One of the most common scope failures in HealthTech pentests is testing in an environment that does not reflect your actual production security controls. Many testing firms default to asking you to disable or bypass your Web Application Firewall for the duration of the engagement, on the grounds that it makes the testing faster and the findings more comprehensive.
There are legitimate reasons to want some testing done with WAF rules relaxed — it can surface underlying vulnerabilities that the WAF is masking rather than fixing. But asking you to disable your WAF entirely means the test is not evaluating the security of the environment your actual users and attackers interact with.
The right approach is a hybrid: some testing with WAF enabled to evaluate what an external attacker would actually encounter, and some testing with WAF rules relaxed to identify underlying vulnerabilities that should be remediated properly rather than just filtered. Ask your vendor explicitly how they handle WAF testing and what their recommendation is for your specific setup. A firm that can articulate this distinction clearly understands production healthcare environments. One that just asks you to turn it off does not.
Why Annual Pentesting Matters Even Before It Is Mandated
The HIPAA Security Rule has not yet been updated to formally mandate annual penetration testing as of mid-2026. HHS published a Notice of Proposed Rulemaking in January 2025 that would require annual pentesting, and finalization is expected sometime in 2026 — but the proposed rule has not yet been finalized, and its final form could differ from the proposal.
What this means in practice is that annual pentesting is not yet a hard legal requirement under HIPAA — but it is already the defensible standard. Most HIPAA auditors expect to see evidence of regular security testing as part of a documented risk analysis. Most enterprise healthcare customers require a current pentest report as a condition of vendor onboarding. And the direction of the regulation is clear — annual testing is coming regardless of the exact finalization timeline.
The HealthTech companies that are caught flat-footed are not the ones who waited for the final rule. They are the ones who treated pentesting as a one-time exercise rather than an ongoing program, and arrived at a critical deal or audit with a report from 18 months ago that no longer reflects their current environment.
Establishing a relationship with a pentest firm that understands your product, your data flows, and your compliance requirements — and that can deliver a credible annual test on a consistent schedule — is worth far more than shopping for the lowest quote each time.
The Question That Filters Most Vendors Quickly
If you want to assess a pentest firm’s healthcare depth in a single question, ask them this: how do you test for tenant isolation failures in a multi-tenant SaaS architecture?
A firm with genuine healthcare SaaS experience will give you a specific, technical answer about how they approach cross-tenant data access testing — what API manipulation techniques they use, how they test IDOR vulnerabilities across tenant boundaries, and how they document the evidence when they achieve unauthorized data access. They will probably also ask you follow-up questions about your specific data model and isolation approach.
A firm without that experience will give you a general answer about authorization testing and OWASP Top 10 coverage. That is not wrong, but it is not what you are buying.
Packet33 conducts web application, API, and external network penetration tests for HealthTech SaaS companies, with engagements scoped to your PHI handling architecture, findings mapped to HIPAA Security Rule requirements, and reports formatted for enterprise security reviews and compliance audits.
Talk to us about scoping a healthcare pentest for your environment.