Skip to main content

HIPAA penetration testing requirements Is it required, and what is changing in 2026?

Does HIPAA require penetration testing? What the Security Rule asks today, what the 2025 proposed update would add, and how testing evidences your safeguards.

Senior Consultant, Summit
4 min read
Clinical team in a hospital setting, representing healthcare organisations protecting electronic health information under HIPAA
HIPAA Security Rule · 45 CFR Part 164, risk analysis and evaluation
On this page
  1. Who the Security Rule applies to
  2. What the current rule requires
  3. What the 2025 proposal would change
  4. What to test
  5. How testing supports compliance and breach defence
  6. A sensible HIPAA testing cadence
  7. How Summit helps
  8. Frequently asked questions

Handle health data? Run the free scan at scan.sumrite.com for a first look, then scope testing around the systems that store or transmit ePHI.

HIPAA is often misread in both directions. Some vendors claim “HIPAA requires an annual pentest” (it does not say so today); others conclude testing is optional (the risk analysis and evaluation duties make that a risky reading). The accurate picture sits in between, and it is about to tighten.

Who the Security Rule applies to

The HIPAA Security Rule covers covered entities, such as health plans, healthcare clearing houses and most healthcare providers, and their business associates: the vendors that create, receive, maintain or transmit ePHI on their behalf. For a modern health-tech company, being a business associate is the common case, and customers’ due-diligence teams will ask how you secure ePHI long before any regulator does.

What the current rule requires

The Security Rule is built on required and addressable implementation specifications, not a list of named tests. Two provisions drive technical testing:

Provision What it requires Why testing fits
Risk analysis, 164.308(a)(1)(ii)(A) An accurate, thorough assessment of risks and vulnerabilities to ePHI You cannot assess technical risk thoroughly without identifying technical vulnerabilities, which is what testing does
Evaluation, 164.308(a)(8) Periodic technical and non-technical evaluation of how well safeguards meet the rule Penetration testing is a direct, evidence-producing technical evaluation

Neither sets a frequency, and that flexibility is deliberate. But flexibility is not permission to skip: the risk analysis is the single document regulators request first after an incident, and a thin one creates liability under the rule as it already stands.

What the 2025 proposal would change

In January 2025, the Department of Health and Human Services published a Notice of Proposed Rulemaking to strengthen the Security Rule. Among many changes, it would require:

  • vulnerability scanning at least every six months; and
  • penetration testing at least once every 12 months.

It would also push several currently “addressable” specifications toward being effectively mandatory, with fewer optional edges. As of 2026 the proposal has not been finalised, the comment period closed in March 2025, and the timeline has slipped past earlier targets. So the explicit six- and twelve-month rules are not yet law. The sensible reading is to treat annual penetration testing and half-yearly scanning as the standard you will be held to, because that is where the rule is heading and where good practice already sits.

Do not wait for the final rule to act

The risk analysis and evaluation duties bind you today. If a breach happens before the update is finalised, you will be judged on whether you had reasonable safeguards now, not on whether a future rule was in force. Recent testing and remediation is exactly the evidence that helps.

What to test

For a covered entity or business associate, scope follows the ePHI. Typical in-scope systems:

  • Patient portals, member portals and the web applications that expose health data
  • Mobile health apps and the APIs behind them
  • EHR, practice-management and claims systems, and their integrations
  • Cloud environments that store or process ePHI
  • Internet-facing infrastructure: VPNs, email and remote access
  • Interfaces with clearing houses, payers and other business associates

How testing supports compliance and breach defence

A penetration test does three useful things for a HIPAA posture. It feeds the risk analysis with real, system-specific findings instead of generic risk statements. It serves as the technical evaluation the rule asks for. And it builds a record that, after any incident, helps you show you took technical risk seriously, found weaknesses and fixed them. Our article on what makes a VAPT report worth paying for covers what that record should contain.

A sensible HIPAA testing cadence

  1. Map ePHI. List every system that stores, processes or transmits health data, including cloud and vendor integrations.
  2. Scan every six months. Regular vulnerability scanning across the in-scope estate, aligning early with the proposed rule.
  3. Penetration test annually. Test the applications, APIs and infrastructure that touch ePHI, and after major changes.
  4. Feed the risk analysis. Put findings into your risk analysis and risk management plan, risk-rated and owned.
  5. Remediate and retest. Close high and critical findings and record the retest.
  6. Keep the evidence. Retain reports, remediation records and retests as proof of reasonable safeguards.

How Summit helps

Summit tests the systems that handle health data: web applications, APIs, networks and cloud environments, with risk-rated findings, fixes and a retest you can fold into your HIPAA risk analysis and evaluation. Our HIPAA compliance page sets out how we run the engagement. Begin with the free check at scan.sumrite.com.

Evidence your safeguards before you are asked

Tell us which systems touch ePHI. We will scope testing that supports your risk analysis and the direction the Security Rule is heading. Get a quote or run the free scan first.

Related reading: Which compliance frameworks require penetration testing? · SOC 2 VAPT report · What makes a VAPT report worth paying for

Frequently asked questions

Does HIPAA require penetration testing?

The current Security Rule does not name penetration testing or set a frequency. It requires a risk analysis under 45 CFR 164.308(a)(1) and periodic technical evaluation under 164.308(a)(8). Penetration testing is a recognised way to meet those duties, and most assessors expect it for systems that handle electronic protected health information.

Is penetration testing going to become mandatory for HIPAA?

A proposed update to the Security Rule, published in January 2025, would require vulnerability scanning at least every six months and penetration testing at least once every 12 months. As of 2026 it is still a proposal and not yet final, so the explicit requirement is not in force, but the direction of travel is clear.

Who must comply with the HIPAA Security Rule?

Covered entities such as health plans, healthcare clearing houses and most healthcare providers, and their business associates, including many software and cloud vendors that handle electronic protected health information on their behalf.

What does the current Security Rule actually require on testing?

A risk analysis that identifies risks to electronic protected health information, and a periodic technical and non-technical evaluation of safeguards. Neither sets a fixed test or interval, but you must be able to show you assess technical risk and act on it.

How does penetration testing help with a HIPAA audit or breach?

It produces concrete evidence that you evaluated technical risk to electronic protected health information, found weaknesses and fixed them. After a breach, being able to show recent testing and remediation supports your position that you had reasonable safeguards.

How do we begin?

Run Summit's free scan at scan.sumrite.com for a first look at external exposure, then scope penetration testing around the systems that store or transmit electronic protected health information.

See all FAQs →

  • HIPAA
  • Healthcare
  • Penetration Testing
  • Compliance
  • US

Nishant Sharma

Nishant Sharma is a Senior Consultant at Summit, working on security testing evidence and compliance engagements for SOC 2, ISO 27001 and data protection frameworks.

Talk to a tester

Want us to look at your application?

Scoped quote within a day. Expert-led testing, verified findings, a fix-and-retest cycle and a report your auditors can use as evidence.