HIPAA penetration testing requirements — what the Security Rule requires today and what HHS has proposed

Not by name. The words “penetration testing” and “vulnerability scanning” do not appear anywhere in the current Security Rule, Subpart C of 45 CFR Part 164, and §164.308 has not been amended since 2013. What the rule does require makes testing hard to avoid in practice:

• §164.308(a)(1)(ii)(A), risk analysis (Required): conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information (ePHI).
• §164.308(a)(1)(ii)(B), risk management (Required): implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.
• §164.308(a)(8), evaluation (a standard): perform a periodic technical and nontechnical evaluation, initially against the standards and afterwards in response to environmental or operational changes that affect the security of ePHI.
• §164.306(b): you choose the security measures, taking into account your size, complexity and capabilities, your technical infrastructure, the cost, and the probability and criticality of potential risks.
• §164.316(b): policies, procedures and any action, activity or assessment the rule requires to be documented are kept in writing for six years from creation or from the date last in effect, whichever is later.

So the honest answer has two halves. Nobody can point to a HIPAA clause that says “annual penetration test”. And a risk analysis that claims to be accurate about technical vulnerabilities, with no technical testing behind it, is exactly the kind of document OCR finds wanting.

NIST SP 800-66 Revision 2 (February 2024), NIST's cybersecurity resource guide for implementing the Security Rule, is where testing appears in writing.

• Risk analysis: when you build the list of vulnerabilities, internal sources may include previous risk assessments, vulnerability scan and system security test results (e.g., penetration tests) and audit reports; external sources include vendor information and vulnerability databases such as the NVD.
• Evaluation, §164.308(a)(8): the key activities include collecting the outputs of automated tools and the results of penetration testing, and to conduct penetration testing, if reasonable and appropriate. The sample questions ask whether specifically worded, written approval from senior management was received for any planned penetration test, and whether the organization has explored automated tools to support the evaluation.

SP 800-66r2 is a resource guide, not a rule. It shows what “reasonable and appropriate” testing looks like to the people who write the reference material, and it gives you a documented basis if you decide a penetration test is not appropriate for a given system.

The current enforcement pressure is on the risk analysis itself. HHS's Office for Civil Rights (OCR) runs a Risk Analysis Initiative, and its settlements keep citing the same failure:

• MMG Fusion (5 March 2026): announced as the 12th enforcement action in the initiative. OCR found, among other potential violations, a failure to conduct an accurate and thorough risk analysis; MMG paid $10,000 and accepted a corrective action plan that OCR will monitor for three years.
• Comstar (30 May 2025): described as OCR's 13th ransomware enforcement action and the 9th in the Risk Analysis Initiative. OCR found that Comstar had not conducted an accurate and thorough risk analysis; it paid $75,000 and accepted a two-year corrective action plan.

The corrective action plans show what OCR means by accurate and thorough. In the OSF Healthcare System plan, for example, the entity must develop a complete inventory of the equipment, systems and applications that create, receive, maintain or transmit ePHI, submit the scope and methodology of its risk analysis to HHS within 60 days, and then deliver the analysis for HHS review. A questionnaire-only risk analysis does not survive that process well; findings from scans and tests that show which vulnerabilities are real are what make it accurate.

On 6 January 2025 HHS published a proposed rule, “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information” (90 FR 898, RIN 0945-AA22). The testing provisions would sit in a new §164.312(h), vulnerability management:

1. Vulnerability scanning: automated vulnerability scans of the relevant electronic information systems in accordance with the risk analysis or at least once every six months, whichever is more frequent, plus a review and test of the scanning tool itself at least once every 12 months or after environmental or operational changes.
2. Monitoring: monitor authoritative sources for known vulnerabilities on an ongoing basis and remediate them through the patch management program.
3. Penetration testing: performed by a qualified person, meaning a person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity and availability of ePHI, at least once every 12 months or in accordance with the risk analysis, whichever is more frequent.
4. Patch and update installation through technical controls.

Around it, the proposal would add a written technology asset inventory and network map reviewed at least every 12 months, a written risk analysis with defined contents, patching of critical risks within 15 calendar days and high risks within 30, a compliance audit at least once every 12 months, and it would remove the distinction between “addressable” and “required” implementation specifications. A final rule would take effect 60 days after publication, with compliance 180 days after that.

It is still a proposal, and nobody should tell a board otherwise.

• Published: 6 January 2025; the comment period closed on 7 March 2025.
• Spring 2025 Unified Agenda: final rule stage, final action listed for May 2026.
• Latest Unified Agenda entry: the rulemaking is listed under long-term actions, with final action listed for July 2027.
• Federal Register: no final rule has been published under RIN 0945-AA22, and §164.308 on eCFR still reads as it has since 2013.

Agenda dates are projections, not commitments, and the final text may differ from the proposal or not arrive at all. The practical reading: the proposal tells you what HHS thinks a reasonable testing cadence is, and it is a useful benchmark for your own risk analysis. It is not yet an obligation, and a program described to auditors as “HIPAA-required semiannual scanning” overstates the law.

The Health Industry Cybersecurity Practices (HICP), 2023 edition, published under Section 405(d) of the Cybersecurity Act of 2015, sets out ten practices against five threats. It is voluntary. Technical Volume 2, for medium and large organizations, covers vulnerability management in Practice #7:

• Sub-practices for medium-sized organizations: host and server-based scanning (authenticated and unauthenticated), web application scanning, system placement and data classification, patch and configuration management, change management.
• Sub-practices for large organizations: 7.L.A penetration testing, 7.L.B vulnerability remediation planning and 7.L.C attack simulation.

On penetration testing, HICP says a proper test should mimic the methods adversaries use, not just try to exploit scanner findings; that it can be run by qualified internal staff or by external partners; and that the authority to test must be documented, including the assets in scope, the methods allowed and the timing. It describes white-box, grey-box and black-box options and targets that include medical technologies. The main volume advises large organizations to review both medium and large sub-practices and encourages medium-sized ones to implement the large sub-practices as applicable.

Why it pays: Public Law 116-321 added section 13412 to the HITECH Act. When HHS decides on fines, audits or the remedies in a settlement, it must consider whether the entity had recognized security practices in place for not less than the previous 12 months, and the 405(d) approaches are named as recognized security practices. The law does not let HHS raise a fine because you did not adopt them. Twelve months of documented testing is therefore evidence that can lower the cost of an investigation, not only a best practice.

Written in the current rule:

• An accurate and thorough assessment of risks and vulnerabilities to ePHI, and security measures that reduce them to a reasonable and appropriate level.
• A periodic technical and nontechnical evaluation, repeated after environmental or operational changes.
• Written documentation of the analysis, the evaluation and the measures, kept for six years and reviewed periodically.

Proposed, not in force:

• Automated vulnerability scans at least every six months, penetration tests by a qualified person at least every 12 months, an annual compliance audit, 15-day and 30-day patch deadlines, an asset inventory and network map.

Guidance, not law:

• NIST SP 800-66r2 on using scan and penetration test results in the risk analysis and evaluation.
• HICP Practice #7, including penetration testing and attack simulation, which counts as a recognized security practice under Public Law 116-321.

Not written anywhere:

• A HIPAA certification, a required test vendor, or a rule that the tester must be external. The proposal asks for a qualified person; HICP allows internal staff.

You can build one program that answers the current rule and would already meet the proposed floors:

1. Start from an inventory of systems that touch ePHI, including medical devices and the paths into the EHR. Every corrective action plan starts there, and so does the proposal.
2. Scan on a schedule your risk analysis justifies, at least every six months if you want to be ready for the proposal, authenticated where systems allow it, and after significant changes.
3. Penetration test at least annually from outside the network and from inside with the access of a standard clinical user, with written senior management approval and documented rules of engagement. See black-box vs gray-box testing.
4. Treat clinical systems deliberately: agree scope and allowed techniques with clinical engineering, test fragile devices in observe-only mode or in a lab, and record why any system is excluded.
5. Feed results into the risk analysis and the risk management plan, with an owner and date per finding, and re-test after each fix.
6. Keep the file for six years: inventory, risk analysis, scan schedules and results, penetration test reports with the tester's qualifications, remediation and re-test records, exceptions and their justification, evaluation reports.

This is also the record that shows recognized security practices in place for the previous 12 months if OCR ever opens an investigation.

An autonomous AI red team for networks and infrastructure does not perform your risk analysis, is not the qualified person the proposal describes, and does not decide whether you comply. What it changes is how much technical evidence exists between one annual test and the next.

• Black box and gray box, on a schedule. Campaigns from outside the network and with a standard clinical user account run once, daily, weekly, monthly or on a custom schedule, so scans and tests can follow the six-month and 12-month floors the proposal sets, or tighter, and run again after changes.
• Findings that say what was exploited. Each finding records whether the vulnerability was actually exploited in your environment, which is what turns a risk register into an accurate one. Each fix can be re-tested with the same proof.
• HIPAA mapping, current and proposed kept apart. The engine maps findings to the risk analysis (164.308(a)(1)(ii)(A)) and evaluation (164.308(a)(8)) safeguards among the 34 frameworks it supports, and tracks the proposed vulnerability scanning and penetration testing requirement as a separate control marked as proposed.
• Clinical systems under human control. Five autonomy levels decide what waits for a person, from approval of any active scan at the lowest level up; EHR, PACS and lab systems can stay out of scope or at observe-only until you approve more. See human in the loop.
• Records that hold up for six years. Every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain, and exported reports are ECDSA-signed.
• PHI stays in the hospital network. Models run on the appliance with no external AI API, so ePHI a test touches and the map of what is exploitable do not go to another vendor platform. See the US healthcare page and on-premise AI red team.

• 45 CFR Part 164, Subpart C, Security Standards (eCFR)
• Proposed rule: HIPAA Security Rule To Strengthen the Cybersecurity of ePHI, 90 FR 898, 6 January 2025 (Federal Register)
• RIN 0945-AA22, latest Unified Agenda entry (reginfo.gov)
• RIN 0945-AA22, Spring 2025 Unified Agenda entry (reginfo.gov)
• NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule (NIST CSRC)
• HICP 2023, main volume (HHS 405(d), PDF)
• HICP Technical Volume 2, Practice #7 Vulnerability Management (HHS 405(d), PDF)
• Public Law 116-321, recognition of security practices (GovInfo)
• HIPAA resolution agreements and civil money penalties (HHS OCR)
• OCR settles HIPAA investigation of MMG Fusion, 5 March 2026 (HHS)
• OCR settles HIPAA ransomware investigation with Comstar, 30 May 2025 (HHS)