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 (164.308(a)(8)), and maintenance of security measures (164.306(e)). The federal implementation guide, NIST SP 800-66r2 (February 2024), places penetration testing inside both standards, to be conducted "if reasonable and appropriate." The proposed rule at 90 FR 898 would add an express requirement for testing by a qualified person at least once every 12 months, plus vulnerability scanning every six months. It is not final: as of 19 September 2026 the Federal Register lists one document under RIN 0945-AA22, and the 2026 Unified Agenda shows a final action target of July 2027.
This guide is written for the people who carry the obligation at scale: security and compliance leaders at hospital systems and health plans, and teams running multi-product health-tech platforms as business associates. Startups appear where the answer differs for them, but the hard problems here are enterprise problems. Scoping several ePHI-bearing systems at once, getting a business associate agreement signed before anyone touches production, keeping a six-year evidence file that survives an OCR document request, and choosing a cadence. Every regulatory statement below was read from the regulation, the Federal Register document, the federal implementation guide or the government regulatory agenda, and links back to that source.
Does HIPAA require penetration testing?
No, not by name, and anyone who says otherwise is describing the proposed rule rather than the one in force.
The Security Rule is written in outcomes rather than techniques. 45 CFR 164.306(a) sets four general requirements: ensure the confidentiality, integrity and availability of all ePHI a regulated entity creates, receives, maintains or transmits; protect against reasonably anticipated threats and impermissible uses; and ensure workforce compliance. Section 164.306(b) then grants flexibility of approach, letting entities use any measures that reasonably and appropriately implement the standards given their size, complexity, infrastructure, costs and risk profile. That is why the Rule names no tool, no scanner, no test type and no vendor, and why penetration testing sits at the centre of three standards without being written into any of them.
Risk analysis, 164.308(a)(1)(ii)(A), marked (Required). "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information." The word doing the work is thorough. NIST SP 800-66r2 names the evidence sources for vulnerability identification directly: internal sources "may include previous risk assessments, vulnerability scan and system security test results (e.g., penetration tests), and audit reports."
Evaluation, 164.308(a)(8). A "periodic technical and nontechnical evaluation" measured against the standards and repeated "in response to environmental or operational changes affecting the security of electronic protected health information." SP 800-66r2 lists among its key activities, "Conduct penetration testing... if reasonable and appropriate," and asks whether "specifically worded, written approval from senior management" has been received for it.
Maintenance, 164.306(e). Review and modify the security measures "as needed" and update the documentation. This turns a one-off exercise into a cadence, but sets no interval, which is the gap the 2025 proposal tries to close.
One distinction is worth settling before it derails a board conversation. 164.306(d) makes some specifications Required and others Addressable, where addressable means assess, implement if reasonable and appropriate, and otherwise document why and implement an equivalent alternative. Risk analysis and risk management are Required. The evaluation standard has no implementation specifications attached, so it is not optional either. Encryption at rest and in transit is Addressable today. OCR wrote in the proposal that it is "concerned that some regulated entities proceed as if compliance with an addressable implementation specification is optional... That interpretation is incorrect."
The HIPAA clause to test type to evidence table
Take this into a risk analysis review or an OCR document request. Left column is the clause, middle column is the testing activity that produces evidence against it, right column is what to retain.
HIPAA clause | Testing activity that produces evidence | Evidence to retain |
|---|---|---|
164.308(a)(1)(ii)(A) Risk analysis (Required) | External and internal network testing, web application and API testing, cloud configuration review | Test report with scope, methodology, findings, severities and dates, plus the written risk analysis showing how each finding was rated |
164.308(a)(1)(ii)(B) Risk management (Required) | Retest of remediated findings | Remediation tickets with owners and dates, and a retest report showing each finding closed or accepted with justification |
164.308(a)(8) Evaluation | Penetration test scoped to the ePHI environment, repeated after material change | Evaluation report, the written senior management approval SP 800-66r2 asks about, and the trigger record for change-driven tests |
164.312(a)(1) Access control and 164.312(d) Authentication | Authorisation and authentication testing on portals and APIs: broken object level authorisation, privilege escalation, session handling, tenancy separation | Authorisation test cases enumerated per role, including the negative cases that passed |
164.312(e)(1) Transmission security | Transport security testing on every ePHI-bearing interface | Configuration findings per endpoint, with certificate and protocol evidence |
164.308(b)(1) and 164.314(a)(2)(i) Business associate contracts | The business associate's own testing, and its subcontractors' | Contract clauses naming a cadence and a right to review results, plus the summary letters actually received |
164.316(b)(2)(i) Documentation time limit (Required) | Nothing to test, everything to keep | A six-year archive of reports, retests, risk analyses and approvals |
The right-hand column is where most healthcare organisations fall down. A good report from two years ago with no retest record is weaker evidence than a smaller test with a documented fix cycle.
What the 2025 proposed rule would add, and where it stands

The notice of proposed rulemaking was published on 6 January 2025 at 90 FR 898 under RIN 0945-AA22, and comments closed on 7 March 2025. It is a structural rewrite. The parts that matter to a testing programme:
Penetration testing becomes an express implementation specification. Proposed 164.312(h)(2)(iii): "Perform penetration testing of the... relevant electronic information systems by a qualified person," meaning someone with "appropriate knowledge of and experience with generally accepted cybersecurity principles and methods," "at least once every 12 months or in accordance with the... risk analysis... whichever is more frequent."
Automated vulnerability scanning gets a six-month floor, under proposed 164.312(h)(2)(i)(A), with the effectiveness of the scanning technology itself reviewed at least once every 12 months.
Patch timelines get numbers: 15 calendar days to patch, update or reconfigure a system after identifying the need to address a critical risk, including risks identified by penetration tests.
A compliance audit every 12 months under proposed 164.308(a)(14), against each standard and implementation specification, which the Rule "does not currently require."
A written technology asset inventory and network map under proposed 164.308(a)(1)(i), maintained continuously and reviewed at least every 12 months, because "the inventory forms the foundation for a fulsome and accurate risk analysis." For a hospital system or a multi-product platform this is the most expensive proposed obligation and the one worth starting early.
The addressable category disappears. All specifications become required "with specific, limited exceptions," including encryption and multi-factor authentication, and business associates would verify and certify their technical safeguards every 12 months in a written analysis plus a certification.
Status on 19 September 2026: proposed, not final
This is the sentence most articles get wrong, so here is the 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 2026 Unified Agenda lists the agenda stage as Long-Term Actions with a timetable of NPRM 01/06/2025 and Final Action 07/00/2027. HHS says the same on its fact sheet: "While the Department is undertaking this rulemaking, the current Security Rule remains in effect."
So the honest position 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 proposal figure is worth flagging at budget time: the regulatory impact analysis estimated each entity would spend an average of 3 hours conducting penetration testing at an information security analyst wage of US$119.94, near US$360 a year. Independent testing is sold in tester days, not hours, at a median published day rate of £1,000 across 30 UK public-sector rate cards in Stingrai's Penetration Testing Price Index 2026. Three hours is a scan review, not a test of a hospital network.
What OCR examines after a breach
Breach volume is why the rulemaking exists. Inside the proposal, the Department recorded that between 2018 and 2023 breaches of unsecured PHI reported to HHS grew 100 percent and individuals affected grew 950 percent, with hacking up 260 percent and ransomware up 264 percent. The trend continued: for calendar year 2025, 804 breaches affecting 500 or more individuals were reported to OCR, covering approximately 138.5 million people, per HHS OCR breach portal data compiled by HIPAA Journal, updated 8 September 2026 from an OCR pull dated 4 September 2026. Late reports keep moving prior-year totals, so treat any single-year count as a dated snapshot. Our full aggregation sits in Healthcare Data Breach Statistics 2026.
Each of those breaches is an OCR investigation, and what OCR asks for is visible in the titles of its own 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 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 breached systems were never assessed. 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, and it gets likelier the larger and more acquisitive the organisation is. Fix the boundary before buying more testing.
Scoping a multi-system ePHI environment
The Security Rule's scope is defined by data, not by network segment. It attaches to all ePHI a covered entity or business associate creates, receives, maintains or transmits. Follow the data.
The electronic health record and its integrations. The EHR is usually the best-defended asset in a health system and the least interesting target. The integrations are the opposite: HL7 and FHIR interfaces, interface engines, lab and imaging feeds, e-prescribing links, and the batch jobs that move data to reporting environments. Test those, the authentication between systems and the service accounts, not just the EHR login page.
Patient-facing portals, mobile apps and the APIs behind them. 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 weak account recovery. An API test is a separate scope line with its own authorisation matrix per endpoint per role, and our guide to why scanners miss broken object level authorisation explains why a scan does not close it out.
Cloud infrastructure. Identity and access management, storage exposure, key management, network policy, and the boundaries between production and non-production. A cloud configuration review is not a network penetration test, and both usually belong in a healthcare scope.
Internal networks, clinical devices and workstations. Internal testing produces the worst results in healthcare, because clinical continuity requirements push back against patching, segmentation and credential hygiene. Medical devices need their own written rules of engagement and are usually tested in a lab or on non-clinical instances.
Acquired entities. Mid-market and enterprise health organisations grow by acquisition, and the acquired clinic group, billing company or app arrives with its own network, identity provider and unmapped ePHI. That is exactly the organisation-wide gap OCR writes settlements about, so put newly acquired systems into the first annual cycle after close, not the second.
Business associates. A covered entity may permit a business associate to handle ePHI only if it obtains satisfactory assurances under 164.308(b)(1), documented in a contract meeting 164.314(a), and the obligation flows down to subcontractors. Your scope is also the testing evidence you can obtain about theirs. Write the cadence and the right to a summary report into the agreement, or you will be asking for it as a favour after an incident. De-identified data sits outside the ePHI definition, though the systems holding it often hold identified data too, and marketing sites with no ePHI should be excluded so budget goes where the data is.
Three test types answer different questions, and buyers routinely purchase one and report it as though it covered all three. External testing answers what an unauthenticated attacker reaches at the perimeter. Internal testing answers how far an attacker gets from a foothold and how fast they reach ePHI, the assumed breach question. Application and API testing answers whether an authenticated user can reach data that is not theirs, which matters most for a platform whose entire security model is an authorisation model, and is the focus of Stingrai's web application penetration testing service. Match them to the organisation.
Organisation type | Primary scope | Usually secondary | Driver |
|---|---|---|---|
Hospital or health system | Internal network and Active Directory, external network | Portal and integration testing, medical device scoping, acquired estates | Ransomware exposure and the organisation-wide risk analysis obligation |
Health plan, payer or clearinghouse | External network, application testing on member and broker portals | Internal network, cloud review | Volume of records held, plan sponsor obligations under 164.314(b) |
Multi-product health-tech platform | Application and API testing across every product with an authorisation model | External network, cloud review, shared identity plane | Enterprise customer security reviews and business associate agreement obligations, more than OCR |
Early-stage digital health vendor | One web application and associated APIs | External network | The first enterprise customer's security review, and SOC 2 |
What a mid-market or enterprise HIPAA buyer needs from a penetration testing vendor
At startup scale, buying a penetration test is one decision about one application. At mid-market and enterprise scale it is a procurement exercise with a security review, a legal review and a six-year evidence requirement attached. Nine things separate a vendor who passes that review from one who creates work for you.
Evidence built for an OCR document request. The deliverable that matters is the package, not the finding list: a scope statement naming systems, a stated severity methodology, dated findings, and a structure that lets you carry each finding into the written risk analysis as threat, vulnerability, likelihood, impact and risk level. Ask for a redacted sample report and retest report before you sign.
A business associate agreement signed before scoping ends. If the engagement can expose the tester to ePHI, and on a production application test it usually can, the tester meets the business associate definition and needs a BAA under 164.308(b) and 164.314(a). Enterprise legal teams will want breach notification timelines, subcontractor flow-down and a return-or-destroy clause in it.
A written PHI handling standard for the engagement itself. Where evidence is stored and in which jurisdiction, who can access it, whether screenshots are redacted, retention period, destruction process. Prefer synthetic records over live patient data wherever the application allows, and record that decision in the rules of engagement.
Named penetration testers with verifiable accreditation. Get names, certifications and the split between automated and manual effort before work starts. The proposed rule's "qualified person" language would formalise this, and SP 800-66r2 already asks, "Are the evaluators sufficiently independent to provide objective reporting?" Firm-level accreditation and individual certification are different things, and a CREST-accredited firm staffing the work with named, certified penetration testers answers both.
Authorisation testing across your full role model, in writing. A hospital portal with patient, caregiver, clinician, scheduler and administrator roles has an authorisation matrix several times larger than a single-role product, because the work scales with role pairs rather than page count. A firm that answers with a scanner name is quoting for the wrong test.
Retesting included, with a stated window. Retesting is the most common gap between a quoted number and a paid invoice, and healthcare fix cycles are slow. Confirm how long the retest stays available and whether a second round is covered.
A portal, not an email thread. At multi-system scale you need findings visible as they land, one place where engineering sees reproduction steps and status, an export your governance platform can ingest, and history against the same asset across engagements.
Procurement and third-party risk fit. Expect to run the vendor through your own process. The questions that stall deals are insurance limits, subcontractor use, background screening, data residency, and whether the vendor can produce its own security evidence on request. Ask for that pack before contracting.
A deliberate cadence decision. An annual point-in-time test satisfies the evaluation standard and most customer questionnaires. Continuous testing suits platforms that ship weekly and organisations that keep acquiring. Many mid-market programmes run both: an annual full-scope engagement across the estate, plus continuous coverage on the fastest-moving products.
Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements, delivered as one-time annual engagements or as continuous programmes through its PTaaS platform. Its penetration testing supports HIPAA Security Rule risk analysis and evaluation work, HITRUST, SOC 2, ISO 27001, PCI DSS 4.0 and NIST SP 800-53 and 800-171 programmes by producing the technical evidence those programmes consume. Healthcare work sits in the healthcare cybersecurity case study and the medical software penetration testing case study, and our ranking of the best penetration testing companies for HIPAA and healthcare puts the shortlist side by side.
What a HIPAA-driven penetration test costs in US and Canadian dollars

There is no HIPAA price list, and any figure presented as one is invented. What can be published honestly is arithmetic on two published numbers: a day rate and a day count. The day rate is the median published rate of £1,000 across 30 UK public-sector rate cards in Stingrai's Penetration Testing Price Index 2026. The day counts are published alongside fixed fees by firms that print both, collected in the cost per hour and day rates guide. Conversions use Federal Reserve H.10 observations dated 11 September 2026: US$1.3524 per GBP and C$1.3864 per US dollar, a cross rate of C$1.8750 per GBP.
Every figure below is a published day rate multiplied by a published day count. None of it is a quote.
HIPAA scope | Tester days | At the median day rate | US dollars | Canadian dollars |
|---|---|---|---|---|
Internal network, single clinic or small estate | 1 to 3 | £1,000 to £3,000 | US$1,352 to US$4,057 | C$1,875 to C$5,625 |
External network perimeter | 3 to 5 | £3,000 to £5,000 | US$4,057 to US$6,762 | C$5,625 to C$9,375 |
Patient portal or single web application | 3 to 5 | £3,000 to £5,000 | US$4,057 to US$6,762 | C$5,625 to C$9,375 |
Cloud configuration review, one platform | 4 to 5 | £4,000 to £5,000 | US$5,410 to US$6,762 | C$7,500 to C$9,375 |
API, interoperability or integration surface | 4 to 9 | £4,000 to £9,000 | US$5,410 to US$12,172 | C$7,500 to C$16,875 |
SaaS platform, multi-tenant | 5 to 7 | £5,000 to £7,000 | US$6,762 to US$9,467 | C$9,375 to C$13,125 |
Internal network, larger estate | 5 to 8 | £5,000 to £8,000 | US$6,762 to US$10,819 | C$9,375 to C$15,000 |
Web application, deeper scope | 6 to 12 | £6,000 to £12,000 | US$8,114 to US$16,229 | C$11,250 to C$22,500 |
Full-scope assessment | 10 to 20 | £10,000 to £20,000 | US$13,524 to US$27,048 | C$18,750 to C$37,500 |
Those rows describe one scope at a time. A mid-market or enterprise programme is several of them in a single year, which is why the annual figure a hospital system or multi-product platform approves sits well above any single line: an external perimeter test, two or three application and API scopes, a cloud review, an internal network engagement, and retests. Three things move a healthcare quote away from the derived bands. Role count is the biggest on applications. Clinical constraints add days on internal engagements, because windows move to nights and weekends and device classes get carved out. Retesting is the line most often left out, and a quote that excludes it 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 at US$3,000 one-time driven by Snipe, our autonomous AI agent for web application penetration testing, 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 associated APIs. The same tiers run continuously at US$650 and US$1,275 per month on a 12-month engagement, so an organisation can fund an annual evaluation, year-round coverage, or both from the same list. For a hospital estate, a multi-application platform or a scope with medical devices in it, request a quote.
Canada and the United States: PHIPA, PIPEDA and selling across the border
Canadian health organisations sit under a different regime with a similar shape. Ontario's Personal Health Information Protection Act, 2004 requires a health information custodian at section 12(1) to "take steps that are reasonable in the circumstances" to protect personal health information "against theft, loss and unauthorized use or disclosure." Like the HIPAA Security Rule it names no test and no cadence, and the most defensible reading of reasonable steps is the same: an independent annual test with a documented retest. Federally, PIPEDA covers personal information handled in commercial activity, and Principle 4.7 requires safeguards appropriate to sensitivity, with health data treated as sensitive. The two overlap rather than replace each other, so a Canadian health-tech vendor usually satisfies a custodian's PHIPA-driven contract terms and its own PIPEDA obligation with one evidence set.
For a Canadian health-tech company selling into the US, the operative pressure is almost never the regulator. It is the business associate agreement and the customer security review. A US hospital system or payer will require a signed BAA, an annual independent penetration test of the products that touch ePHI, a summary letter it can file, and often a SOC 2 Type II. So scope to the American definition of ePHI, which is usually broader than a Canadian custodian contract asked for; document where testing artefacts are stored, because health customers on both sides of the border ask about residency; and align the test date to the US buyer's fiscal calendar, because that date is what their vendor review checks. Our SOC 2 penetration testing guide covers the parallel obligation and the SOC 2 provider ranking covers vendor selection for it. For regional shortlists, see the USA ranking and the Canada ranking.
What a healthcare penetration test actually returns
Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests. Three numbers speak to the HIPAA risk analysis obligation.
92.7% of tests surfaced at least one High or Critical finding. Put that next to a risk analysis that concluded the environment was low risk without anyone attacking it. An untested assessment 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. 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) authentication. They are also the class automated scanning is worst at, because the request is well-formed and the response is a valid 200. Put authorisation testing at the top of every application scope.
The median Critical took 10.5 days to fix, against 38 days for Highs, so budget the fix window, not just the test. The proposed rule's 15 calendar day critical patch deadline sits just inside that median.
The evidence package for the risk analysis
What survives contact with OCR, an enterprise security review or a HITRUST assessor is not the PDF on its own. Assemble these six items and keep them for the full six years, per 164.316(b)(2)(i).
A written scope statement naming systems, applications, URLs, IP ranges, cloud accounts and roles, and what was excluded and why. Exclusions with reasons signal a mature programme; silent exclusions look like gaps.
The rules of engagement, including testing windows, escalation contacts, PHI handling, and medical device and clinical safety carve-outs, signed by both sides.
The written senior management approval, the specific artefact 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 became threat, vulnerability, likelihood, impact and resulting risk level. This is the link most organisations never build, and the one that satisfies 164.308(a)(1)(ii)(A) rather than merely informing it.
The remediation record, the retest report, and the testers' qualifications and independence. Owners, dates and decisions, including risks accepted with a documented rationale, plus the credentials the proposed rule's "qualified person" language would formalise.
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: one well-built evidence set serves several frameworks at once.
What this means for healthcare security teams
Test annually and after material change, even though the Rule does not say so. The maintenance standard already implies a cadence, the proposal names 12 months, and every enterprise vendor questionnaire asks for it. Waiting for the final rule buys nothing.
Fix the risk analysis boundary before buying more testing. A test of the wrong scope is expensive evidence of the wrong thing, and the asset inventory the proposal would require is the work that makes multi-system scoping possible.
Write the testing cadence into business associate agreements. Satisfactory assurances is a contractual standard. Without a named cadence and a right to see results, you have no mechanism.
Track RIN 0945-AA22 rather than the headlines. The Federal Register entry and the Unified Agenda timetable are where the status actually changes.
Frequently Asked Questions
Does HIPAA require penetration testing in 2026?
No. The HIPAA Security Rule in force on 19 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 repeated in response to environmental or operational changes affecting the security of ePHI. 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 what most healthcare buyers already operate, and larger organisations increasingly add continuous testing on the products that change fastest.
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 19 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. HHS states that the current Security Rule remains in effect while the rulemaking continues.
What does a mid-market or enterprise buyer need from a HIPAA penetration testing vendor?
Evidence that maps to the Security Rule risk analysis without rewriting, a signed business associate agreement, a written PHI handling standard covering storage, redaction, retention and destruction, named penetration testers with verifiable accreditation, authorisation testing across the full role model, retesting included with a stated window, a portal rather than an email thread, a vendor that passes your own third-party risk review, and a deliberate choice between annual and continuous testing for each system. Ask for a redacted sample report and a redacted retest report before signing.
What should a hospital system or health plan expect to pay for a HIPAA penetration test?
There is no published HIPAA rate, so the honest answer is derived arithmetic. At the median published day rate of £1,000 from Stingrai's Penetration Testing Price Index 2026 and the published tester-day counts in the cost per hour guide, converted at Federal Reserve H.10 rates observed 11 September 2026, a patient portal test at 3 to 5 days derives to US$4,057 to US$6,762 (C$5,625 to C$9,375), a larger internal network at 5 to 8 days to US$6,762 to US$10,819 (C$9,375 to C$15,000), and a full-scope assessment at 10 to 20 days to US$13,524 to US$27,048 (C$18,750 to C$37,500). An enterprise programme is several of those scopes in one year plus retests. Stingrai's published Autonomous package is US$3,000 one-time for one web application and associated APIs on the pricing page.
Does the penetration testing vendor need a business associate agreement?
If the engagement can expose the tester to ePHI, yes. A firm performing a function 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). Raise the BAA in the first scoping call, together with how evidence containing PHI is stored, redacted, retained and destroyed.
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. See our comparison of penetration testing and vulnerability assessment against what compliance frameworks require.
Related reading
Best Penetration Testing Companies for HIPAA and Healthcare (2026)
Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC (2026)
References
Office of the Federal Register. HIPAA Security Rule, 45 CFR Part 164 Subpart C. General rules 164.306, administrative safeguards 164.308, technical safeguards 164.312, organizational requirements 164.314, documentation 164.316.
HHS 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. 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 testing, scanning, audit and inventory requirements, the 2018 to 2023 breach growth figures, and the 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
Office of Information and Regulatory Affairs. Unified Agenda entry, RIN 0945-AA22. https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0945-AA22. Agenda stage long-term actions, final action timetable July 2027.
HHS Office for Civil Rights. HIPAA Security Rule NPRM Fact Sheet. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html
NIST. SP 800-66r2, Implementing the HIPAA Security Rule. February 2024. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-66r2.pdf
HHS Office for Civil Rights. Breach Portal. https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf
HIPAA Journal. Healthcare Data Breach Statistics. https://www.hipaajournal.com/healthcare-data-breach-statistics/. Compilation of OCR breach portal data, updated 8 September 2026 from an OCR pull dated 4 September 2026. Source of the 804 breaches and approximately 138.5 million individuals affected in calendar year 2025.
HHS Office for Civil Rights. Resolution Agreements and Civil Money Penalties. https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html
Government of Ontario. Personal Health Information Protection Act, 2004. https://www.ontario.ca/laws/statute/04p03. Section 12(1) reasonable steps.
Government of Canada. Personal Information Protection and Electronic Documents Act. https://laws-lois.justice.gc.ca/eng/acts/P-8.6/. Schedule 1, Principle 4.7 safeguards.
Board of Governors of the Federal Reserve System. H.10 Foreign Exchange Rates. Observation dated 11 September 2026. https://www.federalreserve.gov/releases/h10/current/
Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026
Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026
Stingrai. Penetration Testing Cost Per Hour and Day Rates (2026). https://www.stingrai.io/blog/penetration-testing-cost-per-hour-2026
Stingrai. Pricing. https://www.stingrai.io/pricing
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, as an annual engagement, a continuous programme, or both. 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 hospital estate or multi-application scope, or see the pricing page.


