If you work in healthcare IT or compliance, you’ve almost certainly been asked some version of this question: “Does HIPAA require penetration testing?”

The honest answer is: not explicitly. But the practical answer — the one that matters when an auditor is sitting across the table from you — is yes, you almost certainly need it.

Here’s why, and what healthcare organizations need to do to stay compliant.

—

What HIPAA Actually Says About Security Testing

The HIPAA Security Rule (45 CFR Part 164) does not use the phrase “penetration testing.” What it does require is that covered entities and business associates implement reasonable and appropriate safeguards to protect electronic protected health information (ePHI).

Specifically, the Technical Safeguards section (45 CFR 164.312) requires organizations to protect ePHI from unauthorized access, alteration, and destruction. And the broader Security Management Process standard (45 CFR 164.308(a)(1)) requires covered entities to:

  • Conduct an accurate and thorough risk analysis to identify potential threats to ePHI
  • Implement security measures to reduce risks and vulnerabilities to a reasonable level
  • Regularly review and modify security measures as needed

This is where penetration testing enters the picture. The HHS Office for Civil Rights (OCR) has consistently stated that risk analysis must include evaluation of technical vulnerabilities — which means you need a methodology for finding them. Penetration testing is the standard way the security industry does that.

OCR guidance published alongside the Security Rule notes that security testing should include “technical and nontechnical evaluation… of an entity’s operational security.” Penetration testing is the technical evaluation that satisfies this requirement.

—

The Risk Analysis Requirement Is the Real Driver

The most common enforcement gap OCR finds in HIPAA audits is an incomplete or inadequate risk analysis. Organizations that rely solely on automated vulnerability scanning — or worse, annual questionnaires — routinely fail to identify the kind of exploitable weaknesses that a skilled attacker would find.

Penetration testing closes that gap. Unlike a vulnerability scan, which identifies known issues by comparing system configurations against a database of signatures, a penetration test simulates an actual attack. Testers chain together seemingly minor vulnerabilities — an exposed administrative interface here, a weak credential policy there — and demonstrate the actual path to ePHI that a real adversary would follow.

That distinction matters enormously for HIPAA compliance. The Security Rule requires you to assess threats “to the confidentiality, integrity, and availability” of ePHI. A vulnerability scanner tells you what’s exposed. A penetration test tells you what’s exploitable.

What a HIPAA Security Risk Assessment Should Include

The HIPAA Security Risk Assessment (SRA) is the formal process through which covered entities identify and document risks to ePHI. The SRA is not a one-time exercise — it must be conducted periodically and updated whenever significant operational, technical, or organizational changes occur.

A thorough HIPAA security risk assessment addresses four dimensions:

Threat identification. What external and internal threats could compromise ePHI? This includes technical threats (ransomware, credential theft, unauthorized access), physical threats (device theft, unauthorized physical access), and administrative threats (workforce policy failures, third-party vendor risk).

Vulnerability analysis. What weaknesses exist in your systems, processes, and controls that could be exploited? This is where penetration testing provides its most direct HIPAA value — it identifies the exploitable vulnerabilities that automated scanning misses, including chained attack paths that lead from a single compromised endpoint to an entire ePHI database.

Likelihood and impact assessment. For each identified threat-vulnerability pair, the SRA must estimate the probability of occurrence and the potential impact to ePHI confidentiality, integrity, and availability. Penetration test findings provide direct evidence for this assessment — documented exploitation paths with real impact scenarios carry significantly more weight in an OCR audit than theoretical risk ratings from a scanner.

Risk management and remediation tracking. The SRA must document how identified risks are being addressed, with timelines, ownership, and evidence of resolution. Organizations that conduct penetration tests and file the results away without acting on findings have satisfied the testing requirement but failed the risk management requirement. OCR has cited this gap specifically in enforcement actions.

One important nuance: the HIPAA Security Rule’s risk analysis requirement (45 CFR 164.308(a)(1)(ii)(A)) applies to all ePHI your organization creates, receives, maintains, or transmits — including data held by business associates. If your EHR vendor, billing processor, or cloud infrastructure provider handles ePHI on your behalf, their security posture is part of your risk landscape. Business associate agreements are necessary but not sufficient; your risk analysis should account for the security controls your BAs actually have in place.

—

What a HIPAA-Focused Penetration Test Should Cover

Not all penetration tests are created equal. A test scoped for PCI compliance looks very different from one scoped for HIPAA. Similarly, if your organization must meet both HIPAA and CMMC requirements (common for health tech companies serving defense contractors) or SOC 2 (common for health IT vendors), your scope will need to address each framework’s distinct requirements. When engaging a penetration testing firm for HIPAA compliance purposes specifically, your assessment should include:

External network penetration testing. Assess all internet-facing systems that could provide a path to ePHI — including patient portals, remote access gateways, cloud-hosted EHR interfaces, and API endpoints.

Internal network penetration testing. Once an attacker gains initial access (through phishing, a compromised vendor, or a misconfigured perimeter), what can they reach? Internal testing maps the lateral movement paths that lead to ePHI.

Web application testing. HIPAA-covered applications — patient scheduling portals, telehealth platforms, healthcare payment systems — are frequent targets. Web application penetration testing specifically validates authentication controls, session management, and access to patient records.

Access control validation. HIPAA requires that ePHI access be limited to authorized individuals. Penetration testing should verify that role-based access controls actually work as designed, including testing for privilege escalation and unauthorized data access.

Social engineering assessment. Human error remains the leading cause of healthcare data breaches. Phishing simulations and pretexting tests help identify whether staff training is working and where gaps remain.

—

How Often Should Healthcare Organizations Run Penetration Tests?

The Security Rule does not specify a frequency. OCR guidance indicates that assessments should be conducted “periodically” and whenever significant changes occur — new systems, new vendors, mergers, or changes in how ePHI is stored or transmitted.

In practice, most compliance-focused organizations run penetration tests annually at minimum. Healthcare organizations with higher risk profiles — those handling large ePHI datasets, operating patient-facing digital platforms, or subject to state-level regulations on top of federal HIPAA requirements — often conduct assessments twice per year. For a full discussion of testing frequency and how to build a continuous security testing model, see why annual penetration tests aren’t enough.

More importantly, the penetration test should not be a standalone event. The findings should feed directly back into your risk analysis documentation, your remediation tracking, and your Security Management Process. OCR has cited organizations for completing tests but failing to act on findings.

—

What to Do with Penetration Test Results

A penetration test produces a detailed report documenting vulnerabilities discovered, how they were exploited, and what data or systems were at risk. For HIPAA compliance, that report serves two purposes.

First, it feeds your risk analysis. Each finding should be evaluated for its potential impact to ePHI confidentiality, integrity, and availability, and documented as a risk that your organization has assessed and addressed.

Second, it drives remediation. The vulnerabilities identified need to be fixed, with timelines and ownership assigned. Retesting after remediation — either through a focused retest or the next annual assessment — confirms that issues were resolved.

Keep this documentation. OCR investigations frequently go back years, and demonstrating a consistent pattern of testing, finding, fixing, and retesting is evidence of the “reasonable and appropriate” standard the Security Rule requires.

—

Selecting a Penetration Testing Firm for HIPAA Assessments

Look for vendors who understand healthcare environments. That means familiarity with common EHR platforms (Epic, Cerner, Meditech), medical device security, HL7/FHIR API vulnerabilities, and the data flows that characterize healthcare organizations.

Your vendor should also understand HIPAA scoping requirements and be able to produce documentation that maps findings to the Security Rule standards. A report that simply lists CVEs does not help a compliance officer defend the organization’s risk management posture to an auditor.

Ask prospective vendors:

  • How do you scope a HIPAA penetration test differently from a standard engagement?
  • Can you provide a sample report with HIPAA-relevant findings documented?
  • What is your process for handling ePHI encountered during testing?
  • Do you carry appropriate liability coverage, and can you sign a Business Associate Agreement?

The last question is not optional. Any vendor whose testing methodology involves interacting with live ePHI is a business associate under HIPAA and must sign a BAA before work begins.

For a comprehensive framework to evaluate penetration testing vendors across technical qualifications, methodology, and deliverables, see our guide to how to choose a penetration testing company.

—

Frequently Asked Questions

Does HIPAA explicitly require penetration testing?

Not by name. The HIPAA Security Rule requires covered entities to conduct a thorough risk analysis and implement reasonable and appropriate technical safeguards. OCR guidance consistently treats technical security testing — which in practice means penetration testing — as the expected method for satisfying this requirement. Organizations that skip penetration testing in favor of vulnerability scanning alone have consistently faced enforcement scrutiny.

How is a HIPAA penetration test different from a standard pentest?

A HIPAA-focused engagement is scoped around the flow of ePHI through your systems, not just your general network perimeter. The tester needs to understand your EHR architecture, patient portal integrations, HL7/FHIR API connections, and business associate data flows. The resulting report should map findings to HIPAA Security Rule controls — not just CVE IDs — so compliance officers can use it to update their risk analysis documentation.

Does my penetration testing vendor need to sign a BAA?

Yes, if their testing methodology involves accessing, processing, or transmitting live ePHI. This includes testers who connect to production systems containing patient records. Your vendor should be prepared to sign a Business Associate Agreement before work begins. Failing to have a BAA in place with a vendor who handles ePHI is itself a HIPAA violation.

Can I use a vulnerability scan instead of a penetration test for HIPAA?

A vulnerability scan satisfies the monitoring component of HIPAA’s risk analysis requirement, but it is not a substitute for penetration testing. Scans identify known, signature-matched vulnerabilities. Penetration testing identifies which of those vulnerabilities — and which combinations of seemingly minor issues — are actually exploitable in your specific environment. OCR enforcement actions have cited organizations with vulnerability scanning programs that failed to detect the actual attack paths used in breaches.

—

The Bottom Line

HIPAA does not spell out “annual penetration test” as a checkbox requirement. What it requires is a comprehensive, ongoing risk management process — and for any organization handling ePHI, penetration testing is the standard method for satisfying the technical evaluation component of that requirement.

For healthcare organizations still relying on vulnerability scans alone, the risk is not just regulatory. It’s operational. The question is not whether a motivated attacker could find a path to your patient data. A penetration test answers that question before a breach does.

StrikeHaven Security conducts HIPAA-focused penetration tests for healthcare providers, health tech companies, and business associates. Our team has experience with Epic, Cerner, and Meditech environments, HL7/FHIR API security, and HIPAA Security Rule documentation requirements.

> Schedule a HIPAA Compliance Assessment →

>

> Tell us about your environment — EHR platform, cloud infrastructure, and any recent changes — and we’ll scope an assessment that satisfies your risk analysis requirements.