Why Security Should Carry More Weight When You're Choosing SaaS Tools

If you’ve ever weighed up whether or not you should adopt a new SaaS tool, you more than likely relied on a familiar decision framework. Does the tool do what it promises? Does it have the feature list we need? Does it fit within our budget? While these are all more than fair questions to ask, they don’t exactly paint the full picture of what it means to onboard a new SaaS tool.

When most teams evaluate new vendors, they may check whether they have a few compliance certificates and, maybe even, how they store data. But other than that, security isn’t given much of a thought. It’s just another box to tick.

When security is overlooked like this, you don’t get the chance to process how much risk your organization is taking on (and how unevenly this risk is spread across your SaaS stack. A study by the Cloud Security Alliance found that 65% of organizations have difficulty identifying and monitoring the risk of integrated third-party applications and misconfigured SaaS applications. Most of those organizations aren't irresponsible. They're just evaluating tools the same way they always have, while attackers have quietly moved on.

The Issue With The Shared Responsibility Model

When you sign your company up for a SaaS tool, it functions a little differently from traditional software. It's a shared security commitment, a division of labor for keeping data secure in transit and at rest. The vendor is responsible for the infrastructure and the application. You're responsible for how you configure the app, who uses it, and what data flows through it.

This arrangement sounds great and perfectly manageable on paper, that is, until you think about how many other SaaS applications your organization probably uses. If you work for an organization with more than 500 employees, you probably have hundreds of active applications to manage. Some of them you may not even be aware of. Each one brings its own universe of configurations, a separate set of access controls, and a completely separate set of potential exposure points.

This complexity is the exact reason SaaS security has become an entire discipline in its own right. This covers threats like account takeovers, data loss, phishing vectors, and shadow IT, which is the unauthorized applications employees use without IT approval.

Shadow IT alone creates a handful of glaring blind spots, since the tools are managed centrally and are usually not built to meet their organization's security requirements.

What Security Evaluation Looks Like

One of the main problems is that evaluating a vendor's security posture is not quick. Asking whether a vendor has SOC 2 compliance is not the finishing line some buyers want it to be. SOC 2 Type II compliance, Which evaluates a vendor's security systems over time is a deeper measure, but it still only tells a story of what the vendor manages on its side, including aspects of Cloud Security and even enhanced cybersecurity services. The more useful questions (when it comes to security) probe a little deeper.

• What happens to your data when you stop being a customer?
• Are security features like multifactor authentication (MFA) and single sign-on (SSO) available in the plan you want to buy, or are they only available at higher tiers?
• What happens if the vendor suffers from a data breach?
• Does the vendor have an incident response plan that clearly defines how and when they will inform you of a problem, or do they just have something vague in their terms of service?

Third-party risk is another question that tends to get overlooked. Most SaaS vendors don’t just live alone in siloes. They integrate with other services using APIs, and each of these connections extends your potential attack surface, many of which aren’t immediately obvious.
As they say, you’re only as strong as the weakest link in the chain. So keep in mind that a vendor who appears to have a solid security practice can still become a serious liability if they don’t vet their integrations with the same level of diligence.

The Cost of Getting It Wrong

Replacing a SaaS tool can get messy for many reasons. There is, of course, the direct cost of the migration. There is also the cost of productivity disruption and the risk of a compliance breach if the tool processes sensitive data.

There’s a trend, though, across all of these. Most companies only tend to consider these security issues once they are slapped in the face by them, not when you’re evaluating the tool. By then, the data has already been in the SaaS environment for months, the integration has become interleaved into the day-to-day, and it’s far too late to go back on this decision without facing real consequences.

People buy the tool and then find themselves switching not because the features aren’t up to scratch, but because the tool turns out to be a nightmare for governability, configurability, and compliance at scale. These are all things that should have surfaced during a more thorough evaluation.

Integrating Security into Your Evaluation Process

You shouldn't aim to turn every SaaS purchasing decision into a lengthy security review. It’s best to calibrate the level of scrutiny to suit the level of risk the vendor's tool might present to your organization.

Tools like project management software, used almost exclusively in-house, pose limited risk. Other tools, such as customer relationship management (CRM) and file-sharing tools that employees use to share files with colleagues outside the organization, are worth paying more attention to. In these cases, it's best to
invest more time in a structured review of how the vendor handles and governs data.

Another thing to do is define the criteria you will use to evaluate the software before you start talking to vendors. Security requirements will likely get deprioritized as you move through the vendor evaluation process, so try to keep the top of mind as you enter your search.

A few things to add to your evaluation of SaaS software vendors:

• Request that the vendor provide you with their most recent SOC 2 Type II report.
• Confirm that MFA and SSO are available on the plan that you are interested in purchasing.
• Ask the vendor about the data the software will store, where it will be stored, and for how long.
• Find out if the vendor has an incident response process in place.

Final Word

It's easy to view security-related concerns as somewhat frustrating (and maybe unnecessary) constraints on a purchasing decision. They slow the process down, add more questions, and create friction when dealing with vendors that want to make the sale as quickly as possible.

The companies that do this best see security differently. They treat it as part of the due diligence that goes into assessing each vendor's pricing and feature compatibility. It's not something that creates a barrier to adoption, but rather a standard part of any company's understanding of what they’re investing in and bringing into their tool portfolio. The ease with which one can add new SaaS tools is unquestionably a good thing. The downside is that it places the onus on buyers to understand and govern the technology. Knowing the vendor’s security is part of properly buying SaaS applications.