The Enterprise-Ready Checklist: Security, SSO, and RBAC for Growing SaaS

The conversation goes like this. You're on a sales call with a Fortune 500 prospect. The product demo lands well. The economic buyer is excited. Then the IT / security team joins the call, and in the next ten minutes they ask:

• "Do you support SAML SSO? Which IdPs?"
• "Can you provide SCIM for user provisioning?"
• "What's your role-based access control model?"
• "Do you have SOC2 Type 2? Can we see the report?"
• "Where does our data live? Can we require a specific region?"
• "Do you have audit logs? How far back?"
• "What's your data encryption story? At rest, in transit, key management?"
• "Who has admin access? How do you enforce least-privilege internally?"

Each question is binary: either you have a clean answer or you don't. Zero clean answers doesn't just lose the deal — it loses the next deal, because that prospect will tell two other CIOs in their network that "they weren't ready yet."

This post is the specific checklist of what "enterprise ready" means, how to build toward it, and how long it actually takes. It's part of the Technical Foundation cluster.

What enterprise ready actually means

"Enterprise ready" isn't a marketing claim. It's a specific set of capabilities that enterprise IT teams have a checklist for. The list varies slightly by industry (healthcare adds HIPAA; financial services adds additional controls; European buyers add GDPR-specific asks) but the core is consistent.

There are two tiers:

Tier 1: the non-negotiables. Without these, you can't close an enterprise deal, full stop.

• SAML SSO (supporting at least Okta, Azure AD, Google Workspace)
• Role-based access control (RBAC)
• Audit logs
• Encryption at rest and in transit
• A real security page on your site describing your posture
• Basic incident response and disclosure process

Tier 2: the common asks. These show up in about 60–80% of enterprise deals. You can close deals without them, but the conversations are painful and the close rate drops.

• SOC2 Type 2 (the audit report)
• SCIM provisioning
• Data residency options (at least US/EU)
• A DPA (Data Processing Agreement) ready to sign
• Pen test report (annual, from a reputable firm)
• Subprocessor list and policy
• Customer-specific security reviews (filling out their security questionnaire)
• Bring-your-own-encryption-key (BYOK) for the most security-conscious buyers

A company "enterprise ready" for most segments has all of Tier 1 plus most of Tier 2. Tier 1 is table stakes; Tier 2 is the competitive advantage.

Tier 1 in detail

SAML SSO

The single most common enterprise ask. If a prospect has 500+ employees, they almost certainly use an identity provider and want their SaaS tools to integrate with it.

What "SSO support" means specifically:

• SAML 2.0 compliance: your app can serve as a Service Provider (SP) and accept assertions from the prospect's Identity Provider (IdP)
• SP-initiated and IdP-initiated flows: both work
• Attribute mapping: you accept user attributes from the SAML assertion (email, name, role, team) and create/update user records accordingly
• Just-in-time provisioning: new users appear in your system the first time they log in via SSO, without needing a separate admin to create them
• Specific IdP support: prospects ask by name for Okta, Azure AD / Entra ID, Google Workspace, OneLogin, Ping. If you support SAML 2.0 properly, you support all of them — but it's worth explicitly testing and documenting each.

Build vs. buy: WorkOS, Clerk, Auth0 all offer drop-in SSO that handles 95% of cases. Rolling your own SAML is a specific flavor of pain — the SAML spec is old, verbose, and full of edge cases around encryption, signing, and metadata. For most SaaS teams, paying for WorkOS is the right answer. Cost is typically 2–6 months of a senior engineer's time vs. $300–$3000/month subscription. Unless security integration is core to your product, buy it.

Role-based access control (RBAC)

Enterprise buyers will not give every user in their org the same permissions in your product. They need roles — admin, user, viewer at minimum, usually more.

A well-designed RBAC model has:

• A small, consistent set of predefined roles (3–5 is plenty for most products)
• Permission checks on every sensitive action (not just UI hiding — actual enforcement at the API layer)
• Admin UI for managing role assignments
• Audit trail for role changes (who changed whose role, when)

Custom roles and fine-grained permissions are Tier 2 — they come up in bigger enterprise asks but aren't required for Tier 1.

Audit logs

What happened, when, and who did it. For every sensitive operation. Stored for at least 1 year (2+ for SOC2 Type 2). Queryable by admins. Exportable for compliance review.

At minimum, audit logs should capture:

• Authentication events (login, logout, failed logins)
• User management (create, update, delete, role change)
• Permission changes
• Data access for sensitive records (depends on product)
• Configuration changes (SSO setup, integration creation, API key creation)
• API key creation and revocation

The logs need to be immutable — an admin shouldn't be able to delete or modify log entries. Write them to append-only storage (separate database, S3 with object lock, dedicated log service).

Encryption

• At rest: database encryption, S3 bucket encryption, encryption of any disk where customer data lives. Use your cloud provider's default (KMS-managed keys) unless the customer specifically asks for BYOK.
• In transit: TLS 1.2+ everywhere. No HTTP. No old ciphers. Let's Encrypt or a managed cert provider handles the hard parts.
• Key management: cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) is the usual answer. Rotate keys on a schedule. Document the key rotation process.

A security page on your site

yourproduct.com/security or /trust should describe your posture. At minimum:

• Overview of your security approach
• Encryption details
• Compliance certifications (including which are in progress)
• Incident disclosure policy
• Contact for security researchers (security@ email, or a bug bounty if you have one)
• Links to your subprocessor list and DPA

This page exists so prospects' security teams can do initial vetting without waiting for you to send them a PDF. It dramatically reduces the friction of the first security conversation.

Tier 2: the common asks

SOC2 Type 2

The audit report that proves your security posture exists in practice, not just on paper. Type 1 is a snapshot; Type 2 proves the controls worked over a period (typically 6–12 months).

Getting SOC2 Type 2 involves:

1. Defining your controls (with help from a tool like Vanta, Drata, or Secureframe)
2. Running the controls for the audit period
3. Passing the audit (conducted by a third-party auditor)
4. Receiving the report

Realistic timeline: 6–9 months from starting the process to receiving a usable Type 2 report. Cost: $30–75K per year depending on auditor and company complexity. Worth it: absolutely, for almost any company seriously pursuing enterprise sales.

Tools that make this much easier: Vanta, Drata, Secureframe. They automate a huge amount of the evidence-collection work. Paying for one of these is close to table stakes if you're going for SOC2.

SCIM provisioning

SCIM is an API standard that lets the identity provider automatically create, update, and deactivate users in your product based on changes in the HR system. When an employee joins, SCIM creates their account. When they leave, SCIM deactivates it.

Prospects with 1000+ employees will ask for this. Without it, they have to manually manage user lifecycle across dozens of SaaS tools, which they hate.

WorkOS, Clerk, and Auth0 also offer SCIM as part of their SSO products. If you're paying for them anyway, SCIM is usually a checkbox.

Data residency

"Can we keep our data in the EU / Canada / Australia?" is a common ask for international buyers. The regulatory version is GDPR Article 44 (restricting transfers of EU personal data outside the EU). The practical version is that the buyer's security policy requires regional data storage.

Delivering this requires:

• The technical ability to deploy your product (app + database) in a specific region
• A per-customer config that routes their data to the right region
• Documentation of what data lives where

For most SaaS products, this means running in multiple cloud regions (us-east-1, eu-west-1, ap-southeast-2, etc.) and having per-tenant routing logic. This is non-trivial — and it's one of the reasons multi-tenancy model choice matters. Database-per-tenant makes data residency much easier than shared-schema.

DPA (Data Processing Agreement)

A contract where you commit to specific data handling practices on behalf of the customer. Required under GDPR; commonly asked for by any enterprise customer.

You can draft a template DPA once (lawyer-reviewed), publish it on your trust page, and offer it as a standard addendum for customer contracts. Most customers will sign your template; a few large ones will want to negotiate.

Pen test report

Annual penetration test from a reputable firm (Bishop Fox, NCC Group, Cobalt, Trail of Bits, etc.). Report summarizes findings and remediation. The report itself is shared (under NDA) with enterprise prospects who ask.

Cost: $15–40K per year depending on scope. Non-negotiable for serious enterprise pursuit.

Build vs. buy tradeoffs

For each of the major components, the build-vs-buy question has a pretty clear answer:

• SSO: Buy (WorkOS, Clerk, Auth0). Building SAML is a 2–6 month senior engineer commitment.
• SCIM: Buy (usually from same SSO vendor). Same reason.
• SOC2 evidence collection: Buy (Vanta, Drata, Secureframe). Manual SOC2 is a nightmare.
• Audit logs: Build or use OSS. The actual logging is not hard; the storage and query UX is. For most products, building is fine. For high-volume audit log requirements, consider a dedicated service.
• RBAC: Build. It's usually tightly coupled to your product's permissions model and doesn't map cleanly to a generic library.
• Encryption at rest: Use your cloud provider's defaults. Don't roll your own crypto.
• Key management: Use cloud KMS. Don't roll your own.
• Security page: Build (it's just a page on your site).
• DPA: Buy the template from a lawyer. Build: don't.
• Pen test: Buy (obviously — can't DIY this).

A realistic timeline

Here's what a disciplined 6-month enterprise-readiness program looks like:

Month 1: Baseline. SSO via WorkOS/Clerk. Basic RBAC if not already present. Audit logging infrastructure. Security page published.

Month 2: SCIM support. Encryption posture verified and documented. Subprocessor list + DPA template published.

Month 3: Vanta/Drata deployment begins. Initial internal policies written. Controls configured. First pen test scheduled.

Month 4: SOC2 Type 1 report ready (shorter audit, proves controls exist). First pen test completed, findings remediated.

Month 5: Tier 2 items — data residency infrastructure (if needed), BYOK planning (if needed).

Month 6: Continue running SOC2 controls toward Type 2 audit (which requires a 6–12 month observation period).

By month 12, you have SOC2 Type 2 in hand and a mature security posture.

Common mistakes

A few traps to avoid:

• Waiting for a specific deal to force the investment. The deal will stall; you'll rush; you'll ship compromises; security teams will notice; you'll lose the deal anyway. Start before you need to.
• Treating SOC2 as the finish line. SOC2 is a starting point. It proves your controls exist; it doesn't prove they're good. Enterprise buyers will still ask follow-up questions that go beyond the report.
• Building SSO from scratch to save money. Almost always a false economy. The edge cases (metadata refresh, signing/encryption, attribute mapping quirks per IdP) will eat your engineers' time for months.
• Ignoring audit logs until a customer asks. Audit logs are hard to retroactively generate. Start logging immediately — you can always add better query tools later.
• Skipping the security page. It's the cheapest possible piece of this and it reduces the friction of every security conversation.

Where to start

If you're not sure whether to start this investment:

• Count the enterprise deals you've lost or stalled on security/checklist items in the last 6 months
• Compare to the cost of the tools above (~$20–50K/year total for SSO + Vanta + pen test + auditor)
• If even one enterprise deal in the pipeline is worth more than that total, you're already losing money by not investing

And if you want us to scope and deliver the whole program, that's part of the Technical Foundation System. Start with a Growth Engine Audit to identify which checklist items are actually blocking your specific deals.