How to answer the identity questions on an enterprise security questionnaire

The questionnaire arrives as a spreadsheet with somewhere between forty and four hundred rows, and roughly a third of them are about identity. Most teams answer it the way you answer any form, by reading each line literally and writing yes where yes is true.

That is how you end up passing the form and failing the follow-up call.

Security reviewers are not really asking whether you have a feature. They are checking whether you have run this before. A literal yes to "do you support SCIM" and a blank stare when they ask how fast access is actually revoked tells them the same thing a no would have, except now it also tells them you did not know the difference.

This is the identity block, line by line: what each question means, what the reviewer is checking behind it, and where the honest answer sits.

"Do you support SAML 2.0 single sign-on?"

What they are checking: whether their identity provider can be the source of truth for who gets into your product, and whether your implementation is a real one.

The follow-ups that separate the two are always the same three. Do you support both service-provider-initiated and identity-provider-initiated sign-in, because their users click your tile inside Okta and expect it to work. Is configuration per-organization, because they are not the only customer you have. And what happens when their signing certificate rotates, because it will, and the answer "we get a support ticket" is a finding.

Where the answer comes from: this is the most buyable item on the list. A managed SSO integration covers SAML and OIDC across the providers your customers actually run, with per-organization connections and certificate handling included. What stays yours is validating the organization ID on the way back in, and never inferring tenancy from an email domain.

"Do you support SCIM provisioning and deprovisioning?"

What they are checking: the second half of that sentence. Provisioning is convenience. Deprovisioning is the control they are buying.

Almost everyone answers yes to this and a meaningful number of them have only implemented a DELETE handler, which most identity providers never call. Okta and Entra deprovision by sending a PATCH that sets active to false. If your app only listens for deletes, your customer's admin sees "deprovisioned" on their screen while the user keeps working.

Where the answer comes from: buyable, with one caveat worth knowing before you say yes. SCIM syncs from the identity provider, and in a large company the identity provider is not where employment ends. The HR system is. If their source of truth for terminations is Workday, an integration that only listens to Okta is one hop downstream of the event that matters. Directory Sync covers both, including the HRIS side.

"How quickly is access revoked when an employee is terminated?"

What they are checking: whether you have ever measured this. It is the single best question on the form, and the number of vendors who answer it with a real number is small.

The honest answer is a chain, and most of it is not yours. Okta pushes changes as they happen. Microsoft Entra runs provisioning on a fixed background cycle of roughly 40 minutes that admins cannot configure, though they can force one user through on demand. An HRIS export overnight is overnight. Then your handler runs, and then your token lifetimes set a floor underneath everything, because a stateless access token with a one-hour life and no revocation check keeps working for up to an hour no matter how fast the event reached you.

How to answer it: give the range and name the variable. "Within seconds of the event reaching us. How fast that is depends on which system you terminate in, so if you are deprovisioning in Entra expect up to about 40 minutes for the sync, and we can talk through forcing it on demand." That answer tells a reviewer you have done this before. A single confident number tells them you have not.

Do not say "immediately" unless you have revoked sessions, refresh tokens and API keys, and can say so.

"Can users' sessions be revoked or terminated?"

What they are checking: whether your session outlives the decision to end it. A session issued yesterday that still works today is a credential they cannot take back.

This one catches people because it is adjacent to the previous question and has a different answer. Deprovisioning stops new logins. It does nothing to a session already in flight unless you make it. Session lifetime is a security control, not a comfort setting, and the number you choose is the number you are quoting here.

How to answer it: say what your access token lifetime is, whether you revoke server-side sessions on deprovision, and whether unexpired tokens are denylisted or simply allowed to age out. All three are legitimate designs. Not knowing which one you have is not.

"Do you support multi-factor authentication?"

What they are checking: usually not what the question says. Enterprise buyers with an identity provider already enforce MFA there, and what they actually want to know is whether your app lets someone bypass it.

How to answer it: the strong answer is that once SSO is configured for their organization, their policy governs, because non-SSO methods are disabled for that organization. That is better than a list of factors you support, because it means their existing controls reach your product rather than sitting alongside a second set of yours.

If you also offer MFA for customers without an identity provider, mention it second. Lead with the SSO answer.

"Does your product support role-based access control?"

What they are checking: whether an admin at their company can give a contractor less access than a director, inside your product, without emailing you.

How to answer it: name the model. Roles assigned per organization, permissions checked per action, and whether roles can be driven from their directory groups rather than managed separately in your UI. That last part is the one that turns a yes into a good yes, because the alternative is their IT team maintaining two lists forever.

"Can our administrators configure this themselves?"

What they are checking: whether onboarding will require your engineers. This is increasingly a procurement question rather than a security one, because the security team has been through rollouts where every connection took two weeks of email.

How to answer it: demonstrate it. This is the question most improved by a screen share rather than a cell in a spreadsheet. A self-serve Admin Portal where their IT contact configures SSO and directory sync on their own schedule is a thirty-second demo that answers the question better than any wording you could write.

"Do you provide audit logs, and can we export them to our SIEM?"

What they are checking: three things stacked in one line. Do you record the right events, can you keep them long enough, and can they get them into Splunk or Sentinel without a project.

The gap that shows up here is between application logs and audit logs. Reviewers want a record of who did what to which resource, retained and queryable, which is a different artifact from your observability stack. You can sample application logs. You cannot sample an audit trail.

How to answer it: say which events you emit, what retention you offer, and name the destinations you stream to rather than saying "SIEM integration available." If a customer can configure the stream themselves and pick their own destination, say that too, because the alternative is you running an export for them every quarter.

The ones no vendor answers for you

Four items on every questionnaire that buying identity infrastructure does not cover, and one that buying it creates.

• ‍Subprocessors. If you use a managed identity provider, they are a subprocessor, and they belong on the list you give the customer along with what data they process and where. Teams forget this constantly and it surfaces late, usually in legal review after security has already signed off. Get it on the list before you send the document.‍
• Data residency. Where the data lives is a question about your architecture and your vendors together. Have the answer for both.‍
• Incident response and breach notification. Your process, your timelines, your contractual commitment. A vendor's uptime SLA is not your incident response plan, though it belongs in the answer about dependencies.‍
• Your own secure development lifecycle. Code review, dependency scanning, penetration testing, how you handle secrets. None of it is buyable and all of it gets asked.‍
• Compliance reports. SOC 2, ISO 27001 and the rest are about your organization. Where a vendor's reports help is as evidence for the parts of your stack they run; check what your providers publish, and be ready to explain which controls are inherited and which are yours.

The three you cannot fake

Most of the form rewards preparation. Three items reward having actually done the work, because the buyer can verify them during the call.

• ‍Time to revocation, because they will ask you to walk through it and the chain either exists in your head or it does not.‍
• Self-serve configuration, because they will ask to see it, and a screen share settles it in under a minute.‍
• An audit log sample, because they will ask for one, and a real export with real event shapes looks nothing like a promise that logging is available.

Get those three right and the rest of the identity block is a paperwork exercise. Get them wrong and a clean spreadsheet will not save the deal, because the reviewer already knows what they are looking at.

How much of this block you can hand off

The identity questions are the most buyable third of a security questionnaire, which is exactly why they are a poor place to spend engineering time. They are the same requirements at every company selling to enterprises. Here is how the eight above map onto WorkOS, and where the line falls.

• ‍SSO is one integration covering SAML and OIDC across 20 or more identity providers, with per-organization connections so each customer's setup is their own. Certificate handling and the provider-specific differences sit on our side of the line.‍
• SCIM and the HRIS question are Directory Sync: 12 or more directory services, plus Workday, BambooHR and Rippling directly, so the answer to "what if our source of truth is our HR system" is yes rather than a caveat. Deprovisioning arrives as an event your app reacts to.‍
• MFA becomes the strong version of the answer, because configuring SSO for an organization disables the other authentication methods for that organization. Their policy governs, which is what the reviewer wanted to hear.‍
• RBAC puts permissions in the access token so you check them without an extra call, scopes roles per organization, and can drive them from the customer's directory groups instead of a second list in your UI.‍
• Self-serve configuration is the Admin Portal, included in every account. Your customer's IT contact sets up SSO and directory sync on their own schedule, which turns that question from a paragraph into a demo.‍
• Audit logs and SIEM export stream to seven destination types including Splunk, Datadog, Microsoft Sentinel, Snowflake, S3 and a generic HTTPS endpoint, and your customers can configure their own stream through the Admin Portal rather than filing a ticket with you.

That is six of the eight answered by configuration. The other two stay yours, and so does everything in the section above it. Your revocation chain, your session lifetime, your retention period, your subprocessor list, your incident response. Those are answers about your system, and they are the ones that decide whether a reviewer believes the rest of the form.

The point of handing off the first six is having time to know the last ones cold.

Start with AuthKit, free up to a million monthly active users, or talk to us about the questionnaire in front of you.

Keep this open while you fill in the form: