Healthcare Penetration Testing: Scoping Around Clinical Uptime

Healthcare penetration testing goes wrong for reasons that have nothing to do with technical skill.

Somebody runs a discovery sweep across a flat clinical VLAN at 2pm on a Tuesday, an imaging workstation stops responding, and a nurse manager escalates to the CIO before anyone has read a single finding.

MSP Pentesting runs this work channel-only and under your brand, and the first artifact we ask for isn't the target list. It's the clinical schedule.

Get the biomed director's name during scoping, not during execution.

That one phone call has saved more healthcare engagements than any tooling decision we've ever made.

In a clinic or a hospital, availability isn't one third of a triad.

It's the job.

A stopped EHR is a canceled clinic day. A confused monitor is a patient safety event. Nobody in that building cares about your CVSS scores if the news arrives through an incident report.

What HIPAA actually requires, and what it doesn't

Get this right, because a lot of vendors don't and your clients have been burned by it.

The HIPAA Security Rule requires a risk analysis. It doesn't name penetration testing as a required control.

Anywhere.

If a competitor's proposal says HIPAA mandates an annual pentest, that proposal is wrong about today's rule, and your client who checks will stop trusting the rest of it.

That last row is the one you talk about, carefully. OCR published a Notice of Proposed Rulemaking in the Federal Register on January 6, 2025 that would rewrite large parts of the Security Rule.

• make almost every implementation specification required rather than addressable
• mandate MFA and encryption
• require an asset inventory and network map
• add scheduled vulnerability scanning and annual penetration testing

It hasn't been finalized. HHS said plainly that the current Security Rule stays in effect while the rulemaking runs, and the target date for a final rule has already slipped more than once. So don't sell it to your client as law. Sell it as a direction of travel, which it clearly is.

The honest pitch is simpler anyway. A risk analysis is required now. A test is one of the few ways to produce evidence about real vulnerabilities rather than assumed ones, which is exactly what a defensible HIPAA security risk assessment needs underneath it.

That argument holds whether or not the proposed rule ever lands, and it doesn't expire if the rulemaking stalls.

Three zones, three completely different rulebooks

Healthcare networks aren't one environment. Scope them as three, because the blast radius of your mistake is different in each.

Business IT

Email, file servers, finance, HR, the identity plane. Test this the way you'd test any other client. Full external assessment, internal testing, identity attack paths, phishing. There's nothing special here and it's usually where the initial foothold comes from.

You already know how to do this part.

Clinical IT

The EHR, PACS, the interface engine moving HL7 messages between lab, pharmacy and radiology, scheduling, transcription. These are ordinary servers and applications doing a job that stops the building when it fails. Test them, but inside agreed windows, with the application owner reachable and a rollback you both understand.

You don't pick the window here. Your client's schedule does.

Biomedical devices

Infusion pumps, patient monitors, imaging modalities, anesthesia machines, ventilators, lab analyzers.

Different rules entirely.

Three things will catch you out here, and none of them are technical problems.

Biomed, or clinical engineering, frequently reports to facilities rather than IT, so your client contact may have no authority over the equipment at all.

Many devices sit under manufacturer service agreements that restrict what can be installed or changed, and a credentialed scan or an agent can put your client crosswise with their support terms.

And device documentation varies wildly.

• kit submitted to the FDA since the 2023 change under section 524B of the Food, Drug, and Cosmetic Act arrives with a software bill of materials and a postmarket vulnerability plan
• the modality installed in 2013 arrives with nothing

So ask the age of every device before you quote.

Ask for the MDS2 forms, the industry-standard Manufacturer Disclosure Statement for Medical Device Security, before you touch anything. If they exist, they'll tell you more in an hour than scanning would in a day. If they don't exist, that absence is itself a finding and it's worth writing up in your report.

Rules of engagement that actually protect patients

Standard rules of engagement aren't enough here. Six additions, and we won't run a clinical engagement without them.

• A named clinical stop authority. A charge nurse, house supervisor or biomed lead who can halt everything in under a minute. A phone number the tester dials directly. Not a ticket queue, not an email address.
• Windows tied to the actual clinical calendar. An outpatient clinic has evenings. A hospital doesn't. Ask about EHR upgrade weekends, accreditation survey windows, month-end billing runs and seasonal clinics before you propose a date.
• No active work against device segments without biomed in the room. Not present on the bridge. In the room, watching the equipment.
• Passive discovery as the default on clinical VLANs. Span port capture and credentialed configuration review first. Active scanning only where somebody has confirmed what's on the other end.
• A written exclusion list with serials where possible. Vague exclusions like "all medical devices" fall apart the moment a device answers on a general-purpose subnet.
• A two-way emergency path. They can stop you, and you can reach clinical leadership immediately if you find something dangerous mid-test rather than sitting on it until the report.

Get all six into the statement of work before you send anybody on site.

Where these clients actually get hurt

Across the healthcare engagements we run behind partners, the same handful of paths keep showing up. None of them are exotic. You'll recognize most of them.

Remote access is first. Vendor support tunnels into the EHR or into imaging, VPN accounts without MFA, and long-lived credentials for a third party that hasn't touched the account in a year.

Then flat networks, where a compromised front-desk workstation can reach a modality on the same broadcast domain because segmenting it was scheduled for a project that never got funded.

Both of those are yours to fix.

Shared clinical logins come next, and they're the most defensible bad practice in the industry. Clinicians badge in and out of a workstation dozens of times a shift, so somebody built a workflow around a generic account.

It's a real operational constraint and a real attack path at the same time, and the fix is a session management tool, not a lecture.

Then third parties. Billing companies, transcription services, remote radiology reads, device vendors. Each one is a business associate, each one has access, and most of the contracts covering them were signed before anybody asked how that access actually works.

They're associates on paper and unmanaged doors in practice. You inherit both.

Notice how much of that list is yours. Identity, network segmentation, remote access, endpoint. If you're the MSP, you own most of the exposure, which is precisely why the testing has to come from somewhere else.

Run it under white-labeled penetration testing so the report carries your brand and none of your conflict.

Scoping and pricing without guessing

A three-provider clinic and a two-hospital system with an imaging center use the same words to ask for the same thing. They're not the same engagement. What actually drives your scope:

• Number of physical sites and whether they share an identity domain.
• Whether the EHR is vendor-hosted or on-premises, since hosted means somebody else's authorization process and a longer lead time.
• Whether biomedical devices are in scope, which is the single biggest swing factor.
• How many third-party interfaces exist and who owns each one.
• Whether the deliverable has to satisfy an insurer, an enterprise partner or an auditor, because that changes the report, not the testing.

Ask those five questions on your first call. After that, the number stops being a guess.

What hospital and clinic clients ask first

Does HIPAA require penetration testing?

Not today. The Security Rule requires a risk analysis under 164.308(a)(1)(ii)(A) and a periodic evaluation under 164.308(a)(8), and neither names penetration testing as a required control.

The proposed update published in January 2025 would require it at least every 12 months, but it isn't final and the current rule still governs. Testing is strongly advisable and it is not, right now, mandatory.

Is a HIPAA security risk assessment the same as a penetration test?

No, and clients conflate them constantly. The risk assessment is a documented, organization-wide analysis of risks to ePHI covering administrative, physical and technical safeguards. A penetration test is a technical exercise that proves specific attack paths.

The test feeds the assessment. It doesn't replace it, and a vendor selling one as the other is setting your client up for an uncomfortable conversation with OCR.

Will testing take clinical systems offline?

Not if you scope it properly. Your business IT gets tested normally. The clinical applications get tested in windows the clinic picks. Device segments go passive by default, with biomed in the room and a stop signal that works in under a minute.

If a tester won't work that way, don't put them on a hospital network.

Should medical devices be in scope at all?

Usually in a limited, careful form. Inventory them, review how they're segmented, check what remote access exists and how they authenticate. That answers most of the real risk.

Deep protocol work on live equipment belongs in a lab or a scheduled downtime window with the manufacturer looped in, not in an active clinical space.

Who has to sign off, IT or the clinical side?

Both, and get it in writing. IT authorizes the technical work. A clinical leader authorizes the risk to operations.

Engagements that only carry an IT signature are the ones that get halted on day two by somebody who never agreed to any of it, and that's the expensive kind of halt.

Get the biomed director on the scoping call

Healthcare is the largest vertical most MSPs already serve, and it's the one you're most nervous about testing. That nervousness is reasonable. It's solved by scoping, not by avoidance.

Split the environment into three zones. Give the clinical side a real veto. Be accurate about what HIPAA requires, because your credibility with a compliance officer is worth a lot more than a scary line in a proposal you can't defend.

Then give the tester the clinical calendar before you give them the target list.

Got a clinic or a hospital client and no clear idea where the clinical boundary sits? Get a pentest quote, then put the biomed lead on the call. We'll draw the line before anybody scans anything.