HIPAA and Penetration Testing: What's Required Now, and What's About to Be

HIPAA penetration testing sits in an awkward spot. The Security Rule never uses the words "penetration test," so plenty of covered entities have decided they don't need one. Meanwhile, the Office for Civil Rights (OCR) keeps settling enforcement actions with organizations that couldn't show they ever looked for their own vulnerabilities, and a proposed update to the Security Rule would make annual penetration testing an explicit requirement.

This guide covers what the rule requires today, what regulators actually expect when they investigate, and what's coming. If you run a hospital system, a health-tech product, or any business that touches electronic protected health information (ePHI), this is the practical version.

What the Security Rule Actually Says

The HIPAA Security Rule (45 CFR §§ 164.302–318) sets standards for protecting ePHI. Two administrative safeguards do most of the work that testing supports:

• Risk analysis — § 164.308(a)(1)(ii)(A). You must conduct an "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of ePHI. Not once. As an ongoing process.
• Evaluation — § 164.308(a)(8). You must perform a "periodic technical and nontechnical evaluation" of how well your security measures actually protect ePHI, especially after environmental or operational changes.

Neither section prescribes a method. That flexibility is deliberate — the rule was written to scale from a two-physician practice to a national hospital network. But "technical evaluation" has to mean something, and regulators have been clear about what they consider credible evidence.

NIST SP 800-66 Rev. 2, the federal guidance for implementing the Security Rule, names penetration testing as an activity that supports the evaluation requirement. When OCR investigates a breach, "we ran a pentest, fixed the findings, and retested" is the kind of answer that ends a line of questioning. "We had a policy document" is the kind that doesn't.

Does HIPAA Require Penetration Testing?

The honest answer today: not by name. The current Security Rule does not explicitly mandate penetration testing.

The practical answer: you need one anyway, for three reasons.

1. You can't do a thorough risk analysis without testing

The risk analysis requirement demands you identify vulnerabilities. A pentest is how you find the ones that matter — the authorization flaw in your patient portal, the flat network between your guest Wi-Fi and your EHR, the API that returns another patient's records when you increment an ID. Paperwork exercises don't surface those. OCR's most-cited finding in enforcement actions is a risk analysis that wasn't accurate or thorough.

2. The evaluation requirement expects technical evidence

Section 164.308(a)(8) explicitly requires a technical evaluation. An annual penetration test with a remediation trail is the cleanest artifact you can produce for it, and it's what assessors and cyber insurers increasingly ask for by name.

3. The breach math is brutal

Healthcare has topped IBM's Cost of a Data Breach report for more than a decade, and civil penalties for HIPAA violations run to seven figures per violation category per year. A five-figure pentest against that exposure is not a hard budget conversation.

The Proposed Rule That Changes the Answer

In January 2025, HHS published a proposed update to the Security Rule — the first major revision since 2013. It would remove the ambiguity entirely. Among the proposed requirements:

• Penetration testing at least once every 12 months, performed by a qualified person
• Vulnerability scanning at least every 6 months
• Encryption of ePHI at rest and in transit, with narrow exceptions
• Multi-factor authentication for systems that touch ePHI
• Network segmentation, a full asset inventory, and a network map showing how ePHI moves
• 72-hour restoration of critical systems after an incident

The proposal also removes the old "addressable vs. required" distinction — nearly everything becomes required. And it applies to covered entities and business associates alike, with no carve-out for small organizations.

As of this writing (August 2026), the rule is not final. The comment period closed in March 2025, and the federal regulatory agenda currently targets 2027 for final action. Timelines shift. The direction doesn't: explicit, scheduled security testing is where HIPAA is headed, and organizations that wait for the effective date will be starting a multi-year security program under a deadline.

What a HIPAA-Aligned Pentest Should Cover

Scope follows the data. Start from where ePHI lives and how it moves, then test the paths an attacker would use to reach it:

• Patient-facing web applications — portals, scheduling, telehealth. Authorization testing matters most here: can patient A read patient B's chart, results, or messages?
• APIs — FHIR endpoints, mobile backends, integration interfaces with labs, pharmacies, and billing partners. Broken object-level authorization in a health API is a reportable breach waiting to happen.
• External network — everything internet-facing: VPN gateways, remote access, email infrastructure, exposed services.
• Internal network — the scenario behind most large healthcare breaches: one compromised workstation, then lateral movement to the EHR. Segmentation between clinical and business networks gets validated here, and the proposed rule makes segmentation an explicit requirement.
• Cloud environments — where health-tech companies actually keep ePHI: storage buckets, managed databases, IAM configuration, secrets handling.

Whatever the scope, the report should map findings to Security Rule safeguards, rate severity, include proof of exploitation, and — critically — document remediation and retesting. The artifact you hand an auditor, assessor, or OCR investigator should tell the whole story: tested, found, fixed, verified.

Timing and Frequency

• Annually at minimum. This matches the proposed rule, cyber-insurance expectations, and what OCR considers a reasonable evaluation cadence.
• After significant changes. Section 164.308(a)(8) ties evaluation to environmental and operational change. A new patient portal, an EHR migration, a new integration partner, or a cloud re-architecture each warrant testing before ePHI flows through them at volume.
• Leave room to remediate. Schedule testing so your team has weeks — not days — to fix findings and get them retested before any audit, assessment, or renewal that depends on the report.

Mistakes That Surface in OCR Investigations

1. Treating the risk analysis as a document instead of a process

A risk analysis template filled out in 2023 and untouched since is the single most common gap OCR cites. Testing on a schedule is what keeps the analysis "accurate and thorough" as your environment changes.

2. Scanning and calling it testing

A vulnerability scan is not a penetration test. Scans catch missing patches. They do not catch the access-control and business-logic flaws that actually expose patient records — the class of bug we find most often in healthcare applications.

3. Scoping around the ePHI

Testing the marketing website while the patient portal, the API, and the internal network go untouched produces a report that answers none of the questions an investigator will ask. Scope must follow the data.

4. Ignoring business associate exposure

If you're a health-tech vendor, your covered-entity customers are already asking for your testing evidence during procurement, and you are directly liable under the Security Rule. A current pentest report shortens security reviews and sales cycles at the same time.

5. No remediation trail

A report full of open critical findings from eight months ago is worse than no report — it proves you knew. Fix, retest, and keep the evidence. At Voke Cyber, retesting within 30 days is included with every engagement.

Frequently Asked Questions

Does a vulnerability scan satisfy HIPAA's evaluation requirement?

A scan alone is thin evidence. Scans find known, unpatched software issues. They do not test authorization logic, session handling, or the paths an attacker actually takes to reach ePHI. The proposed Security Rule update treats them as separate controls: scanning at least every six months and penetration testing at least every twelve. Plan for both.

Are business associates required to test too?

Yes. Business associates have been directly liable under the Security Rule since the 2013 Omnibus Rule, and the proposed update applies its testing requirements to covered entities and business associates alike. If you host, process, or transmit ePHI for a covered entity, the same expectations apply to you.

How much does a HIPAA-aligned penetration test cost?

For a typical patient portal or health-tech application with supporting external infrastructure, expect $8,000 to $25,000 depending on the number of applications, user roles, and whether internal network testing is in scope. That's a small line item next to a healthcare breach.

What happens if OCR investigates and we have no testing evidence?

The investigation will ask what you knew about your vulnerabilities and when. No risk analysis, no evaluation records, and no testing history makes every other answer worse. The failure to conduct an accurate and thorough risk analysis is the most common finding in OCR enforcement actions, and settlements regularly include multi-year corrective action plans on top of the fines.