Every health-tech and biotech team eventually asks the same question, does HIPAA actually require a penetration test. The honest answer has changed shape over the past year, and getting it right now matters more than it used to, because a proposed rule is about to make it explicit.
This guide gives the full answer, what the HIPAA Security Rule requires today, the 2025 proposal that would name penetration testing directly, the difference between a scan and a test, and what to actually cover on a platform that handles patient data.
The current HIPAA Security Rule does not name penetration testing, but a test satisfies the risk analysis and periodic evaluation it does require. The Notice of Proposed Rulemaking published January 6, 2025 would make penetration testing an explicit requirement at least every 12 months, with vulnerability scanning every 6 months, though it is not yet final. Building the capability now is the safe move.
I reviewed the HIPAA Security Rule, the January 2025 NPRM, and OCR enforcement data on July 27, 2026. This is a practical overview, not legal advice, and the proposed rule remains subject to change.
Common Questions About HIPAA Penetration Testing Requirements
The demand here is concrete, and the questions are consistent across health-tech teams.
Does HIPAA actually require a penetration test, or just recommend one?
Does it require testing annually?
What is the difference between a vulnerability scan and a penetration test in HIPAA terms?
Which systems have to be in scope?
Is the new rule that everyone is talking about final yet?
Does HIPAA Require Penetration Testing Today?
The reason this question causes confusion is that the answer has three layers, and most sources give only one. Taken together they are clear.
Layer one is the current rule. The HIPAA Security Rule does not use the words penetration testing anywhere as a named requirement, so on a literal reading it is not mandated.
Layer two is what the rule does require, a risk analysis and a periodic evaluation, both of which a penetration test is a recognized and often the best way to satisfy. Layer three is the direction of travel, a proposed rule that would make testing explicit, which signals where enforcement is heading.
So the accurate statement is that HIPAA requires the outcome a penetration test produces, even though it does not yet name the test. Health-tech teams that treat it as optional are reading only layer one.
What The HIPAA Security Rule Requires Today
The current Security Rule is built on safeguards and a duty to assess them. Covered entities and business associates must implement administrative, physical, and technical safeguards for electronic protected health information, and two administrative standards are where testing lives.
The first is the risk analysis under 164.308(a)(1)(ii)(A), an accurate and thorough assessment of the risks to ePHI. A penetration test directly supports it by finding the exploitable exposures a paper assessment misses, which is why OCR guidance and auditors treat testing as strong risk-analysis evidence.
The second is the evaluation standard under 164.308(a)(8), a periodic technical and nontechnical evaluation of how well controls meet the rule. A penetration test is the technical evaluation, and reading the two standards together is how a test maps to HIPAA even without being named.
Our SOC 2 requirements guide covers the parallel logic in another framework, since the same test evidences overlapping standards.
The 2025 Proposed HIPAA Rule For Annual Penetration Testing
In January 2025 the picture shifted. HHS published a Notice of Proposed Rulemaking in the Federal Register on January 6, 2025, the most significant update to the Security Rule in more than two decades, written in response to a wave of healthcare ransomware and record-breaking breach numbers.
The proposal makes penetration testing explicit. It would require all covered entities and business associates to conduct penetration testing of their electronic information systems at least once every 12 months, codified at 45 CFR 164.312(h)(2)(iii), by qualified persons with appropriate knowledge of cybersecurity.
It sits alongside more than a dozen other changes, vulnerability scanning at least every six months, multi-factor authentication, encryption of ePHI at rest and in transit, a written asset inventory and network map, and a documented audit every 12 months, and it converts many previously addressable standards into required ones.
The status matters as much as the content. As of mid-2026 the rule is proposed, not final, OCR is still reviewing public comments, and many health systems have asked for it to be narrowed.
Until a final rule publishes, the current Security Rule remains in force, and the practical guidance from most advisors is to build the capability now on a would basis rather than waiting.
Vulnerability Scanning Vs Penetration Testing Under HIPAA
The proposed rule treats scanning and testing as two separate requirements, which makes the distinction between them a compliance question rather than a semantic one. They are different activities with different purposes.
A vulnerability scan runs a tool against your systems and reports known weaknesses from a database, such as a missing patch or an outdated library. A penetration test goes further and attempts to exploit those weaknesses, determining whether a missing patch can actually be used to reach patient data or move deeper into the environment.
That difference is why both are in scope under the proposal. Scanning every six months catches known issues early, and testing every twelve proves whether the controls hold against a real attacker, and a program needs both to understand its true exposure to ePHI.
What Systems A HIPAA Penetration Test Must Cover
Scope under HIPAA follows the data, and the rule is expansive about it. A test has to cover every system that creates, receives, maintains, or transmits ePHI, which on a modern health-tech platform is most of the stack.
That means the clinical applications and electronic health records, the patient-facing and researcher portals, the APIs and integrations that move data between systems, the identity and access controls that gate it, and the cloud infrastructure underneath. For a biotech or genomics platform it extends to the clinical trial and genomic databases and the bioinformatics APIs that query them.
The failure that matters most across these systems is authorization. The most damaging exposure on a multi-tenant clinical or research platform is broken object level authorization, where an API returns another patient's or another study's records without checking who is asking, and proving that boundary holds is central to a credible HIPAA test.
Who Can Perform A HIPAA Pentest And How Often To Test
The proposed rule adds a qualification bar, testing by qualified persons with appropriate knowledge of generally accepted cybersecurity principles, which rules out an unattended scan relabeled as a test. The evidence has to come from competent, adversarial testing.
On cadence, the current rule ties frequency to your risk analysis, and the proposal sets a floor. Under the proposal, testing runs at least every 12 months, or in accordance with the entity's risk analysis, whichever is sooner, so a high-risk platform launching new portals or moving to the cloud needs to test more often than once a year.
A retest after remediation is part of demonstrating the control actually improved.
Why HIPAA Penetration Testing Matters For Enforcement And Breaches
The stakes here are concrete, because OCR is enforcing the standards that testing supports. In 2024, OCR completed 22 HIPAA enforcement actions, the second-highest total in its history, and the single most frequently cited violation was inadequate risk analysis, appearing in 13 of the 22 matters.
The threat behind the enforcement is severe. Healthcare had its worst year on record for breached data, with hundreds of millions of records exposed, and ransomware attacks against hospitals rose sharply, because medical records carry high value and care disruption creates pressure to pay.
A penetration test is the most direct evidence that the risk-analysis obligation OCR keeps citing is being met with something real.
What To Test On A Health-Tech Platform Handling ePHI
The practical scope for a software-driven health company is the application and cloud layer, which is also where patient data is most exposed. A credible test reaches the parts of the platform an attacker would.
The priorities are the multi-tenant data model and the APIs on top of it, the patient and researcher portals and their authentication, the data export and reporting paths that move ePHI in bulk, and the cloud storage and identity configuration behind them. The full workflow runs these across black, white, and gray box modes, and reading the code is what confirms whether an endpoint checks record ownership before returning patient data.
One honest scope note. Testing that reads code and exercises applications covers the software, cloud, API, and portal layer thoroughly, and it does not replace specialized hardware or firmware testing for physical medical devices or lab equipment, which is a separate discipline.
A health-tech platform should scope the software layer to a code-aware test and handle device firmware separately.
How Code-Aware Continuous Testing Supports HIPAA Compliance
The evidence HIPAA wants is only as current as the testing behind it, and health-tech platforms ship constantly. A single annual test produces one data point against a risk-analysis duty that is continuous, and the proposed annual floor is a minimum rather than a target.
Continuous, code-aware testing answers both the current rule and the proposal at once. It re-examines the ePHI-handling surface on every change, so each new portal, API, and integration is validated as it ships, and it keeps the risk-analysis and evaluation evidence current rather than reconstructed once a year.
The walkthrough of how AI penetration testing traces a data leak shows the depth behind each finding.
The human element lines up with the qualified-person bar. Combining autonomous, code-aware testing with human researcher revalidation produces adversarial evidence with a working proof of exploit, across black, white, and gray box modes, which is the standard both the risk analysis and the proposed rule are reaching for.
How CodeAnt AI Supports HIPAA Penetration Testing Evidence
CodeAnt tests the ePHI-handling parts of a health-tech platform the way an attacker would, continuously. It reads the code alongside the live product, proves whether patient and study data stays isolated across tenants, and ships a working proof of exploit with the remediation and retest an assessor expects.
Because it runs on every change, the evidence reflects the platform as it is now, which is what a continuous risk-analysis duty actually requires, and it gets a team ahead of the proposed annual-testing and six-month-scanning floor rather than scrambling if the rule finalizes. Findings map to your HIPAA risk analysis and to overlapping frameworks like SOC 2 and HITRUST.
The pricing suits a growth-stage health-tech budget. Testing is outcome-based, a zero engagement fee with payment only on confirmed critical findings, so continuous coverage of a regulated platform does not mean a large fixed bill.
Conclusion: Treat HIPAA Pentesting As Risk Analysis Evidence
The HIPAA penetration testing question is no longer just “is it explicitly required?” Under the current HIPAA Security Rule, penetration testing is not named directly, but the rule does require risk analysis and periodic evaluation of security controls protecting ePHI. A real penetration test is one of the clearest ways to prove that those controls work beyond policy language or scanner output.
The 2025 proposed rule makes the direction even clearer. The rule is still proposed as of mid-2026, but the safer path for health-tech, biotech, and healthcare SaaS teams is to build the testing capability before it becomes mandatory.
The scope should follow ePHI. That means testing the clinical apps, portals, APIs, integrations, identity systems, cloud infrastructure, and data paths where patient or study data is created, received, maintained, or transmitted. For software-driven health platforms, code-aware continuous testing is especially useful because it can validate authorization, tenant isolation, API exposure, and remediation as the platform changes.
Treat HIPAA penetration testing as evidence for your risk analysis and evaluation duties today, and preparation for the proposed annual testing rule tomorrow. Start with the ePHI-handling systems, prove whether patient data stays protected, retest fixes, and keep the evidence current as your platform ships. For how the same test clears enterprise security reviews, see our guide to SOC 2 penetration testing requirements.
