How To Assess Integration Security Risks When Evaluating SaaS Vendors

One of our top priorities since founding Merge has been ensuring that our integrations are as secure as possible.

With this goal in mind, we’ve built out several features, invested in certain infrastructure, and adopted specific policies that go beyond the industry’s highest standards of security and privacy for keeping customer data protected.

These experiences have also informed our approach for evaluating prospective SaaS vendors’ integrations, which is a key part of our criteria when gauging these vendors’ security risks.

I’ll break down this part of our security evaluation process in the hopes that it helps you add something similar to your company’s third-party risk management process.

Defining a Data Classification Framework and Taking Inventory of Our Data

In order to get a sense for the impact of these integrations as we onboard new vendors, we first needed to classify and inventory the data we have across our existing systems. Our security team built a data classification system that clearly lays out how sensitive different types of data are.

More specifically, they created four buckets, where each is associated with a certain type of data.

• Restricted: Includes data that will negatively impact both our business and that of our customers, such as integration credentials and integration data that’s in production

• Confidential: Comprised of data that would cause significant damage to our business if it were made public, such as internal strategy information or sensitive financial data

• Internal use: Any data that all of our full-time employees can access but can’t share externally, such as our employee handbook

• Public: Data that can be shared with anyone and is likely available online, such as our open roles

It’s worth noting that these buckets and their respective definitions can vary from company to company, as it depends on an organization’s risk tolerance, target industry, product and other factors.

After defining these buckets, our security team worked to create an inventory of data across the organization to track where each type of data is stored. Once done, they built an intake form for vendor submissions that took the whole picture into account when evaluating prospective vendors’ integrations.

Kicking Off the Vendor Review Process

As part of our vendor intake form, we ask the requestor to list any integrations they plan to build to the SaaS tool and the use cases associated with the integrations.

This information is combined with the information in our data inventory as well as the other information submitted by the requestor. Taking all of this together, the security team can determine an initial risk score for the vendor, which can inform the next steps in the process.

For instance, a vendor that only needs access to publicly-available data can be approved without further review. But if a vendor requires confidential data through integrations, our team will need to ask them questions around their policies for managing integration credentials and scopes (we’ll cover this further in the next section).

Working With Vendors To Review Potential Areas of Concern in Depth

Once the requestor’s intake form is completed and it’s determined that the vendor requires a security review, our team will send the vendor a security questionnaire.

Part of the questionnaire asks for specific details that help determine how they manage access to integration data and credentials. And since this information is often not included in the scope of security compliance frameworks or in more generic security documentation, it’s critical that they provide these details to us directly.

For example, the security team would dig into how a prospective vendor’s security policies apply to managing authentication credentials, such as API keys or OAuth tokens. This includes determining who within the vendor’s organization can actually access the authentication credential and how the vendor’s application stores and handles credentials (including logging and monitoring).

In addition, the security team ensures (often through follow-up questions for the vendor) that the scopes of the integration match the authorization granted to it. For instance, if a tool only needs access to the names of our employees but requests an API key or OAuth token with admin access to our HRIS system, we’d ask the vendor if their tool still functions if it’s granted a more limited scope.

Integration security is just one piece of the puzzle when determining how risky a SaaS vendor is for our business. We also need to determine whether they comply with certain security regulations (e.g., GDPR), pass particular audits (e.g., SOC 2 Type 2), and so on.

That said, assessing integration security risks across prospective SaaS vendors successfully has been critical in helping us pinpoint the most secure vendors over time. Hopefully, it can do the same for you.