5 Questions to Ask When Adopting a New SaaS Tool
Let’s face it – often, the best developers are lazy! Because if you’re lazy (and smart), you’ll write code and adopt tools that will make your life easier. We hate the “NIH (not invented here) syndrome” — which can be defined as a tendency for people and organizations to avoid things that they didn’t create themselves — because, let’s be real, if someone already wrote a library or a tool that will help me out, I’m definitely not going to write it on my own. However, we’re also advocates against the “NDH (not deployed here) syndrome.” If someone has already deployed and is maintaining a tool that I want to use, then let me subscribe and start using it. Bring on your SaaS!
That said, adopting a new SaaS tool, especially if it will have access to your company’s or customers’ data, can sometimes be a risky decision. That’s why, when we adopt a new SaaS tool, we try to ask ourselves the following five questions. Hopefully, they’ll help you to fearlessly adopt new SaaS tools.
What data will the SaaS tool have access to?
Usually the most precious and important thing in a company (other than the employees, of course) is data. Adopting a new tool will usually involve giving that tool access to your company’s and customers’ data. To understand the risk involved in giving access to your data to a third party, you must categorize your data into two components: sensitive data and insensitive data. For the most part, your customers’ data is sensitive; whatever the type – private information, health information, financial information. This must be guarded at all costs. Your customer may be happy that you’re using a new SaaS analytics tool, but it can’t be at the expense of their privacy. Make sure that your new tool will allow you to control the data flow, redact sensitive data and explore any risk mitigation efforts the vendor is using.
What sort of access will the tool have to my company’s IP?
As a software company, our intellectual property (IP) is our company’s source code. Many SaaS tools require access to your source code. Your source code is already – hopefully – hosted in a secure source code management (SCM) system, and you want to keep it that way. First and foremost, ask yourself, is my source code really a secret?
In modern languages, it is quite difficult to enforce code secrecy. For example, if your product is a Node.js module, then it is already public due to the nature of the language. Everybody already knows about it, and has read-level access to it. If this is the case, go wild. If the tool also requires write access to your SCM, make sure that you already have high standards of enforcement on your source code life cycle, so that the SaaS tool can’t cause damage. Think of it this way: none of your developers should be able to alter your code without peer review and proper CI, and neither should a third party tool. An unauthorized source code alteration can be a major risk, and could even become an attack vector against your company or your customers, so it’s in your best interest to make sure that all your bolts are tightened, so to speak. When you do allow access, make sure that, if needed, you’ll be able to revoke it.
What sort of compliance does the SaaS tool have?
It’s imperative to understand the risk involved with the access you give to the SaaS tool. Why don’t you simply ask what certificates it has and compliance standards it must adhere to? For example, when you take medicine, you don’t have to perform your own due diligence and risk management assessment for it, because regulators (such as the FDA) already certified and approved it, which ensures that the medicine is safe. That’s how compliance and certification works; the industry has very strict standards and regulations.
Standards such as SOC 2, ISO 27001, and even HIPAA make sure that the vendor you are working with has the highest security and compliance standards. They are audited by a third party annually, which ensures you don’t have to ask all the questions they’ve already asked. Now, that said, simply saying “We’re SOC 2 compliant!” doesn’t mean that you shouldn’t ask vendors the proper questions, but it does mean that someone else already has. Additionally, you need to remember that if you are compliant or certified with one of those standards, and your customers rely on that, then you need to make sure that your vendors – and SaaS tools – comply with the same standards.
Does the SaaS tool have any partial on-premises offering?
The scariest thing about using a SaaS tool is the fact that the data (note: your data) is stored somewhere outside of your control. Someone else is maintaining it, allowing access to it, auditing it and liable to it. The amazing part is that you aren’t responsible for the maintenance and scale. But what if you’re worried about the data itself?
Many SaaS tools offer a partial on-premises solution, allowing you to offload most of the headaches (maintenance, software upgrades, scale, etc.) while taking advantage of the ability to control security of the most sensitive data. Don’t deploy anything you’re not comfortable with! Look for SaaS solutions that offer at least partial on-premises solutions for the data over which you want to retain control.
Will this be the only tool of its kind I will need?
Too many vendors, and too many SaaS tools, can create a bit of a mess. Your security is only as strong as your weakest link, so the more SaaS tools that you have, the more potential weak links (or leaks) exist for you to manage. Now, I’m not saying that you must use only one SaaS tool for everything. I’m all for using the best-of-breed tool for every task! Yet, when looking for the right tool for you, make sure that it addresses all your needs; you don’t want to add more tools later to accommodate what it lacks. For example, let’s say that you want to use a static application security testing (SAST) tool. Make sure to choose one that can scan all languages your company uses (or is planning to use), because there is simply no point in using a different vendor for every language. Besides security, your employees will also really appreciate it if they don’t have to learn to use multiple tools. Instead, they can learn, once, how to use one tool perfectly.
Using SaaS tools is amazing, when you think about it. Someone else did (and is still doing) the hard work of developing a great tool. But finding the perfect fit can be like finding the right partner: everyone prefers something different, and every pot has its lid. That’s why there are so many tools out there! But whatever you do, when you pick the right tool for you, make sure that you don’t compromise on security. Your customers depend on it, so make sure that you choose wisely and ask the right questions.
