This is another in a series on Product Security for B2B SaaS.

I’ve worked on both ends of the spectrum in the enterprise market, as the person evaluating SaaS products for large enterprises and as an advisor to B2B SaaS executives helping them roadmap and meet the expectations of the enterprise.

This guide takes from that culmination of experience.

TLDR - Enterprise Security For B2B SaaS

Not interested in reading this whole thing? Here’s a summary:

• YMMV with the security team / individual may need to give their blessing before allowing the purchase of your product. Their approval is often based on a combination of personality, policies, and power in the organization.

• Bake in SSO into your product. Some companies won’t even work with you if you don’t have SSO

• Don’t pull any more data than you need to, to do your job. Anything sensitive you do pull, try to anonymize or sanitize earlier in the process.

• Clean up your security hygiene ASAP. That means no

  • Shared passwords

  • Unpatched servers, containers, endpoints

  • And more… (see next topic

• Expect to be forced to do a SOC 2 sooner than later. You might get a pass the first year with a large client, but not the second year. If you’re dealing with sensitive data or high profile institutions like banks, then you might not even get that.

  • Otherwise, expect 400 question questionnaires on the state of your infrastructure and security. Nothing more stressful than answering “No” all over these questionnaires.

The Nature Of the Enterprise Beast

When selling to the enterprise, you have a few different personas involved. For the purpose of this article, I will highlight a few:

The Buyer - The person and champion that’s really interested in your awesome product to solve their painful problem.

The Security Team - The team that’s responsible for the security of the Enterprise’ and their customers’ data. 

Passing Security Review

Your buyer loves your product, great! Now they go through the procurement process. Even for a POC, they have to follow the process. Sometimes buyers don’t go through this process and end up upsetting procurement and security teams alike.

Part of the process is passing a security review. There are a number of ways these reviews happen. The team may choose any number of combinations mentioned below:

• Checking out your website. They’re looking for a /security or other sort of mention of security on your website. Sometimes it’s a list of what you’re doing with a downloadable whitepaper (PDF).

• Using a security risk solution. They may have software that has evaluated your company already or where you have submitted information via a solution previously and they’ll use that data.

• Asking for a security report like SOC 2 or recent pentest.

• Sending you a large questionnaire and evaluating your security based on your honest answers😬 and follow up questions.

You then may have a few more hurdles. Examples come down to the person on the other side and whether they…

a) actually understands what your product does and

b) understand anything about cloud computing and infrastructure.

At the end of the day, it will be a wake up call for you and your organization dealing with enterprise security and realizing how much of a gap your current security posture is from the expectations of industry. Many folks think they’re good from a security perspective, but there is no “done” in security, just like your product, there’s always room for improvement.

Getting Your Product Enterprise Ready

Ok, so let’s get to the heart of it. You may have been building a B2C product and are now looking to pivot into B2B or maybe you had a community offering and now trying to sell to the enterprise, or you’re trying to get larger logos under your belt.

Well, the larger the enterprise, the more security scrutiny you’re going to face. Period.

So let’s start with features, here is a breakdown of some features enterprises will expect or like to have:

If you’re not supporting SSO (SAML / OIDC), then your product will have some additional Identity and Access expectations, such as:

The ability for the customer to:

• Control password criteria, length, and strength

• Enforce 2FA across all users

• Utilize passwordless login or magic links

Summary - Product Security Series

This is another in a series on building products for the enterprise. The previous article in the series discussed authentication into a customer’s AWS account and things to avoid…

What do you think? Would you like to see more like this? Did this help you on your journey? Leave a comment, reply, or email me (ayman at cloudsecuritylabs dot io).