Enterprise Readiness Checklist for B2B SaaS: 9 Gates
An enterprise readiness checklist for B2B SaaS built from real procurement blockers — SSO, SCIM, RBAC, audit logs, tenant isolation, and the order to ship them.
The Deal Doesn't Die in Sales. It Dies in IT.
The pattern is always the same. A founder-led sale goes beautifully for six weeks. The champion loves the product, the pilot metrics are good, budget exists. Then the deal reaches the customer's IT and security team, and a document arrives asking whether you support SAML 2.0, SCIM 2.0, role-based access control and exportable audit logs. The honest answer is no, and the deal enters a holding pattern it usually does not come out of.
Every enterprise readiness checklist for B2B SaaS you'll find online is a feature list. That's the least useful part of it. The features are well known and the specs are public. What kills companies is the order they're built in, the architectural decisions made in year one that make gate three cost five engineer-months instead of five days, and the habit of treating all nine gates as one undifferentiated "enterprise tier" epic that never gets prioritized because it doesn't ship a customer-visible feature.
This is the version we use when a client asks us to get their product through enterprise procurement. It's a build order, not a wish list.
What "Enterprise Ready" Actually Means
Strip the marketing off and enterprise readiness is one thing: your product can be governed by someone who does not use it.
That's the whole idea. An IT administrator at a 4,000-person company will never open your app to do their job. They need to grant access, revoke it the same hour someone is terminated, prove to an auditor who had access to what in March, and enforce their own password and MFA policy without trusting you to enforce it for them. Every item below is a mechanism for delegating control to a person who is not your user.
This is also why "we have a great admin UI" is not an answer. A great admin UI requires a human to click it. Enterprise governance is automated by definition — it runs off their identity provider, their offboarding script, their SIEM.
The Enterprise Readiness Checklist for B2B SaaS
Nine gates. The blocker column is what actually happens when it's missing.
| # | Gate | Minimum bar | What happens without it |
|---|---|---|---|
| 1 | SSO | SAML 2.0 + OIDC, IdP-initiated and SP-initiated, per-tenant config | Hard stop in security review |
| 2 | Directory sync | SCIM 2.0 Users + Groups, including deprovisioning | Manual offboarding — an audit finding |
| 3 | RBAC | Named roles, least privilege, role mapped from IdP groups | "Everyone is an admin" fails access review |
| 4 | Audit logs | Immutable, exportable, actor + resource + timestamp | Cannot answer "who did this, when" |
| 5 | Tenant isolation | Enforced below the application layer | One bug becomes a cross-customer breach |
| 6 | Data lifecycle | Export, deletion with SLA, retention config, residency | GDPR/DPA negotiation stalls indefinitely |
| 7 | Availability | Status page, real SLA, tested restore, incident comms | Procurement scores you as single-point risk |
| 8 | API & automation | Stable versioned API, rate limits, webhooks, sandbox | Blocks their integration team, not yours |
| 9 | Compliance evidence | SOC 2 Type II, DPA, subprocessor list, pen test summary | Nothing proceeds past first review |
Gates 1 and 2 are one project, not two
SSO and SCIM are the two that block deals most often, and teams consistently ship the first and postpone the second. That's a mistake, because they fail for the same reason: the user record was designed around an email address.
If user.email is your primary identity key, SSO will mostly work and SCIM will not. Enterprise IdPs change email addresses on name changes, reuse addresses, and — critically — SCIM deprovisioning arrives as a PATCH against an opaque external ID, not an email. Your schema needs external_id, idp_id and tenant_id as first-class columns on day one, with email demoted to a mutable attribute. Retrofitting that after 30,000 accounts exist is a data migration with a customer-visible failure mode.
Two specifics worth getting right early:
- Just-in-time provisioning is not directory sync. JIT creates a user on first login. It never deletes one. An account that only ever gets created is exactly the finding an access review is designed to catch.
- Enforce SSO at the tenant level, with a break-glass path. Once a tenant turns on required SSO, password login must be dead for that tenant — otherwise you've built a documented bypass of the customer's MFA policy. Keep exactly one break-glass account, and log every use of it loudly.
One commercial note, because it affects architecture: gating SSO behind your top pricing tier is increasingly read by security-conscious buyers as hostile, and it has its own public wall of shame. Whatever you decide about packaging, build it so SSO is a per-tenant flag rather than a code path only the enterprise plan can reach.
Gate 4: audit logs are a product, not a log file
Your application logs are not audit logs. Audit logs answer a specific question from a specific person — a compliance officer reconstructing an incident months later — and that imposes requirements application logs don't have: an append-only store, a stable event schema, actor and target identity that survive a user being deleted, and retention measured in years.
The two design decisions that hurt later:
- Emitting from the wrong layer. If audit events are emitted by controllers, every new code path is a chance to forget one. Emit from the persistence or service boundary where the state change happens, so coverage is structural rather than a code review convention.
- No export. Enterprise customers want the events in their SIEM. A UI table with a date filter is not an answer. Offer a paginated API with cursor semantics and, once you have the demand, a push to S3 or a log drain.
Denormalize identity into the event at write time. Joining to a users table to render an audit entry means a deleted user makes your audit trail unreadable — which is the moment the trail actually mattered.
Gate 5: isolation is an architecture question with a deadline
Pooled multi-tenancy is fine. Pooled multi-tenancy where isolation is enforced only by a WHERE tenant_id = ? clause that every developer must remember to write is not.
Push the boundary down a layer: row-level security in Postgres, a repository layer that physically cannot construct an unscoped query, or separate schemas per tenant. Then prove it — a test suite that attempts cross-tenant reads through every public endpoint and expects a 404 belongs in CI, not in a threat model document. At Kuaray this is the first thing we look at during a readiness review, because it's the only gate on this list where the failure mode is a breach notification rather than a slow deal.
Gate 9: evidence, and the ISO question
SOC 2 Type II is effectively table stakes for US enterprise procurement. Type I is a point-in-time snapshot; Type II tests whether controls operated over a period, typically 6 or 12 months — which means the clock is the constraint, not the effort. Start the observation window before you need the report.
If you're selling into Europe, expect ISO 27001 to be asked for alongside or instead of SOC 2, and expect AI-specific questions on top. Those obligations are converging with the regulatory ones; we cover the engineering side of that in our guide to EU AI Act compliance for SaaS.
Build Order
Most teams work the enterprise readiness checklist for B2B SaaS top to bottom, which is exactly wrong — the visible gates depend on the invisible ones. Sequence by deal-unblocking value per engineer-week instead, which is not the same as sequencing by difficulty:
- Fix the identity schema.
tenant_id,external_id,idp_id. Nothing above works properly without this, and it gets more expensive every week. - Tenant isolation below the app layer, plus the cross-tenant test suite. Do this while the codebase is small.
- Audit event emission at the service boundary. Even if nothing reads it yet — you cannot backfill history.
- SAML + OIDC SSO, per-tenant, with enforced mode.
- SCIM 2.0, Users and Groups, deprovisioning included.
- RBAC with IdP group mapping. Three or four real roles beat a permission matrix nobody configures.
- Data export, deletion SLA, retention controls.
- SOC 2 Type II observation window, started as early as your controls allow.
- Status page, tested restore, incident comms plan.
Steps 1 through 3 are invisible to customers and are the entire game. They're cheap now and structural later. Steps 4 through 6 are the ones sales will scream for, and they go fast if step 1 was done.
The Three Mistakes We See Most
Building SSO for one customer. The first enterprise deal produces a hardcoded integration against Okta with that tenant's metadata in an env var. The second deal uses Entra ID and the third uses a self-hosted Keycloak. Model IdP connections as tenant-scoped configuration records from the first one.
Treating readiness as a sales problem. It's an architecture problem that presents as a sales problem. Every month it stays on the sales side, the fix gets more expensive.
Shipping the feature without the evidence. Enterprise buyers verify. "We support SCIM" needs to survive their IT team actually running a deprovisioning test in a sandbox tenant — which is why gate 8 includes a sandbox environment they can break.
Nothing on this enterprise readiness checklist for B2B SaaS is exotic engineering. It's schema design, an authorization boundary, an event stream and two identity protocols with public specs. What makes it hard is that it competes with roadmap work that demos better, right up until the quarter where it's the only thing standing between you and a contract an order of magnitude larger than anything you've signed.
If you're mid-deal and just received the questionnaire, the fastest useful move is to audit gates 1 through 5 honestly and find out which are schema problems and which are just missing endpoints. We do that as a fixed-scope engagement — see how we approach custom software and security engineering.