Reply in one business day
Thanks, we've received your message.
We'll be in touch shortly.
When you need it
The situations that bring teams to this engagement, and where it fits alongside the rest of your program.
The requirement
Requires a risk analysis (§164.308(a)(1)(ii)(A)), a periodic technical and nontechnical evaluation of safeguards (§164.308(a)(8)), and the technical safeguards of §164.312: access control, audit controls, integrity, authentication, and transmission security. It does not name a testing method. A penetration test is the accepted way to evidence the evaluation and to feed real findings into the risk analysis, and OCR resolution agreements routinely cite the absence of such testing.
In January 2025 HHS published a proposed rule to strengthen the Security Rule. Among other changes it would require penetration testing at least every twelve months and vulnerability scanning at least every six months for all systems that create, receive, maintain, or transmit ePHI, and it would remove the distinction between “required” and “addressable” safeguards. As of September 2026 the rule is still proposed, not final, with final action targeted for 2027, and the details may change. Organizations that adopt the proposed cadence now are simply doing what the current rule already treats as reasonable.
The proposal is not law yet, so plan around the current rule and budget for the proposed cadence: one penetration test a year and a vulnerability scan every six months. Our guide to HIPAA penetration testing requirements tracks the rule section by section, and our HIPAA compliance checklist covers the rest of the Security Rule.
How they fit
The risk analysis is the document OCR asks for first in every investigation. It inventories where ePHI lives, identifies threats and vulnerabilities, and rates the risk. A penetration test is the strongest input it can have: instead of estimating whether a patient portal could expose records, the test shows whether it did, with evidence. The findings become the vulnerabilities in the analysis, the exploited paths become the likelihood ratings, and the retest becomes the record of remediation. We write the report so it drops into that structure, and our security risk assessment guide shows where each piece lands.
What we assess
We test the systems that actually touch ePHI and map every finding to the HIPAA Security Rule, giving your compliance officer evidence, not a generic scan.
Technical safeguards controlling who can reach electronic PHI and how.
We test for
How ePHI is protected as it moves across and rests within your systems.
We test for
Whether activity on systems holding ePHI is logged and data is protected from tampering.
We test for
The applications and infrastructure that store, process, or transmit ePHI.
We test for
Scope
Penetration testing for healthcare starts with one question: where does electronic protected health information live, move, and rest? For most healthcare organizations that means five groups of systems.
The EHR or EMR platform, PACS and imaging, laboratory systems, and the interfaces between them. HL7 v2 interfaces were designed for trusted internal networks and often carry no authentication or encryption; FHIR APIs bring standard API risks, such as broken object-level authorization, to clinical data.
Portals, telehealth, scheduling, and payment flows. Internet-facing, handling ePHI, and usually the highest-value target in a healthcare estate. Tested as web, mobile, and API engagements.
The internal network, segmentation between clinical and corporate VLANs, Active Directory, remote access, and the cloud environments hosting any of the above.
Anything a vendor operates on your behalf that touches ePHI. Their systems cannot be tested without written authorization, but their exposure is your regulatory problem, which is why BAAs and vendor assessments matter.
Infusion pumps, monitors, and imaging equipment. Tested as a separate hardware engagement with clinical safety rules, never during patient use.
Patient safety
A test that degrades a clinical system is not an inconvenience, it is a patient-safety incident. Healthcare engagements manage that risk explicitly, and a firm that will not discuss these rules in detail during scoping has not tested healthcare environments before.
Typical findings
Across healthcare engagements the recurring themes are consistent, and most of them are a HIPAA breach in a single request or a single phished workstation.
Who is covered
Providers, health plans, and clearinghouses. Scope typically centers on the EHR and its integrations, patient portals, clinical and billing applications, the internal network that connects them, and the perimeter around it all. Testing is mapped to the technical safeguards and to your risk analysis. New York general hospitals also answer to 10 NYCRR 405.46, which requires an annual penetration test.
Health-tech vendors, billing companies, cloud hosts, and anyone else handling ePHI on a covered entity’s behalf. Directly liable under the Security Rule since HITECH, and increasingly required by BAA language to show independent testing. Scope is the product and infrastructure that touch the customer’s ePHI, and the report is written to satisfy the customer’s security review as well as your own program. When a health-system customer asks for HITRUST instead, see HITRUST penetration testing.
Manufacturers are usually not covered entities, but hospitals ask for device testing evidence during procurement and FDA premarket cybersecurity guidance expects it. Devices are tested as a separate hardware engagement, from $5,200. Our guide to medical device penetration testing covers how to test safely.
Healthcare threats
Healthcare has carried the highest breach costs of any industry in IBM’s annual study for over a decade. These are the attack paths behind those numbers, and the tests that cover them.
Most healthcare ransomware starts with one compromised workstation or vendor connection and spreads through a flat clinical network. An internal penetration test shows how far it would get and whether segmentation around clinical systems holds, and a ransomware readiness assessment adds whether backups could be reached and recovery would work.
Authorization flaws that let one patient see another’s records are the most common finding in the applications we test. Web application and mobile testing covers the portal, the app, and the APIs behind them.
Infusion pumps, imaging equipment, and monitoring devices carry firmware and network interfaces nobody patches. Hardware and IoT testing covers the device; the internal test covers the network it sits on.
HL7, FHIR, and vendor APIs move ePHI between systems constantly. API penetration testing checks the authentication and authorization on every interface, including the ones partners use.
Methodology
Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.
These are the phases your compliance test runs through.
The systems your framework actually covers, and nothing you would pay to test twice.
The component penetration tests run to PTES and OWASP standards by senior testers.
Every finding tied to the requirement or control it evidences.
Evidence formatted the way your assessor, examiner, or QSA expects to read it.
A free retest so the audit shows closed findings, not open ones.
How it works
From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.
Scope ePHI
We identify the systems that store, process, or transmit electronic PHI.
Test safeguards
We test access, transmission, and audit controls against the Security Rule.
Mapped report
Findings mapped to the Security Rule as evidence for your compliance team.
Fix & retest
Fix the findings, then a free retest that strengthens your risk analysis.
Component tests
Compliance testing is built from our standard fixed-scope engagements. Each one is scoped to your boundary and reported against the framework.
Proof
Every engagement is confidential, so the work below is anonymized to sector and engagement type.
Free
Retest on every penetration test
185+
Years combined experience
14
Senior in-house specialists
24h
Onboarding after signing
Healthcare · Imaging
Organization-Wide Phishing Simulation
Over half the workforce took the bait: roughly a third clicked the link and a quarter entered their credentials on the simulated capture page.
Outcome. Quantified credential-compromise risk across the whole organization and delivered a prioritized program of role-targeted awareness training, recurring simulations, and a faster, simpler reporting workflow.
11,800+
Employees targeted
53%
Phish-prone
24%
Entered credentials
Fintech · Payments
Web Application Penetration Test
Critical: a remote code execution flaw in the application’s web framework that could have given an attacker full control of the server. We escalated it to the development team while the test was still running.
Outcome. The critical RCE was reported and remediated during the engagement via an emergency framework upgrade, which also closed the server-side request forgery, and the remaining findings were retested to confirmation.
1
Critical (RCE)
Mid-test
Critical remediated
2
High
Resources
HIPAA Penetration Testing Requirements: What the Security Rule Requires Now and What Is Proposed
HIPAA penetration testing requirements: what the Security Rule requires today, the proposed annual test and six-month scans, what OCR penalizes, how to scope.
HIPAA Compliance Checklist: Security Rule Requirements, Privacy and Breach Notification (2026)
A 2026 HIPAA compliance checklist: each Security Rule safeguard marked required or addressable, Privacy and Breach Notification items, and evidence to keep.
HIPAA Security Rule Technical Safeguards: What §164.312 Requires in Practice
HIPAA Security Rule technical safeguards in 45 CFR 164.312: access control, audit, integrity, authentication and transmission, and what a test evidences.
Want to see a report first?
Read a sample report for a fictional client, or request a redacted one from a real engagement. Our guide explains what a penetration testing report should contain.
Under the current Security Rule, no method is prescribed: it requires a risk analysis (§164.308(a)(1)(ii)(A)) and a periodic technical evaluation of your safeguards (§164.308(a)(8)), and a penetration test is the most widely accepted way to evidence both. A proposed update to the Security Rule, published in January 2025 and not yet final, would make annual penetration testing and vulnerability scanning every six months explicit requirements for covered entities and business associates.
The systems that store, process, or transmit electronic PHI, including in-scope applications, infrastructure, and business associate environments where applicable. We confirm scope with you before testing.
Yes. Business associates are directly subject to the HIPAA Security Rule and must protect the ePHI they handle on behalf of covered entities, and your customers increasingly require evidence of testing in their business associate agreements. We scope the test to the systems where you store or process their ePHI.
Yes. We map findings to the Security Rule's technical safeguards and provide documentation your compliance officer can use to support the required risk analysis.
A HIPAA test is scoped to the systems that handle ePHI, usually a web application and/or network test (from $5,200 and $4,200), quoted as a fixed price after scoping, with a free retest. Starting prices for every service are on our pricing page.
Annually at a minimum, and after any significant change to the systems that handle ePHI: a new patient portal, an EHR migration, a new business associate integration, or a cloud move. That cadence matches what OCR investigators treat as reasonable today and what the proposed Security Rule update would make explicit. Many covered entities pair the annual test with vulnerability scanning every six months, which is the other cadence the proposal names.
No. The proposal treats scanning and penetration testing as separate requirements on separate cadences: automated vulnerability scans at least every six months and a penetration test at least every twelve months. Scans find known weaknesses; the penetration test proves which ones expose ePHI. Our vulnerability scanning service covers the first, and it is included in a testing program alongside the annual test.
Four things, whatever the rule’s wording: scope that follows the ePHI (every system that creates, receives, maintains, or transmits it, including business associate connections), a test that does not endanger care delivery, findings that feed the risk analysis with evidence rather than assumptions, and a record that remediation was verified. Auditors, OCR investigators, cyber insurers, and hospital procurement teams all look for the same four, and the report is built around them.
Raise it during scoping. Any tester who may be exposed to ePHI while testing a live system should be covered by a BAA, and the engagement agreement sets out how test data and any incidental ePHI are handled, stored encrypted, and destroyed. Where a staging environment with synthetic data is available, we test there instead and the exposure question does not arise. Our list of healthcare penetration testing companies covers the other questions to ask any vendor.
Yes, as a separate scope. Infusion pumps, imaging equipment, and monitoring devices are tested as hardware and IoT engagements: firmware, hardware interfaces, wireless protocols, and the device’s backend communications, never fuzzed while attached to a patient. FDA premarket cybersecurity guidance expects manufacturers to show this kind of testing, and health systems increasingly ask for it during procurement. Our guide to medical device penetration testing covers how to do it safely.
Talk to our team about what your HIPAA compliance requires.
Prefer the full scoping questionnaire?Tell us what you need tested. We reply within one business day.
Thanks, we've received your message.
We'll be in touch shortly.
