5 October 2026 · 9 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
HIPAA Penetration Testing: What the Security Rule Expects and What OCR Looks For
HIPAA never used the words "penetration test" in its original Security Rule. Covered entities and business associates still run them, because risk analysis and periodic evaluation are impossible to evidence without one. Here is where the obligation comes from and how to meet it.
Does HIPAA require penetration testing?
The HIPAA Security Rule (45 CFR Part 164, Subpart C) requires covered entities and their business associates to protect electronic protected health information (ePHI) through administrative, physical and technical safeguards. Two administrative standards drive testing: the risk analysis and risk management implementation specifications under 164.308(a)(1)(ii)(A) and (B), and the evaluation standard under 164.308(a)(8), which requires a periodic technical and non-technical evaluation of how well your safeguards meet the rule.
In January 2025 the US Department of Health and Human Services published a proposed rule to modernise the Security Rule. Among its proposals: vulnerability scanning at least every six months and penetration testing at least every twelve months, with the addressable-versus-required distinction removed. Organisations should track the final status of that rulemaking, but the direction is clear and most auditors already treat annual penetration testing as the expected practice.
The Security Rule provisions a penetration test gives evidence for
The Office for Civil Rights (OCR) enforces HIPAA by asking for documentation. These are the provisions where a test report answers the question.
164.308(a)(1)(ii)(A) Risk analysis
An accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI. OCR's most common finding in enforcement actions is a missing or inadequate risk analysis. A penetration test provides the technical vulnerability input that makes the analysis accurate and thorough rather than theoretical.
164.308(a)(1)(ii)(B) Risk management
Security measures sufficient to reduce risks to a reasonable and appropriate level. Findings with severity and remediation evidence show risk being managed, not just identified.
164.308(a)(8) Evaluation
Periodic technical and non-technical evaluation in response to environmental or operational changes affecting ePHI security. The technical half of this evaluation is where penetration testing sits.
164.312 Technical safeguards
Access control, audit controls, integrity, authentication and transmission security. A test demonstrates whether these controls hold against an attacker, for example by attempting to access ePHI without authorisation or to intercept it in transit.
164.308(a)(5)(ii)(D) and the proposed rule
Password management and, under the proposed modernisation, explicit vulnerability scanning and penetration testing cadences. Testing now positions you ahead of the rule rather than behind it.
Scoping a HIPAA penetration test
Scope follows ePHI. Any system that creates, receives, maintains or transmits ePHI, and any system that can reach those, is in scope.
- Patient portals, telehealth platforms, scheduling and billing applications, tested against OWASP Top 10 and authorisation flaws that expose one patient's data to another
- Electronic health record (EHR) integrations and APIs, including HL7 FHIR endpoints and third-party connectors
- External perimeter: VPNs, remote-access gateways, email, cloud consoles
- Internal network: assumed-breach testing from a workstation, lateral movement toward ePHI stores, Active Directory or Entra ID weaknesses
- Medical devices and clinical networks where in scope, tested with safety constraints agreed in advance
- Business associate interfaces: the connections to vendors that process ePHI on your behalf
- Retest after remediation, documented for the risk management file
HIPAA testing cadence: current practice and the proposed rule
What auditors expect today versus what the 2025 proposed Security Rule would require.
| Activity | Current expectation | Proposed rule (2025 NPRM) |
|---|---|---|
| Risk analysis | Periodic, and whenever the environment changes | Written, reviewed at least every 12 months |
| Penetration testing | Annually by common practice; required by many BAAs and cyber insurers | At least every 12 months |
| Vulnerability scanning | Regular, frequency set by the entity | At least every 6 months |
| Evaluation (164.308(a)(8)) | Periodic technical and non-technical | Compliance audit at least every 12 months |
| Remediation | Reasonable and appropriate | Patch critical within 15 days, high within 30 days |
What OCR and auditors look for in the evidence
OCR investigations, whether triggered by a breach report or a complaint, start with a document request. For technical testing they expect to see the scope tied to your ePHI inventory, the date of the test, who performed it and their qualifications, the findings with severity, and the remediation record showing each finding was addressed or formally accepted as risk. A test with no remediation trail is often worse than no test, because it documents known vulnerabilities that were left open.
The report should also feed your risk analysis document explicitly. Auditors look for the link: this finding, this risk register entry, this mitigation. We structure HIPAA reports so the mapping is already done.
European healthcare and health-tech companies serving US patients
If you are a Dutch or EU health-tech company whose platform handles US patient data, you are typically a business associate under HIPAA and a controller or processor under the GDPR at the same time. One well-scoped penetration test serves both: the HIPAA risk analysis and evaluation standards on one side, GDPR Article 32's requirement to regularly test the effectiveness of security measures on the other. We scope and report for both frameworks in one engagement.
Frequently asked questions
Handling ePHI?
We scope to your ePHI systems, test for the access-control failures that cause breach reports, and deliver a report mapped to the Security Rule standards your auditor will cite. Talk to an expert.