Quick answer: HIPAA does not require penetration testing today. The Security Rule at 45 CFR Part 164 Subpart C never uses the phrase. It requires a risk analysis (45 CFR 164.308(a)(1)(ii)(A), marked Required), a periodic technical and nontechnical evaluation (45 CFR 164.308(a)(8)), and maintenance of security measures (45 CFR 164.306(e)). The federal implementation guide, NIST SP 800-66r2 (February 2024), places penetration testing inside both of those standards, to be conducted "if reasonable and appropriate." A proposed rule published at 90 FR 898 on 6 January 2025 would add an express requirement at proposed 45 CFR 164.312(h)(2)(iii) for penetration testing at least once every 12 months by a qualified person, plus automated vulnerability scanning at least once every six months. That proposal is not final. As of 5 September 2026 the Federal Register lists one document under RIN 0945-AA22, the proposal itself, and the 2026 Unified Agenda shows the rulemaking as a long-term action with a final action target of July 2027.
Every regulatory statement on this page was read from the regulation, the Federal Register document, the federal implementation guide or the government regulatory agenda on 5 September 2026, and links back to that source. Where a claim could not be traced to a primary source, it was dropped rather than softened.
Does HIPAA require penetration testing?
No, not by name, and anyone who tells you otherwise is describing the proposed rule rather than the one in force.
The confusion is understandable, because the Security Rule is written in outcomes rather than techniques. It sets four general requirements at 45 CFR 164.306(a): ensure the confidentiality, integrity and availability of all ePHI a regulated entity creates, receives, maintains or transmits; protect against reasonably anticipated threats; protect against reasonably anticipated impermissible uses and disclosures; and ensure workforce compliance. Then it grants flexibility of approach at 164.306(b): entities may use any security measures that reasonably and appropriately implement the standards, taking account of their size, complexity and capabilities, their technical infrastructure, the costs of the measures, and the probability and criticality of potential risks.
That structure is why the Rule names no tool, no scanner, no test type and no vendor. It is also why penetration testing sits at the centre of three separate standards without ever being written into any of them.
The three clauses that pull testing into scope
Risk analysis, 45 CFR 164.308(a)(1)(ii)(A), marked (Required). The text is short: "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate." The word doing the work is thorough. NIST SP 800-66r2 spells out what a thorough vulnerability identification step looks like, and it names the evidence sources directly: internal sources "may include previous risk assessments, vulnerability scan and system security test results (e.g., penetration tests), and audit reports."
Evaluation, 45 CFR 164.308(a)(8). "Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart." SP 800-66r2 reproduces that standard at section 5.1.8 and lists, among the key activities for conducting the evaluation, "Conduct penetration testing (where testers attempt to compromise system security for the sole purpose of testing the effectiveness of security controls), if reasonable and appropriate." It also lists collection methods that include "the results of penetration testing," and asks whether "specifically worded, written approval from senior management" has been received for any planned penetration testing.
Maintenance, 45 CFR 164.306(e). "A covered entity or business associate must review and modify the security measures implemented under this subpart as needed to continue provision of reasonable and appropriate protection of electronic protected health information, and update documentation of such security measures." This is the clause that turns a one-off exercise into a cadence. It sets no interval, which is precisely the gap the 2025 proposal tries to close.
Required versus addressable, and why it matters here
45 CFR 164.306(d) draws the distinction that generates most HIPAA security arguments. Where an implementation specification is labelled Required, an entity must implement it. Where it is labelled Addressable, the entity must assess whether it is reasonable and appropriate, implement it if so, and if not, document why and implement an equivalent alternative if reasonable and appropriate.
Risk analysis and risk management are both Required. The evaluation standard at 164.308(a)(8) is a standard in its own right with no implementation specifications attached, which means it is not optional either. Encryption of ePHI at rest and in transit, by contrast, sits at 164.312(a)(2)(iv) and 164.312(e)(2)(ii) and is Addressable today.
OCR has said in the rulemaking record that it believes this distinction is being misread. In the proposed rule the Department wrote that it is "concerned that some regulated entities proceed as if compliance with an addressable implementation specification is optional, and that where there is an addressable implementation specification, that compliance with the relevant standard is also optional. That interpretation is incorrect and weakens the cybersecurity posture of regulated entities."
The HIPAA clause to test type to evidence table
This is the table to take into a risk analysis review or an OCR document request. Left column is the clause, middle column is the offensive testing activity that produces evidence against it, right column is what to retain.
HIPAA clause | What the clause requires | Testing activity that produces evidence | Evidence to retain |
|---|---|---|---|
164.308(a)(1)(ii)(A) Risk analysis (Required) | Accurate and thorough assessment of potential risks and vulnerabilities to ePHI | External and internal network testing, web application and API testing, cloud configuration review | Full test report with scope statement, methodology, findings, severity ratings and dates, plus the written risk analysis showing how each finding was rated |
164.308(a)(1)(ii)(B) Risk management (Required) | Security measures sufficient to reduce risks to a reasonable and appropriate level | Retest of remediated findings | Remediation tickets with owners and dates, retest report showing each finding closed or accepted with justification |
164.308(a)(8) Evaluation | Periodic technical and nontechnical evaluation against the Rule's standards, and in response to environmental or operational change | Penetration test scoped to the ePHI environment, repeated after material change | Evaluation report, the written senior management approval NIST SP 800-66r2 asks about, and the trigger record for change-driven tests |
164.306(e) Maintenance | Review and modify security measures as needed, and update documentation | Recurring test cadence tied to the change log | Change log entries linked to test and retest dates |
164.312(a)(1) Access control and 164.312(d) Person or entity authentication | Access limited to authorised persons and software; verify identity of anyone seeking ePHI | Authorisation and authentication testing on portals and APIs: broken object level authorisation, horizontal and vertical privilege escalation, session handling, tenancy separation | Application test report with authorisation test cases enumerated per role, including the negative cases that passed |
164.312(b) Audit controls | Mechanisms that record and examine activity in systems containing ePHI | Detection check during the engagement: compare test timeline against what the logging and alerting stack actually captured | Test start and end timestamps alongside the alerts raised, or the gap where none were |
164.312(e)(1) Transmission security | Technical measures guarding ePHI in transit | Transport security testing on every ePHI-bearing interface, including machine to machine integrations | Configuration findings per endpoint, with the certificate and protocol evidence |
164.308(b)(1) and 164.314(a)(2)(i) Business associate contracts | Satisfactory assurances that a business associate will appropriately safeguard ePHI, documented in a written contract | The business associate's own testing, and its subcontractors' | Contract clauses that name a testing cadence and a right to review results, plus the summary letters actually received |
164.316(b)(2)(i) Documentation time limit (Required) | Retain required documentation for six years from creation or last effective date, whichever is later | Nothing to test, everything to keep | A six-year archive of test reports, retest reports, risk analyses and approvals, not a folder that gets cleaned out at renewal |
Two notes on using the table. First, the clause column is what an investigator asks about; the testing column is not a substitute for the clause, it is the evidence that the clause was satisfied. Second, the right-hand column is where most healthcare organisations fall down. A test that produced a good report two years ago and no retest record is weaker evidence than a smaller test with a documented fix cycle.
What the 2025 proposed rule would add, and its status right now
On 27 December 2024, OCR issued a notice of proposed rulemaking to modify the Security Rule. It was published in the Federal Register on 6 January 2025 at 90 FR 898, under RIN 0945-AA22, and the comment period closed on 7 March 2025.
The proposal is a structural rewrite rather than a patch. The changes most relevant to a testing programme:
Penetration testing becomes an express implementation specification. Proposed 45 CFR 164.312(h)(2)(iii) reads: "Penetration testing. Perform penetration testing of the covered entity's or business associate's relevant electronic information systems by a qualified person." A qualified person is defined in the proposal as "a person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of electronic protected health information." And the cadence: "Penetration testing must be performed at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis required by Sec. 164.308(a)(2), whichever is more frequent."
Automated vulnerability scanning gets its own clause and a six-month floor. Proposed 164.312(h)(2)(i)(A) would require automated vulnerability scans "in accordance with the covered entity's or business associate's risk analysis required by Sec. 164.308(a)(2) or at least once every six months, whichever is more frequent," with the effectiveness of the scanning technology itself reviewed and tested at least once every 12 months.
Patch timelines get numbers. The proposal would require patching, updating or reconfiguring a relevant electronic information system within 15 calendar days of identifying the need to address a critical risk, based on the risk analysis, the vulnerability scans, the monitoring of authoritative sources and the penetration tests.
A compliance audit every 12 months. Proposed 164.308(a)(14) would require regulated entities "to perform and document an audit of their compliance with each standard and implementation specification of the Security Rule at least once every 12 months." The Department noted in the same passage that "the Security Rule does not currently require regulated entities to conduct internal or third-party compliance audits."
An asset inventory and a network map. Proposed 164.308(a)(1)(i) would require a written technology asset inventory and a network map of the electronic information systems and all technology assets that may affect the confidentiality, integrity or availability of ePHI, maintained on an ongoing basis and reviewed at least once every 12 months and on relevant change. In the Department's own words, "the inventory forms the foundation for a fulsome and accurate risk analysis."
The addressable category disappears. The proposal would "remove the distinction between required and addressable implementation specifications and make all implementation specifications required, with specific, limited exceptions." Encryption at rest and in transit, and multi-factor authentication, move into the required column with limited exceptions.
Business associates would have to verify and certify. The proposal would require business associates to verify at least once every 12 months, in a written analysis by a subject matter expert plus a written certification, that they have deployed the technical safeguards the Rule requires.
Status as of 5 September 2026: proposed, not final
This is the sentence most articles on this topic get wrong, so here is the verification trail rather than an assertion.
The Federal Register API returns exactly one document associated with RIN 0945-AA22: the proposed rule of 6 January 2025. No final rule, no interim final rule, no withdrawal, no supplemental proposal.
The government's own regulatory agenda agrees. The entry for RIN 0945-AA22 in the 2026 Unified Agenda lists the agenda stage of rulemaking as Long-Term Actions, and the timetable carries two rows: NPRM, 01/06/2025, 90 FR 898; and Final Action, 07/00/2027. The priority is listed as economically significant and the rule is flagged as major.
HHS says the same thing in plainer language on its own fact sheet for the proposal: "While the Department is undertaking this rulemaking, the current Security Rule remains in effect."
So the honest position for a compliance programme in September 2026 is this. You are not out of compliance for lacking an annual penetration test. You may well be out of compliance for having a risk analysis that never looked at your ePHI-bearing applications, because that obligation is Required today and has been since 2003.
One number from the proposal worth arguing about
Buried in the regulatory impact analysis, the Department estimated that each regulated entity would spend an average of 3 hours conducting penetration testing, with a low estimate of 2 hours and a high of 10, at the hourly wage of an information security analyst, which the proposal puts at US$119.94. That works out to roughly US$360 per entity per year.
Set that against what the market actually publishes. Independent penetration testing is sold in tester days, not hours, and the median published day rate is £1,000 across 30 UK public-sector rate cards in Stingrai's Penetration Testing Price Index 2026. A single published consultant day runs 7.5 hours, which puts the implied rate near £133 an hour, as set out in the penetration testing cost per hour guide. Three hours of anything is a scan review, not a penetration test of a hospital network or a patient portal. The Department also asked commenters directly, at question (x) in the same section, "For regulated entities that have conducted penetration tests, the amount of time and costs of such tests." If the final rule lands with a realistic burden estimate, that question is why.
What OCR examines after a breach
Breach volume is the reason the rulemaking exists at all, and the Department published the numbers inside the proposal. Between 2018 and 2023, the number of breaches of unsecured PHI reported to HHS grew by 100 percent, and the number of individuals affected by those breaches grew by 950 percent. Reported hacking rose 260 percent and ransomware 264 percent over the same window. In 2022, roughly three-quarters of breaches affecting 500 or more individuals were the result of hacking of electronic equipment or a network server. In 2023, more than 160 million individuals were affected by breaches involving the PHI of 500 or more people, a record at the time of writing the proposal.
Every one of those 500-plus breaches lands on the HHS breach portal, and each one is an OCR investigation. What OCR asks for is visible in the titles of its own published settlements on the Resolution Agreements page: "Five breaches add up to millions in settlement costs for entity that failed to heed HIPAA's risk analysis and risk management rules," and "$750,000 HIPAA Settlement Underscores the Need for Organization Wide Risk Analysis."
The pattern in that headline language is the practical lesson. OCR's recurring finding is not that an entity failed a penetration test. It is that the entity never performed an accurate and thorough risk analysis across the whole environment, so the systems that got breached were never assessed in the first place. The word organization-wide is doing the work: a risk analysis limited to the electronic health record while a patient portal, a scheduling API and a research data lake sit outside the boundary is the exact failure mode.
That is why the scoping question below matters more than the cadence question.
Scoping the ePHI environment
The Security Rule's scope is defined by data, not by network segment. The obligation attaches to all ePHI a covered entity or business associate creates, receives, maintains or transmits. Draw the boundary by following the data.
The electronic health record and its integrations. The EHR itself is usually the best-defended asset in a health system and the least interesting target. The integrations around it are the opposite: HL7 and FHIR interfaces, interface engines, results feeds from labs and imaging, e-prescribing links, and the batch jobs that move data to reporting environments. Test the interfaces, the authentication between systems, and the service accounts, not just the EHR login page.
Patient-facing portals and mobile apps. These are the highest-risk applications in most healthcare estates because they combine authenticated multi-tenant access to records with self-service registration and account recovery. The failure classes that matter are broken object level authorisation (changing a patient identifier and receiving someone else's record), broken function level authorisation, tenancy and proxy-access flaws in caregiver and dependant relationships, and account recovery flows that can be driven by knowledge an attacker can obtain.
APIs. Interoperability requirements have pushed a great deal of healthcare data behind APIs that were never designed for hostile traffic. An API test is a separate scope line from a web application test, with its own object-level authorisation matrix per endpoint per role. Our guide to why scanners miss broken object level authorisation explains why an automated scan does not close this out.
Cloud infrastructure. Identity and access management, storage exposure, key management, network policy, and the workload boundaries between production and non-production. A cloud configuration review is not the same exercise as a network penetration test and both usually belong in a healthcare scope.
Internal networks, clinical devices and clinical workstations. Internal testing is where healthcare estates tend to produce the worst results, because clinical continuity requirements push back hard against patching, segmentation and credential hygiene. Medical devices need their own rules of engagement, agreed in writing, and are usually tested in a lab or on non-clinical instances rather than in a live care setting.
Business associates. A covered entity may permit a business associate to handle ePHI on its behalf only if it obtains satisfactory assurances, under 164.308(b)(1), documented in a written contract meeting 164.314(a). The same obligation flows down from business associate to subcontractor. In practice this means your scope is not only your own systems: it is also the testing evidence you can obtain about theirs. Write the cadence and the right to receive a summary report into the business associate agreement, or you will be asking for it as a favour after an incident.
What sits outside. De-identified data is outside the Security Rule's ePHI definition, but the systems holding it are frequently the same systems holding identified data, and the de-identification pipeline itself is worth testing. Marketing sites with no ePHI can be excluded, and should be, so budget goes where the data is.
Internal, external and application testing for covered entities and business associates
The three test types answer different questions, and healthcare buyers routinely purchase one and report it as though it covered all three.
External network testing answers: what can an unauthenticated attacker on the internet reach and exploit at the perimeter? For a covered entity this covers the VPN concentrators, the remote access gateways, the mail infrastructure and the exposed management interfaces that ransomware crews actually use. It is the cheapest of the three and the one that maps most directly to the breach data above.
Internal network testing answers: given a foothold, typically a phished clinical workstation or a compromised vendor connection, how far does an attacker get and how fast do they reach ePHI? This is an assumed-breach exercise. It is the test that produces uncomfortable results in hospitals and the test most likely to change a segmentation roadmap. Our explainer on assumed breach engagements covers how to set the starting position.
Application and API testing answers: can an authenticated user reach data that is not theirs? For a digital health vendor or a business associate operating a multi-tenant platform, this is the test that matters most, because the platform's whole security model is an authorisation model. Stingrai's web application penetration testing service is scoped around exactly this class of question.
The split by organisation type, in practice:
Organisation type | Primary scope | Usually secondary | Driver |
|---|---|---|---|
Digital health or health IT vendor (business associate) | Application and API testing on the multi-tenant platform | External network, cloud configuration review | Customer security reviews and business associate agreement obligations, more than OCR |
Hospital or health system (covered entity) | Internal network and Active Directory, external network | Portal and integration testing, medical device scoping | Ransomware exposure and the risk analysis obligation |
Physician group or clinic (covered entity) | External network, internal network on a small estate | Portal testing if patient-facing | Risk analysis obligation, cyber insurance questionnaires |
Health plan or clearinghouse | External network, application testing on member portals | Internal network, cloud review | Volume of records held, plan sponsor obligations under 164.314(b) |
Billing, RCM or transcription business associate | Application testing, external network | Internal network where staff handle ePHI directly | Covered entity flow-down and subcontractor assurances |
What a HIPAA-driven penetration test costs
There is no HIPAA price list, and any figure presented as one is invented. What can be published honestly is arithmetic on two numbers that are themselves published: a day rate, and a day count.
The day rate used below is the median published penetration testing day rate of £1,000 across 30 UK public-sector rate cards in Stingrai's Penetration Testing Price Index 2026, with a central band of £800 to £1,200. The day counts are the tester-day counts published alongside fixed fees by two firms that print both, collected in the penetration testing cost per hour and day rates guide. Currency conversions use US$1.3555 per GBP, the Federal Reserve H.10 observation dated 28 August 2026 cited in that guide.
Every figure in this table is derived from a published day rate multiplied by a published day count. None of it is a quote.
HIPAA scope | Published tester days | At the index median day rate | In US dollars |
|---|---|---|---|
Internal network, single clinic or small estate | 1 to 3 days | £1,000 to £3,000 | US$1,356 to US$4,067 |
External network perimeter | 3 to 5 days | £3,000 to £5,000 | US$4,067 to US$6,778 |
Patient portal or single web application | 3 to 5 days | £3,000 to £5,000 | US$4,067 to US$6,778 |
Cloud configuration review, one platform | 4 to 5 days | £4,000 to £5,000 | US$5,422 to US$6,778 |
API, interoperability or integration surface | 4 to 9 days | £4,000 to £9,000 | US$5,422 to US$12,200 |
SaaS platform, multi-tenant | 5 to 7 days | £5,000 to £7,000 | US$6,778 to US$9,489 |
Internal network, larger estate | 5 to 8 days | £5,000 to £8,000 | US$6,778 to US$10,844 |
Web application, deeper scope | 6 to 12 days | £6,000 to £12,000 | US$8,133 to US$16,266 |
Full-scope assessment | 10 to 20 days | £10,000 to £20,000 | US$13,555 to US$27,110 |
Three things move a healthcare quote away from those bands. Role count is the biggest one on applications: a portal with patient, caregiver, clinician, scheduler and administrator roles has an authorisation matrix several times larger than a single-role SaaS product, and authorisation testing scales with role pairs rather than page count. Clinical constraints add days on internal engagements, because testing windows get pushed to nights and weekends and device classes get carved out and handled separately. Retesting is the line most often left out of a comparison: a fix cycle on a healthcare application is rarely a single pass, and a quote that excludes retesting is not comparable to one that includes it.
Stingrai publishes fixed package prices rather than a metered rate. The pricing page lists an Autonomous Pentest from US$3,000 one-time driven by Snipe, and a Hybrid Pentest at US$6,800 one-time where certified penetration testers work alongside Snipe throughout the engagement, both covering one web application and its APIs. The same two tiers run continuously at US$450 and US$1,275 per month on a 12-month engagement, so a covered entity can fund an annual point-in-time evaluation or year-round coverage from the same published list. For a hospital estate, a multi-application platform or a scope with medical devices in it, request a quote and the number comes back scoped rather than guessed.
What a healthcare penetration test actually returns
A cadence argument is easier to have with data about what the tests find. Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests, and three of its numbers speak directly to the HIPAA risk analysis obligation.
92.7% of tests surfaced at least one High or Critical finding. That is the number to put next to a risk analysis that concluded the environment was low risk without anyone attacking it. A written assessment that has never been tested is an opinion about vulnerability, not a measurement of it.
70% of web application tests that produced findings surfaced a High or Critical authentication or authorization finding. For healthcare, this is the headline. Authorisation failures are how one patient's record reaches another patient's screen, and they map straight onto 164.312(a)(1) access control and 164.312(d) person or entity authentication. They are also the class that automated scanning is worst at, because the request is well-formed and the response is a valid 200; only a tester who knows which record belongs to whom can tell that it should not have been returned.
The median Critical took 10.5 days to fix, against 38 days for Highs. Budget the fix window, not just the test. Under the proposed rule, a critical risk identified by a penetration test would carry a 15 calendar day patch deadline, which sits just inside that observed median and well inside the High figure.
One more number worth carrying into a vendor conversation: the dataset's false positive rate was 0.74%. Evidence quality is what an investigator or an enterprise customer is judging, and a report padded with unvalidated scanner output degrades the credibility of the findings that matter.
The evidence package for the risk analysis
The deliverable that survives contact with OCR, an enterprise customer's security review or a HITRUST assessor is not the PDF on its own. Assemble these eight items and keep them for six years, per 164.316(b)(2)(i).
A written scope statement naming the systems, applications, URLs, IP ranges, cloud accounts and roles in scope, and naming what was excluded and why. Exclusions with reasons are a sign of a mature programme; silent exclusions look like gaps.
The rules of engagement, including testing windows, escalation contacts, and the medical device and clinical safety carve-outs, signed by both sides.
The written senior management approval for the testing, which is the specific artefact NIST SP 800-66r2 prompts for under the evaluation standard.
The full technical report, with reproduction steps, affected assets, severity ratings and a stated rating methodology. Severity without a methodology is not auditable.
The risk analysis update showing how each finding was carried into the written assessment: threat, vulnerability, likelihood, impact, resulting risk level. This is the link most organisations never build, and it is the one that satisfies 164.308(a)(1)(ii)(A) rather than merely informing it.
The remediation record with owners, dates and decisions, including risks accepted with a documented rationale. That is the 164.308(a)(1)(ii)(B) risk management evidence.
The retest report confirming closure. An unretested fix is an assertion.
The tester's qualifications and independence, which is what the proposed rule's "qualified person" language would formalise and what SP 800-66r2 already asks about when it prompts, "Are the evaluators sufficiently independent to provide objective reporting?"
Our guide to the pentest evidence auditors accept across SOC 2, ISO 27001, PCI DSS and CMMC covers the same package in a multi-framework context, and the overlap is close to total. One well-built evidence set serves several frameworks at once.
Choosing a tester for a HIPAA scope
Six questions separate a firm that has done healthcare work from one that will learn on your environment.
Will you sign a business associate agreement? If the engagement can expose the tester to ePHI, and on a production application test it usually can, the tester meets the definition of a business associate and needs a BAA under 164.308(b) and 164.314(a). A firm that will not sign one, or does not know why it is being asked, is telling you something.
How is PHI handled during and after the test? Ask where evidence is stored, who can access it, whether screenshots are redacted, how long artefacts are retained, and what the destruction process is. Prefer synthetic test records over live patient data wherever the application allows it, and get that decision recorded in the rules of engagement.
Can you test authorisation across our role model? Ask for the authorisation test methodology in writing before signing. A firm that answers with a scanner name is quoting for the wrong test.
Do you know HITRUST and SOC 2 evidence expectations? Most healthcare vendors are running a HIPAA obligation and a customer-facing certification at the same time. A tester familiar with what a HITRUST External Assessor or a SOC 2 auditor will actually inspect will structure the report so one engagement feeds both. The companion guide to HITRUST penetration testing requirements sets out what those assessors do and do not publish.
Is retesting included, and for how long? Retesting is the single most common gap between a quoted number and a paid invoice, and in healthcare the fix cycle is slow because change windows are constrained.
Who is actually testing, and are they independent of the systems being assessed? Get names, certifications and the split between automated and manual effort. Independence is an explicit question in the federal implementation guide and an explicit rule in HITRUST's assessor programme.
Stingrai is a CREST-accredited penetration testing service provider at the firm level, holds 18 published CVEs across the team, and is rated 5.0 out of 5.0 across 19 Clutch reviews. Its penetration testing supports HIPAA, HITRUST, SOC 2, ISO 27001 and PCI DSS 4.0 programmes by producing the technical evidence those programmes consume. Healthcare engagements sit in the healthcare cybersecurity case study and the medical software penetration testing case study.
What this means for healthcare security teams
Test annually and after material change, even though the Rule does not say so. The maintenance standard at 164.306(e) already implies a cadence, the proposed rule names 12 months, and every enterprise healthcare customer's vendor questionnaire asks for it. Waiting for the final rule buys nothing.
Fix the risk analysis boundary before buying more testing. OCR's published settlement language points at organisation-wide risk analysis failures, not at test frequency. A test of the wrong scope is expensive evidence of the wrong thing.
Put authorisation testing at the top of the application scope. It maps to two Security Rule technical safeguards, it is the class that scanners miss, and in our own dataset it is where High and Critical findings concentrate on web application tests.
Write the testing cadence into business associate agreements. Satisfactory assurances is a contractual standard. If the contract does not name a cadence and a right to see results, you have no mechanism.
Keep the whole evidence package for six years, not just the report. Scope statement, approval, report, risk analysis linkage, remediation record, retest. The retention period is Required, not addressable.
Track RIN 0945-AA22 rather than the headlines. The Federal Register entry and the Unified Agenda timetable are the two places where the status actually changes.
Frequently Asked Questions
Does HIPAA require penetration testing in 2026?
No. The HIPAA Security Rule in force on 5 September 2026 does not require penetration testing and does not use the term. It requires a risk analysis at 45 CFR 164.308(a)(1)(ii)(A), a periodic technical and nontechnical evaluation at 164.308(a)(8), and maintenance of security measures at 164.306(e). NIST SP 800-66r2, the federal implementation guide, places penetration testing inside those standards as an activity to perform "if reasonable and appropriate." A proposed rule would make it explicit and annual, but it is not final.
How often does HIPAA require a penetration test?
The current Rule states no interval. It requires the evaluation to be periodic and to be repeated in response to environmental or operational changes affecting the security of ePHI, and it requires security measures to be reviewed and modified as needed. The proposal at 90 FR 898 would set the floor at once every 12 months, or more often if the entity's own risk analysis calls for it. Annual plus after material change is the cadence most healthcare buyers and their customers already operate.
Has the 2025 HIPAA Security Rule update been finalised?
No. The proposed rule was published on 6 January 2025 and comments closed on 7 March 2025. As of 5 September 2026, the Federal Register lists a single document under RIN 0945-AA22, the proposal itself, and the 2026 Unified Agenda records the rulemaking as a long-term action with a final action target of July 2027. A target date is not a commitment: a proposed rule can be finalised as proposed, modified, re-proposed, delayed or withdrawn. HHS states that the current Security Rule remains in effect while the rulemaking continues.
What does the proposed rule say about penetration testing exactly?
Proposed 45 CFR 164.312(h)(2)(iii) would require a regulated entity to "perform penetration testing of the covered entity's or business associate's relevant electronic information systems by a qualified person," with a qualified person defined as someone with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for protecting ePHI, and with testing performed "at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis, whichever is more frequent." The same proposed standard would require automated vulnerability scanning at least once every six months.
What does OCR look for after a healthcare breach?
The recurring finding in OCR's own published settlement titles is a failure to conduct an accurate, thorough, organisation-wide risk analysis and to act on it, rather than a failure to run a specific test. The Resolution Agreements page carries settlement headlines such as "Five breaches add up to millions in settlement costs for entity that failed to heed HIPAA's risk analysis and risk management rules." Expect document requests covering the risk analysis, the systems it covered, the evidence behind it, and what was done with the results.
Do business associates need penetration testing under HIPAA?
Business associates are subject to the Security Rule directly, so the same risk analysis, evaluation and maintenance obligations apply to them. Separately, a covered entity may only use a business associate if it obtains satisfactory assurances under 164.308(b)(1), documented in a written contract meeting 164.314(a). In practice, most business associates are driven to test by customer contracts long before regulation reaches them, and the proposed rule would add an annual written verification and certification of technical safeguards to covered entities.
What should be in scope for a HIPAA penetration test?
Follow the ePHI. That normally means patient-facing portals and mobile applications, the APIs behind them, EHR integrations and interface engines, cloud accounts holding or processing ePHI, the internal network and Active Directory where clinical workstations sit, and any third-party connection that carries records. Marketing sites with no ePHI can be excluded, and medical devices need separate rules of engagement rather than exclusion by default.
How much does a HIPAA penetration test cost?
There is no published HIPAA rate. Deriving from published inputs, at the median published day rate of £1,000 from Stingrai's Penetration Testing Price Index 2026 and the published tester-day counts collected in the cost per hour guide, a patient portal test at 3 to 5 days derives to £3,000 to £5,000 (US$4,067 to US$6,778), an API scope at 4 to 9 days to £4,000 to £9,000, and a full-scope assessment at 10 to 20 days to £10,000 to £20,000. Stingrai's published packages start at US$3,000 one-time for one web application and its APIs on the pricing page.
Does a vulnerability scan satisfy HIPAA?
Not on its own, and the proposed rule makes the distinction explicit by putting automated vulnerability scanning and penetration testing in separate implementation specifications with different frequencies. A scan enumerates known-signature weaknesses; it does not test whether one authenticated patient can retrieve another patient's record, which is the failure class that produces reportable breaches in healthcare applications. Our comparison of penetration testing and vulnerability assessment against what compliance frameworks require sets out the difference framework by framework.
Does the tester need a business associate agreement?
If the engagement can expose the tester to ePHI, yes. A firm performing a function or activity on behalf of a covered entity that involves access to protected health information falls within the business associate definition, and the Security Rule requires the relationship to be documented in a written contract meeting 164.314(a). Ask about the BAA in the first scoping call, together with how evidence containing PHI is stored, redacted, retained and destroyed.
How long do we have to keep penetration test reports?
45 CFR 164.316(b)(2)(i) requires documentation of any action, activity or assessment the Security Rule requires to be documented to be retained for six years from the date of its creation or the date it was last in effect, whichever is later. Where a test report is the evidence behind a risk analysis or an evaluation, keep it, and the retest and the remediation record, for the same six years.
Where can I read the actual rules?
Start with the regulation itself on eCFR: 164.306 general rules, 164.308 administrative safeguards, 164.312 technical safeguards, 164.314 organizational requirements and 164.316 documentation. Then read the proposal at 90 FR 898 and check its status on the Unified Agenda entry for RIN 0945-AA22. For implementation guidance, NIST SP 800-66r2 is the federal resource guide.
Related Reading
HITRUST Penetration Testing Requirements: r2 vs i1 vs e1, Scope, Frequency
Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC (2026)
SOC 2 Penetration Testing: What Auditors Expect and How to Scope It (2026)
PCI DSS Penetration Testing: Requirement 11.4 Explained (2026)
Penetration Testing vs Vulnerability Assessment: What Compliance Frameworks Really Require
References
Office of the Federal Register. 45 CFR 164.306, Security standards: General rules. Current as of 3 September 2026. https://www.ecfr.gov/current/title-45/section-164.306. General requirements, flexibility of approach, the required and addressable distinction, and the maintenance standard at paragraph (e).
Office of the Federal Register. 45 CFR 164.308, Administrative safeguards. Current as of 3 September 2026. https://www.ecfr.gov/current/title-45/section-164.308. Risk analysis and risk management implementation specifications, the evaluation standard at paragraph (a)(8), and business associate contract requirements at paragraph (b).
Office of the Federal Register. 45 CFR 164.312, Technical safeguards. Current as of 3 September 2026. https://www.ecfr.gov/current/title-45/section-164.312. Access control, audit controls, integrity, person or entity authentication and transmission security standards.
Office of the Federal Register. 45 CFR 164.314, Organizational requirements. Current as of 3 September 2026. https://www.ecfr.gov/current/title-45/section-164.314. Required content of business associate contracts and group health plan document requirements.
Office of the Federal Register. 45 CFR 164.316, Policies and procedures and documentation requirements. Current as of 3 September 2026. https://www.ecfr.gov/current/title-45/section-164.316. The six-year documentation retention requirement at paragraph (b)(2)(i).
U.S. Department of Health and Human Services, Office for Civil Rights. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information. Proposed rule, 90 FR 898, 6 January 2025, RIN 0945-AA22, comments closed 7 March 2025. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information. Source of the proposed penetration testing, vulnerability scanning, compliance audit, asset inventory and network map requirements, the breach growth statistics for 2018 to 2023, and the regulatory impact analysis burden estimates.
U.S. Government Publishing Office. Federal Register, 6 January 2025, document 2024-30983, full text. https://www.govinfo.gov/content/pkg/FR-2025-01-06/html/2024-30983.htm. The authenticated full text used to verify the regulatory language quoted on this page.
Office of Information and Regulatory Affairs. Unified Agenda entry, RIN 0945-AA22, HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information. Publication ID 2026. https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0945-AA22. Records the agenda stage as long-term actions and the final action timetable entry as July 2027.
U.S. Department of Health and Human Services, Office for Civil Rights. HIPAA Security Rule Notice of Proposed Rulemaking to Strengthen Cybersecurity for Electronic Protected Health Information: Fact Sheet. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html. Summary of the proposals, including vulnerability scanning every six months and penetration testing every 12 months, and the statement that the current Security Rule remains in effect during the rulemaking.
National Institute of Standards and Technology. SP 800-66r2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide. February 2024. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-66r2.pdf. Section 5.1.8 covers the evaluation standard and lists penetration testing as a key activity, and the risk assessment guidance lists penetration test results as a vulnerability identification source.
U.S. Department of Health and Human Services, Office for Civil Rights. Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information. https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf. The public register of breaches affecting 500 or more individuals.
U.S. Department of Health and Human Services, Office for Civil Rights. Resolution Agreements and Civil Money Penalties. https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html. OCR's published settlements, including the risk analysis and risk management cases quoted on this page.
Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, severity mix, authentication and authorization finding rates, remediation timing and false positive rate.
Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026. Median published day rate and central band across 30 public-sector rate cards.
Stingrai. Penetration Testing Cost Per Hour and Day Rates (2026). https://www.stingrai.io/blog/penetration-testing-cost-per-hour-2026. Published tester-day counts per engagement type and the currency conversion basis used in the cost table above.
Stingrai. Pricing. https://www.stingrai.io/pricing. Published one-time and continuous package prices for one web application and its APIs.
Ready to scope a HIPAA penetration test?
The Security Rule obligation that bites today is the risk analysis, and a risk analysis that has never been tested is an opinion. Stingrai is a CREST-accredited penetration testing service provider whose penetration testing supports HIPAA and HITRUST programmes by producing the scope statement, technical report, remediation record and retest evidence those programmes consume. Certified penetration testers work alongside Snipe, our autonomous AI agent for web application penetration testing, throughout the engagement, hunting the broken authorization and business logic flaws that put one patient's record on another patient's screen. Book a free scoping call, get a quote for a multi-application or hospital estate scope, or read the published package prices on the pricing page.
