How to scope a healthcare penetration test

Start with the journey

Map a patient registering, receiving a referral, viewing a result and delegating access. For each step, record the application, identity, organisation boundary and downstream processor. This exposes hand-offs that disappear in a simple list of web addresses. Include staff and supplier workflows as well as the patient-facing interface.

Prepare identities and data

Create synthetic patients, a proxy relationship, clinician roles and at least two organisations when the service is multi-tenant. Assign expected permissions before the test. The tester needs both positive and negative cases: an authorised record read and a denied read of a different patient’s object.

Turn the map into permission

List systems the organisation can authorise, systems requiring supplier consent, test windows and prohibited operations. Define who can pause activity when a care workflow slows or unexpected health information appears. Keep a route for urgent clinical escalation that works independently of the systems being tested.

Ask for a coverage record

The final report should state the roles, workflows and interfaces actually exercised, plus exclusions and blocked paths. Compare this with the original scope. Untested integrations and incomplete test accounts are residual coverage gaps, not silent passes. A useful proposal makes these dependencies visible before work starts.

Turn a patient journey into a testable boundary

Consider an illustrative referral journey: a patient submits information through a portal, a scheduling service creates an appointment and a clinician retrieves the referral through an integration. The scope should identify who can create, read, change and export each synthetic record at each step. Include the background identity that moves the referral between services. A test limited to the portal login would say little about a message delivered to the wrong organisation or an export retained after the user's access changes.

Use a short workshop with clinical operations, application owners and infrastructure staff to reconcile the diagram with actual service behaviour. Ask which actions generate external notifications or change a clinical queue. Those side effects help determine whether a representative test environment is sufficient or whether a tightly bounded production check is needed.

Separate access checks from disruption tests

Write down the evidence needed before choosing a technique. Reading a designated synthetic referral may establish an authorisation failure without querying real patient files. A controlled connection to an agreed endpoint can demonstrate a network path without scanning every medical device on that segment. Explicitly exclude load generation, destructive changes and interaction with clinical devices unless separately assessed and authorised. Define who can stop activity and how testers verify that the stop instruction reached the delivery team.

Hospital estates add further dependencies: wards, imaging services and medical engineering may all own different parts of the same route. The hospital testing rules of engagement guide explains how to make these operational permissions usable during execution.

Make the final coverage decision visible

Before the start date, produce a coverage table with the journey, system, principal, expected decision, permission owner and evidence method. Flag missing accounts or supplier approvals as gaps, not administrative notes. At reporting, distinguish a completed test from a blocked or excluded test; neither silence nor an empty findings list proves that the boundary worked. Where a healthcare platform serves several organisations, borrow the controlled comparison approach in our API tenant isolation testing guide: hold the operation constant and change only the permitted ownership relationship.

The commissioning team can then decide whether the remaining uncertainty is acceptable, requires a follow-up window or needs a compensating review. This is a much stronger procurement outcome than an unexplained count of tested IP addresses.

Put the guidance to work

Use the readiness checklist to document assumptions, or inspect the fictional Healthcare AG report for evidence and treatment-plan examples. Contact Atlant Security with a non-sensitive description of your scope.