Buying new software and systems for your healthcare enterprise can be a precarious endeavor. On the one hand, replacing an old system that is holding you back or purchasing new functionality that will increase efficiency is a promising and positive thing. On the other, selecting the wrong vendor could cause delays, setbacks and even security incidents. In this article, I will offer my empirical experience of the current state of the request for proposal (RFP) process with an eye on cybersecurity. I also offer seven concrete tips that will, I hope, make your RFP more successful.
Sectra is unique among vendors in that we are an international security and medical IT company, so secure data is at our core. We pride ourselves on knowing security, with a large part of our company selling solutions for secure communications to the most selective of customers, such as NATO. For the last 30 years, we have built software and systems for hospitals, so the intricacies and complexities of PACS are well known to us. Thus, we have united these two skill sets that are integral to today’s fast-moving and secure healthcare enterprise.
Responsibilities
So what is security in this context? One way of looking at it is security—and cybersecurity—consists of three parts. First, there’re product security, which is our—the vendor’s—responsibility. As a security architect, I make sure that the software we create is “secure by design.” This describes our ambition to ensure that all developers and testers are aware of and consider security in their daily work. If we can stick to that ambition as a vendor, we have a good chance of delivering very secure products and maintaining the trust that we have earned.
Second is deployment security. The most secure product in the world can be rendered useless from a security perspective if it is incorrectly installed and configured. Firewalls, proxies, hardening of servers, certificate management—the list goes on. This is a joint responsibility between the vendor and the customer. We enable secure deployment through our products and documentation, and together with customers we create best practices for secure deployment.
Our project engineers work closely with our customers to make sure our software and systems are secure and adapted to the environment and infrastructure they reside in.
Third is operational security. A system like PACS is a like a living thing, changing, evolving and must be, in cooperation with users, maintained and administrated. Passwords must exist, access and privileges must be given, and integration projects need to be carried out. Security patching must be done on a regular basis. This is primarily the customer’s responsibility. We—the vendors—are again the enablers but we do not run day-to-day operations.
For cloud and hybrid products, the last two areas are somewhat different since more of the responsibility is shifted to the vendor.
The RFP Process
So with our common understanding of context and language, let’s talk about the RFP process. Lately, we’ve seen the number of questions in RFPs related to cybersecurity increase tenfold. It went from being a side note to a deal-breaker in just a couple of years. This is a good thing; it shows that the healthcare business is catching up with the rest of the world. The downside is that when scrambling for a better security focus in proposals, one might be tempted to think that more questions, broader questions or even more strict requirements are the answer. A cynical person might even believe that there are consultancy firms out there profiting from selling question packs with promises of compliance and all-encompassing coverage.
I would argue that fewer cybersecurity questions are better as long as those questions are the right ones. What are we actually purchasing here? A secure system yes, but in fact, if the product is good, are we not shopping for a long-term partnership and trust? Establishing that one of the vendors is the best one for you—the customer—should be our goal.
To establish that, one of the most important factors is that healthcare leaders understand all the questions and see the need for each one. They should know what to look for in the answers, both good and bad responses, because there will be red flags in those answers.
Questions should be constructed so that they, when seen as a whole, paint a picture of the vendor’s security competence, capabilities and stance on developing secure software. How transparent the vendor is willing to be could be is a very important factor when you are signing a multi-year partnership.
Another drawback of overly strict or catch-all types of questions is that the vendors may be fatigued by the sheer number and scope of the questions. This might lead them to make assumptions as to what answers are expected or how others might answer the questions, rather than providing the most accurate depiction of the situation.
For all these reasons, fewer is better when it comes to questions on security, targeting areas that really show the security capabilities of a variety of vendors. Only use questions that you understand well and see a definitive need for. The RFP process is not an ISO certification audit; avoid noise.
