HIPAA

The Security Rule does not say "penetration test". It says something harder.

HIPAA is deliberately technology-neutral: it requires an accurate risk analysis and periodic technical evaluation of your safeguards, and leaves the method to you. That is why OCR findings so often turn on a risk analysis that was never done properly rather than on a missing scan.

The short answer

The HIPAA Security Rule does not explicitly require penetration testing. It requires an accurate and thorough risk analysis (45 CFR §164.308(a)(1)(ii)(A)) and periodic technical and nontechnical evaluation (§164.308(a)(8)). Testing is how most covered entities and business associates satisfy the technical half.

Is a pentest mandatory?
Not named in the rule. Risk analysis and periodic evaluation are required.
Who it applies to
Covered entities and their business associates, including SaaS vendors handling ePHI
Frequency
Not specified. "Periodic" plus in response to environmental or operational change.
What OCR examines
Whether the risk analysis is accurate, thorough and current — the most cited failure
Proposed change
The January 2025 NPRM proposes explicit scanning every six months and annual pentesting. Proposed, not final.
Business associates
Contractually and directly liable; a BAA does not transfer the obligation away

The requirements

What the HIPAA text actually says

45 CFR §164.308(a)(1)(ii)(A)

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.

In practice: This is the requirement, and it is the one OCR cites most. "Accurate and thorough" means it covers every system that touches ePHI — including the shadow ones — and reflects reality rather than a template.

45 CFR §164.308(a)(1)(ii)(B)

Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.

In practice: Risk management follows risk analysis. Findings you identified and did not address are worse than findings you never looked for, because the record shows you knew.

45 CFR §164.308(a)(8)

Perform a periodic technical and nontechnical evaluation in response to environmental or operational changes affecting the security of electronic protected health information.

In practice: The clause that testing satisfies. Note "in response to changes" as well as periodic — a major platform migration triggers evaluation regardless of when the last one happened.

45 CFR §164.312(a)(1)

Implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to those persons or software programs that have been granted access rights.

In practice: Access control, and the reason authorisation testing matters more than anything else in a health application: unique user identification and least privilege are testable assertions about your software.

45 CFR §164.312(b) / §164.312(e)(1)

Implement hardware, software and procedural mechanisms that record and examine activity in systems containing ePHI; implement technical security measures to guard against unauthorised access to ePHI transmitted over a network.

In practice: Audit controls and transmission security. Testing intersects when a test reaches ePHI and nothing in your logs records that it happened.

Why the Rule Avoids Naming Methods

The Security Rule was written to apply to a solo dental practice and a national hospital network at once, so it states objectives and lets scale determine the method. That flexibility is why it has survived two decades of technology change, and why "does HIPAA require a penetration test?" has no clean yes.

What it does not give you is permission to do nothing. The risk analysis is a required implementation specification, not an addressable one, and OCR enforcement history is full of settlements where the underlying failure was an inadequate or absent risk analysis rather than a specific missing control.

For a software company handling ePHI, the practical translation is straightforward: know every place ePHI lives and moves, test whether access controls actually hold there, fix what you find, and keep the record.

What Testing Should Cover in a Health Application

Authorisation first, and by a wide margin. In a health application the catastrophic finding is one patient record reachable by another patient, or by a clinician outside the care relationship, or by a partner organisation whose access should be scoped. That is a business rule, invisible to scanners, and it needs testing as every role you support: patient, clinician, administrator, support staff, partner, integration.

Then the integration surface, which is where health software differs from most SaaS. FHIR and HL7 interfaces, referral and results feeds, document exchange, and any bulk export path deserve specific attention because they move a lot of ePHI in one request and are frequently built with implicit trust between systems.

Then the ordinary things that leak ePHI anyway: verbose errors containing patient identifiers, ePHI in URLs that end up in logs and referrers, documents accessible by sequential identifier, and audit logging that does not record access to the records it is supposed to protect.

Business Associates Are Not Sheltered by the BAA

If you are a SaaS vendor processing ePHI for a covered entity, the Security Rule applies to you directly, and a business associate agreement allocates responsibility rather than removing it. Your customers will also push their own obligations down contractually, which is why health-sector deals come with the longest security questionnaires in software.

The commercially useful consequence: being able to hand a prospect a current test report with a remediation trail shortens those reviews materially. It is the same artefact your own evaluation requirement calls for, so the compliance work and the sales work are the same work.

The Proposed Rule, Handled Carefully

In January 2025 HHS published a notice of proposed rulemaking that would modernise the Security Rule, including explicit requirements for vulnerability scanning every six months and annual penetration testing, along with asset inventories, network mapping and stricter encryption expectations.

It is a proposal. Until a final rule is published, the enforceable text remains the current Security Rule, and any vendor telling you HIPAA now mandates annual penetration testing is ahead of the regulation. That said, the direction is clear, and a programme built around continuous scanning plus annual testing today is both defensible under the current rule and prepared for the proposed one.

Evidence

What to hand your auditor

  • ✓A current, dated risk analysis covering every system that creates, receives, maintains or transmits ePHI
  • ✓Risk management decisions: what you found, what you did, and the justification for anything accepted
  • ✓Evidence of periodic technical evaluation — test reports being the usual form
  • ✓Evidence of evaluation triggered by environmental or operational change, not just by the calendar
  • ✓Test scope showing every user role in the application was covered, including support and partner access
  • ✓Remediation and retest records for findings that touched ePHI paths
  • ✓Audit log evidence showing access to ePHI is recorded, including access generated during testing
  • ✓Business associate agreements, and where you sit in the chain for each

Avoid

What costs teams an audit cycle

  • ✕Treating a security questionnaire or a gap assessment as a risk analysis. OCR distinguishes them, and the risk analysis is the required one.
  • ✕A risk analysis that omits the systems nobody remembered: the reporting database, the export job, the staging environment with real patient data.
  • ✕Testing unauthenticated only, which by definition cannot find the cross-patient access flaws that matter most.
  • ✕Identifying a risk and neither mitigating nor documenting the acceptance decision — the record then shows you knew.
  • ✕Assuming a BAA moves the obligation to your customer or your vendor. It allocates responsibility; the rule still applies to you.
  • ✕Citing the January 2025 proposed rule as though it were in force. It is not, and an auditor will notice.

FAQ

HIPAA testing questions

Does HIPAA require penetration testing?

Not explicitly. The Security Rule requires an accurate and thorough risk analysis (§164.308(a)(1)(ii)(A)) and periodic technical and nontechnical evaluation (§164.308(a)(8)). Penetration testing is how most organisations satisfy the technical evaluation, but the rule names the objective rather than the method.

How often should we test for HIPAA?

The rule says "periodic" and adds "in response to environmental or operational changes", without an interval. Most organisations settle on annual testing plus continuous scanning, and test again after significant changes. The January 2025 proposed rule would make six-monthly scanning and annual testing explicit, but it is not final.

What is the difference between a risk analysis and a penetration test?

A risk analysis is the required, organisation-wide assessment of risks to ePHI across all systems, including administrative and physical safeguards. A penetration test is a technical activity that provides evidence for part of it. You cannot substitute the test for the analysis, and OCR findings frequently turn on exactly that gap.

Do business associates have to test?

The Security Rule applies to business associates directly, so the same risk analysis and evaluation obligations apply. A BAA allocates responsibility between parties; it does not remove your own. In practice customer contracts often impose testing explicitly on top.

What findings matter most in health applications?

Access control between patients, clinicians and organisations — one record reachable by the wrong identity is the catastrophic case, and it is invisible to scanners. After that: the integration surface (FHIR, HL7, bulk export), ePHI leaking into URLs and logs, and audit logging that fails to record access it should.

Produce the evidence continuously, not the week before the audit

Penetrify tests on every deploy from $100/month, with retests included — so the trail of what was found, fixed and verified builds itself.

Start free scan