A planning guide for healthcare security teams covering everything from goals and objectives to rules of engagement.
I’m sure everybody knows this, but you don’t just start hacking, right? You have to figure out how to do this safely. A hospital penetration test is significantly different from how you’d conduct a test in a traditional enterprise environment. Significantly different.
Over 16-plus years of testing hospital environments, I’ve seen many recurring trends — both in where security deficiencies occur and where engagements go wrong before testing even begins. The planning phase is where most of the mistakes happen. This post covers how we approach it and why each decision matters more in a clinical environment than anywhere else.
“We need a penetration test for compliance” — that’s something I hear a lot. But that’s not a goal. That’s a procurement trigger. Generally speaking, what I hope a goal is, is having a realistic picture of how a threat actor sees your environment. Where’s the risk that you need to be aware of? What do you need to remediate, monitor, or at least acknowledge and understand? Because the worst time to find out if you have a huge risk is during an actual incident.
What we like to know is: what are your fears? What are the things that keep you up at night? That’s going to drive and help maximize your return on investment for the engagement.
Common fears we hear from hospital security teams:
Each of those drives different test cases. Write them down. They form the basis of the Rules of Engagement and determine how findings get prioritized in the final report.
A lot of that stuff — you don’t want to find out you had a huge risk during an incident. That’s the worst time to find out. That’s what a well-scoped penetration test is designed to prevent.”
On the compliance angle
If your organization is preparing for the proposed HIPAA annual penetration testing requirement under 45 CFR 164.312(h)(2)(iii), getting the scope right from the start is especially important. We cover what the proposed rule actually requires, the specific timelines, and how to prepare in detail in: HIPAA Annual Pentest Rule: What Healthcare Organizations Must Do Now — breakpoint-labs.com/hipaa-annual-pentest-rule
What makes hospitals fundamentally different to test isn’t complexity. It’s consequence. Three things stand out.
Clinical systems can’t absorb disruption
When you go against life-supporting technology, you don’t want to overload it and cause an impact. You want to be nice and slow. A lot of the stuff we do in medical environments is manual — we’re not launching a tool at clinical devices, because launching a tool at one could cause negative impact. Ventilators, infusion pumps, patient monitoring systems — these aren’t enterprise servers. In a hospital, a test failure isn’t a failed test. It’s a patient safety incident.
The environment is public-facing by design
Hospitals let the public in. That’s not a security failure — it’s the nature of healthcare. But it creates physical attack surface that most organizations never deal with: waiting rooms with active network ports, construction zones that bypass access controls, service hallways connecting secure and public areas. A thorough hospital engagement accounts for all of this.
Corporate entity risk is often completely invisible
A lot of hospitals are part of larger health systems where a corporate entity manages Active Directory, identity infrastructure, and security controls across multiple facilities. The controls might be inherited from that corporate entity — and you inherit all their risks as well.
I had an environment once where I started working with a single hospital. During the planning phase, we realized all their controls were at the corporate entity level. We recommended testing the corporate entity too, and they got them involved. When I compromised the corporate entity, I had domain admin access across all 12 hospitals in the network. Same flaws for all of them. It’s pretty scary — I actually could have put ransomware at every single one of them. And nobody knew that risk existed.
So before you scope anything: is this facility part of a larger health system? If so, that completely changes the question of where the security perimeter actually sits.
If your hospital is part of a larger health system, you inherit the corporate entity’s risks whether or not they’re in scope. That’s a conversation worth having before testing begins.
This is another area where you see a lot of assumptions made, right? If you think “somebody’s going to hack me,” you’ll think: come in from the internet, break in through an application, phish someone, land on their box — do it as realistic as possible, like the bad guy would.
There are benefits to that. There are also risks. When you force a team to come in through an operational application, or impact a user by coming in through phishing, you’re adding additional risk to the project. And when you talk about a life-supporting environment, you usually want to reduce risk as much as possible.
What we find — the best approach for hospitals — is to do an assumed breach scenario. You still test for all the ways someone could get into the network. You still identify that risk. But you don’t require the testing team to push through those areas to test the inside. The assumed breach scenario is essentially saying: we’re going to assume a breach happened, we’re going to establish internal testing infrastructure for the testing team, and this removes the risk of having to come in through an operational application or compromising a user who’s actively caring for patients.
You still get the benefit of understanding how somebody would break in. But you’re not relying on the team to push through those holes. For hospitals that haven’t done a penetration test before, this is almost always the right starting point.
You want to define the scope — essentially, what’s going to be tested and how the testing’s going to occur. Is this just an external penetration test, or is it also internal? Is wireless in scope? Is physical in scope? These are all things to hammer out based on the goals and objectives.
External, internal, or both
External evaluates what’s accessible from the internet. Internal evaluates what an attacker can do once they’re on the network. Most hospital engagements benefit from both, but for a first engagement using the assumed breach approach, internal testing typically produces more actionable findings.
Wireless
Hospital wireless is layered — guest networks, clinical device networks, staff networks — often connected in ways that aren’t fully documented. Scope wireless explicitly and handle it with care around devices that rely on wireless connectivity for patient monitoring.
Physical security
Physical testing needs explicit agreement before anyone shows up on site. If the goal is to understand whether someone can walk in, find an unlocked network port, and access the internal network — that’s a legitimate and valuable test case. Without locking down those ports in public areas, an attacker can plug into the wall, circumvent all the external controls, and land on the internal network. Doesn’t require a sophisticated exploit. Just access. Scope physical separately from the technical work and give it dedicated planning time.
Web applications
Patient portals, EHR interfaces, billing platforms, scheduling systems — these are high-value targets and a completely different discipline from network penetration testing. Scope web application testing as its own workstream with dedicated time and its own findings.
Critical and life-supporting systems
You’ve got critical systems on the network. I don’t suggest completely ignoring them — but you may go about it very differently. You can discuss potentially cloning them into development environments, or doing just sort of a white-glove review alongside the sysadmin for that system. You still could look at it, you just may address it very differently. Whatever approach you agree on, document it in the Rules of Engagement before anyone gets near anything life-supporting.
It’s pretty standard in the industry to say “do a pen test in a week.” And that’s not the right approach for hospitals.
Because you have life-supporting systems, and if you try to push everything into a week, you’re going to really increase your risk of negative system impact. Or just miss a lot of stuff.
Our suggested approach, working with hospitals, is to have it a little more drawn out. Now, it doesn’t mean you’re billing for full-time efforts — 4 to 6 weeks isn’t going to map to that much of a cost increase — but it allows things to happen slower, more methodical. That’s important when you’re going against life-supporting technology.
“It’s pretty standard to say ‘do a pen test in a week.’ That’s not the right approach for hospitals. If you try to push everything into a week, you’re going to really increase your risk of negative system impact. Or just miss a lot of stuff.”
A typical hospital engagement timeline:
This is very important to discuss ahead of time, because it’s a common assumption made on either side — either the hospital has an assumption, the testing company has an assumption, and nobody surfaces it until mid-engagement.
Penetration tests, by their nature, are not designed to be stealthy. They’re designed to be efficient and find the maximum number of vulnerabilities. When you talk about being stealthy to avoid detection, that usually falls into what’s called a red team.
I’ve seen this happen all too many times: you do the engagement, and you get some lower-level IT folks involved who say “well, we detected you — so that’s not real risk, because we caught you.” But was detection avoidance even part of the planning? If it wasn’t, I would have done the engagement entirely differently. The way you go about the test if detection is a goal is very, very different. Night and day difference.
What we usually do is a hybrid approach. We go through the engagement like normal, finish it, and in the last few days we go through and emulate stealthy attacker techniques and map it back to the MITRE ATT&CK framework with timestamps. Then we work with you to see which of those you detected and where you didn’t. You still get the benefit of detection-avoidance testing, but you don’t have to pay the full cost of a red team engagement.
Which, by the way, if you’ve never done a penetration test before, doing a red team is going to add limited value. You’re better off getting a pen test first, doing some remediation, and then running a full-blown red team engagement. We’ve written more about how red team assessments differ from penetration tests and when each is the right choice here: Red Team Assessments: A Strategic Approach to Cyber Defense.
All of this gets put into a master document called the Rules of Engagement. This is going to codify everything about the test — how it will be performed, the scope, what’s allowed, and what’s not. Everything kind of scopes and frames the entire assessment in that document. Everybody agrees on it, signs off on it — the stakeholders — so everybody’s on the same page. We try to remove all those assumptions that are maybe baked in, so we can get everyone aligned before testing starts.
Communication plan
Define your communication plan. That’s also very important — you want to understand what the cadence of communication looks like. Usually it’s a weekly thing. What we do is have a weekly sync, a weekly touchpoint. Friday is usually a good day — people’s schedules are a little slower. But that’s all individual to you. I’ve had some customers who want to do a daily touchpoint in the morning and even before we end the day. It all depends on what works best for your environment.
De-confliction contacts
Establish trusted points of contact for de-confliction. When you have an engagement going on, you might notice somebody calling in because an application’s running slow — and you’re immediately going to wonder if the testing team is responsible. You want to make sure you have those trusted contacts to reach out to, so they can say “we’re not even looking at that, it’s not us” or “that is us, we’ll stop testing.” That de-confliction process matters on both sides.
It’s important for the testing team as well, because if they find something critical — especially on an internet-facing asset — they’re going to want to reach out immediately and maybe start remediation before the test is done. Because if it’s on the internet, a threat actor could see it, and you want to address that sooner than a couple weeks out.
Approved testing infrastructure
Discuss your approved testing infrastructure. The testing team will deploy internal access points, command-and-control servers, and test accounts to support the engagement. All of it needs to be documented and agreed upon in advance. Your security team needs to know what belongs to the testing team and what’s unauthorized activity — especially once alerts start firing.
There are a lot of important people that generally need to be involved, and getting them in early might add some delays — but you don’t rush this part. You take it slow and figure out how to set things up. The planning phase should include:
These groups don’t all need to meet together. What matters is that each one gets briefed, can raise concerns, and is included in the Rules of Engagement before testing starts. The stakeholder who surfaces a concern mid-engagement is always more disruptive than the one who raises it during planning.
There’s a lot of planning that should go into place to make sure you’re doing this safely. The decisions made before testing begins determine whether the engagement finds what it needs to find, whether it does so safely, and whether the findings are specific enough to act on.
If you’re planning your first hospital security engagement — or evaluating whether a previous one was scoped correctly — a good starting point is understanding what your environment looks like from the outside before committing to a full internal test.
We offer a complimentary External Attack Surface Report that shows exactly what a threat actor sees when they look at your organization: exposed assets, breach data, email security configuration, and external footprint. No network access required, no disruption to operations. It removes the guesswork from the first scoping conversation.
Reach out to request yours, or check out the related posts below for more on the technical side of hospital security testing.
The goal is to get a realistic picture of how a threat actor sees your environment, identifying the risks that need to be remediated, monitored, or acknowledged. A well-scoped test is designed to prevent finding out about a huge risk during an actual incident.
A hospital penetration test is significantly different because of the potential for “consequence”. Clinical systems, such as infusion pumps and ventilators, cannot absorb disruption, meaning a test failure could become a patient safety incident. Additionally, hospitals are public-facing by design, creating unique physical attack surfaces.
The recommended approach for hospitals, especially for a first test, is the Assumed Breach Scenario. This involves establishing internal testing infrastructure, which removes the risk of impacting an operational application or a user who is actively caring for patients.
If a hospital is part of a larger health system, it inherits the corporate entity’s risks, as security controls like Active Directory are often managed at that level. Before scoping, it’s essential to determine where the security perimeter sits and consider testing the corporate entity.
Penetration tests are not inherently stealthy; they are designed to find the maximum number of vulnerabilities efficiently. Stealthy testing is usually characteristic of a Red Team engagement. A beneficial hybrid approach is to run the penetration test normally, then, in the final days, emulate stealthy attacker techniques, map them to the MITRE ATT&CK framework, and check which were detected.
The standard one-week industry timeline is generally not recommended for hospitals. The suggested timeline for active testing is four to six weeks to ensure a slower, more methodical approach that reduces the risk of negative system impact on life-supporting technology.
The Rules of Engagement is a master document that codifies how the test will be performed, the scope, and what is allowed. Key elements to include are a defined communication plan (e.g., a weekly sync), establishing de-confliction contacts to quickly address anomalies, and documenting the approved testing infrastructure such as internal access points and test accounts.
Andrew McNicol is the Chief Technology Officer and a co-founder of BreakPoint Labs, where he oversees the company’s technical strategy and manages the Cybersecurity Assessments line of business. He is a recognized expert in adversarial penetration testing, with more than 16 years of experience leading numerous technical teams on red team operations, vulnerability assessments, and penetration testing engagements to achieve each client’s specific objectives. Andrew holds numerous professional certifications and is a frequent speaker at government and industry security forums.
