Your First Enterprise Customer Wants SSO, Audit and an SLA: What to Build

When your first enterprise customer asks for SSO, an audit log, an uptime SLA and a security review, triage the list before you build. Some items block the signature (SSO, honest questionnaire answers), some can be promised and delivered later (SCIM, custom roles), and some you buy rather than build (the SSO protocol layer). Build what is hard to retrofit, promise the rest, claim no certification you lack.

If you would rather have the enterprise-readiness work scoped and built for you, see how RAITHub would build this below. This guide is the "a real deal just arrived" companion to the broader roadmap in from MVP to enterprise-ready SaaS: that one plans six months of work, this one gets you through the deal in front of you without over-building.

What is the enterprise buyer actually asking for?

Three different teams are asking, and each has its own checklist. The request that reads as one email is really IT, security and procurement each needing a box ticked. Knowing who asks tells you what will actually unblock the contract.

Request	Who asks	What unblocks the deal	Build now or later?
SSO (SAML or OIDC)	IT	Staff sign in with the company identity provider; no extra passwords	Now: usually a hard gate
Audit log	Security, compliance	Who did what, when, viewable and exportable by their admins	Foundation now, viewer later
Role-based access (RBAC)	Security, team leads	Give a user exactly the access their job needs, no more	Now if "is admin" is all you have
Uptime SLA and status page	Procurement, operations	A written availability target and somewhere to see incidents	Now: it is mostly honesty, not code
Security questionnaire	Security	Truthful answers with evidence and a dated plan for gaps	Now: this is what blocks signature
SCIM provisioning	IT	Users auto-created and deactivated from their directory	Later: promise it, build when the second asks
Data export and deletion	Legal	A documented export format and a deletion timeline	Export now, full workflow later

The deal usually hinges on SSO, an honest questionnaire and a written SLA. Build those first. SCIM, custom roles and SIEM streaming can be a dated commitment in the contract.

What does SSO really involve, and should you build it?

Buy the protocol layer; build the parts that touch your data model. The signed-XML or token handling of SAML and OIDC is a solved problem a vendor will sell you; mapping an identity to a tenant and a role is your product's job and cannot be outsourced.

If you can only ship one protocol first, ship SAML, because it is the one large enterprise IT teams most often require, then add OIDC. SAML 2.0 is an OASIS standard from 2005 that sends a signed XML assertion (OASIS SAML 2.0 specifications); OpenID Connect is "a simple identity layer on top of the OAuth 2.0 protocol" using JSON Web Tokens (OpenID Connect Core 1.0). The protocol comparison and a sample SCIM deactivation handler are in from MVP to enterprise-ready SaaS. The hard parts that are yours either way: linking an existing password account to an SSO identity, deciding whether SSO is enforced per organization, and keeping a break-glass admin login for when the customer's identity provider is down.

What audit log do enterprise buyers expect?

Actor, action, target, tenant, time and source, written in the same database transaction as the change, append-only, and exportable by the customer's own admins. Buyers ask three things: can we see it, can we export or stream it, and how long is it kept.

The foundation is hard to retrofit, so build it now even if the viewer screen comes later: once events are written in-transaction and append-only, adding a UI and an export is straightforward. On Sundor Skin, a B2B wholesale platform RAITHub built, the audit log is append-only and hash-chained, written in the same transaction as each change across 146 PostgreSQL tables, among 530+ tests. The design detail, including what never to log, is in SaaS audit log design.

How granular does access control need to be?

Granular enough that a customer admin can grant exactly the access a job needs. That means roles made of named permissions, not a single "is admin" flag, because the next enterprise buyer will ask for read-only auditors and billing-only users.

If permissions were named from the start, those requests are configuration; if access is scattered through "if admin" checks, each one is a code change and a security risk. Sundor Skin runs 12 staff roles built from 88 permission codes with row-level security. The method is in the PostgreSQL row-level security guide. You do not need customer-defined roles for the first deal; you do need permission-based roles so they are cheap to add for the second.

What uptime SLA should you promise?

Most B2B contracts start at 99.9% monthly availability, which allows about 43 minutes of downtime in a 30-day month. Promise only what your monitoring can measure and your deploys and restores can survive.

Target	Allowed downtime / 30 days	What it usually requires
99.5%	About 3.6 hours	One region, managed database, monitoring and alerts
99.9%	About 43 minutes	Zero-downtime deploys, tested restores, on-call, a runbook per failure
99.95%	About 22 minutes	Redundancy across availability zones and fast failover

The figures are arithmetic on a 43,200-minute month. Publish incidents on a status page so the customer sees the same truth you do, and exclude announced maintenance in the contract. Zero-downtime deploys underpin the 99.9% line; the technique is in zero-downtime database migrations for SaaS.

How do you answer the security questionnaire with no SOC 2?

Truthfully, control by control, with evidence and a dated plan for each gap. A SOC 2 report audits the company running the service, so it is yours to obtain, not your development partner's, and many first deals close on a completed questionnaire without one.

The wording, the document pack and which answers are "yes, with evidence" are in your first enterprise security questionnaire, with no SOC 2. For the record: RAITHub is not SOC 2 or ISO 27001 certified, makes no compliance claim, and will not write one onto your form. It builds the controls an auditor tests, signs NDAs and DPAs, keeps production data in your own cloud account and uses synthetic data in development. Legal and contract obligations here are general information; confirm them with your adviser.

What is the minimum to not stall the deal?

1. SSO your buyer's identity provider supports, enforced per organization, with a break-glass admin.
2. An audit log written in-transaction and append-only, exportable on request even if the viewer UI comes later.
3. Permission-based roles, so "read-only" and "billing-only" are configuration, not code.
4. A written 99.9% SLA you can actually meet, plus a status page.
5. A completed, honest security questionnaire with evidence and a dated plan for gaps.

Everything else, SCIM, customer-defined roles, SIEM streaming, regional data residency, can be a written commitment with a date. Promising a date you can hit beats building a feature the deal never required.

Buy, build or hire?

Option	What you get	Choose this when
Off-the-shelf identity service	SAML, OIDC and SCIM protocol handling, and sometimes audit streaming, as a paid service	You need SSO in weeks and your memberships model is already clean
Starter kit or open-source identity server	A self-hosted base you run and patch, with no per-connection fee	You have engineers to run it and want no per-customer cost
Custom build on your stack	Your own tenancy, roles, sessions and audit, often on a vendor for the protocol layer	Enterprise is your core market and these are product features, not a checkbox
Hire a fixed-scope enterprise-readiness release	The whole list audited, built and tested against a deadline	A deal is waiting and nobody in-house has the time or the depth

The common, sensible mix: a vendor for the SSO and SCIM protocols, and your own code for tenants, permissions, sessions and the audit log.

How RAITHub would build this

Because the parts vendors cannot sell you, tenant isolation, permissions and tests that prove them, are what RAITHub has already built on live platforms.

• Scope: audit tenant isolation, memberships and permissions; add SAML then OIDC SSO with per-organization enforcement and a break-glass admin; make the audit log append-only and in-transaction with an export; add permission-based roles, a status page and monitoring for your SLA; assemble an evidence pack mapping each control to a questionnaire answer.
• Timeline: 4–6 weeks at fixed scope for a defined enterprise-readiness release, following the SaaS service range; deeper work such as regional deployment fits the 6–12 week backend range.
• You receive: automated tests and CI, including tests that try to cross tenant and role boundaries; handover docs and runbooks; and full IP under NDA.
• Proof: Sundor Skin has 12 roles from 88 permission codes and a hash-chained audit log across 146 tables (530+ tests); PropDesk serves 4 roles from one codebase (1,024 tests); this site has 400+ tests and database-backed login rate limiting without Redis. See the SaaS development service.

When you don't need us

• Your model is already clean. If memberships and permissions are sound, a vendor plus a week or two of your own time may be all you need.
• No enterprise buyer has asked yet. Put the foundations in place and wait for a real request before building SSO or SCIM.
• You need a SOC 2 report this quarter. That is a CPA-firm audit of your company; RAITHub cannot supply it.
• You want engineers placed in your team. RAITHub offers fixed-scope work and dedicated teams, not staff augmentation.

If a first enterprise deal is waiting on SSO and a security review, send RAITHub the questionnaire and your stack, and book the free 15-minute technical audit.

Documentation checked on 11 October 2026.

Frequently asked questions

What does an enterprise customer need before they will sign?

Usually SSO their identity provider supports, an audit log, permission-based roles, a written uptime SLA with a status page, and honest security-questionnaire answers with evidence. SCIM, custom roles and data residency can often be a dated commitment rather than a built feature for the first deal.

Do I need SOC 2 to close my first enterprise deal?

Not always. Many buyers accept a completed questionnaire with evidence and a dated plan for gaps. SOC 2 is an audit of your company by a CPA firm. RAITHub is not SOC 2 certified and cannot provide one, but it builds the controls an auditor tests.

Should I build SSO or buy it?

Buy the protocol handling (SAML, OIDC, SCIM) from an identity vendor, and build the parts that touch your data model: mapping identities to tenants and roles, enforcing SSO per organization, and a break-glass admin for when the customer's identity provider is down.

What uptime SLA should a SaaS startup promise an enterprise?

99.9% monthly availability is a common starting point, allowing about 43 minutes of downtime in a 30-day month. Promise only what your monitoring measures and your deploys and restores can support, and publish incidents on a status page.

Can I promise SCIM and build it later?

Yes. SCIM auto-provisioning is usually a second-deal requirement, so a dated contract commitment is fine. Build the audit log and permission-based roles now, because those are hard to retrofit; add SCIM when the next customer needs directory-driven user management.

What is the biggest mistake teams make with their first enterprise deal?

Over-building. They construct SCIM, custom roles and residency before the deal requires any of them, and miss the deadline. Triage the request, build only what gates the signature, and put the rest in the contract with dates you can hit.