Healthcare Penetration Testing

The portal is where the public reaches your data, so it is where we spend the most time. We test whether a logged-in patient can read another patient’s results by changing an identifier, whether appointment history leaks through an API the front end no longer uses, and whether a password reset can be steered onto an account that is not yours.

Inside the EHR, the questions change. Can a receptionist role reach clinical notes meant for doctors? Does an exported report carry fields the interface hides? We check that the walls between roles hold under pressure, because insider misuse and a stolen staff login look identical to the record system.

Health data rarely lives in one place. HL7 v2 messages, FHIR APIs and older file-drop integrations stitch systems together, and each hop is a chance to inject, intercept or replay a message. We test these interfaces as an attacker who has reached the internal network would, not just from the front door.

We start by learning your estate. Using nmap for service discovery and Burp Suite to map every request the applications make, we build a picture of the attack surface: exposed hosts, forgotten subdomains, staging environments left reachable, and the APIs behind the mobile app. In healthcare this stage often turns up a test system loaded with real patient data, which is a finding on its own.

With credentials for each user role, we work through authentication, session handling and access control by hand. This is where the serious healthcare issues surface: broken object-level authorization on a records endpoint, a clinician role that can escalate to administrator, or a booking workflow that can be abused to enumerate every patient in the system.

A finding is only useful if we can show it is real. We safely demonstrate impact: retrieving a record we should never see, moving from a low-privilege account to a high one, or reaching an internal system through a server-side request forgery. We stop short of anything that touches patient safety or availability, and any intrusive step is agreed with you first.

You receive an executive summary written for the board and a technical report written for the people who will fix the issues. Each finding carries a CVSS score, the business impact in plain language, exact reproduction steps, and a prioritized fix. Once your team has worked through the list, we retest at no extra cost and confirm the holes are closed.

Insecure direct object references are the recurring healthcare finding. A record URL contains an identifier, the server trusts it, and changing the number returns someone else’s history. On patient portals this is the single fastest route to a mass data breach, and a scanner rarely proves it because it cannot tell one patient’s data from another.

Weak password reset flows, sessions that survive logout, and multi-factor authentication that can be skipped on the API while it is enforced on the web page. We test the auth path the way an attacker with one phished credential would, because that is how most real intrusions begin.

SSRF in an image importer or a document-conversion feature lets an attacker reach internal services from the outside, including cloud metadata endpoints. In hospital networks that are flatter than they should be, one SSRF can open a path to systems that were assumed to be private.

SQL injection still appears in older clinical software, and API endpoints frequently return more data than the front end displays. We check every parameter the application accepts, including the ones hidden in JSON bodies and in the FHIR and HL7 messages that flow behind the scenes.

We test whether the clinical VLAN is genuinely isolated from the corporate and guest networks, a control that PCI DSS and ISO 27001 both expect to be verified rather than assumed. Flat networks are common in healthcare because clinical uptime is prioritized over segmentation, and that trade-off is exactly what an attacker relies on.

Health data is special-category data under Article 9, and Article 32 requires security appropriate to the risk, including regular testing of technical measures. A documented penetration test is direct evidence you meet that duty, and it is one of the first things a data protection authority asks for after an incident.

ISO 27001 control A.12.6 covers technical vulnerability management, and our report supports your certification evidence. Hospitals and larger health providers increasingly fall under NIS2 as essential entities, and health-sector fintech or insurance arms may face DORA testing obligations. We align the deliverables to whichever regime applies.

If you serve US patients or partner with US providers, HIPAA’s Security Rule expects regular evaluation of technical safeguards. Our reports translate cleanly to that context, so a single engagement can support both your European and US obligations.