Penetration Testing

May 25, 2026

HIPAA Penetration Testing Requirements: What Healthcare SaaS Must Know

Sarah Chen

Senior Security Researcher

HIPAA does not use the words "penetration test" anywhere in its regulatory text. That ambiguity causes two problems: some healthcare SaaS companies skip testing entirely and believe they are compliant, and others run a basic vulnerability scan, hand the report to their auditor, and assume that satisfies the requirement. Neither approach holds up under a real Security Rule audit.

WhatHIPAA Actually Requires (and Why Pen Testing Falls Under It)

The HIPAA Security Rule, specifically 45 CFR §164.308(a)(8), requires covered entities and business associates to perform periodic technical and non-technical evaluations of their security controls. This is the Technical Evaluation standard. Separately, 45 CFR §164.308(a)(1) requires a comprehensive risk analysis that identifies threats to the confidentiality, integrity, and availability of electronic protected health information (ePHI).

A penetration test satisfies both requirements when scoped correctly. The risk analysis obligation is not a one-time checkbox. OCR enforcement actions, including the $2.175 million settlement with Advocate Aurora Health and the $1.25 million settlement with Memorial Healthcare System, have cited incomplete risk analysis as a primary finding. In both cases, the covered entity had some security tooling in place. What they lacked was documented evidence that their controls had been actively tested against realistic attack scenarios.

If your SaaS product stores, transmits, or processes ePHI, whether you are a covered entity or a business associate under a BAA, the Security Rule applies to your infrastructure. A pen test is the most defensible way to demonstrate that your risk analysis reflects actual, tested reality rather than theoretical control mapping.

What HIPAA Auditors Actually Look For in a Pen Test

OCR auditors and third-party HIPAA assessors are not reviewing your pen test report for vulnerability counts or CVSS scores. They are looking for four things:

1. Evidence that ePHI attack paths were specifically tested. A generic web application test that ignores your HL7 FHIR API endpoints, your patient data export functions, or your clinical integrations does not satisfy the evaluation requirement. The scope must reflect where ePHI actually lives and moves.

2. Documentation that findings were remediated or risk-accepted with justification. A pen test report sitting in a folder proves nothing. Auditors want to see a remediation log, a re-test result or a documented risk acceptance with a named owner and a review date.

3. Testing cadence tied to your change management process. The §164.308(a)(8) evaluation requirement says "periodic." OCR has interpreted this to mean testing must occur after significant changes to your environment, not just annually. If you launched a new patient portal, migrated to a new cloud region, or added an EHR integration, that change triggers a new evaluation obligation.

4. Methodology that goes beyond automated scanning. This is the one most SaaS teams get wrong. Running Nessus or Qualys against your production environment and exporting the results does not constitute a security evaluation under the Security Rule. OCR guidance published in 2022 explicitly distinguishes between vulnerability scanning and security testing. A credible pen test involves a human tester attempting to chain vulnerabilities, bypass authentication, and reach ePHI through paths an automated scanner cannot reason about.

Scoping a HIPAA Pen Test for Healthcare SaaS

Healthcare SaaS scope differs from a standard web application test in four meaningful ways.

ePHI data flows must be mapped before scoping begins. Your tester needs to know where ePHI enters your system, how it transits between services, where it rests, and what third-party systems it touches. A scope that misses a background sync job that writes patient records to an S3 bucket is a scope that leaves an auditable gap.
Business logic testing is non-negotiable. Scanners find known CVEs. They do not find a patient A accessing patient B's records through a broken object-level authorization flaw in your patient portal API. BOLA vulnerabilities are endemic in healthcare SaaS, and they are exactly the class of flaw that leads to breach notifications and OCR investigations.
Third-party integrations are in scope. If your SaaS connects to an EHR via API, that integration surface belongs in the test. You are responsible for the security of ePHI from the moment it enters your system, regardless of where it originated.
Cloud infrastructure testing is not optional. Most healthcare SaaS runs on AWS, GCP, or Azure. Misconfigured S3 buckets, over-permissioned IAM roles, and unencrypted database snapshots have been the root cause of reportable breaches. A pen test that covers only the application layer and ignores the cloud control plane is half a test.

HIPAA Pen Test vs. Vulnerability Assessment: What Is the Difference

Healthcare SaaS teams frequently conflate these two engagements. They are not interchangeable.

Capability	Vulnerability Assessment	Penetration Test
Method	Automated scanning with analyst review	Manual exploitation by a human tester
Output	List of known vulnerabilities by severity	Demonstrated attack paths to ePHI
HIPAA value	Supports risk analysis inputs	Satisfies §164.308(a)(8) evaluation standard
Business logic coverage	None	Core to the engagement
Auditor acceptance	Partial (insufficient alone)	Full when scoped and documented correctly
Frequency	Continuous or quarterly	At minimum annually and after major changes

A vulnerability assessment is a useful input to your risk analysis. It is not a substitute for a penetration test, and presenting one to an OCR auditor in place of the other is a compliance gap waiting to become a finding.

How to Validate Your Pen Testing Firm Before You Sign a SOW

Your pen test is only as good as the tester running it. For HIPAA engagements specifically, vet your vendor on these criteria before you sign anything.

OSCP or equivalent offensive credential. This tells you the tester can actually exploit vulnerabilities manually, not just categorize them from a scanner report.
Healthcare SaaS experience. Ask specifically about HL7, FHIR, DICOM, and EHR integration testing. A firm that cannot speak to these without Googling them is not a healthcare security firm.
BAA willingness. Any pen testing firm that accesses your ePHI during testing is a business associate. They must sign a BAA before the engagement begins, full stop. If a vendor hesitates on this, walk away.
Sample report quality. Ask to see a redacted report from a comparable engagement. A good report shows attack narratives, proof-of-concept evidence, and remediation guidance that your engineering team can act on. A bad report shows CVSS scores and CVE numbers copied from a scanner.

What to Do With the Report After the Test

OCR auditors are interested in what you did after you got the findings, not just whether you ran a test. A pen test report that collects dust is worse than useless in an enforcement context because it proves you had knowledge of vulnerabilities and did not act on them.

Build a remediation tracker the day the report arrives. Assign a named owner and a target remediation date to every critical and high finding. For findings you choose to accept rather than remediate, document the business justification, the compensating controls in place, and the date on which the risk acceptance was approved. Schedule a retest for critical findings once remediation is complete. Keep all of this documentation in your security program records alongside the original report.

That paper trail is what your auditor will actually audit.

When You Need to Run Another Test

Annual testing is the baseline expectation, but HIPAA's change-driven evaluation requirement means several events should trigger an out-of-cycle test for healthcare SaaS companies.

These include: a major release that changes how ePHI is stored or transmitted, a cloud migration or infrastructure re-architecture, the addition of a new EHR or third-party API integration, a security incident or near-miss involving ePHI, and a change in the scope of your BAA relationships.

If your engineering team is shipping significant features on a quarterly cadence, a once-a-year test almost certainly leaves gaps. Many healthcare SaaS companies at Series A and beyond run two full-scope tests per year and supplement with quarterly vulnerability assessments to manage this.

FAQ

HIPAA does not explicitly mandate penetration testing by name, but the Security Rule's Technical Evaluation standard at 45 CFR §164.308(a)(8) requires periodic testing of security controls, and the Risk Analysis requirement at 45 CFR §164.308(a)(1) requires identifying threats to ePHI. A penetration test is the most defensible method for satisfying both obligations simultaneously. OCR enforcement actions have cited inadequate risk analysis as a primary finding in multiple settlements, making documented pen testing a practical compliance necessity for any SaaS handling ePHI.

A vulnerability scan uses automated tools to identify known software vulnerabilities in your environment. A penetration test involves a human tester manually attempting to exploit those and other vulnerabilities to reach ePHI through realistic attack chains, including business logic flaws that scanners cannot detect. For HIPAA compliance purposes, a vulnerability scan supports your risk analysis as an input but does not satisfy the Security Rule's evaluation standard on its own. OCR has published guidance distinguishing the two, and auditors expect evidence of active, human-led security testing.

At minimum, annually. The Security Rule requires testing after significant environmental changes as well, so a healthcare SaaS company that ships major features, migrates infrastructure, or adds new EHR integrations during the year may need two or more tests within a twelve-month period. The safe approach is to tie your testing cadence to your change management process, not only to the calendar.

Yes. If the penetration testing firm accesses systems containing ePHI during the engagement, the firm qualifies as a business associate under HIPAA, and a signed Business Associate Agreement is legally required before the engagement begins. Any testing firm that refuses to sign a BAA or does not know what one is should not be testing your healthcare environment.

A compliant HIPAA pen test report should document the scope of the engagement including which ePHI systems were tested, the methodology used, specific attack paths that reached or could reach ePHI, proof-of-concept evidence for critical findings, and actionable remediation guidance for each finding. It should also note any ePHI-adjacent systems that were explicitly excluded from scope and why. CVSS scores alone are insufficient. Auditors need to see that realistic attack scenarios were tested against your actual ePHI data flows.

No. Automated scanners identify known vulnerabilities based on signatures and version fingerprinting. They cannot test business logic, chain multiple low-severity findings into a critical attack path, or reason about how an attacker would pivot through your environment to reach ePHI. Healthcare SaaS applications are particularly vulnerable to access control and API authorization failures that only manual testing exposes. OCR's guidance and the broader expectation from HIPAA assessors is that security evaluations reflect realistic threat modeling, which requires human expertise.

Ready to scope a HIPAA pen test that will hold up under audit? Request a scoping call with an Ivasta tester and get a clear engagement proposal within 48 hours.