Does HIPAA require penetration testing?

The honest answer, then the useful one

Search the HIPAA Security Rule for "penetration test" and you'll find nothing. HIPAA was written to be technology-neutral and scalable from a two-person practice to a national insurer, so it specifies outcomes, not techniques. Anyone telling you "HIPAA mandates an annual pen test" is quoting industry practice, not the regulation.

But the regulation does require something a pen test is built to deliver. 45 CFR §164.308(a)(8) — Evaluation — requires you to "perform a periodic technical and nontechnical evaluation … that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements" of the Security Rule, initially based on the rule's standards and "subsequently, in response to environmental or operational changes affecting the security of electronic protected health information."

Unpack that and three things fall out:

• It's a required standard — not addressable — and it binds business associates, i.e., every SaaS company under a BAA.
• It must be technical as well as procedural. Reviewing your policy binder is the nontechnical half; something has to actually probe whether your safeguards work. That's where security testing lives.
• It's periodic and change-triggered — repeat it on a cadence and after meaningful changes to your environment.

Add §164.308(a)(1)(ii)(A), which requires an "accurate and thorough" risk analysis — accuracy is hard to claim about technical vulnerabilities you never tested for — and the practical position is settled: HIPAA doesn't name penetration testing, but a defensible HIPAA program includes it.

Three outside forces close the loop. OCR: corrective action plans in resolution agreements routinely require strengthened technical evaluation and vulnerability management — entities that ignored known technical weaknesses fare badly in enforcement. NIST: SP 800-66 (the implementation guide for the Security Rule) points to vulnerability scanning and penetration testing as activities supporting evaluation and risk analysis. Your customers: every enterprise healthcare security review asks for your most recent third-party pen test report or letter of attestation. In a deal, the absence of one is functionally a failed requirement, whatever the CFR says.

Pen test vs. vulnerability scan — don't substitute one for the other

The two get conflated constantly, including by vendors selling scans labeled as pen tests. They answer different questions:

You need both layers: scanning as the continuous hygiene loop, testing as the periodic adversarial check. A SaaS company that hands an auditor a Nessus export in response to "share your latest penetration test" has answered a different question — and experienced reviewers spot it instantly.

Scoping a pen test for a healthcare SaaS

Scope should follow your ePHI, which for a cloud-native SaaS means the application layer first:

External network

Your internet-facing perimeter: exposed services, DNS, mail, anything listening. Table stakes, usually quick for a cloud-native company.

Web application

The product itself, tested authenticated and unauthenticated: injection, access control, session handling, file upload paths — the OWASP Top 10 and beyond.

API

Often the biggest PHI surface and the least tested. Authentication, authorization on every object reference (BOLA/IDOR), rate limiting, and — critically for multi-tenant SaaS — tenant isolation: can an authenticated user of tenant A reach tenant B's records? Insist this is an explicit test objective.

Cloud configuration

IAM policies, storage bucket exposure, security groups, key management. Most modern healthcare data exposure is misconfiguration, not exotic exploitation.

Internal / assumed breach

What a compromised laptop or leaked credential can reach. Increasingly relevant as headcount grows; often phased into year two or three.

Social engineering

Phishing the workforce. Valuable, but ad-hoc — many teams cover the human layer through their training program's phishing simulations instead and spend pen test budget on the application.

For a startup's first engagement, external + web app + API with tenant isolation as a named objective is the right minimum. Two operational notes: agree rules of engagement (testing windows, off-limits actions, emergency contacts) before anyone touches production, and — since testers may encounter real ePHI — sign a BAA with the testing firm and specify how captured evidence is handled and destroyed. Many teams route destructive testing at a staging environment seeded with synthetic data and keep production testing non-destructive.

Frequency: annual plus change-driven

The industry norm, and what review processes are calibrated to:

• Full test annually. Customer questionnaires assume a report less than 12 months old; an older one reads as a lapsed control.
• Targeted retest after major change — a new product surface handling ePHI, an auth system replacement, a re-architecture, a major new integration, or remediation of critical findings (verify the fix, don't assume it). This isn't gold-plating; §164.308(a)(8) explicitly keys re-evaluation to "environmental or operational changes affecting the security of ePHI."
• Continuous scanning between tests — dependency scanning in CI, infrastructure scanning at least monthly, cloud posture monitoring always-on.

Choosing a vendor

The market ranges from excellent boutiques to scan-and-rebrand mills. Filters that work:

• Tester credentials and firm accreditation — OSCP/OSWE-level certifications on the individuals actually doing the work; CREST or similar accreditation on the firm. Ask who is staffed on your engagement, not who's on the website.
• Relevant experience — multi-tenant SaaS and healthcare. Ask directly: "how do you test tenant isolation?" A good firm has a crisp answer.
• A sample report — read one before signing. You're buying the artifact as much as the testing: it goes to your auditors and customers, so it needs an executive summary a buyer can read and technical detail your engineers can act on.
• Methodology transparency — mapped to something recognizable (PTES, OWASP testing guides, NIST SP 800-115), with manual testing explicitly distinguished from automated scanning.
• Retest included — confirm whether verification of fixes is in the price, and whether they issue a remediation letter or attestation you can share without exposing the full findings.
• Willingness to sign a BAA — a firm that regularly works in healthcare won't blink.

Handling findings — where the compliance value actually lives

The report is not the deliverable; the remediation trail is. A pen test report you commissioned and shelved is documented knowledge of unaddressed risk — in an OCR investigation or a breach lawsuit, that's worse than ignorance. Wire findings into your risk machinery:

1. Triage into the risk register. Each finding gets rated with the same likelihood/impact scales as your risk analysis — that's the §164.308(a)(1)(ii)(B) risk management process doing its job. The tester's severity is an input; your rating reflects your environment and compensating controls.
2. Assign owners and SLAs tied to severity. Common practice: criticals in 7–15 days, highs in 30, mediums in 90, lows by next cycle or formally accepted. Whatever numbers you choose, write them into your vulnerability management policy and then hit them — a documented SLA you miss is its own finding.
3. Document risk acceptance properly. Findings you won't fix need a written rationale, compensating controls, and sign-off from someone with authority to accept the risk.
4. Verify and evidence closure. Retest (vendor or internal), capture the proof, and link it to the register entry. "Fixed" without evidence doesn't survive an audit.
5. Feed the lessons sideways — recurring finding classes belong in engineering standards, code review checklists, and training content; systemic ones belong in the next risk analysis.

One test, two frameworks

If you're pursuing SOC 2 alongside HIPAA — and most healthcare SaaS companies end up doing both — the same engagement produces evidence for each:

• HIPAA: the report plus remediation trail evidences the §164.308(a)(8) technical evaluation and feeds the §164.308(a)(1) risk analysis and risk management documentation.
• SOC 2: the same artifacts support the monitoring-of-controls criteria (commonly cited as CC4.1) and the vulnerability management expectations under the security criteria; your auditor will request the report, the tracking of findings, and closure evidence.
• Customers: the attestation letter answers the pen test question on every security questionnaire for the next twelve months.

The operational trick is storing the artifacts once — report, register entries, remediation tickets, retest evidence — and mapping them to every framework that needs them, rather than rebuilding the story per audit. That cross-mapping is exactly the job of evidence management done properly (and exactly what LukaGRC automates). Run the free HIPAA SaaS readiness checker to see where testing and evaluation sit among your other gaps, then work the plan in the full HIPAA compliance guide.

Related reading

• HIPAA for SaaS & digital health — the full resource hub
• HIPAA SaaS readiness checker — free instant gap readout
• HIPAA compliance guide — the complete walkthrough
• HIPAA risk assessment — where pen test findings get rated and tracked
• HIPAA technical safeguards — the controls a pen test puts under pressure
• HIPAA vs SOC 2 — running both programs off shared evidence

Common questions

Does HIPAA explicitly require penetration testing?

No. The words 'penetration test' appear nowhere in the HIPAA Security Rule. What the rule does require is a periodic technical and nontechnical evaluation (§164.308(a)(8)) of how well your safeguards meet the rule's requirements, plus an accurate and thorough risk analysis (§164.308(a)(1)(ii)(A)). Penetration testing has become the de facto way to satisfy the technical half of that evaluation — and the thing OCR resolution agreements, auditors, and enterprise customers expect to see.

What is the difference between a penetration test and a vulnerability scan?

A vulnerability scan is automated: a tool enumerates known weaknesses (missing patches, weak TLS, exposed services) and produces a list, cheaply and repeatably — run it at least monthly. A penetration test is human-driven: a skilled tester chains weaknesses together, exploits them in a controlled way, and demonstrates real impact like reaching ePHI. Scans find known issues; pen tests find what an actual attacker could do with them. You need both, and substituting a scan for a pen test is a gap auditors and customers notice immediately.

How often should a SaaS company do a HIPAA pen test?

The norm is annually, plus a targeted retest after major changes — a new product surface handling ePHI, a significant architecture change, a new authentication system, or post-incident. §164.308(a)(8) explicitly ties re-evaluation to environmental and operational changes, not just the calendar. Most enterprise customer contracts and security questionnaires also assume an annual external test with a report less than 12 months old.

What should be in scope for a healthcare SaaS pen test?

At minimum: your external network perimeter, the web application, and the APIs — including authentication, authorization, and multi-tenant isolation (can tenant A reach tenant B's PHI?). Add cloud configuration review for your AWS/GCP/Azure footprint. Internal network testing and social engineering matter more as you grow; for a small cloud-native SaaS, the application and API layer is where ePHI exposure actually lives.

Can we do penetration testing in-house?

Nothing in HIPAA prohibits it, and internal security teams running offensive testing is valuable. But independence matters for evidence: customers and auditors weight a third-party report far more heavily than a self-assessment, and an external tester brings fresh eyes to assumptions your team stopped questioning. The common pattern is continuous internal scanning and ad-hoc internal testing, plus an annual independent third-party test.

How do we choose a penetration testing vendor?

Look for relevant credentials (OSCP/OSWE-certified testers, CREST-accredited firms), healthcare or multi-tenant SaaS experience, a sample report you can read before signing, and clear rules of engagement. Ask how they test authorization and tenant isolation specifically — that's where your PHI risk concentrates. And because testers may encounter real ePHI during the engagement, sign a BAA with the testing firm and pin down data handling in the contract.

What do we do with pen test findings under HIPAA?

Treat them as inputs to your risk analysis and risk management process (§164.308(a)(1)(ii)(A)-(B)): rate each finding, feed it into the risk register, assign an owner and a remediation deadline tied to severity, and document closure with evidence. A pen test report you paid for and didn't act on is documented knowledge of unaddressed risk — in an OCR investigation that's worse than not knowing. Most teams set SLAs like critical 7-15 days, high 30, medium 90.

Do pen test results count as evidence for both HIPAA and SOC 2?

Yes — the same engagement does double duty. For HIPAA it evidences the §164.308(a)(8) evaluation and feeds the risk analysis. For SOC 2 it supports the monitoring criteria (commonly CC4.1) and vulnerability management expectations, and auditors will ask for the report plus remediation tracking. Store the report, the risk-register entries, and the closure evidence once, and map them to both frameworks.

Will a pen test disrupt production or expose PHI?

A well-run test shouldn't. Rules of engagement define what's off-limits (destructive tests, denial of service), testing windows, and emergency contacts. Many teams point testers at a staging environment seeded with synthetic data for the aggressive work and limit production testing to non-destructive verification. If testers could plausibly touch real ePHI, have a BAA in place and require secure handling and destruction of any data captured in evidence.

Is a bug bounty program a substitute for penetration testing?

No — it's a complement. Bounty programs give you continuous, incentive-driven coverage of whatever researchers happen to look at; a pen test gives you systematic, scoped, documented coverage with a report you can hand to auditors and customers. The evaluation requirement and customer due-diligence expectations are satisfied by the methodical artifact, not the existence of a bounty inbox.

What does a HIPAA-relevant pen test cost?

It varies widely with scope, application complexity, and firm reputation — boutique firms testing a single web app and API sit at the lower end, while broad engagements covering external, internal, cloud config, and social engineering cost multiples more. Get quotes against a written scope rather than budgeting from a rule of thumb, and weigh the report's credibility with your enterprise customers as part of the value, not just the finding count.

Last updated: June 12, 2026 · Reviewed by the LukaGRC compliance team