The HIPAA Security Rule is older than most of the technology it governs and is deliberately non-prescriptive, which makes it easy to misread in both directions. Some organizations conclude it demands very little. Others assume a specific list of required tests exists.
Neither is right, and the enforcement record is the most useful guide to what actually matters.
What the Rule Requires
Two standards do most of the work.
The risk analysis standard, at 164.308(a)(1)(ii)(A), requires 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 organization. This is a required implementation specification, not an addressable one.
The evaluation standard, at 164.308(a)(8), requires periodic technical and non-technical evaluation establishing the extent to which security policies and procedures meet the rule's requirements, performed in response to environmental or operational changes affecting the security of ePHI.
Neither names penetration testing. Both are difficult to satisfy credibly without technical assessment, because both use words like "accurate", "thorough" and "technical".
What OCR Has Said About Inadequate
The enforcement record is more instructive than the rule text, and it is publicly available.
A consistent theme across resolution agreements is that risk analyses were found inadequate. The specific deficiencies recur: analyses that covered only part of the environment; analyses conducted once and never updated as systems changed; analyses that were essentially a completed questionnaire with no technical basis; and organizations that had identified a risk, documented it, and taken no action.
That last category is worth dwelling on, because it is the one organizations create for themselves. Identifying a vulnerability and doing nothing is worse than not looking, because the documentation establishes knowledge. The corollary is that a tracked finding with a remediation plan, or an accepted risk with a written rationale and appropriate sign-off, is a defensible position.
Where Testing Fits
Think of the risk analysis as the obligation and testing as one of its inputs.
A defensible risk analysis needs to know where ePHI actually is, which is frequently more places than the inventory says. It needs to know what vulnerabilities exist in the systems holding it, and critically which of those are exploitable in your specific configuration, since a vulnerability behind a compensating control carries different risk than the same vulnerability exposed. And it needs to know what an attacker would actually reach.
Those are questions testing answers and a questionnaire does not. An analysis built only from self-assessment records what your team believes about the environment, which is a different thing from what is true.
What Is Worth Testing in a Healthcare Environment
Healthcare environments have a characteristic shape, and scoping should follow it.
The identity layer, first. Most healthcare breaches begin with a compromised account, and clinical environments carry particular pressures: shared workstations, staff moving between locations, and legitimate clinical need for rapid access that sits in tension with authentication friction.
Cloud environments holding ePHI. Most providers have moved core systems to cloud platforms, frequently in stages and with different teams configuring different parts. Permission drift and storage exposure are the recurring findings.
Third-party and vendor connectivity. Healthcare runs on interconnection, and vendor-managed systems inside the network are consistently among the weakest points assessed.
Medical devices and clinical systems, with appropriate care. Active testing of equipment in clinical use is not appropriate; passive assessment and configuration review are. Any provider proposing to scan a clinical network aggressively should be declined.
The path from corporate IT to clinical systems, which is the healthcare version of the IT to OT boundary problem and produces the same finding: connectivity accumulated faster than anyone documented.
Business Associates
If you process ePHI on behalf of a covered entity, the Security Rule applies to you directly. This has been true since the HITECH Act and remains widely misunderstood by technology companies who believe their obligations run only through the business associate agreement.
Practically, that means a SaaS company serving healthcare customers carries its own risk analysis and evaluation obligations, independent of what any customer requires. It also means your customers will increasingly ask to see evidence, because their own obligations extend to assessing you.
Documentation Is the Deliverable
The rule requires documentation to be retained for six years, and in an enforcement context the documentation is what exists.
Keep the risk analysis, the technical assessments underneath it, the decisions made about each identified risk, the evidence of remediation, and the record of who accepted what and when. Update it when the environment changes rather than annually by calendar.
An organization that can produce a current risk analysis, technical evidence supporting it, and a documented trail of decisions is in a substantially different position after an incident than one producing a spreadsheet dated three years earlier.
To discuss a healthcare security assessment, get in touch.
Frequently asked questions
Does HIPAA require penetration testing?
Not by name. The Security Rule requires an accurate and thorough assessment of risks to electronic protected health information under the risk analysis standard, and periodic technical and non-technical evaluation under the evaluation standard. Neither names a specific test. In enforcement actions, OCR has repeatedly found risk analyses inadequate where they amounted to a questionnaire rather than a technical assessment.
What is the difference between a risk analysis and a penetration test?
A risk analysis is the broader obligation: identify where ePHI lives, what threatens it, what vulnerabilities exist and what the resulting risk is. A penetration test is one input to that, establishing which vulnerabilities are real and exploitable. A risk analysis without technical input tends to record assumptions, which is the deficiency OCR most often cites.
Do business associates have the same obligations?
Yes. Business associates are directly liable for Security Rule compliance, including the risk analysis and evaluation standards, and OCR has taken enforcement action against them. If you process ePHI on behalf of a covered entity, these obligations apply to you directly rather than only through your business associate agreement.
How often should we test?
The rule says periodically and in response to environmental or operational changes, without specifying an interval. Annual testing plus assessment after significant change is the common and defensible interpretation. What matters more than the interval is that you can explain how you chose it and show it was followed.
What does OCR look at after a breach?
The risk analysis, almost immediately, and whether it was accurate, thorough and current. A substantial proportion of resolution agreements cite an inadequate or absent risk analysis as a central failing, frequently alongside evidence that the organization knew about a weakness and had not addressed it. Documentation of what you found and what you did about it is the most valuable thing you can hold.