HIPAA penetration testing: what the Security Rule actually requires

Does HIPAA require a penetration test?

Not by name. The HIPAA Security Rule (45 CFR Part 164, Subpart C) does not use the phrase "penetration test" anywhere in its text. It requires covered entities and business associates to conduct a Risk Analysis under 164.308(a)(1)(ii)(A) - "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of" ePHI - and, separately, a periodic technical and nontechnical Evaluation under 164.308(a)(8) that establishes whether your security policies and procedures still meet the Rule's requirements. In practice, a penetration test is one of the standard ways organizations satisfy the technical half of both.

If you handle ePHI, you need to be able to show your safeguards actually hold up under testing. A pentest is a common way covered entities and business associates do that, even though the Security Rule never names it.

A vendor page that flatly states "HIPAA requires a pentest" is inaccurate, and it is the kind of overclaim that answer engines increasingly discount. The accurate answer is the useful one: no named mandate, but a risk analysis and evaluation obligation that security testing is a standard way to evidence.

The Security Rule: risk analysis and evaluation

Risk Analysis (164.308(a)(1)(ii)(A)) is the foundational, ongoing exercise: identify where ePHI lives, what could go wrong, and how likely and severe that would be. Evaluation (164.308(a)(8)) is the check that your implemented safeguards still hold up - performed initially against the standards you implemented, and again whenever operational or environmental changes could affect ePHI security, such as a new application, a cloud migration, or a prior incident. Neither standard specifies a method, but a technical evaluation of an internet-facing application is difficult to perform credibly without some form of hands-on security testing.

A 2025 HHS proposal to update the Security Rule (a Notice of Proposed Rulemaking, published January 2025) would go further and add an explicit requirement for annual penetration testing. As of this writing that proposal has not been finalized - it is not yet part of the Security Rule, and covered entities should treat it as a signal of direction, not a current obligation.

Which safeguards a pentest supports

The Technical Safeguards standard (45 CFR 164.312) sets out five standards, and a pentest most directly exercises them: access control (limiting system access to authorized persons or software), audit controls (recording and examining activity in systems that hold ePHI), integrity (protecting ePHI from improper alteration or destruction), person or entity authentication (verifying that whoever or whatever is seeking access to ePHI is who they claim to be), and transmission security (guarding ePHI against unauthorized access while it moves across a network). A pentest against a web application or API handling ePHI probes exactly these boundaries - authentication and authorization, logging, data integrity, and encryption in transit.

How Intrudify helps

Intrudify runs a full web and API pentest and produces a report that maps each finding to the relevant Security Rule provisions, with reproducible proof for high and critical findings and developer-ready remediation. It supports your Risk Analysis and Evaluation evidence for systems handling ePHI; Intrudify does not itself certify you against HIPAA or replace your organization's own risk analysis.

• Findings mapped to the relevant Risk Analysis, Evaluation, and Technical Safeguards provisions
• Reproducible proof-of-exploit for high and critical findings
• Developer-ready remediation and a re-test window
• Delivered in hours, validated by OSCE3-certified testers

How a pentest maps to controls

See how Intrudify tests web apps and APIs against the controls that carry HIPAA into your security program.