Last updated: September 2026
Most of a vendor security questionnaire’s identity section comes down to five questions: whether you support single sign-on with the customer’s own identity provider, whether multi-factor authentication is enforced rather than just offered, who can reach customer data and how often that access is reviewed, whether you keep an audit log of sign-ins and admin changes, and whether you have a SOC 2 report (or an equivalent such as ISO 27001) to share. If you can answer those five honestly and with evidence, you have usually covered the login part of the review. If one of them is a “not yet”, it is better to know now, because it is the kind of gap that stalls a deal for weeks.
This post is for the CTO, head of engineering or founder at a SaaS company whose deal has just landed in a prospect’s security review. It walks through what each identity question is really asking, what a good answer looks like, and how to turn a gap into a plan you can share with the prospect. It is written so you can forward it to whoever is filling in the spreadsheet.
Why does login show up on almost every questionnaire?
Login shows up everywhere because the common questionnaire frameworks put identity and access management at their core. The Shared Assessments SIG questionnaire covers access control among its control domains, the Cloud Security Alliance’s CAIQ is the question set for its Cloud Controls Matrix (version 4 arrived in 2021 and version 4.1 in late 2025), which has a dedicated Identity and Access Management domain, and the Vendor Security Alliance publishes its own questionnaire with access control questions. When a prospect’s procurement team sends you a spreadsheet, it is usually one of these, a trimmed version of one, or an in-house list modeled on them.
The same focus runs through SOC 2. The AICPA’s 2017 Trust Services Criteria (with revised points of focus, 2022), which SOC 2 audits test against, include a group of logical access controls (the CC6 series) covering how users are registered, authorized, given access by role and removed. A questionnaire is often the buyer’s way of checking the same things before they have your report, or instead of it.
There is also a practical reason. Weak or shared logins, accounts that should have been removed, and admin actions nobody logged are common routes into a vendor’s systems, and they are easy for a reviewer to ask about, so they tend to come first.
What are the questions that come up most often?
The wording varies between questionnaires, but the same five topics appear on almost all of them. Here is what each one is really checking.
Do you support single sign-on for enterprise customers?
This question is asking whether the prospect’s employees can sign in to your product through the prospect’s own identity provider, such as Microsoft Entra ID, Okta or Google Workspace, using SAML or OpenID Connect. It is not asking whether users can click “Sign in with Google”. The difference matters to the buyer because SSO through their identity provider means that when they disable an employee in their own directory, that person also loses access to your product, without anyone remembering to do it by hand.
A good answer names the protocols you support (SAML 2.0, OIDC or both), says whether each customer can connect their own identity provider, and says whether SSO can be enforced so that a customer’s users cannot fall back to a password. If you want the protocol background, our SAML vs OIDC explainer covers when a customer will expect each one. Some questionnaires follow up with a question about SCIM, the standard for automatically creating and removing user accounts from the customer’s directory, which our SCIM explainer describes. On our side, customer SSO is covered on the single sign-on feature page.
How do you enforce multi-factor authentication?
This question usually has two parts, and they are easy to confuse. The first is about your customers’ users, and asks whether a customer can require MFA for everyone in their account. The second is about your own staff, and asks whether MFA is required for every employee who can reach production systems or customer data. Many questionnaires ask for both, and the second is the one teams tend to answer too quickly.
“We offer MFA” is a weaker answer than “MFA is required, and here is the policy”. Where you can, say which methods you support. Increasingly, buyers ask specifically about phishing-resistant methods such as passkeys and security keys, because codes sent by text message can be intercepted. If your answer is that MFA is required for staff through your company identity provider, be ready to show the policy setting if asked.
Who can access customer data, and how is that reviewed?
This is the access review question, and it is the one small teams most often answer with a promise rather than a process. To an auditor or a security reviewer, an access review means a documented, repeated check (commonly quarterly) in which someone confirms that every person with access to production systems and customer data still needs it, and removes anyone who does not. It has a date, an owner and a record of what changed.
A one-time cleanup before the questionnaire arrived does not count, and reviewers can usually tell. A credible answer describes how access is granted (ideally by role, following least privilege, which means giving people only the access their job needs), how it is removed when someone leaves, and when the last review happened. If you are still designing roles, our RBAC primer is a reasonable starting point.
Do you keep an audit log of authentication events?
“We have logs somewhere” does not answer this question. The reviewer wants to know that sign-ins, failed sign-ins, password and MFA changes, and administrative actions (such as someone granting a role or changing a security setting) are recorded, kept for a defined period, protected from being edited, and actually reviewed or alerted on.
A usable answer says which events you record, how long you keep them, where they are stored, and whether a customer can get the events for their own users, for example through an export or a feed into their security monitoring. That last part increasingly matters to larger buyers, who want their own security team to see sign-in activity for their employees. Our guide to identity event logging shows what a complete set of authentication and admin events looks like in practice.
Do you have a SOC 2 report or equivalent?
This question asks for evidence you can hand over, not a statement of intent. A SOC 2 report is an independent auditor’s opinion on your controls, and procurement teams ask for the report itself because it lets them rely on someone else’s testing rather than taking your word for everything above. Being “SOC 2 ready”, or having started an audit, is useful to mention but is not the same answer.
It also helps to know the two report types. A Type I report says your controls were designed properly at a single point in time. A Type II report says they also operated effectively over a period, usually several months, and it is what most enterprise buyers expect. ISO 27001 certification is often accepted as an equivalent, particularly by European buyers. If you have neither, say so plainly and say what you are doing about it; our SOC 2 announcement post explains what the Type I and Type II audits covered for us, which gives a sense of the scope.
Why do the identity questions often depend on your identity provider?
Many of these answers depend on the system that handles your product’s login, whether you built it yourself or use a provider. If your application’s login is custom code, then SSO per customer, enforced MFA, a sign-in audit log and session revocation are all features your team has to build, test and maintain. If your login runs on an identity platform, most of those become configuration, and the platform’s own compliance reports can support your answers.
This is one reason some teams move login to identity management as a service before a large deal, rather than during one. We run one such service, Skycloak, which is managed hosting for the open-source Keycloak project. Here is how the five questions map onto Keycloak itself, whoever hosts it:
| Questionnaire item | Where Keycloak handles it |
|---|---|
| SSO with the customer’s identity provider | An identity provider (SAML or OIDC) per customer, or per Organization |
| Enforced MFA | OTP and WebAuthn (including passkeys) as required steps in the authentication flow |
| Access by role, and reviewing it | Realm and client roles, groups, and the admin console’s user and role views |
| Audit log | Login events and admin events, which can be exported |
| SOC 2 or equivalent | Not a software feature: it comes from whoever operates the service |
Our B2B SaaS page lists which questionnaire items map to configuration on Skycloak. Our SOC 2 Type II report and ISO 27001 certificate are listed on the procurement checklist, and the security overview covers encryption, hosting regions and incident response. Whatever platform you use, check that its reports cover the parts of your answers you are relying on it for.
How do you turn gaps into a plan instead of a scramble?
When the honest answer to one of these questions is “not yet”, the useful move is to sort the gap by how long it really takes to close. Roughly, they fall into three groups:
- Configuration work, days rather than weeks: requiring MFA for all staff in your company identity provider, turning on sign-in and admin event logging, and writing down your access review process and running the first one.
- Engineering work, weeks: adding SSO for customers’ identity providers, customer-facing MFA enforcement and audit log export, if your login is custom-built. On an identity platform, much of this moves into the first group.
- Longer projects, months: a SOC 2 Type II report, because the audit has to observe your controls working over a period before the report can be issued.
Then answer the questionnaire truthfully and attach the plan. Buyers generally accept a gap with a credible timeline much more readily than a vague “yes” that falls apart in the follow-up call, and security reviewers do follow up. Give dates only for work you control. For a SOC 2 audit, give the observation window and the expected report date your auditor has confirmed, rather than a date you hope for.
Finally, keep the answers. The same five questions will arrive with the next prospect, and a maintained set of answers with links to evidence (a policy document, a screenshot of the MFA setting, the date of the last access review) makes the next questionnaire much faster to complete.
Frequently asked questions
What is a vendor security questionnaire?
A vendor security questionnaire is a list of questions a company sends to a supplier before buying, to check how the supplier protects data and systems. Common standardized versions include the Shared Assessments SIG, the Cloud Security Alliance CAIQ and the Vendor Security Alliance questionnaire, though many companies use their own list based on these.
How many security questionnaire questions are about login and access?
It varies by questionnaire, but identity and access management is usually one of the largest single sections. Frameworks such as the CSA Cloud Controls Matrix have a dedicated identity and access management domain, and the SOC 2 Trust Services Criteria include a whole series of logical access controls, so questionnaires built on them ask about login in some depth.
Does “Sign in with Google” count as single sign-on on a questionnaire?
Usually not. The questionnaire is asking whether an enterprise customer can connect their own identity provider, such as Entra ID or Okta, over SAML or OpenID Connect, so that their IT team controls access. Social login is convenient for individuals, but it does not give the customer’s IT team that control.
What is the difference between SOC 2 Type I and Type II?
A Type I report assesses whether controls are designed properly at a single point in time. A Type II report also tests whether they operated effectively over an observation period, commonly several months. Enterprise buyers generally ask for Type II, because it shows the controls work in practice and not just on paper.
What should I do if I cannot answer yes to a questionnaire item?
Answer honestly, describe the compensating controls you have today, and attach a plan with dates you control. A reviewer can usually accept a documented gap with a realistic timeline, while an overstated “yes” tends to be caught in follow-up questions or during the audit that comes later, which does more damage to the deal.