Enterprise-Readiness Checklist for B2B SaaS

The identity and trust features enterprise buyers check before they sign: SSO (SAML and OIDC), SCIM, audit logs, RBAC, admin console, session controls, data residency and SOC 2, each with the question buyers ask and the evidence to have ready.

Enterprise buyers send a security questionnaire before they sign, and most of the identity questions on it come down to eight things: single sign-on, automated provisioning, audit logs, roles, a self-serve admin console, session controls, where the data lives, and an independent audit report. This checklist lists each one, the question you will actually be asked, the minimum bar most security teams accept, and the evidence to have ready. Each item names the standard it maps to, so your engineers build to the spec and not to one customer's interpretation of it.

How to use this checklist

Fill in the Status column for your product today: Yes, Partial, No, or Roadmap (with a quarter).
Work the Minimum bar rows first. They are what blocks deals. The Strong answer rows are what wins them against a competitor.
Keep the Evidence links current. A questionnaire answer with a link to public docs gets accepted faster than a paragraph.
Decide your packaging deliberately (see the note on plan gating at the end). Buyers ask which plan each feature is on.

Fill-in fields are shown as [like this].

Product: [product name] | Owner: [name, role] | Last reviewed: [date]

1. Single sign-on

Buyer question: "Do you support SSO with our identity provider, and can we require it for all our users?"

#	Item	Bar	Status	Evidence
1.1	SAML 2.0 SP-initiated and IdP-initiated sign-in (OASIS SAML 2.0 Core)	Minimum	`[ ]`	`[docs URL]`
1.2	OpenID Connect sign-in with an enterprise IdP (OIDC Core 1.0)	Minimum for newer buyers	`[ ]`	`[docs URL]`
1.3	More than one SSO connection per tenant (subsidiaries, contractors, acquisitions)	Strong	`[ ]`
1.4	Domain verification, so only the customer's verified domains route to its IdP	Minimum	`[ ]`
1.5	SSO enforcement: admins can switch off password login for their users, with a documented break-glass admin path	Minimum	`[ ]`
1.6	Just-in-time account creation from SAML or OIDC claims, with role mapping from IdP groups	Strong	`[ ]`
1.7	Signing certificate rollover without downtime (two active certificates, expiry alerts to the customer admin)	Strong	`[ ]`
1.8	Self-serve SSO setup in the admin console, not a support ticket	Strong	`[ ]`

Guidance: test against at least the three IdPs your customers use most, since metadata quirks differ. If requiring SSO switches off your app's own passkeys or MFA, say so in your docs; in SWI's Phishing-Resistant MFA Support Matrix, 9 of the 51 apps that support passkeys or security keys behave this way, which moves phishing resistance entirely to the customer's IdP. See the complete guide to implementing SSO and SAML vs OIDC.

2. Automated provisioning (SCIM)

Buyer question: "When we remove someone in our IdP, how fast do they lose access to your product?"

#	Item	Bar	Status
2.1	SCIM 2.0 server for Users (RFC 7643 schema, RFC 7644 protocol)	Minimum	`[ ]`
2.2	Groups resource, with group-to-role mapping	Strong	`[ ]`
2.3	PATCH support (IdPs send partial updates; PUT-only servers break)	Minimum	`[ ]`
2.4	Deactivation (`active: false`) ends the user's sessions and revokes their API tokens, not just the login	Minimum	`[ ]`
2.5	Filtering on `userName` and `externalId`, so the IdP can match existing users	Minimum	`[ ]`
2.6	Per-tenant SCIM bearer token that admins can rotate and that is scoped to provisioning only	Minimum	`[ ]`
2.7	Provisioning events written to the audit log	Strong	`[ ]`

Guidance: item 2.4 is the one auditors test. A deprovisioned user who keeps a live session or personal API token is still a user. The SCIM provisioning recipe and SCIM implementation guide cover the edge cases. In the SWI matrix, 17 of 66 apps that document SCIM (25.8%) offer it only on an enterprise plan, and buyers notice.

3. Audit logs

Buyer question: "Can we see who did what in our tenant, and can we send it to our SIEM?"

#	Item	Bar	Status
3.1	Sign-in events (success and failure), admin actions, permission changes, SSO and SCIM configuration changes, data exports	Minimum	`[ ]`
3.2	Each event records actor, action, target, timestamp (UTC), source IP, user agent and result	Minimum	`[ ]`
3.3	Tenant admins can view and search logs in the console	Minimum	`[ ]`
3.4	Export by API, and streaming to a SIEM or object storage	Strong	`[ ]`
3.5	Retention of `[__ days]` in product, stated in docs and contract	Minimum	`[ ]`
3.6	Logs cannot be edited or deleted by tenant users, including admins	Minimum	`[ ]`
3.7	API token and integration (OAuth app) activity attributed to the token, not only to the user who created it	Strong	`[ ]`

Guidance: item 3.7 matters after fan-out breaches such as the Salesloft Drift OAuth token theft, where customers had to work out which data an integration's token had pulled.

4. Roles and permissions

Buyer question: "Can we limit what each user can see and do?"

#	Item	Bar	Status
4.1	Built-in roles that separate admin, member and read-only	Minimum	`[ ]`
4.2	Custom roles built from granular permissions	Strong	`[ ]`
4.3	Billing admin separate from security admin	Strong	`[ ]`
4.4	Roles assignable from IdP groups (SAML/OIDC claims or SCIM groups)	Strong	`[ ]`
4.5	Scoped API tokens with expiry, owned by a user or a service account, listable and revocable by admins	Minimum	`[ ]`

Guidance: see implementing RBAC and RBAC vs ABAC vs ReBAC.

5. Admin console

Buyer question: "Can our IT team manage this without opening tickets with you?"

Tenant-level settings for SSO, SCIM, MFA policy, session policy and allowed domains in one place.
User list with status, last sign-in, role and sign-in method, exportable to CSV.
Ability to suspend a user and end all their sessions in one action.
Multiple admins required (no single-admin tenants), with an admin-change alert to all admins.
Support staff access to the customer tenant is off by default, granted by the customer, time-bound, and logged in the customer's audit log.

Guidance: the last item answers a question buyers now ask directly after support-system breaches like Okta's 2023 support case incident.

6. Authentication and session controls

Buyer question: "Can we enforce MFA and control session length?"

#	Item	Bar	Status
6.1	Admin can require MFA for all local (non-SSO) users	Minimum	`[ ]`
6.2	Passkeys or WebAuthn security keys supported	Strong	`[ ]`
6.3	Admin can require phishing-resistant MFA, not just offer it	Strong	`[ ]`
6.4	Idle timeout and maximum session lifetime configurable per tenant	Minimum	`[ ]`
6.5	Sessions end on SSO logout, SCIM deactivation and admin action	Minimum	`[ ]`
6.6	IP allowlisting for the tenant and for API tokens	Strong	`[ ]`
6.7	Receives session revocation and credential-change events from the IdP over the Shared Signals Framework (SSF, CAEP)	Differentiator	`[ ]`

Guidance: item 6.3 is where most apps fall short. Only 12 of 95 apps in the SWI matrix let an admin require passkeys or security keys. For timeout values, NIST SP 800-63B-4 is a defensible reference; see the MFA and authentication standard template.

7. Tenancy, data residency and data handling

Buyer question: "Where is our data stored, who can access it, and how is it kept apart from other customers?"

Hosting regions offered: [list]. Whether the customer chooses the region at sign-up, and whether backups and logs stay in-region: [answer].
Tenant isolation described in writing (logical isolation model, how tenant ID is enforced on every query, how this is tested).
Public sub-processor list with a change-notification process.
Data processing agreement available without negotiation for standard terms.
Encryption at rest and in transit described, and whether customer-managed keys are offered.
Data export and deletion on contract end, with a stated deadline of [__ days].

Guidance: buyers subject to the GDPR will ask about transfers and sub-processors; buyers in financial services may cite DORA. See GDPR for identity systems.

8. Assurance and compliance

Buyer question: "Can you send your SOC 2 report?"

SOC 2 Type II report, current period, against the AICPA Trust Services Criteria. The identity controls auditors test sit mostly in CC6 (logical access); see SOC 2 for identity.
ISO/IEC 27001 certificate if you sell into Europe or to buyers who require it; see identity controls for ISO 27001.
Penetration test summary letter from the last 12 months.
A trust page with the above, the sub-processor list and a security contact.
Pre-filled answers to the questionnaires your buyers send most often.

9. Standards direction to watch

The OpenID Foundation's IPSIE working group (Interoperability Profiling for Secure Identity in the Enterprise) is writing profiles of existing standards for exactly this list: single sign-on, user lifecycle management, entitlements, risk signal sharing, logout and token revocation. If you are designing SSO, SCIM and session revocation now, building to those standards (SAML or OIDC, SCIM, SSF and CAEP) keeps you close to where the profiles are heading.

A note on plan gating

In SWI's matrix, 49 of 82 apps with a documented SSO plan (59.8%) charge more for SSO, the practice buyers call the SSO tax. Whether you gate SSO is a business decision, but write down the answer before the questionnaire arrives, and consider putting SCIM deactivation and audit logs on the same plan as SSO: a buyer who can sign in through their IdP but cannot deprovision through it has a gap their auditor will find.

Identity RFP question bank (what buyers will ask you)
Build vs buy identity
Capability checker
SCIM explained