Don't start with another tool. Start with what could actually halt your business.
After our webinar “The system belongs to the vendor. The risk stays with the facility,” one question kept running through my mind: was this material actually too simple?
We didn't show off any magic devices that solve security in one go, nor any tool that turns all indicators green immediately after deployment. Instead, we talked a lot about dependencies, access, privileges, business continuity, and what actually happens within an organization when one of its key systems stops working.
The more I think about it, the more convinced I am that this is exactly where most organizations should start.
Cybersecurity has an image problem
We like it when things look complicated. A dashboard full of alerts, a 24/7 SOC, an architecture with dozens of arrows, and names of technologies that half of the board doesn't understand, but which sound serious enough to secure a spot in the budget.
Risk analysis looks rather pale in comparison. Asking “what happens if the registration system is down tomorrow morning?” doesn't sound nearly as impressive as a brand-new security solution.
Yet, the answer to that first question can be far more consequential for your facility.
A facility doesn't operate simply because it has an IT system. It operates because a patient can register, the front desk can find their records, the doctor can perform their work, the laboratory can send the results, and the entire process runs without major disruptions.
Technology is running underneath it all. As long as it works, almost no one thinks about it. Only an outage truly reveals how closely the business process and the IT system are intertwined.
The system may belong to the vendor. The problem quickly becomes yours
This was essentially the core of the entire webinar.
We can use an external registration system, medical software, cloud services, apps, laboratories, or communication platforms. We might not own the infrastructure, have access to the code, or know exactly which servers host the service.
But when that service stops working, the patient doesn't call the system vendor. They call the facility.
The front desk cannot simply say that it is a vendor incident and therefore doesn't concern the facility. The problem very quickly becomes operational: someone cannot register, someone lacks access to necessary data, and employees don't know whether to wait, switch to manual operations, or inform patients about canceled appointments.
That is why it is so crucial not only to ask how to prevent incidents, but also what the organization will do if one of them inevitably occurs.
Where to start if you don't have a large security team?
Certainly not by purchasing another tool.
Initially, much more value can come from talking to the people who actually know the day-to-day operations of your organization. Not just IT, but also the reception desk, administration, finance teams, process owners, or managers of specific departments.
It is worth working together to identify which systems would actually halt operations if they were down for a few hours, which vendors your key processes depend on, and who has administrative access to critical environments. You also need to know what emergency operations look like, who contacts the vendor, how escalation works, and whether data remains after an incident to help determine what actually happened.
This isn't a full-blown risk analysis yet, but it is an excellent start. Such a conversation often reveals issues that previously remained hidden: the only contact to a vendor is a person who isn't always available, the emergency procedure exists but only the manager knows it, backups are created but no one has tested a restore in a long time, or an account created years ago still has extensive privileges.
And that is exactly when risk analysis stops being a dry document and becomes a practical conversation about how the organization truly operates.
A good risk analysis shouldn't end with a colorful spreadsheet
The term “risk analysis” itself sounds like something prepared solely for an auditor. Likelihood three, impact four, risk twelve, the cell changes color, and the topic is considered closed.
From a management perspective, however, the number 12 explains very little.
It is much more useful to ask what exactly will happen in our facility if a given scenario actually plays out. If the system is down in the morning, we need to know whether the front desk can still receive patients, what data they retain access to, how long the organization can function without the primary solution, and who makes the decision to switch to emergency mode.
This way, risk takes on a concrete meaning. It is no longer an abstract value, but an answer to the question of at what point a technical issue begins to impact operations, finances, quality of service, or the facility's reputation.
Next step: verify if our assumptions are true
And this is where technical testing comes in.
An organization might be convinced that its systems are properly segregated, the vendor's account has limited permissions, and the public application offers no path to more sensitive data. These assumptions may be true, but until they are verified, they remain just assumptions.
That is why a pentest delivers the greatest value when it isn't ordered simply to “do a pentest.” It is far more beneficial to ask a specific question: could compromising this application lead to patient data? Does an external vendor's account allow access deeper than we assumed? Or could an error in one system impact another, more critical process?
Then, the report is not just a list of vulnerabilities. It becomes a way to verify whether the scenarios discussed during the risk analysis are actually possible.
A business-aligned pentest offers more than a list of vulnerabilities
A technical report must contain information about vulnerabilities, their severity, and remediation steps. That is obvious. However, for an organization, it is often even more important to understand what someone could actually achieve by exploiting the discovered flaw.
If a tester accessed data they shouldn't have, we now have key insights into our actual level of protection. If they managed to pivot from one account to another system, we gain valuable information about privileges and architecture. If a vulnerability in a public-facing application allows someone to disrupt a critical business process, we have a concrete risk scenario ready to address.
And that is when it is worth doing more than just fixing the bug.
We need to consider whether such an incident would be detected, who would receive the alert, which account should be blocked, what data should be verified, and whether the organization could continue to operate while the issue is being resolved. In this way, a technical test begins to support not just application security, but the resilience of the entire process.
You don't have to test everything at once
One common mistake is the belief that a valuable pentest must immediately cover a massive portion of the organization. This isn't always practical or necessary.
If you are just starting to organize your security posture, it is better to choose a single process that has a real impact on your operations. This could be patient registration, the patient portal, a mobile app, an API, an admin panel, vendor access, laboratory integration, or the payment system.
Instead of trying to answer the overly broad question “are we secure?”, it is better to test what would have to happen for this specific process to stop working, or for someone to gain unauthorized access to data.
This scope provides a much more actionable answer, which can then be translated into concrete decisions for the organization.
What to do after the analysis and testing?
The most important thing is not to stop at the diagnosis.
Once we know where the vulnerabilities lie and which scenarios matter to the organization, we can select the right actions. In one case, it might mean restricting privileges or changing a configuration; in another, cleaning up vendor access, testing backup restoration, or improving segmentation.
Sometimes, the issue will turn out to be primarily organizational. In those cases, preparing an emergency procedure, identifying escalation contacts, updating vendor touchpoints, or establishing what information should be shared during an incident will bring greater value.
You might also discover a lack of monitoring or logs needed for subsequent analysis. Other times, the priority will be training employees so they know how to act during an outage.
There is no single answer for everyone. That is why a logical order matters: first, you need to know what you are concerned about and where the risks truly lie, and only then should you select the safeguards.
A large vendor doesn't relieve you of thinking about your own resilience
There is another trap in relationships with vendors.
The larger the company, the easier it is to assume that “they surely have this well secured.” Perhaps they do. However, the vendor's security and your organization's resilience are not the same thing.
A vendor may have highly secure infrastructure, yet we might still have overly broad permissions on our own account. They might hold certifications, follow strict procedures, and run a 24/7 SOC, while our front desk doesn't know how to work during a multi-hour outage. They might also restore the service within an agreed SLA that is reasonable from their perspective, but still causes a severe operational bottleneck for your facility.
That is why it is not enough to ask if the vendor is secure. You must understand how dependent your organization is on them and what happens on your side when things go wrong.
If I had to point to a first step
I wouldn't start by purchasing a tool or writing dozens of procedures.
I would take a single process that the organization absolutely cannot do without tomorrow morning, and break it down. I would check which systems are required, which people are involved, which vendors it depends on, where the data is stored, and which accounts or integrations hold the most weight.
Only then would I ask what could stop working and what the consequences would be. If the answer shows that the biggest unknown is technical, we can verify it with a pentest. If the issue is a missing procedure, we need to write it. If the greatest risk stems from the vendor relationship, we need to review the contract, scope of responsibility, and escalation paths.
This sequence is far more important than the number of tools you deploy.
Want to go through this in your facility?
For the webinar, we prepared a simple scorecard for healthcare facilities to help you navigate key questions regarding vendor dependencies, business continuity, and incident response. You can use it as a starting point for discussions within your organization.
Security doesn't begin with the question “what should we buy?”
A much better starting point is asking what can halt your operations, how much that scenario would hurt, and whether your people will know what to do when it happens.
Only on this basis can we have meaningful conversations about tools, procedures, pentests, monitoring, or vendor requirements.
Otherwise, it is very easy to spend a significant budget on security and still find yourself unprepared for an event that actually halts your business.
And that is perhaps the most important takeaway I wanted to share from our webinar.
You don't have to do everything at once. You just need to know where to start.