HIPAA Penetration Testing: 2026 Requirements and Scope

HIPAA penetration testing is a security test of the systems that create, receive, maintain or transmit electronic protected health information (ePHI). The HIPAA Security Rule in force today does not require it by name: it requires a risk analysis and periodic technical evaluation, and a penetration test is the most direct technical evidence for both. HHS proposed an explicit penetration test at least every 12 months and vulnerability scans every six months, but as of November 4, 2026 that rule is not final. This guide covers the requirement, the rule status, and how to scope the test.

Key Takeaways

• Is penetration testing required by HIPAA? Not by name under the rule in force today. The Security Rule requires an accurate risk analysis and a periodic technical evaluation, and a penetration test is the most direct technical evidence for both. HHS proposed a penetration test at least every 12 months and vulnerability scans at least every six months (proposed rule published January 6, 2025), but as of November 4, 2026 no final rule has been published, and HHS's 2026 regulatory agenda projects final action for July 2027.
• HIPAA penetration testing means performing structured security tests on systems handling PHI (web apps, APIs, devices, etc.) to find exploitable weaknesses.
• U.S. healthcare organizations need deep, contextual testing, because generic pentests can miss healthcare-specific workflows and data flows.
• Traditional vulnerability scans auto-discover issues; penetration tests manually exploit them to show real risk; HIPAA testing applies these to PHI flows.
• Test scope should cover patient portals, EHR/EHR-connected systems, mobile apps, APIs, identity/MFA flows, remote access paths, privileged admin interfaces, cloud components, third-party integrations, and more.
• Scope a HIPAA penetration test from your ePHI inventory and data flows, including systems that never store a patient record but control access to them, such as identity providers, remote access gateways and backup tooling.
• Clear scope, evidence, remediation guidance, and retesting are critical for meaningful assurance. Reports must tie findings to PHI impact and business risk.
• Penetration testing is risk-based and complements, but does not replace, HIPAA risk analysis and continuous monitoring. It provides one layer of technical validation and can strengthen security defensibility when paired with remediation and governance.
• Leadership should focus first on a thorough risk-based scope, high-value controls (identity, authentication, data flow), and ensuring findings drive remediation and accountability.

HIPAA penetration testing is a high-assurance validation activity that goes beyond checklists to actively probe healthcare systems for PHI exposure. It’s not enough to “run a pentest” as a one-off task; organizations must carefully scope the right systems, simulate realistic attack paths, document evidence, and drive defensible remediation. In practice, healthcare environments combine web applications, APIs (including FHIR/HL7), cloud services, identity and access controls, and third-party integrations in ways that can significantly affect PHI. Testing must cover patient portals, EHR-connected applications, mobile apps, authentication/MFA flows, remote access pathways, privileged admin interfaces, cloud misconfigurations, and more. Effective HIPAA pentesting focuses on how real attackers could exploit identity compromise, API abuse, or workflow flaws to access or exfiltrate PHI. Done properly, it helps validate whether key safeguards actually hold up under realistic attack conditions and whether PHI exposure paths have been meaningfully reduced.

Definition

HIPAA penetration testing refers to the structured security assessment of applications, APIs, identity pathways, privileged workflows, and supporting infrastructure used in healthcare environments that create, receive, maintain, or transmit protected health information, with the goal of identifying exploitable weaknesses, validating realistic attack paths, and supporting more defensible technical risk reduction.

What Is HIPAA Penetration Testing?

HIPAA penetration testing is the practice of simulating realistic cyberattacks on healthcare systems that handle PHI, in order to find and confirm security weaknesses. It differs from a generic pentest in its focus on PHI exposure and healthcare workflows. For example, a standard pentester might find a SQL injection vulnerability on a web server; a HIPAA-focused test would take it further by demonstrating how that flaw could expose patient records in an EHR or billing database. Vulnerability scanning (automated tools) can identify known issues, but penetration testing goes deeper. As NIST explains, security testing (including pentests and scans) is used to find vulnerabilities and verify compliance with security policies. HIPAA-oriented pentesting interprets findings through the lens of the Security Rule’s risk framework. In other words, rather than a simple checklist, HIPAA penetration testing is a risk-driven activity tailored to the healthcare environment. It might involve scenario-based attacks on patient portals, phishing attempts against hospital staff to test MFA, or exploiting EHR integration points to confirm how much PHI could be accessed. In a strong HIPAA pentest, testers validate exploitability of vulnerabilities rather than just listing them, and they explain the impact on ePHI. This approach aligns with risk management: finding out how an attacker could gain PHI and determining how that scenario maps to HIPAA controls.

Is Penetration Testing Required by HIPAA?

Short answer: no, the HIPAA Security Rule in force today does not name penetration testing or set a testing calendar. It does require every covered entity and business associate to perform an accurate and thorough risk analysis (45 CFR 164.308(a)(1)(ii)(A)) and a periodic technical and nontechnical evaluation of its safeguards (45 CFR 164.308(a)(8)). For systems that hold ePHI, a penetration test is usually the most direct way to produce technical evidence for both. HHS has proposed making a penetration test mandatory at least every 12 months, but that proposal is not final as of November 4, 2026.

HIPAA’s Security Rule does not say “you must perform an annual penetration test.” Instead, it sets risk management obligations. Covered entities and business associates must conduct an accurate and thorough risk analysis of all ePHI and implement safeguards that reduce those risks to a reasonable and appropriate level. They must also perform a periodic “technical and nontechnical evaluation” (45 CFR 164.308(a)(8)) that shows how well their security policies and procedures meet the rule, first against the standards and then again after environmental or operational changes. The rule does not prescribe a method for that evaluation, so penetration testing is a choice rather than a named mandate. In practice, a risk analysis that never checks whether access controls, authentication and transmission safeguards hold up under attack is hard to defend as accurate and thorough, which is why many security and compliance teams treat a penetration test as expected evidence rather than an optional extra. A pentest is still not a free ticket to compliance on its own.

Federal guidance points the same way. NIST SP 800-66 Rev. 2, the NIST resource guide for implementing the Security Rule, lists conducting penetration testing “if reasonable and appropriate” as a key activity under the evaluation standard, and it asks whether senior management has given specifically worded, written approval before any planned penetration test. On the regulatory side, HHS proposed updating the Security Rule to make penetration testing at least every 12 months and vulnerability scanning at least every six months explicit requirements. That proposal is not final; the status and dates are in the next section. In summary, HIPAA requires risk analysis and control evaluation; penetration testing is the practical way to give those obligations technical evidence, but the current rule does not prescribe it.

Is the HIPAA Security Rule Update Final? Status as of November 2026

No. As of November 4, 2026, HHS has not published a final rule. The Federal Register lists one document under the rulemaking's identifier, RIN 0945-AA22: the notice of proposed rulemaking published January 6, 2025 at 90 FR 898. The eCFR text of 45 CFR 164.308, current through October 30, 2026, still shows the existing Security Rule, including the periodic evaluation standard at 164.308(a)(8). Until a final rule is published and takes effect, the current Security Rule is the enforceable text.

That timeline explains why 2026 sources disagree. Many articles were written against the Spring 2025 agenda entry, which projected a final rule in May 2026, and some describe the proposed requirements as if they already apply. The 2026 agenda entry now lists the rule as a long-term action with final action projected for July 2027. An agenda date is a projection, not a deadline. The proposal can change before it is finalized, and it may not be finalized in its current form.

If HHS finalizes the rule as proposed, the final rule would take effect 60 days after publication, and regulated entities would generally have 180 days after the effective date to comply. The proposal also includes a longer transition for some existing business associate agreements.

What to do now: test on the current rule's terms, meaning risk analysis and periodic evaluation, while designing the program so it would already meet the proposed cadence. In practice that means at least one penetration test of ePHI systems every 12 months, vulnerability scans at least every six months, and retests after significant changes and remediation. Check the Federal Register and HHS before relying on any projected date.

What the Proposed Rule Says About Penetration Testing and Vulnerability Scanning

Everything in this section is proposed text from the January 6, 2025 notice of proposed rulemaking. It is not in effect and may change in a final rule. The testing provisions sit in a new vulnerability management standard at proposed 45 CFR 164.312(h).

• Penetration testing (proposed, 164.312(h)(2)(iii)): perform penetration testing of relevant electronic information systems by a qualified person, at least once every 12 months or in accordance with the risk analysis, whichever is more frequent.
• Qualified person (proposed): someone with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for protecting the confidentiality, integrity and availability of ePHI. HHS's explanation describes this as a combination of credentials, skills or experience in ethical hacking or offensive security. The proposed text does not say the tester must be an outside firm.
• Vulnerability scanning (proposed, 164.312(h)(2)(i)): conduct automated vulnerability scans at least once every six months, or more often if the risk analysis calls for it, and review and test the effectiveness of the scanning tool at least once every 12 months or after environmental or operational changes.
• Monitoring and patching (proposed, 164.312(h)(2)(ii) and (iv)): monitor authoritative sources for known vulnerabilities on an ongoing basis and remediate them under the organization's patch management program.
• Related proposals: a written technology asset inventory and a network map showing how ePHI enters, exits and moves, reviewed at least every 12 months and after changes (proposed 164.308(a)(1)); a compliance audit at least every 12 months (proposed 164.308(a)(14)); and written verification from each business associate, at least every 12 months, that it has deployed the required technical safeguards (proposed 164.308(b)).

Two details matter for planning. First, “whichever is more frequent” makes 12 months a floor, not a target: a risk analysis that identifies high-exposure systems can require testing more often. Second, the proposal defines a relevant electronic information system as one that creates, receives, maintains or transmits ePHI, or that otherwise affects its confidentiality, integrity or availability. That ties penetration testing scope to the whole ePHI environment, not to one application.

What HIPAA Penetration Testing Does Not Prove

A penetration test does not prove full HIPAA compliance on its own. It does not replace required risk analysis, workforce training, policy development, vendor oversight, incident response planning, or administrative and physical safeguards. It validates selected technical attack paths within the defined scope and test window. Findings should therefore be interpreted as one input into broader HIPAA-aligned security governance, not as stand-alone proof of compliance. Organizations that also pursue HITRUST should note the same limit applies to HITRUST certification penetration testing, which validates technical controls rather than replacing the wider assessment.

Why HIPAA Penetration Testing Matters

• Protecting PHI: A targeted penetration test shows how electronic protected health information could be exposed through realistic attack paths. It validates whether controls around storage, transmission, and access actually hold up under adversarial conditions. For organizations working with third-party billing providers, medical billing HIPAA compliance also involves safeguarding ePHI throughout billing workflows. Testing can help validate these safeguards within the agreed scope.
• Identity and Access Validation: Many healthcare breaches begin with compromised credentials or weak privilege boundaries. Testing helps determine whether authentication, session management, MFA, and role separation are sufficient to prevent unauthorized PHI access.
• Risk Prioritization: Penetration testing helps organizations distinguish between theoretical weaknesses and issues that can actually be exploited to reach sensitive systems or data. That makes remediation more defensible and easier to prioritize.
• Remediation Guidance: Strong testing provides actionable evidence, not just lists of findings. It helps engineering, security, and compliance teams understand what failed, why it mattered, and what should be fixed first.

Penetration testing is one component of a broader healthcare security program. It does not replace policy controls, logging, continuous monitoring, training, or formal HIPAA risk analysis, but it adds technical validation that those safeguards are working as intended.

Penetration Testing vs Vulnerability Scanning vs HIPAA Risk Analysis

Healthcare organizations often need all three. Vulnerability scans provide regular breadth, risk analysis ensures all PHI is accounted for in policy, and penetration testing provides depth by confirming what an attacker can actually do. Each serves a different role in a compliant security program.

How to Scope a HIPAA Penetration Test: ePHI Systems, EHR, APIs and Medical Devices

Scope a HIPAA penetration test from where ePHI lives and moves, not from a list of public IP addresses. The proposed rule's definition of a relevant electronic information system is a useful test even before it is final: include systems that create, receive, maintain or transmit ePHI, and systems that otherwise affect its security. The second group pulls in identity providers, remote access gateways, backup platforms and administrative tooling that never store a patient record but can expose all of them. The general rules for writing a scope are in our penetration testing scope checklist; the steps below apply them to HIPAA.

1. Start from the asset inventory and data-flow map behind your risk analysis. If none exists, build one first: the proposed rule would require a written inventory and a network map showing how ePHI enters, exits and is accessed from outside.
2. Classify each system as storing or processing ePHI, transmitting it, or affecting its security (identity, network, backup, logging, management planes).
3. Rank systems by exposure: internet-facing, number of patient records reachable, privilege level, and whether vendors or business associates can connect.
4. Match a test type to each system: external network, web application, API, cloud configuration, internal network and Active Directory, mobile, and social engineering where the risk analysis supports it. Define the user roles to test, such as patient, clinician, billing staff and administrator.
5. Write the rules of engagement: testing windows, clinical systems excluded or tested passively, emergency stop contacts, handling of any PHI seen during testing, and a business associate agreement where testers may access PHI.
6. Record what is out of scope and why, so the gap is carried into the risk analysis instead of disappearing.

Four system groups need specific attention. EHR platforms and patient portals need role-based tests that check whether one patient, or one clinic, can reach another's records. FHIR and HL7 interfaces need authorization checked on every request, using the OWASP API Security Top 10 as a baseline for object-level and property-level authorization checks. Identity and remote access paths need MFA coverage and vendor access reviewed.

Medical devices need the most care: manufacturers test devices before market under FDA's medical device cybersecurity expectations, while a hospital's test should focus on how devices are deployed, such as network exposure, segmentation and the servers that collect device data, under clinical engineering supervision. For EHR, FHIR API and device network testing in depth, see our healthcare penetration testing guide.

Typical Scope for HIPAA Penetration Testing

Penetration testing must address all interfaces where PHI resides or travels. The scope should reflect the organization’s environment: a hospital network with local EHR servers will differ from a SaaS telemedicine platform in the cloud, but in each case the above areas will be adapted to the specific architecture.

Scope Differences Across Covered Entities, Business Associates, and Hosted Platforms

Scope planning must account for shared responsibilities. For instance, a hospital IT team (Covered Entity) might focus on clinical networks and user access, while a cloud-based EHR vendor (Business Associate) focuses on multi-tenant data controls. Testing must ensure that when PHI passes between these domains, the interfaces are secure.

Healthcare Systems to Include and Clinical Safety Rules

Healthcare environments combine systems that ordinary penetration tests rarely meet: clinical applications, device networks, and integration engines that move PHI between organizations. A healthcare penetration test should name these systems in the scope and agree safety rules before testing starts.

• EHR and patient portals: authentication, role-based access between patients, clinicians, and billing staff, and whether one patient can reach another patient’s records.
• Integration interfaces (HL7 v2, FHIR APIs, integration engines): authorization on every API request, exposure of bulk data endpoints, and the trust placed in connected organizations.
• Medical devices and IoMT: network exposure and segmentation of device networks, tested in coordination with clinical engineering and the manufacturer. Devices in clinical use should not be actively exploited without explicit patient-safety approval; test lab units or passive configurations where possible.
• Telehealth and mobile apps: session handling, data stored on the device, and the backend APIs behind the app.
• Identity and remote access: Active Directory, VPN and remote-access gateways, MFA coverage, and third-party vendor access, which are common entry points for ransomware.
• Business associate connections: how billing, transcription, and cloud vendors connect to your network and which PHI they can reach.

Before the engagement, agree testing windows, clinical systems that are out of scope, emergency stop contacts, and how any PHI seen during testing is handled, with no export of real patient records. Put these terms in the rules of engagement, and sign a business associate agreement if the testers may access PHI.

For a deeper look at how to test EHRs, FHIR APIs and medical device networks safely, see our healthcare penetration testing guide.

Threat Scenarios That Matter in HIPAA-Relevant Environments

• Compromised Credentials → PHI Theft: Attackers commonly use phishing or credential stuffing to obtain valid login credentials (e.g. a doctor’s VPN password). Once inside, they can access patient records in EHR systems or portals. Because healthcare staff often have broad data access, stolen credentials can directly expose large volumes of PHI.
• Patient Portal Exploitation: Attackers may create bogus patient accounts or use application flaws (like an insecure direct object reference) to view other patients’ data. For example, manipulating a patient ID in a portal URL might expose another person’s lab results or health data. Such logic flaws could allow an attacker to traverse beyond their own patient record.
• API Data Exfiltration: Unsecured or poorly controlled APIs (for example, FHIR endpoints) can let attackers download entire datasets. An attacker who obtains a valid API token (through phishing or an OWASP API flaw) could repeatedly call an endpoint to extract patient identifiers, visit histories, or medical images.
• Privilege Escalation: A moderate vulnerability in an internal admin portal (like a hospital inventory system) could allow attackers to elevate privileges to domain or system admin. This could let them grant access to new accounts, disable security tools, or directly query databases containing PHI.
• Remote Access Hijack: Poorly secured VPN or remote desktop services give attackers an open door into the network. For example, exploiting an unpatched remote access appliance could let an attacker bypass network defenses and roam laterally to find systems with e-PHI.
• Third-Party Access Abuse: Attackers might exploit a third-party integration (like a lab results system or billing partner) that has a trust relationship with the main system. If that partner’s network or API is compromised, the attacker could pivot and access PHI stored on the primary healthcare system.

Each of these scenarios focuses on an attacker goal (typically unauthorized PHI access or exfiltration) and shows a likely path through healthcare-specific systems. Understanding them helps define realistic pentest activities and highlights why protecting PHI requires more than just standard IT security measures.

Core Security Domains a Strong HIPAA Pentest Should Cover

A robust HIPAA penetration test should systematically cover these domains because weakness in any one of them can materially affect PHI exposure. Coverage across these areas produces stronger technical assurance, but it should still be interpreted alongside broader risk analysis and governance activities.

How HIPAA Penetration Testing Supports Security Governance

Penetration testing feeds into risk management and security governance by providing concrete evidence of how technical controls perform under realistic attack conditions. Findings can help leadership prioritize remediation, validate assumptions in the risk analysis, and track whether critical weaknesses were actually fixed. The value of a penetration test in governance comes from evidence quality, scope discipline, and follow-through on remediation, not from treating the test itself as proof of compliance.

Common Failures in HIPAA Penetration Testing Programs

• Equating Scans with Testing: Automated scanning alone does not validate exploitability or real PHI exposure.
• Narrow Scope: Limiting the exercise to one public-facing application while excluding APIs, identity workflows, remote access, internal admin functions, or connected systems leaves major gaps.
• Ignoring Third-Party Integration: Healthcare environments often depend on vendors, business associates, and trusted external services that materially affect PHI risk.
• Overlooking Identity and Admin Workflows: Weak password resets, excessive privileges, orphaned accounts, and insecure support processes can undermine otherwise strong technical controls.
• Poor Evidence and Reporting: Findings without screenshots, logs, exploit context, or PHI impact are harder to trust and harder to remediate.
• No Retesting: A vulnerability is not meaningfully closed until remediation has been verified.

A high-quality HIPAA penetration testing program avoids these failures through disciplined scope design, manual validation, and clear reporting tied to patient-data risk.

What a High-Quality HIPAA Pentest Report Should Include

A strong penetration testing report turns technical findings into actionable insight aligned with HIPAA. Key elements include:

• Clear Scope and Rules of Engagement: The report should document exactly what was tested (systems, networks, IP ranges) and how (test windows, exclusion of sensitive operations, etc.). This transparency establishes the boundaries and limits of the findings.
• Detailed Asset Inventory and Workflows: Listing the assets (servers, applications, APIs) and their role in PHI processing helps readers understand where vulnerabilities were found. Workflows (for example, how a patient record is accessed end-to-end) clarify attack paths.
• Validated Findings with Evidence: Each high or medium finding should be supported by proof (screenshots, logs, packet captures). This shows the vulnerability was not just theoretical. For HIPAA, it’s ideal to tie each finding to a type of e-PHI affected.
• Exploit Context and Business Impact: Findings should include an explanation of how an attacker can exploit the issue (e.g. steps or chains used). The impact on PHI should be spelled out: how many records, what sensitivity of data, or what business function is at risk.
• PHI/Data Context: Good reports will note what kind of PHI could be accessed or leaked due to the vulnerability. This might involve mapping findings to HIPAA controls (for example, explaining that a flaw violates the “minimum necessary” or “access control” requirements).
• Remediation Guidance: For each issue, the report should offer clear, prioritized recommendations. This includes not just technical fixes (e.g. “apply security patch”) but also process changes (e.g. “enforce multi-factor login”). Prioritization should reflect HIPAA risk for example, fixing a critical ePHI exposure first.
• Risk Rationale: The report should explain why each finding matters. Rather than just stating CVSS scores, it should relate back to patient data protection and compliance risk (for example, explaining that a privilege escalation flaw could lead to a reportable breach of 10,000 records).
• Retest or Mitigation Verification Plan: If this is an interim report, it should include a plan for re-testing vulnerabilities post-fix. If it’s a final report, it can note which issues were retested and closed. Retest documentation closes the loop on remediation.
• Executive Summary vs. Technical Details: The report should separate an executive overview (high-level risks, business impact) from the technical findings. Leadership needs a succinct summary to make decisions, while engineers need the detailed reproduction steps.

NIST SP 800-66r2 also emphasizes documentation: “Document each evaluation finding, as well as remediation options, recommendations, and decisions”. In practice, a weak report undermines even real security testing. Without clear scope, evidence, and impact analysis, stakeholders cannot act confidently on the findings. A high-quality HIPAA pentest report becomes an input into the organization’s security governance and compliance evidence.

Questions to Ask Before Buying a HIPAA Pentest

• What exact systems, environments, integrations, and user roles are in scope?
• Will APIs, mobile applications, remote access paths, and identity workflows be tested?
• How will the report tie findings to PHI exposure and business impact?
• Are cloud IAM, secrets handling, and third-party trust boundaries included?
• Is retesting included after remediation?
• Will the provider separate executive reporting from technical evidence?

How Often Should HIPAA-Relevant Environments Test?

Testing frequency should be risk-based rather than fixed to a single universal schedule. Many organizations test critical healthcare environments at least annually, with additional testing after major application changes, cloud migrations, new integrations, or material shifts in PHI exposure. Vulnerability scanning, configuration review, and change-driven testing can occur more frequently, but penetration testing should be scheduled where it provides meaningful validation of real attack paths.

HIPAA itself does not currently prescribe a fixed penetration testing frequency. Organizations should therefore base testing frequency on exposure level, sensitivity of ePHI, pace of change, and the results of formal risk analysis. HHS's proposed Security Rule update would set a floor of one penetration test every 12 months and automated vulnerability scans every six months, with more frequent testing where the risk analysis calls for it. It is not final: the 2026 regulatory agenda lists it as a long-term action with final action projected for July 2027. A schedule that holds up under either outcome is to test ePHI systems at least annually, scan at least every six months, and retest after major changes and after remediation.

Best Practices for Strengthening HIPAA-Relevant Security Validation

• Risk-Based Scoping: Define scope based on where PHI resides, how it moves, and which systems create the greatest exposure if compromised.
• Identity-Aware Testing: Test across relevant user roles, authentication paths, privileged workflows, and access boundaries rather than treating all users as equivalent.
• API-First Focus: Give dedicated attention to APIs, token handling, authorization logic, and data exposure risks in FHIR or custom healthcare integrations.
• Cloud and Secrets Review: Evaluate IAM roles, storage controls, exposed secrets, and cloud security testing that could lead to unauthorized PHI access.
• continuous validation: Verify that critical findings have actually been fixed and that compensating controls work in practice.
• Change-Driven Reassessment: Re-test after major application changes, cloud migrations, new integrations, or material shifts in PHI exposure.

These practices keep penetration testing focused on real healthcare risk rather than broad but low-value technical coverage.

What HIPAA Penetration Testing Means for Procurement, Leadership, and Risk Committees

For senior stakeholders, HIPAA penetration testing is as much a governance issue as a technical one. UK healthcare vendors supporting U.S. PHI workflows should expect procurement teams to include explicit security testing requirements in RFPs and contracts. A qualified penetration test provider should have healthcare domain expertise (understanding EHR systems, PHI flows, regulatory needs) this ensures they scope tests correctly and interpret findings in a compliance context. Certifications like CISSP, OSCP, or healthcare-specific training can be indicators of credibility.

CISOs and compliance leaders can use penetration test results in board reports to demonstrate due diligence. A well-structured report (with executive summary highlighting PHI risk) provides clear metrics on security gaps and progress over time. This transparency can support more credible governance reporting to partners, customers, and oversight stakeholders by showing that security is being actively measured and managed.

From a risk committee perspective, test outcomes become part of enterprise risk assessments. Critical findings (e.g. a flaw that exposes large volumes of e-PHI) might trigger shifts in risk appetite or new investments (such as additional encryption or monitoring tools). Conversely, clean results can justify focusing resources elsewhere.

Procurement and legal teams will also use penetration test policies in business associate agreements and supplier evaluations. For example, they may require evidence that cloud services undergo regular pen tests. This turns technical quality (the thoroughness of testing) into a business criterion.

Ultimately, high-quality penetration testing affects vendor selection and security assurance. A vendor that restricts meaningful testing or produces weak, generic reporting should raise concern. By contrast, well-executed testing can strengthen security defensibility and demonstrate that technical safeguards were actively evaluated. In breach scenarios, a documented history of testing and remediation may support a more credible governance posture, but it should not be framed as guaranteed protection from regulatory scrutiny or enforcement.

FAQs

• What is HIPAA penetration testing?

HIPAA penetration testing is a security assessment tailored to healthcare. It involves simulating attacks on systems that create, receive, or transmit protected health information (PHI) such as patient portals, EHR platforms, mobile apps, and APIs. The goal is to find and exploit vulnerabilities in the context of healthcare workflows, thereby validating how exposed PHI could be. Unlike a general pentest, it specifically focuses on the risk to patient data and regulatory controls.

• Does HIPAA require penetration testing?

Not explicitly, under the rule in force today. The Security Rule requires a thorough risk analysis and a periodic technical and nontechnical evaluation of security controls, and a penetration test is the most common way to give those obligations technical evidence. It is not the only way to comply. HHS's proposed update, published January 6, 2025, would require a penetration test at least every 12 months and vulnerability scans at least every six months, but as of November 4, 2026 it has not been finalized.

• How does HIPAA penetration testing differ from vulnerability scanning?

Vulnerability scanning uses automated tools to quickly identify known software flaws, missing patches, and misconfigurations. It’s broad and fast but can only report potential issues. Penetration testing, on the other hand, is a manual, targeted process where testers actually exploit vulnerabilities to demonstrate impact. In other words, a scan might tell you about a weak TLS version; a pentest will show if that weakness can be chained to steal patient data. For HIPAA, pentesting adds value by confirming which vulnerabilities can truly lead to PHI exposure.

• What systems are usually in scope for a HIPAA penetration test?

Any system that processes or stores electronic PHI (e-PHI) is in-scope. Common targets include web application security testing and mobile apps, EHR and healthcare applications, APIs (e.g. FHIR/HL7 interfaces), user authentication and SSO systems, remote access services (VPN, RDP), privileged admin portals, cloud-hosted infrastructure (servers, databases, storage), and interfaces with third-party vendors (labs, billing partners). Email systems or collaboration tools may also be included if they carry PHI. The specific scope depends on the organization’s environment, but it must reflect the flow of PHI through all relevant digital systems.

• How often should a HIPAA environment be penetration tested?

Testing frequency should be risk-based. Many organizations test critical systems at least annually, with additional testing after major application changes, new integrations, cloud migrations, or material changes in PHI exposure. The right schedule should follow the organization’s risk analysis rather than a single fixed rule. HHS has proposed requiring penetration testing at least once every 12 months, but that rule is not final as of November 2026; HHS's 2026 regulatory agenda projects final action for July 2027.

• Does a penetration test help with HIPAA compliance?

A penetration test can support HIPAA compliance by validating technical safeguards, but it does not prove compliance on its own. It should be treated as one input into risk analysis, control evaluation, remediation, and broader security governance.

• What should a HIPAA penetration test report include?

A strong report will have clear scope and rules of engagement, a summary of tested assets, and for each finding it should include the evidence (e.g. exploit screenshots or logs) and a description of PHI risk. It should explain the business impact (for example, “this flaw could allow access to X patient records”). Remediation guidance should be provided for each issue, prioritized by risk. An executive summary (focusing on PHI exposure and overall risk level) should be separated from the technical details so that both leaders and engineers can act on it. Importantly, findings should be tied back to HIPAA concerns: for example, noting which security control was violated.

• How is a HIPAA risk assessment different from penetration testing?

A HIPAA risk assessment (risk analysis) is a mandatory process that identifies all threats and vulnerabilities to e-PHI across the organization. It is a broad review (including administrative, physical, and technical safeguards) and must be documented to comply with the Security Rule. Penetration testing is a narrower, technical activity that attempts to exploit vulnerabilities to confirm their impact. In short, risk analysis decides what needs protection and how big the risks are, while penetration testing actively tests whether the protections work in practice. They complement each other: pentest findings should feed into the overall risk assessment, but a risk analysis covers many additional factors (like policy gaps) that a pentest does not.

• What is the new HIPAA rule in 2026?

There is no new final HIPAA Security Rule in 2026. HHS published proposed changes on January 6, 2025, and the comment period closed on March 7, 2025. The proposal would require vulnerability scanning at least every six months, penetration testing at least every 12 months, an annual compliance audit, and a technology asset inventory and network map, and it would remove the distinction between required and addressable specifications. HHS's 2026 regulatory agenda lists it as a long-term action with final action projected for July 2027. The current Security Rule stays in force until a final rule is published and takes effect.

• Who can perform a HIPAA penetration test?

The current Security Rule does not say who must perform the test. The proposed rule would require a qualified person with appropriate knowledge of and experience with generally accepted cybersecurity principles; it does not require an outside firm. Many organizations still use an independent tester so that the people who built the controls are not the only ones checking them. Whoever tests should work under written rules of engagement and, where they may access PHI, a business associate agreement.

• Is a vulnerability scan enough for HIPAA?

A scan alone rarely shows whether ePHI can actually be reached. Scans find known weaknesses across many systems; a penetration test shows which of them, alone or chained, lead to patient data. The proposed rule treats them as separate requirements, scans at least every six months and a penetration test at least every 12 months, which reflects that they answer different questions.

HIPAA penetration testing should be treated as a high-assurance technical validation exercise for environments that create, receive, maintain, or transmit e-PHI. Its value lies in showing how identity compromise, application weaknesses, API abuse, cloud misconfigurations, and third-party trust relationships could lead to real data exposure. A mature healthcare organization uses penetration testing to validate risk assumptions, improve remediation priorities, and strengthen technical assurance over time. Still, penetration testing should be treated as one component of HIPAA-aligned security assurance rather than a stand-alone proof of compliance.

Next step: if you need a HIPAA penetration test that covers EHR, API, identity and cloud exposure, DeepStrike's penetration testing services are delivered manually and reported for compliance programs including HIPAA. Contact DeepStrike to scope a test against your ePHI inventory.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• Electronic Code of Federal Regulations, 45 CFR Part 164, Subpart C (HIPAA Security Rule)
• Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, 90 FR 898 (January 6, 2025)
• Reginfo.gov, RIN 0945-AA22, 2026 Unified Agenda entry
• Reginfo.gov, RIN 0945-AA22, Spring 2025 Unified Agenda entry
• HHS, HIPAA Security Rule NPRM fact sheet
• HHS, Guidance on Risk Analysis
• HHS OCR, Audit Protocol
• NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• FDA, Cybersecurity (medical devices)
• OWASP API Security Top 10 (2023)