There’s a common scene that plays out while selling B2B SaaS products - you have a prospect that is excited about your product, has a problem that you can solve, and is ready to sign a deal to get started! Yay!

A tale as old as TPRM

And then they bring you in front of their security team as part of the vendor due diligence process, and the security team says, “hang on a minute”. Except that “a minute” really means 6 months.

Maddeningly, the security issues that are flagged are not with your product! Instead the problems are with their systems, the integration point or database needed to get your product live has highly confidential data in it, and the security team is worried that it will end up in your systems. The prospect’s security program doesn’t allow for the highly confidential data to be accessed or shared with third-parties. Even your SOC2 Type 2 can’t change the fact that they are prohibited by their own policies.

This leads to exacerbated negotiations - maybe they can start with a subset of the data to get the integration rolling? Or create a copy of the data with the confidential parts removed?

These all sound great to the prospect! Except that the data team would need to get involved before the integration can take place, and their roadmap is completely full for the next two quarters.

(If you are curious why this is happening in more deals today, a short history of vendor due diligence at the end of this article)

I’ve seen this so many times, deals getting delayed indefinitely after lots of sales work to find and connect with an amazing (potential) customer.

Fortunately JumpWire offers a great solution to this logjam! JumpWire’s policy engine has a setting to drop data that doesn’t match a known label, which gives your integration with a customer a guarantee that confidential data won’t be shared or stored in your product.

It’s designed to be very easy to manage, simply import an OpenAPI spec file corresponding to your API, and only the request properties that are required for your product will be accepted by the policy.

Then using our HTTP proxy, you can inspect requests to your API in real time and drop any unnecessary sensitive information that might be contained in that request. Here’s a diagram of how this setup looks:

Proxy is filtering a person’s name from integration

Now there might still be a security objection to this setup — the highly confidential data is still being transmitted over the Internet before getting dropped, which is still a violation of their policy which restricts it from leaving their environment.

But this is also not a problem! Because JumpWire easily installs “on premise”, the HTTP proxy can be deployed in your customer’s environment to drop the data before it leaves! You’ve saved them months of data munging work and unblocked the deal!

Proxy runs on customer’s integration

If you’d like to see more, book a demo and we’ll personally walk you through JumpWire in action.

Quick History of Third Party Risk Management

Before SaaS became so common in the enterprise world, most software was distributed to be run inside a customer’s IT systems i.e. “on premise”. Security models revolved around “network segmentation”, which basically means the servers that run the software are not connected to or reachable from the Internet. This provided a layer of defense against data being exposed, even if malicious software was able access it.

Now that software runs on the Internet as a service, security teams can’t control the infrastructure to ensure that data is disconnected from the Internet. “Third Party Risk Management” is now a major focus in the security world which catalogs what data is being exchanged with SaaS vendors, since they can still control where data moves.

Some of the worst data leaks in recent history (Uber, LastPass, Okta) have been caused by a vendor being compromised, or are themselves a vendor to thousands of companies.

Companies are also overwhelmed with vendors, with hundreds of SaaS products in their organization. Each of these vendors need to be reviewed on a regular basis, which creates a backlog for internal teams responsible for TPRM.

They often react to this backlog by taking a hard line around sensitive data, which can block adoption of new software by other teams that could potentially share that data with a third party. Can you really blame them though?

• Ryan