HHS Wants Annual Pentests in the HIPAA Security Rule. Here's What That Looks Like.

The HIPAA Security Rule Is Getting Specific About Pentesting

The Department of Health and Human Services (HHS) published a Notice of Proposed Rulemaking (NPRM) for the HIPAA Security Rule in January 2025 that would significantly expand technical testing requirements for covered entities and business associates. The most notable addition: explicit penetration testing requirements.

The current HIPAA Security Rule (45 CFR 164.308(a)(8)) requires periodic "technical and nontechnical evaluation" of security controls. The word "penetration testing" does not appear in the current rule. The proposed revision would add specific requirements for vulnerability scanning and penetration testing as distinct, required activities.

What the Proposed Rule Requires

Vulnerability Scanning

The NPRM proposes that covered entities and business associates must conduct vulnerability scanning at least every six months for all systems that create, receive, maintain, or transmit ePHI. This includes:

• Application-level scanning (SAST/DAST) for custom-developed software
• Infrastructure scanning for network and system vulnerabilities
• Dependency scanning for third-party components

The proposed rule explicitly calls out "automated tools" as a required method, moving beyond the current ambiguous "evaluation" language.

Penetration Testing

The NPRM proposes annual penetration testing as a required (not addressable) implementation specification. The penetration test must:

• Cover all systems and networks that process ePHI
• Include application-layer testing, not just network-layer
• Be conducted by qualified personnel (internal or external)
• Produce a written report with findings, risk ratings, and remediation timelines
• Be followed by documented remediation of identified vulnerabilities

Continuous Monitoring

The proposed rule adds a continuous monitoring requirement for ePHI systems, defined as "ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions." This goes beyond periodic scanning to require real-time or near-real-time security monitoring.

Why This Matters for Development Teams

Healthcare applications that process ePHI are in scope for all three requirements. The proposed rule does not distinguish between infrastructure and application-layer testing. Both are required. This means:

1. Custom-built healthcare applications need both SAST and DAST coverage
2. FHIR API implementations are application-layer targets for the pentest requirement
3. Patient portals are internet-facing ePHI systems, the highest priority for testing
4. Internal clinical tools that access ePHI are also in scope

The Application Pentest Gap

Most healthcare penetration tests focus on network infrastructure: perimeter scanning, firewall rules, VPN configurations. The proposed rule's explicit inclusion of application-layer testing closes a gap that has been obvious to security practitioners for years.

Healthcare application vulnerabilities (SQL injection in patient search, broken authentication in API gateways, IDOR in patient record endpoints) are the attack vectors behind the largest healthcare breaches. The Change Healthcare breach (2024, 100M+ records) and Ascension Health breach (2024, 140 hospitals disrupted) both involved application-layer compromise, not network perimeter failure.

The Cost Pressure

Healthcare organizations already face significant compliance costs. The proposed pentesting requirement adds operational expense. Qualified pentesters are expensive, and annual testing of all ePHI systems at the application layer is a meaningful scope expansion.

This creates economic pressure for continuous security testing that reduces pentest scope. If an organization can demonstrate continuous vulnerability scanning with documented remediation throughout the year, the annual pentest validates the process rather than discovering months of accumulated vulnerabilities.

Preparing Now

The NPRM is in the comment and finalization period. Regardless of the exact final rule language, the direction is clear: HHS is moving toward explicit, prescriptive security testing requirements. Organizations that implement continuous scanning and application-layer security testing now will be positioned for compliance when the final rule takes effect.

How Deva Addresses Healthcare Pentest Requirements

Deva's HIPAA preset covers all 25 code-relevant HIPAA Security Rule controls, including the evaluation requirement (164.308(a)(8)) that the proposed rule is expanding. Continuous scan-on-save provides the ongoing monitoring evidence the proposed rule describes.

The Pentest Engine's attack surface analysis gives healthcare development teams an offensive security perspective during development. Identifying the application-layer vulnerabilities that would appear in a penetration test, before the pentester arrives.

For organizations subject to the proposed scanning cadence (every six months), Deva's SARIF export produces timestamped, signed evidence packages showing scan coverage, findings, and remediation status. The documentation the proposed rule requires.

The local model matters here more than anywhere: ePHI code patterns, patient data in test fixtures, and clinical workflow logic stay on the developer's machine. No healthcare-specific context traverses an external API.