HIPAA penetration testing: what the Security Rule actually requires

Not by name. The HIPAA Security Rule, set out in 45 CFR Part 164, Subpart C, does not use the words penetration testing or vulnerability scanning in its current text. What it does require of every covered entity and business associate includes an accurate and thorough risk analysis and a periodic technical and nontechnical evaluation. A penetration test is the usual way to evidence the technical part of both.

That may change. In January 2025 the Department of Health and Human Services (HHS) proposed amendments that would require penetration testing at least every 12 months and vulnerability scanning at least every six months. As of October 2026 the proposal has not been finalised, and the current federal regulatory agenda lists it among long-term actions.

The Rule is written to be technology neutral. Section 164.306(b) lets an organisation use any security measures that reasonably and appropriately implement the standards, taking into account its size, complexity and capabilities, its technical infrastructure, costs, and the probability and criticality of risks to electronic protected health information (ePHI). HHS guidance on risk analysis confirms the Rule prescribes no particular risk analysis method.

The risk analysis at 45 CFR 164.308(a)(1)(ii)(A) is a required implementation specification: "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information" the organisation holds. HHS guidance says it must be documented. The evaluation at 164.308(a)(8) is a "periodic technical and nontechnical evaluation", first against the standards as implemented and then in response to environmental or operational changes affecting the security of ePHI.

The Office for Civil Rights (OCR), which enforces the Rule for HHS, has said what accurate and thorough means for technical weaknesses. Its first-quarter 2022 cybersecurity newsletter says a risk analysis should include processes that identify technical and non-technical vulnerabilities, lists periodic penetration tests and vulnerability scanning among the ways to find the technical ones, and advises against relying on any single technique. NIST's resource guide to the Security Rule, SP 800-66 Revision 2 from February 2024, includes conducting penetration testing, if reasonable and appropriate, among the steps for carrying out the evaluation at 164.308(a)(8).

Both are guidance, not requirements, and an organisation that can justify another method may use it. In practice the test is easier to defend. A risk analysis that rates an internet-facing patient portal as low risk with nothing behind the rating is an assertion; one that cites a dated test and its verified fixes is evidence. And OCR's scrutiny lands on the risk analysis. It runs a Risk Analysis Initiative, and an April 2026 HHS announcement of four ransomware settlements reported the same failure in all four investigations: no accurate and thorough risk analysis.

The kind of test matters too. A scanner sees two well-formed requests for two patient records and cannot know that one should have been refused, so access control and authentication need a human tester. The comparison of manual testing and scanning sets out why.

On 6 January 2025 HHS published a notice of proposed rulemaking at 90 FR 898, under RIN 0945-AA22, and comments closed on 7 March 2025. It would add a vulnerability management standard to the technical safeguards at a new 164.312(h), requiring vulnerability scans at least every six months and penetration testing at least every 12 months, or more often if the risk analysis calls for it. The testing would have to be performed by a qualified person, meaning someone with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for protecting ePHI.

Status as of October 2026

Not final. The proposal is still the only Federal Register document under its RIN. In the Spring 2025 Unified Agenda, the government's published plan of forthcoming regulations, HHS put it at the final rule stage with final action projected for May 2026. The current 2026 edition of the Unified Agenda lists it under long-term actions, meaning HHS does not expect a regulatory action within 12 months of that edition's publication, and projects final action for July 2027.

Those dates are projections. A final rule could differ from the proposal or never be issued, and any final rule would set its own effective and compliance dates. Build to the current text and treat the proposal as a benchmark: for an organisation already testing every year, the proposed penetration testing interval changes little, and six-monthly scanning is the larger step.

Section 164.302 applies the Security Rule to covered entities and business associates alike. Under 45 CFR 160.103, covered entities are health plans, health care clearinghouses, and health care providers that transmit health information electronically in connection with a covered transaction. A business associate creates, receives, maintains or transmits protected health information on a covered entity's behalf, or provides it with certain services involving that information, and the definition extends to subcontractors.

A business associate's obligation does not depend on its contract. The HHS fact sheet on direct liability states that under the HITECH Act and a 2013 final rule, business associates are directly liable for failing to comply with the Security Rule. A telehealth platform or a billing service owns its risk analysis as fully as a hospital does.

Two consequences follow. Each party evidences the systems it operates, so a covered entity's testing does not cover its vendors and a vendor's testing does not cover its customers. And a customer asking a vendor for a recent penetration test is acting on the contract or its vendor review: 164.314(a) requires the business associate agreement to bind the vendor to Subpart C but specifies no test, so read what the customer actually asked for.

Scope follows the ePHI. The risk analysis covers all the ePHI an organisation creates, receives, maintains or transmits, so a test offered as evidence for it has to cover the systems where that data lives and moves. A test of the marketing website evidences nothing for HIPAA.

• Patient portals and clinical web applications, tested with accounts for every role: patients, caregivers or proxies, clinicians, billing staff and administrators. The finding that matters most is one patient reaching another patient's record, and only a test with at least two patient accounts can look for it. That is web application testing built around the authorisation model.
• APIs and integrations: the API behind the portal and the mobile app, interfaces to the electronic health record system, payer and partner integrations, and webhooks. Nobody uses them through a screen, so an authorisation gap there is easy to miss. API testing covers the side of each integration you operate.
• Mobile apps, including what they store on the device and the backend API behind them, which mobile app testing covers together.
• Remote access: VPN gateways, remote desktop services, vendor support access and the identity provider behind them, tested from outside as part of network testing.
• The internal network where ePHI is stored and processed. Only internal testing shows what someone already inside can reach.
• Administrative and support tools with access to patient data, which are easy to leave out because they are internal.
• The cloud configuration underneath, which is a configuration review against the CIS Benchmarks rather than a penetration test.

What to exclude, and what to agree first

Systems you do not own, such as a hosted electronic health record or a partner's API, need their owner's permission before anyone tests them. Exclude what you cannot authorise and write down why. Networked medical devices need care because testing can disrupt systems used in patient care, so decide explicitly whether they are in scope and under what constraints.

Testers may see real patient data, so prefer a faithful non-production environment with synthetic data. Where production is in scope, the rules of engagement should say how any ePHI encountered is handled and destroyed, and your privacy or security official should decide whether the agreement with the testing firm needs to cover it, including whether a business associate agreement is required. The scoping guide covers rules of engagement and test accounts.

The current Rule sets no testing interval. The evaluation at 164.308(a)(8) is periodic and must be repeated after environmental or operational changes affecting the security of ePHI, and the HHS risk analysis guidance says the Rule does not specify how often to perform a risk analysis.

Annual testing plus testing after significant change is the common practice. It is not a written requirement today, though it would meet the proposed 12-month floor. In healthcare, typical significant-change triggers include:

1. 1A patient-facing release that changes who can see what.
2. 2A new integration, API partner or data feed carrying records.
3. 3A move to a new electronic health record system, hosting provider or identity provider.
4. 4A new remote access route, including access granted to a vendor.
5. 5An acquisition that connects another organisation's network to yours.

Between tests, scanning at least every six months is a reasonable benchmark, and the proposal would apply it to all relevant systems, internal ones included. Monitoring between engagements on our platform watches your attack surface with a lightweight check every 24 hours and a full scan weekly or monthly, kept separate from tester findings. It supplements manual testing and does not replace it.

Whoever reviews the programme, from OCR in an investigation to a customer assessing you as a vendor, wants to see that an evaluation happened, that it covered the systems holding ePHI, and that the organisation acted on what it found.

• The report, with the testing dates stated separately from the report date.
• A scope statement that maps onto the systems in your risk analysis.
• Who tested, and how they are independent of the people who build and run the systems.
• The methodology followed.
• Each finding with its severity, evidence and outcome: fixed and verified by a retest, or accepted with a named owner, a rationale and a review date.
• The link back to the risk analysis, showing which risk ratings changed because of what the test found.

The last item is what turns a test report into HIPAA evidence. A report filed apart from the risk analysis shows that somebody looked. A risk analysis that cites the test shows the Rule's process working. Keep the report and the retest record with the risk analysis documentation, which 164.316(b)(2)(i) requires you to retain for six years from its creation or from when it was last in effect, whichever is later.

On our engagements the same test can be exported as a HIPAA Security Rule report for your compliance officer, in Word, PDF or Excel, with findings mapped to the Security Rule safeguards for the evaluation requirement under 164.308. The mapping is to requirement areas, not individual implementation specifications. Every area is listed even where nothing was found, a finding the mapping cannot place is listed as unmapped instead of dropped, and the document states that a test is supporting evidence, not a certification. HHS makes the same point in its FAQ on certification.

1. 1Citing the proposed rule as if it were in force, in a policy, a report or an answer to a customer questionnaire.
2. 2A test that never reaches the risk analysis, so the risk ratings still describe the system as it was imagined before anyone tested it.
3. 3A scope chosen for convenience, such as the public website or an unauthenticated pass over the portal. The ePHI inventory decides the scope, and access control under 164.312(a)(1) is about what a logged-in user can reach.
4. 4Findings closed on an engineer's say-so with no retest, leaving the risk management evidence a claim, not a verdict.
5. 5A vulnerability scan offered as the evaluation. Scans have a place, and the proposal would require them separately, but they cannot test authorisation or business logic.
6. 6Retest records and risk acceptances discarded before the six years are up. They are harder to reconstruct than the report.

If you also need a SOC 2 report, the underlying testing is largely the same work: the SOC 2 guide covers that examination, and the audit evidence checklist sets out the evidence pack across frameworks. A scoping call is where we agree a scope against your own risk analysis.