.svg)
The HIPAA Security Rule does not contain the phrase “penetration testing.” It also does not set a testing schedule. Yet auditors ask for pentest reports, and organisations that cannot produce one tend to have a harder time in a breach investigation. Both things are true, and the reason is worth understanding properly.
The Two Requirements Testing Maps To
164.308(a)(1)(ii)(A) — risk analysis. An accurate and thorough assessment of the potential risks and vulnerabilities to ePHI. “Accurate and thorough” is doing significant work in that sentence. An assessment based entirely on what your team already believes about its own systems is neither.
164.308(a)(8) — evaluation. Periodic technical and non-technical evaluation establishing the extent to which your safeguards meet the Rule's requirements. The word technical is the important one. Reviewing policies is the non-technical half. Testing whether the safeguards hold is the technical half.
Penetration testing is the strongest practical method of satisfying the technical half. It is not the only conceivable method, which is why the Rule does not name it — but it is what produces evidence rather than assertion.
What Should Be in Scope
Any system that creates, receives, maintains, or transmits ePHI, plus the paths into them:
- EHR platforms and clinical applications
- Patient portals and any patient-facing web application
- APIs and integrations moving ePHI between systems
- Cloud infrastructure hosting or processing ePHI
- Internal network segments where ePHI systems live
- Remote access paths — VPN, remote desktop, and third-party support access
- Connected medical devices where they touch the network
Remote access and third-party support paths deserve specific attention. They are frequently excluded from scope and are a recurring factor in healthcare breaches.
Vulnerability Scanning Is Not the Same Thing
Scanning identifies known vulnerabilities against a signature database. Useful, cheap, and worth running continuously. What it cannot do is chain findings together, establish whether a vulnerability is actually reachable, or demonstrate what an attacker could get to.
A scanner tells you a server is running an outdated component. A penetration test tells you whether that gets someone to your ePHI. For evaluation evidence, the second answer is the one that matters.
The BAA Requirement
A penetration tester working on systems containing ePHI is a business associate. That means a signed business associate agreement before testing begins — not after, not as a formality filed later.
Any provider willing to test ePHI systems without executing a BAA has told you something useful about their understanding of HIPAA. Ask about it during scoping.
How Often
The Rule sets no interval, so you define and justify your own cadence through your risk analysis. Most organisations settle on annually, plus retesting after material changes to the ePHI environment — a new EHR deployment, cloud migration, significant architectural change, or merger.
The proposed Security Rule update would make twelve months explicit, alongside six-month vulnerability scanning. That is a proposal, not current law — our guide to the proposed update covers the status. Organisations already testing annually would absorb a final rule without disruption.
What the Report Needs to Contain
For it to function as compliance evidence rather than a technical exercise: defined scope naming the systems tested, testing dates, tester qualifications, findings with severity ratings and evidence, remediation guidance specific enough to act on, and retest results confirming closure.
A report that lists findings and stops leaves the loop open. What demonstrates a functioning security programme is the remediation and retest, not the finding.
Internal Testing Deserves Equal Weight
External testing gets most of the attention, and healthcare breaches frequently do not start at the perimeter. Phishing, a compromised vendor connection, or a stolen credential puts an attacker inside, and what matters then is how far they can move.
Internal testing answers that: whether a workstation compromise reaches the EHR, whether clinical systems are segmented from general corporate networks, whether service accounts are over-privileged, and whether an attacker can reach ePHI without triggering anything.
For an evaluation under 164.308(a)(8) covering the safeguards that actually protect ePHI, internal testing is frequently the more informative half.
Medical Devices and Legacy Systems
Connected medical devices and legacy clinical applications need care in scoping. Many run unsupported operating systems, and some cannot tolerate aggressive testing without affecting clinical operations.
The answer is not to exclude them, since they are frequently the weakest point. It is to scope them explicitly with appropriate constraints — testing in a lab environment where one exists, passive assessment where active testing carries patient safety risk, and testing the network segmentation around the device where the device itself cannot be touched.
Document the reasoning either way. A scope that silently omits medical devices looks like an oversight; one that explains the constraint and describes the compensating approach looks like risk management.
Using the Report as Evidence
A pentest report supports several Security Rule requirements at once, and it is worth mapping that explicitly rather than filing the report and hoping the connection is obvious.
Findings feed your risk analysis under 164.308(a)(1)(ii)(A) as identified vulnerabilities with assessed likelihood and impact. The engagement itself evidences the periodic technical evaluation under 164.308(a)(8). Remediation records evidence risk management under 164.308(a)(1)(ii)(B). Findings about access control and authentication map to the technical safeguards at 164.312.
Writing that mapping into your documentation is a small amount of work that makes the evidence considerably more useful in an investigation, because it shows the testing was part of a programme rather than an isolated purchase.
Testing That Produces Evidence
Our HIPAA security risk assessment combines the documented risk analysis with technical testing of the systems that actually touch ePHI. BAA signed before testing starts, and retest included on originally scoped assets.
See also the HIPAA compliance checklist and cost guide.