The HHS Office for Civil Rights closed multiple seven-figure HIPAA settlements that turned on the same root cause: a risk analysis that never identified the exposure that later caused the breach. Not a missing pentest. A risk analysis that was not accurate or thorough. That is the lens to read HIPAA through, because the Security Rule, written in 2003 to be technology-neutral, never uses the words "penetration test" at all.
So you cannot point at a clause and say "HIPAA requires a pentest" the way you can with PCI DSS. What you can say is that HIPAA requires you to genuinely understand and reduce the risks to electronic protected health information, and after a breach the regulator will ask how you knew an attacker could not reach ePHI. This post covers the two provisions that actually drive technical testing, why one of them is required rather than addressable, how to scope a telehealth platform by following ePHI data flows, what OCR asks for in an investigation, and how findings map back to specific safeguards.
No. Neither the Security Rule nor the implementing regulations at 45 CFR Part 164 use the words "penetration testing." HIPAA instead requires covered entities and business associates to conduct a risk analysis and to perform periodic technical evaluations of their safeguards.
A pentest is a recognized way to satisfy the technical side of both, but it is not a named control. The Security Rule deliberately uses outcome-based language and a mix of "required" and "addressable" implementation specifications so it can apply to a solo practice and a national insurer alike. That flexibility cuts both ways: you have latitude in how you assess risk, but you carry the burden of showing your method was reasonable and appropriate for the ePHI you hold. The failure pattern we see in smaller covered entities is reading "not required" as "optional" and skipping technical testing entirely, which is exactly the gap an OCR investigator probes after a breach. The safer reading: HIPAA does not prescribe a pentest, but makes one very hard to do without if you want a risk analysis that survives scrutiny.
This is the detail that changes the conversation. Two provisions do the heavy lifting for technical testing, and one of them you cannot opt out of.
HIPAA splits implementation specifications into "required" and "addressable." Addressable does not mean optional, but it does let you document why an alternative (or nothing) is reasonable. The 164.308(a)(8) evaluation is required, so that escape hatch does not exist: you must perform the periodic technical evaluation. You only get latitude in how. NIST SP 800-66 Rev. 2, the HHS-referenced guide for implementing the Security Rule, explicitly points to technical testing including penetration testing as a method here. So while no clause says "pentest," the government's own implementation guidance treats it as a normal way to meet a required standard. A pentest plus authenticated vulnerability scanning is the most defensible way to cover the technical half.
Scope is any system component that creates, receives, maintains, or transmits ePHI. If ePHI can flow through it or rest on it, it is in scope for your risk analysis and, by extension, for testing. The disciplined way to find the boundary is to map ePHI data flows first, then test the systems those flows touch.
A telehealth platform is the clarifying example. The obvious systems (the patient app, the EHR) are easy. The ones that sink projects are the quiet ePHI sinks: a log aggregator capturing request bodies, an analytics warehouse, a nightly backup. Map it concretely:
ePHI data-flow map - Telehealth platform (scope basis)
patient app (web/iOS) --ePHI--> api.telehealth.io [IN]
video signaling svc --PII---> session metadata store [IN]
api.telehealth.io --FHIR--> provider EHR (R4) [IN]
api -> Postgres primary + 2 read replicas (visit records) [IN]
api -> S3 visit-recordings/ , uploaded-docs/ [IN]
Auth0 / Cognito identity layer [IN]
app logs --(request bodies w/ ePHI!)--> Datadog [IN] <- often missed
marketing site, internal Slack (no ePHI) [OUT]The Datadog line is the trap: nobody intends to log ePHI, but a verbose request logger quietly puts protected health data into a third-party SaaS, and that pipeline is now in scope for both the risk analysis and the test. The opposite error is over-scoping the whole company. Map the flows, scope what they touch. For application-layer ePHI exposure such as one patient reading another's chart, see the access-control fundamentals in the OWASP WSTG, and for the API surface, the OWASP API Top 10 methodology.
HIPAA mandates no specific frequency. The evaluation standard says testing must be "periodic" and must recur when "environmental or operational changes" affect ePHI security, which leaves the interval to your judgment, with consequences.
The defensible, widely adopted interpretation is at least annually, plus a fresh test after any significant change: a new application, a cloud migration, or an integration that moves ePHI a new way. Annual cadence aligns with how healthcare auditors, cyber insurers, and partners under business associate agreements expect to see testing, and a BAA from a large health system will frequently spell out an annual pentest as a contractual term even though the rule itself does not. Going longer than a year is hard to defend if a breach occurs and OCR asks how you evaluated your safeguards. Our breakdown of how to prepare for a penetration test helps you scope ePHI systems before the engagement begins.
An OCR investigator does not open with "where is your pentest." They ask for your risk analysis, your evaluation records, and evidence you acted on what you found. The pentest matters because it is the technical backbone that makes those documents credible. In a HIPAA audit or post-breach investigation the request list reads:
OCR documentation request (Security Rule)
[1] Most recent risk analysis - 164.308(a)(1)(ii)(A)
[2] Periodic technical+nontechnical evaluation - 164.308(a)(8)
[3] Risk management plan - 164.308(a)(1)(ii)(B)
[4] Dated technical testing evidence (pentest/scan reports)
[5] Inventory of systems handling ePHI
[6] Remediation records: what was fixed, when, by whom
[7] Encryption decisions for ePHI at rest/in transit - 164.312(a)(2)(iv), (e)The methodology-driven pentest with severity-rated findings and a remediation trail does the heavy lifting for items 1 and 4: it shows the risk analysis was "accurate and thorough" rather than a spreadsheet of guesses. The failure pattern OCR punishes is not the absence of a pentest, it is a risk analysis that never identified an obvious exposure that later caused the breach. If your test found the SQL injection or the unauthenticated FHIR endpoint, you assessed it, and you fixed it, you can show diligence. If you never looked, "we did not know" is not a defense the regulators accept.
A penetration test feeds the risk analysis; it does not replace it. The 164.308(a)(1)(ii)(A) risk analysis is the required document, and the pentest is the technical evidence that makes it accurate rather than theoretical. The workflow teams skip is the mapping: the test finds exploitable weaknesses, you rate them (CVSS, with EPSS or CISA KEV context for priority), and those findings become inputs to the risk analysis where you assess likelihood and impact to ePHI and decide remediation under the risk management standard at 164.308(a)(1)(ii)(B).
On a recent telehealth assessment we found a FHIR endpoint that accepted a patient identifier in the URL with no authorization check on the bearer token's scope. One valid session could pull any patient's records by incrementing the ID. That single finding was a confidentiality risk under the risk analysis, an access-control gap under 164.312(a)(1), and the kind of unauthenticated ePHI exposure that becomes a reportable breach if an attacker finds it first. We rated it, the team scoped the token check to the requesting patient, and the retest confirmed the fix. The mapping below shows how that kind of finding lands on specific safeguards. One honest caveat: the risk analysis owns the likelihood-and-impact judgment, so map the finding to the safeguard, but let the risk analysis set the priority.
An assumption-based risk analysis is exactly what OCR finds inadequate after a breach. Skipping the test means your analysis rests on beliefs about your defenses; running it means you can state, with evidence, which paths to ePHI an attacker could actually take.
ePHI environments also change fast, and an annual snapshot ages quickly: a new integration, a refactored API, a third-party logging change can each open a path that last year's test never saw. Keeping testing ongoing with agentic pentesting produces the fresh evidence the "was it accurate and thorough?" question rewards, between the annual formal tests. The bar to aim for: at any moment, you can show a current, evidence-backed answer to "could an unauthorized party reach ePHI, and how do you know?"