What B2B SaaS founders learn during their first enterprise security review

A B2B SaaS founder closes their first enterprise deal verbally. Champagne is opened. Two weeks later the security questionnaire arrives, and three weeks after that the legal review, and somewhere around week six the deal that was closed in spirit is renegotiated, postponed, or quietly lost. The founder spends the next quarter scrambling to add the things the questionnaire surfaced.

This is so predictable that it has become a stage of SaaS company life. The founders who survive it learn the same lessons. The ones who do not survive it learn them anyway, just expensively.

What the questionnaire is really asking

A forty-page security questionnaire from a Fortune 500 buyer feels like an exhaustive technical audit. It is not. It is asking a much simpler question: if our security team has to defend this purchase to our CISO, can we?

The questions are not really about the answers. They are about whether you have thought about the answers, whether the answers are consistent with each other, and whether your posture matches the seriousness of the data you would hold. A questionnaire with blank fields fails. A questionnaire with confident, specific, internally consistent answers passes, even if some of those answers are "we do not currently do this and here is our roadmap to do it."

This means the founder who treats the questionnaire as a test to pass is missing the point. The questionnaire is a conversation. The buyer is asking whether they can trust you with their data, and whether their security team can defend the decision to trust you.

The five things that always come up

Across enough enterprise deals, the same five things appear in almost every questionnaire and they are the same five things SaaS founders are usually not prepared for.

SSO via SAML or OIDC, with SCIM provisioning. The buyer's IT team does not want to manage individual accounts in your product. They want to provision users from their identity provider and have access flow through that. If you do not have SSO, you do not have an enterprise tier. SCIM — automatic deprovisioning when an employee leaves — is the next ask, and it is non-negotiable for any buyer with a meaningful headcount.

Audit logs the customer can access. Not "we have audit logs on our side." The customer wants their audit logs, in their SIEM, queryable by their team. This is usually surfaced as a "send events to our security tool" requirement. Without it, the buyer cannot run their own incident investigation against your product, which means they cannot use you for anything sensitive.

A defensible answer on multi-tenancy. "Is our data isolated from your other customers' data?" The honest answers are usually "yes, logically, in a shared database with tenant scoping enforced at the application layer." That is fine, if you can explain it confidently and demonstrate the controls. The answer that fails is the founder who panics, oversells the isolation, and produces inconsistent answers on the follow-up. Confidence in a moderate posture beats handwaving about a strong one.

Data residency and export. Where does the data live? Can the customer get it out? On termination, what happens to it? These questions are short on the questionnaire and large in practice. Many SaaS architectures assume the data lives in one cloud region forever and the customer never leaves. Both assumptions break enterprise deals.

Subprocessor transparency. Every vendor you use that touches customer data needs to be disclosed. Stripe, Twilio, OpenAI, Datadog, every AI provider. The customer will read this list and one of them will be unacceptable for reasons specific to that customer. You need to be ready to discuss alternatives, or you need to have a credible answer for why the dependency cannot be removed.

The order to add them in

If you are pre-enterprise and trying to get ready, the order matters. Building all five at once is not realistic for most teams; building them in the wrong order leaves you with awkward partial coverage.

The order that has worked across our SaaS engagements:

First, audit logs, because they are easy to retrofit but become impossible to backfill if you wait. Every action in the system should be logged with actor, target, action, timestamp, and IP, from week one. You will thank yourself later.

Second, SSO, because it is the question that most often comes up first in an enterprise conversation and the one that takes the longest to bolt on cleanly if you skipped it. Build it with both SAML and OIDC. SCIM can wait until you have two enterprise customers asking for it, but the SSO foundation has to be there.

Third, multi-tenant data model rigor, because this is the hardest to change later. If your tenant isolation is sloppy, fix it now. If it is clean, document it clearly so you can defend it on the questionnaire.

Fourth, subprocessor inventory, because it is easy to assemble and is almost always asked for. Maintain it as a living document. New vendor? It goes on the list and gets reviewed.

Fifth, data residency and export, because this is the most likely to be deferred. Even a manual, supported "export your data on request within 30 days" process is enough for many buyers, and is far better than the silent "we do not actually have a process for this" answer.

The deeper lesson

The questionnaire is not the obstacle. The obstacle is that enterprise customers are buying not just your product but a defensible decision to use your product. The features above exist to make that decision defensible.

A founder who internalizes this stops dreading enterprise procurement and starts using it as a design constraint that shapes the product in healthy ways. SSO is the right thing to build anyway. Audit logs make your support team better. Data export is the right thing to do for customers. The procurement gate is, in a sense, doing you a favor by forcing the question.

It just rarely feels like a favor while you are filling out the questionnaire.