# Enterprise-Readiness Checklist for B2B SaaS

Source: https://startwithidentity.com/templates/enterprise-readiness-checklist-b2b-saas/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

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

1. Fill in the **Status** column for your product today: Yes, Partial, No, or Roadmap (with a quarter).
2. Work the **Minimum bar** rows first. They are what blocks deals. The **Strong answer** rows are what wins them against a competitor.
3. Keep the **Evidence** links current. A questionnaire answer with a link to public docs gets accepted faster than a paragraph.
4. 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](https://startwithidentity.com/standards/saml-2-0/) SP-initiated and IdP-initiated sign-in ([OASIS SAML 2.0 Core](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)) | Minimum | `[ ]` | `[docs URL]` |
| 1.2 | [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) sign-in with an enterprise IdP ([OIDC Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)) | 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](https://startwithidentity.com/glossary/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](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/), 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](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/) and [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/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 | Evidence |
|---|------|-----|--------|----------|
| 2.1 | [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) server for Users ([RFC 7643](https://www.rfc-editor.org/rfc/rfc7643) schema, [RFC 7644](https://www.rfc-editor.org/rfc/rfc7644) 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](https://startwithidentity.com/recipes/set-up-scim-provisioning/) and [SCIM implementation guide](https://startwithidentity.com/guides/implementation/scim-provisioning-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 | Evidence |
|---|------|-----|--------|----------|
| 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](https://startwithidentity.com/glossary/fan-out-breach/) such as the [Salesloft Drift OAuth token theft](https://startwithidentity.com/breaches/incidents/2025-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 | Evidence |
|---|------|-----|--------|----------|
| 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](https://startwithidentity.com/guides/authorization/implementing-rbac-enterprise/) and [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/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](https://startwithidentity.com/breaches/incidents/2023-okta-support-system-har-session-tokens/).

## 6. Authentication and session controls

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

| # | Item | Bar | Status | Evidence |
|---|------|-----|--------|----------|
| 6.1 | Admin can require MFA for all local (non-SSO) users | Minimum | `[ ]` | |
| 6.2 | [Passkeys](https://startwithidentity.com/glossary/passkey/) or [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/) 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](https://startwithidentity.com/standards/shared-signals-framework/) ([SSF](https://openid.net/specs/openid-sharedsignals-framework-1_0.html), [CAEP](https://openid.net/specs/openid-caep-1_0.html)) | Differentiator | `[ ]` | |

Guidance: item 6.3 is where most apps fall short. Only 12 of 95 apps in the [SWI matrix](https://startwithidentity.com/tools/mfa-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](https://startwithidentity.com/templates/mfa-authentication-standard/).

## 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](https://startwithidentity.com/regulations/european-union/gdpr/) will ask about transfers and sub-processors; buyers in financial services may cite [DORA](https://startwithidentity.com/regulations/european-union/dora/). See [GDPR for identity systems](https://startwithidentity.com/guides/compliance/gdpr-for-identity-systems/).

## 8. Assurance and compliance

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

- [ ] [SOC 2](https://startwithidentity.com/glossary/soc2/) Type II report, current period, against the AICPA [Trust Services Criteria](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services). The identity controls auditors test sit mostly in CC6 (logical access); see [SOC 2 for identity](https://startwithidentity.com/guides/compliance/soc2-for-identity/).
- [ ] [ISO/IEC 27001](https://www.iso.org/standard/27001) certificate if you sell into Europe or to buyers who require it; see [identity controls for ISO 27001](https://startwithidentity.com/guides/compliance/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](https://openid.net/wg/ipsie/) (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](https://startwithidentity.com/glossary/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.

## Related

- [Identity RFP question bank](https://startwithidentity.com/templates/identity-rfp-question-bank/) (what buyers will ask you)
- [Build vs buy identity](https://startwithidentity.com/guides/buyer-guides/build-vs-buy-identity/)
- [Capability checker](https://startwithidentity.com/tools/capability-checker/)
- [SCIM explained](https://startwithidentity.com/guides/fundamentals/what-is-scim/)