Does HIPAA Require Penetration Testing?

Not by name. The HIPAA Security Rule never uses the words "penetration test." What it requires is a documented risk analysis, which is a Required implementation specification at 45 CFR 164.308(a)(1), and a periodic evaluation, which is a standard in its own right at 164.308(a)(8): a periodic technical and nontechnical evaluation of how well your security policies and procedures meet the Rule's requirements. A penetration test is the ordinary way organizations evidence the technical half of that evaluation, which is why nearly every regulated entity of any size ends up buying one despite the absence of a mandate. Nobody has ever been fined for the absence of a pentest report; plenty have been fined for a risk analysis that never tested whether the controls it described actually worked.

So the real question is not whether the Rule compels you. It is what your evaluation has to be able to show, and who is going to ask. This article covers both, and it is deliberately against our own interest in one place.

Key takeaways

• The Security Rule never uses the words "penetration test". What it requires is an accurate and thorough risk analysis at 45 CFR 164.308(a)(1) and a periodic technical and nontechnical evaluation at 164.308(a)(8).
• The evaluation is a standard, so it is required outright. It is explicitly both technical and nontechnical, which means a policy review alone does not satisfy it.
• Nobody has been fined for the absence of a pentest report. Plenty have been fined for a risk analysis that never tested whether the controls it described actually worked.
• Four forcing functions actually drive testing, and none is the Rule itself: enterprise customer questionnaires, SOC 2, PCI DSS 11.4 if you take cards, and cyber insurance underwriting.
• Scope the test to follow the ePHI, not the org chart, and ask explicitly for multi-tenant and cross-account authorization testing. That is the failure mode that ends up in a breach notification.

What the Rule actually says

Two provisions carry the weight.

164.308(a)(1)(ii)(A), risk analysis, Required. Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the entity. Note "accurate and thorough." That phrase is doing a lot of work. An assessment that lists controls without any evidence they function is neither.

164.308(a)(8), evaluation, a standard. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under the Rule and subsequently in response to environmental or operational changes affecting the security of ePHI, that establishes the extent to which the policies and procedures meet the requirements.

Three observations follow. The evaluation is a standard, so it is required outright, not addressable. It is explicitly both technical and nontechnical, so a policy review alone does not satisfy it. And it is triggered by change as well as by the calendar, which is the same trigger logic every other framework uses.

The Rule does not tell you what the technical evaluation must consist of. That is deliberate: the Security Rule is scalable to the size, complexity and risk profile of the entity, so a five-person telehealth startup and a national payer are not expected to evaluate identically. NIST SP 800-66 Revision 2, "Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide," published February 2024, is the recognized federal guidance on how to implement the Rule and is the document to hand your engineering team when they ask what good looks like.

Where the actual obligation comes from

In practice, four forces make healthcare companies test, and none of them is the Security Rule.

Enterprise customers. Every hospital system and health plan vendor questionnaire we have seen in the past two years asks for a current penetration test, usually within the last twelve months, usually with a summary report attached. This is the binding constraint for most health tech companies, and it arrives with a deal attached.

SOC 2. If you are also pursuing SOC 2, and most health tech companies selling to enterprises are, auditors expect testing as part of the risk assessment and monitoring criteria. It is not a line item in the criteria, but a report is what closes the conversation.

PCI DSS, if you take cards. This one genuinely is prescriptive. Requirement 11.4.2 and 11.4.3 mandate internal and external penetration testing at least every 12 months and after significant change, and the cadence is not negotiable. Our how often to run a penetration test article covers the full 11.4.x family, including the segmentation testing requirements that catch service providers.

Cyber insurance. Underwriters ask, and the answer affects the premium and sometimes the coverage.

If none of those four apply to you, the honest answer is that you have discretion. The Rule wants an evaluation. What that evaluation is made of is a risk decision you get to make and document.

What a defensible evaluation looks like when you are small

We would rather write this section than sell a test to someone who does not need one yet.

For an early-stage company with a small, stable environment and no enterprise customers yet, a defensible technical evaluation can be built from work you can do without a consultancy: authenticated vulnerability scanning on a real cadence with the findings tracked to closure, cloud configuration review against the provider's own benchmark, a documented review of access controls and logging against what 164.312 requires, and dependency scanning in CI. Write it up, date it, and keep the evidence. That is a technical evaluation, and it is honest.

What it is not is a substitute for testing once your risk profile changes. The moment you handle a meaningful volume of ePHI, ship a patient-facing application, integrate with a hospital's systems, or sign your first enterprise customer, a scan-only evaluation stops being defensible, because scanning and testing answer different questions. Penetration testing versus vulnerability scanning sets out the difference properly.

Scoping a healthcare penetration test so it evidences the right thing

If you are buying one, the scope should follow the ePHI, not the org chart.

Start from the data-flow map you built for the risk analysis. The systems that create, receive, maintain or transmit ePHI are the systems in scope. That usually means the patient or member-facing application, the APIs behind it, the administrative or clinician console (which is routinely omitted and routinely where the good findings are), the integration surface with customer systems, and the cloud control plane.

Two scoping notes specific to healthcare. First, authorization testing matters more than in most verticals, because the failure mode that ends up in a breach notification is one patient's record visible to another patient's account, and that is an authorization defect no scanner finds. Ask explicitly for multi-tenant and cross-account authorization testing.

Second, if any part of your platform touches a medical device or a device companion app, say so at scoping. The threat model and the safe-testing constraints are different, and a tester who discovers it mid-engagement will lose time.

For what an engagement should cost and what drives the number, our penetration testing cost breakdown has the sourced ranges. We are not restating figures here, because one page per number is the rule that keeps this site's answers consistent.

What changes if the proposed Security Rule is finalized

HHS published a proposed overhaul of the Security Rule on January 6, 2025 at 90 FR 898, and as of August 2026 it is still a proposal with no final rule on the record. The proposal's section-by-section analysis is where the security-testing provisions live, and it is worth reading in the original rather than through a vendor summary, several of which have already described proposed requirements as though they were in force.

What we will say is the direction of travel, which is not in dispute: the proposal makes explicit a set of practices the current Rule leaves to your judgment, and testing is among them. If you are already testing annually because a customer asked, finalization changes nothing for you. If you have never tested, you are the organization the change would reach. Our status article on the proposed rule covers what is verifiable about the timeline, which is less than most pages claim.

Where Top Floor fits, and when to say no

We do healthcare-scoped penetration testing and the HIPAA risk analysis and evaluation work around it.

Two situations where we would tell you not to buy from us or anyone else. If you have no ePHI in production yet, testing a staging environment that does not resemble production produces a report that answers a question nobody asked. And if your last test produced findings you have not fixed, buying another test is the most expensive way to avoid remediation. Fix, retest the fixes, then schedule the next full engagement.

How to decide this week

Open the last risk analysis and find the sentence where it establishes that a technical control works, rather than that it exists. If there is no such sentence, that gap is your evaluation gap, and it exists whether or not you buy a test.

Then check whether any of the four forcing functions apply: an enterprise customer questionnaire, a SOC 2 audit window, cardholder data in your environment, or an insurance renewal. If one does, you have a date, and the date is what should drive the schedule.

If none does, write the technical evaluation you can honestly produce today, date it, and set a review trigger tied to your next architecture change. That is a compliant answer, and it is cheaper than the alternative we sell.

Frequently asked questions

Does HIPAA require a penetration test?

Not explicitly. The Security Rule never uses the words penetration test. It requires an accurate and thorough risk analysis as a Required implementation specification at 45 CFR 164.308(a)(1)(ii)(A), and a periodic technical and nontechnical evaluation as a standard at 164.308(a)(8). A penetration test is the usual way organizations evidence the technical half of that evaluation, but the Rule leaves the method to you, scaled to your size, complexity and risk. What is not optional is being able to show that the controls your risk analysis describes actually work.

How often should a healthcare company run a penetration test?

At least once a year and again after significant change is the consensus floor across frameworks, and it is what enterprise healthcare customers ask for in security questionnaires. HIPAA itself sets no interval; it ties the evaluation to periodic review plus environmental or operational changes affecting ePHI security. If you also handle cardholder data, PCI DSS Requirements 11.4.2 and 11.4.3 make annual internal and external testing mandatory rather than advisory, and that is the cadence that will govern you.

Is a vulnerability scan enough to satisfy the HIPAA evaluation standard?

It can be, for a small and stable environment, provided the scanning is authenticated, runs on a real cadence, and the findings are tracked to closure alongside a documented review of access controls and logging. Write it up and date it. It stops being defensible once your risk profile changes: a patient-facing application, a meaningful volume of ePHI, an integration into a customer's systems, or a first enterprise customer all move you past what scanning alone can evidence, because scanning finds known vulnerabilities while testing finds the authorization and business-logic flaws that produce breach notifications.

Would the proposed HIPAA Security Rule change require penetration testing?

The proposal published on January 6, 2025 at 90 FR 898 would make explicit a number of practices the current rule leaves to judgment, and its section-by-section analysis is where the security testing provisions sit. As of August 2026 it remains a proposal with no final rule on the Federal Register record, so nothing in it is enforceable, and we are not going to quote proposed cadences we have not read in the operative text. Read the section-by-section analysis directly if you need the detail, and treat any page that states the proposal as current law with suspicion.