HIPAA does not contain the phrase "penetration test." The Security Rule was written in 2003 to be technology-neutral, so it describes outcomes (assess your risks, evaluate your safeguards) rather than naming specific techniques. That is why you cannot point to a clause and say "HIPAA requires a pentest" the way you can with PCI DSS. What HIPAA does require is that you genuinely understand and reduce the risks to electronic protected health information, and a penetration test is one of the strongest ways to prove you have done that.
This post covers the two Security Rule requirements that actually drive technical testing, what counts as ePHI scope, how often regulators and auditors expect testing, and where pentesting fits alongside the required risk analysis. We will keep the line between "required" and "expected practice" sharp.
No, HIPAA does not explicitly require a penetration test. Neither the Security Rule nor the implementing regulations at 45 CFR Part 164 use the words "penetration testing."
Instead, HIPAA requires covered entities and business associates to conduct a risk analysis and to perform periodic technical evaluations of their safeguards. A penetration test is a recognized way to satisfy the technical side of both, but it is not named as a mandatory control. The Security Rule deliberately uses "addressable" and "required" implementation specifications and outcome-based language 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 also carry the burden of showing your method was reasonable and appropriate for the ePHI you hold.
Two provisions do the heavy lifting for technical testing: the risk analysis requirement and the evaluation standard. Both are administrative safeguards under 45 CFR 164.308.
NIST SP 800-66, the HHS-referenced guide for implementing the Security Rule, points to technical testing including penetration testing as a method for these requirements. So while no clause says "pentest," the government's own implementation guidance treats it as a normal way to meet 164.308(a)(8).
Scope is any system component that creates, receives, maintains, or transmits electronic protected health information. If ePHI can flow through it or rest on it, it is in scope for your risk analysis and, by extension, for testing.
In modern environments that usually means the patient-facing application, the APIs and integrations that move ePHI (HL7, FHIR endpoints, billing feeds), the databases and storage holding records, the cloud infrastructure underneath, and the authentication systems guarding access. A frequent and costly mistake is scoping only the obvious EHR while ignoring a logging pipeline, analytics store, or backup that quietly contains ePHI. Mapping ePHI data flows first, then testing the systems those flows touch, is the defensible order. For application-layer ePHI exposure such as broken access control letting one patient read another's record, see what penetration testing is and how it works.
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.
The defensible, widely adopted interpretation is at least annually, plus a fresh test after any significant change such as a new application, a cloud migration, or a major integration. Annual cadence aligns with how most healthcare auditors, cyber insurers, and partners under business associate agreements expect to see testing. Going longer than a year between tests is hard to defend if a breach occurs and the Office for Civil Rights asks how you evaluated your safeguards. Our breakdown of penetration testing frequency covers how to set a risk-based interval, and how to prepare for a penetration test helps you scope ePHI systems before the engagement.
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; the pentest is technical evidence that makes that document accurate rather than theoretical.
The workflow is straightforward: the pentest finds exploitable weaknesses, you rate them (CVSS is standard), and those findings become inputs to the risk analysis, where you assess likelihood and impact to ePHI and decide on remediation. Skipping the test means your risk analysis rests on assumptions about your defenses; running it means you can state, with evidence, which paths to ePHI an attacker could actually take. This is also where continuous approaches help, because ePHI environments change often and an annual snapshot ages quickly. Keeping testing ongoing with agentic pentesting produces fresh evidence the OCR-style "was it accurate and thorough?" question rewards. Strobes uses this evidence flow in supporting compliance audits and assessments.
