HIPAA Penetration Testing: Requirements, Scope, and Provider Checklist

HIPAA does not contain the words "penetration test." You will not find them in the Security Rule, the Privacy Rule, or any enforcement guidance published by HHS. Yet covered entities and business associates face a clear obligation: evaluate risks to electronic protected health information (ePHI), implement safeguards, and periodically verify those safeguards actually work. A well-scoped penetration test is often the most direct, defensible way to produce that verification. It generates evidence an auditor can review, surfaces vulnerabilities a scanner alone will miss, and gives your remediation team concrete findings ranked by clinical and business impact.

This guide walks through the regulatory basis, scoping decisions, planning logistics, and provider evaluation criteria that healthcare executives, CTOs, and security leads need before commissioning a test.

Is HIPAA penetration testing required?

The short answer is that HIPAA requires the outcome a penetration test delivers, without naming the method.

Two provisions matter most:

1. Risk analysis under 45 CFR 164.308(a)(1)(ii)(A). Every covered entity and business associate must conduct an accurate, thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. The HHS Office for Civil Rights risk analysis guidance reinforces that the scope must include all ePHI an organization creates, receives, maintains, or transmits, and that no single methodology is prescribed.
2. Periodic evaluation under 45 CFR 164.308(a)(8). Organizations must perform periodic technical and nontechnical evaluations in response to environmental or operational changes affecting the security of ePHI. A penetration test is a technical evaluation that directly satisfies this standard.

What a pen test proves that a vulnerability scan does not

Automated scanners flag known CVEs and misconfigurations. They do not chain vulnerabilities together, test business logic in a patient portal, or demonstrate whether an attacker can move laterally from a compromised workstation to a database holding ePHI. Manual penetration testing does all of that. The resulting report separates theoretical exposure from what is actually exploitable, which is exactly the evidence HHS expects when it asks whether you have identified risks and evaluated safeguards.

A penetration test does not, by itself, make an organization compliant. Compliance requires documented policies, workforce training, access controls, encryption decisions, incident response procedures, and ongoing risk management. The test is one input, but it is a high-value input that is difficult to replace with anything else.

What a healthcare pen test should cover

Healthcare environments have characteristics that generic corporate pen tests often miss. Patient portals expose scheduling, messaging, and lab results. EHR integrations pass ePHI through HL7 or FHIR APIs. Telehealth platforms handle real-time audio and video alongside clinical data. A test scoped too narrowly will leave the riskiest surfaces untouched.

Below are the areas a thorough penetration testing services engagement should address when ePHI is in scope:

• Internet-facing web applications. Patient portals, provider dashboards, appointment scheduling, and payment pages. Test authentication, session management, authorization bypass, injection flaws, and data exposure using a methodology like the OWASP Web Security Testing Guide.
• APIs and microservices. REST and FHIR endpoints that exchange clinical data between systems. Verify token validation, rate limiting, object-level authorization, and error handling that might leak ePHI in responses.
• Cloud configuration. Storage buckets, IAM policies, network security groups, logging, and encryption-at-rest settings in AWS, Azure, or GCP. Misconfigured cloud resources are a recurring cause of healthcare breaches. Organizations using DevOps and cloud services should include infrastructure-as-code review alongside runtime testing.
• Identity and access management. Password policies, MFA enforcement, privilege escalation paths, service account hygiene, and SSO integration. Test whether a compromised low-privilege account can reach ePHI.
• Mobile applications. iOS and Android apps used by patients or clinicians. Check local data storage, certificate pinning, API communication, and session persistence on lost or shared devices.
• EHR and third-party integrations. Interfaces with Epic, Cerner, Athenahealth, or lab systems. Focus on data in transit, credential storage, and error conditions that could expose records.
• Network segmentation. Verify that clinical network segments are isolated from guest Wi-Fi, IoT medical devices, and administrative VLANs. Attempt lateral movement after initial compromise.
• Logging and monitoring. Confirm that attack activity during the test triggers alerts. If the security team does not detect simulated exploitation, the monitoring stack has gaps.
• Backup and restore assumptions. Validate that backups are encrypted, stored separately, and actually restorable. Ransomware scenarios depend on backup integrity.

Not every engagement needs to cover every area. The right scope depends on your risk analysis findings, asset inventory, and recent changes to your environment.

HIPAA penetration testing scope and evidence table

The table below maps common scope areas to the ePHI risk they address, the test evidence produced, and the typical internal owner responsible for remediation.

This table is a starting point. Adjust it based on your organization's architecture and the systems identified in your most recent HIPAA security risk analysis.

How to plan the test without disrupting care

Healthcare systems cannot tolerate unplanned downtime. A penetration test that crashes a patient portal during clinic hours or triggers a false-positive lockout on an EHR creates real clinical risk. Planning matters more here than in most industries.

Authorization and documentation

• Obtain written authorization from an executive with authority over the systems in scope. This letter should name the testing firm, define the scope, specify the test window, and confirm that the organization accepts the inherent risk of active testing.
• If any systems are hosted by a third party or business associate, confirm that your BAA and hosting agreement permit security testing. Some cloud providers require advance notification or have specific testing policies.

Scope boundaries and rules of engagement

• Define which IP ranges, domains, applications, and environments are in scope. Explicitly list anything that is out of scope, such as production EHR databases where even read-only testing could affect performance.
• Establish "safe harbor" rules: no denial-of-service testing against production systems, no modification or exfiltration of real patient data, no social engineering of clinical staff during patient care hours unless specifically authorized.
• Decide whether the test runs against production or a staging environment. Production testing is more realistic but carries more risk. Staging testing is safer but may miss configuration differences. Many organizations test staging first, then run a limited production validation.

Test windows and communication

• Schedule active exploitation phases during low-traffic periods. For a clinic, that might be evenings or weekends. For a 24/7 hospital system, coordinate with the NOC and clinical informatics team to identify the least disruptive windows.
• Designate emergency contacts on both sides. If a tester discovers an active breach or triggers an unintended outage, there must be a direct line to someone who can act immediately.
• Agree on real-time communication channels. A shared Slack channel or secure messaging thread lets testers flag high-severity findings before the final report, giving your team a chance to remediate urgent issues quickly.

PHI handling during the test

• The testing firm will likely encounter ePHI during the engagement. Ensure a Business Associate Agreement is in place before testing begins.
• Define how testers will handle any ePHI they access: no screenshots containing real patient data, no storage of ePHI on tester workstations beyond what is needed for evidence, and secure deletion after the engagement.
• If the test uses synthetic data in a staging environment, document that no real ePHI was involved. This simplifies post-test compliance documentation.

Reporting expectations

• Require a report that includes an executive summary, detailed technical findings with reproduction steps, risk ratings tied to ePHI impact, and specific remediation guidance.
• Ask for findings mapped to HIPAA safeguard categories (administrative, physical, technical) so your compliance team can update the risk register directly.
• Include a retest clause. The provider should verify that remediated findings are actually fixed, not just marked as resolved in a ticket.

How to choose a provider

Not every penetration testing firm understands healthcare workflows, regulatory expectations, or the clinical consequences of a misconfigured test. Here is what to evaluate:

Healthcare experience

Ask for references from organizations similar to yours: hospitals, clinics, digital health SaaS companies, or business associates. A firm that has tested patient portals, FHIR APIs, and EHR integrations will scope the engagement more accurately than one whose experience is limited to corporate networks.

If you are building or maintaining healthcare software, your testing provider should understand the clinical data flows specific to your product, not just generic OWASP categories.

Manual testing depth

Automated scanning is table stakes. The differentiator is manual testing: business logic flaws, chained exploits, authorization bypass in multi-role applications, and creative attack paths that scanners cannot model. Ask what percentage of the engagement involves manual work and request sample findings from previous reports (redacted, of course).

The OWASP penetration testing methodology outlines standard phases from pre-engagement through post-exploitation and reporting. Your provider should be able to describe their methodology in comparable terms and explain how they adapt it for healthcare environments.

Cloud, API, and mobile capabilities

If your ePHI lives in AWS, Azure, or GCP, the testing team needs cloud-native skills: IAM policy analysis, serverless function review, container escape testing, and infrastructure-as-code auditing. Similarly, if you have a mobile app, the team should test both the client and the API layer it communicates with.

Organizations that rely on custom software development services for their patient-facing applications should ensure the testing provider can review custom code paths, not just off-the-shelf components.

Report quality and remediation support

Request a sample report before signing. Look for:

• Findings with clear reproduction steps that your developers can follow
• Risk ratings that account for ePHI exposure, not just generic CVSS scores
• Remediation recommendations specific enough to act on, not boilerplate advice like "apply patches"
• An executive summary that a non-technical board member or compliance officer can understand

Some providers offer remediation consulting or can work directly with your development team to fix findings. This is especially useful if your internal security team is small.

BAA and security handling

The provider will access your systems and potentially encounter ePHI. They should:

• Sign a BAA before the engagement begins
• Demonstrate their own security practices: encrypted communications, secure evidence storage, background checks on testers, and defined data retention and destruction policies
• Carry professional liability insurance appropriate for healthcare engagements

Retest policy

A finding is not resolved until someone verifies the fix works. Confirm that the engagement includes at least one retest cycle at no additional cost, or negotiate retest pricing upfront. Retesting should cover all high and critical findings at minimum.

Reference check questions

When speaking with the provider's healthcare references, ask:

• Did the test disrupt any clinical operations?
• How quickly were critical findings communicated?
• Was the report useful for both technical remediation and compliance documentation?
• Did the provider understand your regulatory obligations without extensive coaching?

Practical next steps

You do not need to start from scratch. If you have completed a HIPAA security risk analysis, you already have the inputs needed to scope a focused penetration test.

1. Pull your asset inventory. Identify every system that creates, receives, maintains, or transmits ePHI. This is the universe of potential test targets.
2. Review your risk register. Look for risks rated high or critical that involve technical controls: authentication weaknesses, unencrypted data flows, unvalidated API endpoints, or unclear network segmentation. These should be prioritized in the test scope.
3. Map recent changes. The evaluation standard under 45 CFR 164.308(a)(8) specifically calls for evaluation in response to environmental or operational changes. If you launched a new patient portal, migrated to a new cloud provider, or integrated a new EHR module, those changes belong in scope.
4. Draft a scope document. List the systems, test types (web app, API, cloud config, network, mobile), rules of engagement, test windows, and PHI handling requirements. Share this with prospective providers and compare their responses.
5. Evaluate providers using the checklist above. Weight healthcare experience and manual testing depth heavily. A lower price from a firm that runs only automated scans will not produce the evidence your compliance program needs.
6. Budget for remediation, not just testing. The test will produce findings. Allocate engineering time and budget to fix them. A penetration test report that sits in a drawer does not reduce risk and will not impress an OCR auditor.
7. Schedule the retest. Plan a retest window 30 to 60 days after receiving the initial report. This gives your team time to remediate while keeping the engagement fresh enough for testers to validate fixes efficiently.
8. Update your risk analysis. Feed the test results back into your HIPAA risk analysis. Document what was tested, what was found, what was remediated, and what residual risk remains. This closes the loop that HHS expects and positions you well for the next evaluation cycle. NIST SP 800-115 provides a structured framework for planning tests, analyzing findings, and developing mitigation strategies that support this documentation process.

The goal is not a clean report. The goal is a defensible, documented process that shows your organization identifies risks, tests controls, fixes gaps, and verifies the fixes. A well-scoped penetration test is one of the strongest pieces of evidence you can produce toward that end.

Vladimir Terekhov

Co-founder and CEO at Attract Group