7 HIPAA Penetration Testing Requirements Healthcare Teams Miss

HIPAA penetration testing sits in an unusual regulatory position. The HIPAA Security Rule has always required covered entities to conduct technical security reviews, but the specific language around penetration testing has been intentionally flexible, describing it as "addressable" rather than "required" in the original rule.

That is changing. HHS proposed a HIPAA Security Rule update in January 2025 that would make annual penetration testing explicitly mandatory for covered entities and business associates. Whether or not the proposed rule is finalized in its current form, the direction of regulatory expectation is clear: penetration testing is moving from a recommended practice to a named compliance requirement.

The problem is that many healthcare organizations are already misreading what their current HIPAA obligations require from security testing, and the proposed rule raises the bar further. These are the seven specific requirements where healthcare teams most commonly fall short, either misunderstanding what is required or implementing testing that satisfies the letter of the rule while leaving the underlying security gaps open.

Requirement 1: The risk analysis must inform the pentest scope

The HIPAA Security Rule's Risk Analysis requirement under 45 CFR 164.308(a)(1) is the foundation of all other security requirements. Every security measure, including penetration testing, is supposed to be informed by a current, comprehensive risk analysis.

In practice, most healthcare organizations conduct risk analysis and penetration testing as parallel but disconnected exercises. The risk analysis identifies theoretical risks. The pentest is scoped based on what systems are available and what the vendor proposes. The findings from neither consistently inform the other.

What HIPAA actually requires is that risk analysis findings drive pentest scope. If the risk analysis identifies patient portal authentication as a high-risk area, that surface needs to be tested with corresponding depth. If electronic health record API integrations are identified as critical data pathways, those APIs need to be tested with the same rigor as the EHR system itself. A pentest that does not reflect current risk analysis findings is not satisfying the Security Rule's intent, even if it produces a clean report.

This is also where the proposed 2025 HIPAA NPRM raises the bar: it requires that penetration testing scope be documented and justified against the organization's risk analysis, creating an explicit connection between the two exercises that auditors can evaluate.

Requirement 2: Business associates and their systems must be in scope

HIPAA's Security Rule applies not only to covered entities but to all business associates who handle protected health information (PHI) on their behalf. The definition of business associate is broad: EHR vendors, cloud hosting providers, billing processors, telehealth platforms, medical device manufacturers with connected devices, and any technology partner who creates, receives, maintains, or transmits PHI.

Most healthcare penetration tests focus on the covered entity's own infrastructure. They test the hospital network, the patient portal, the internal EHR deployment. The business associate ecosystem, including the APIs that connect to third-party systems, the data flows to external billing platforms, and the integration points with cloud-hosted services, is frequently out of scope.

A healthcare breach in 2026 is as likely to enter through a business associate integration as through the covered entity's own systems. Testing only the covered entity's perimeter while leaving business associate connection points unexamined is a compliance gap that OCR enforcement actions have consistently highlighted.

Requirement 3: PHI transmission paths need end-to-end coverage

The HIPAA Security Rule's Transmission Security standard under 45 CFR 164.312(e)(1) requires that covered entities implement security measures to guard against unauthorized access to PHI transmitted over electronic communications networks.

Most organizations satisfy this by verifying TLS configuration: checking that patient portals use HTTPS, that email encryption is enabled, that API connections use TLS 1.2 or higher. These checks are necessary but they are not transmission security testing. They are configuration verification.

Thorough transmission security testing covers the actual paths PHI follows through an organization's systems: whether internal API calls between microservices use encrypted channels, whether database replication across data centers uses encryption in transit, whether backup systems transmit data securely, whether medical devices send telemetry data over encrypted channels, and whether HL7 and FHIR interfaces enforce transport security consistently across all endpoints.

The gap between "our patient portal uses HTTPS" and "PHI is encrypted across all transmission paths" is where most HIPAA transmission security audits fail.

Requirement 4: Audit controls must be tested, not just configured

The Audit Controls standard under 45 CFR 164.312(b) requires covered entities to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use PHI.

Most healthcare organizations satisfy this by enabling audit logging in their EHR systems and reviewing logs periodically. What is rarely tested is whether the audit controls actually work: whether PHI access events are being captured completely, whether the logs cannot be tampered with by users who have access to the systems being logged, whether log coverage extends to all systems that handle PHI including integrated third-party applications, and whether the logging configuration would detect the specific access patterns associated with insider threats and unauthorized data extraction.

A penetration test that satisfies the Audit Controls requirement needs to include active testing of whether logging captures the tester's actions, whether those actions are distinguishable from normal user behavior in the logs, and whether the log data can be manipulated or deleted by users with elevated system access.

This is a category of testing that most standard penetration test methodologies omit entirely because it requires specific PHI-aware test cases rather than generic security assessment. For context on the broader set of requirements that standard assessments leave open, the security gaps standard testing consistently misses covers the structural reasons why generic testing approaches fail compliance-specific requirements.

Requirement 5: Medical device and IoT security is not optional scope

The healthcare attack surface has expanded dramatically through connected medical devices. IV pumps, patient monitors, imaging systems, wearable devices that transmit vitals, and clinical workstations running legacy operating systems all represent PHI-handling systems that are frequently excluded from penetration test scope.

The typical rationale for excluding medical devices is that they are managed by the device manufacturer or by biomedical engineering rather than IT, and that disrupting them during testing is clinically risky. Both concerns are legitimate. Neither justifies leaving medical device security entirely untested.

HIPAA does not create an exception for medical devices. Any device that creates, receives, maintains, or transmits PHI falls under the Security Rule's requirements. Healthcare organizations are responsible for ensuring those devices are part of their security program, which means either testing them directly under controlled conditions or obtaining documentation from manufacturers that demonstrates the device's security posture against current threat models.

OCR enforcement actions have explicitly cited connected medical device vulnerabilities as HIPAA findings. Testing scope that excludes all connected clinical devices is a compliance gap, not a reasonable risk management decision.

Requirement 6: Workforce access control testing must go beyond network perimeter

The Access Control standard under 45 CFR 164.312(a)(1) requires covered entities to implement technical policies and procedures that allow only authorized persons to access PHI. This sounds straightforward. The compliance gap is in what "access control testing" typically covers versus what the standard actually requires.

Standard access control testing in a healthcare penetration test checks whether the network perimeter requires authentication, whether the patient portal requires login, and whether administrative functions require elevated credentials. What it rarely tests is the granularity of access control within authenticated sessions: whether a nurse with access to their patient cohort can access records for patients outside their unit, whether billing staff with access to financial data can navigate to clinical records, whether a physician's credentials that should only access their own patients' records can be used to extract records for the full patient population.

Role-based access control (RBAC) enforcement in EHR systems is frequently misconfigured in ways that allow broader PHI access than the organization's policies permit. This misconfiguration is invisible to perimeter-focused testing and visible only through multi-user access control testing within authenticated sessions, which is a testing requirement for HIPAA's Access Control standard and a category of testing that most standard engagements skip.

Requirement 7: Remediation must be tested and documented within defined timelines

The HIPAA Security Rule does not specify remediation timelines for penetration test findings, but it does require that covered entities have a Risk Management standard under 45 CFR 164.308(a)(1)(ii)(B) that implements security measures sufficient to reduce risks to a reasonable and appropriate level.

OCR has consistently interpreted this to mean that findings from security assessments, including penetration tests, must be remediated and that remediation must be tracked and documented. A penetration test that produces findings that sit in a report without remediation action or without documentation of why remediation was deferred does not satisfy the Security Rule's risk management requirement.

The specific gap most healthcare teams miss is the retest confirmation requirement. Remediating a finding without confirming through retesting that the remediation actually works does not satisfy "implementing security measures sufficient to reduce risk." If an authentication bypass is patched but not retested, the organization does not know whether the patch closed the vulnerability or introduced a regression. Documentation of the remediation without documentation of its effectiveness is not sufficient evidence under the Security Rule.

This is the same remediation validation gap that affects every compliance framework, but it is particularly acute in healthcare because OCR enforcement actions frequently cite inadequate documentation of security measure effectiveness as a distinct HIPAA violation. Continuous agentic pentesting addresses this by automatically retesting findings when fixes are deployed, producing timestamped remediation confirmation records. The autonomous pentesting overview covers how this continuous validation loop generates the documentation trail that OCR expects to see.

The 2025 HIPAA NPRM: what is changing

HHS proposed significant updates to the HIPAA Security Rule in January 2025 through a Notice of Proposed Rulemaking (NPRM). The proposed changes are directly relevant to penetration testing requirements.

The NPRM would make penetration testing explicitly mandatory, specifying that covered entities conduct a penetration test at least once every 12 months and following any environment change that could affect the security of ePHI. It would require that penetration testing scope be documented and justified against the organization's risk analysis, and that results be reviewed by workforce members with the technical knowledge to evaluate findings.

The NPRM was under review as of mid-2026 and had not been finalized. Whether or not these specific requirements become law in their proposed form, they signal the direction of OCR enforcement expectations. Healthcare organizations building their security programs around the minimum viable interpretation of current HIPAA requirements are building programs that will not satisfy the regulatory environment of the next two to three years.

Building a HIPAA-compliant penetration testing program

The seven requirements above define the minimum scope for a penetration testing program that genuinely satisfies HIPAA's Security Rule rather than approximating it.

Satisfying all seven requires a testing approach that is informed by the organization's current risk analysis, covers business associate integration points, tests PHI transmission paths end to end, validates audit control effectiveness, includes medical device security assessment, tests access control granularity within authenticated sessions, and produces timestamped remediation documentation.

An annual manual engagement can cover most of this in scope but struggles with continuous cadence and automatic remediation validation. A continuous agentic testing model covers the full scope continuously and produces the evidence record that OCR expects. For healthcare organizations evaluating what that looks like in practice, see how the 10x Pentest platform is structured for continuous, exploit-driven testing, or explore pricing for your organization size. For teams ready to map their current testing posture against these seven requirements, the 10x Pentest team can identify where your existing program satisfies HIPAA obligations and where the gaps are.

Frequently asked questions

1. Does HIPAA require penetration testing?

HIPAA's Security Rule has always required covered entities to implement reasonable and appropriate technical safeguards to protect ePHI, and the Risk Analysis and Risk Management standards have consistently been interpreted to include technical security testing. Penetration testing is currently described as "addressable" rather than "required" under the Security Rule, meaning covered entities must either implement it or document a reasonable alternative. The 2025 HIPAA NPRM proposed making annual penetration testing explicitly mandatory. Whether or not the NPRM is finalized as proposed, OCR has cited absence of penetration testing in enforcement actions, and most healthcare legal and compliance professionals treat it as a practical requirement rather than an optional measure.

2. How often should HIPAA penetration testing be done?

Under current HIPAA requirements, the frequency should be determined by the organization's risk analysis and must be "reasonable and appropriate" given the organization's size, complexity, and capabilities. In practice, annually is the widely accepted minimum. The 2025 HIPAA NPRM proposes explicitly mandating annual testing, plus additional testing following any environmental change that could affect the security of ePHI. For healthcare organizations with frequently changing technology environments, continuous or cadence-matched testing is the model that satisfies both the frequency expectation and the post-change testing requirement.

3. What systems must be included in a HIPAA penetration test?

Any system that creates, receives, maintains, or transmits ePHI should be included in scope. This extends beyond the primary EHR system to include patient portals, API integrations with business associates, billing and claims platforms, telehealth systems, connected medical devices and clinical IoT, internal communication tools used to discuss patient information, backup and disaster recovery systems, and cloud infrastructure hosting PHI. The scope should be justified against the organization's current risk analysis, ensuring that systems identified as high-risk receive proportionally thorough testing.

4. What is the penalty for failing a HIPAA penetration test?

HIPAA does not have a "pass or fail" penetration test structure. The Security Rule requires covered entities to conduct appropriate security assessments and act on findings. Penalties arise from OCR enforcement actions when an organization fails to implement required safeguards, fails to conduct appropriate risk analysis and management, or experiences a breach that reveals inadequate security measures. Civil monetary penalties range from $100 to $50,000 per violation category per year, with a maximum of $1.9 million per violation category per year. Criminal penalties apply for intentional violations.

5. Can agentic AI pentesting satisfy HIPAA penetration testing requirements?

Yes. Agentic AI penetration testing produces findings with documented evidence of exploitability, generates timestamped testing records, automatically retests findings after remediation, and can be run continuously to satisfy both the frequency requirement and the proposed post-change testing requirement. For HIPAA purposes, the key characteristics a penetration testing approach must demonstrate are that testing is conducted at appropriate frequency, scope reflects the risk analysis, findings are documented and acted on, and remediation is confirmed and documented. Agentic pentesting satisfies all of these operationally, and the continuous evidence record it produces is well-suited to OCR documentation requirements.