What enterprise buyers ask before they sign

There is a recognisable moment in a growing SaaS product: the first customer arrives whose procurement process is longer than your sales cycle. They like the product. Then a security questionnaire lands, and it asks for things nobody has built. This article is the list, in the order it usually gets asked.

Single sign-on, and why email-and-password is a blocker

Above a certain company size, the security team will not accept a system where employees set their own password and where removing a leaver's access depends on your product being remembered during offboarding. SSO is not a convenience feature to them — it is the control that makes your product acceptable at all.

• SAML 2.0 remains the most widely required protocol in enterprise procurement; OIDC is increasingly accepted and simpler to implement
• Configuration must be per-tenant, since each customer brings their own identity provider
• Decide and document whether SSO is enforced or optional per tenant — security teams will ask, and "optional" often fails the requirement
• Just-in-time user creation on first SSO login avoids a manual user-import step that procurement will notice

SCIM, or the question behind the question

SSO controls authentication. It does not remove a departed employee's account, which is what the auditor actually asks about. SCIM provisioning lets the customer's identity provider create, update and deactivate users in your product automatically.

SCIM is materially more work than SSO and is required less often. A reasonable sequence is to ship SSO first, then SCIM when the second or third enterprise prospect asks — but know that deals above a certain size will require it.

Audit logs the customer can read themselves

An audit log that only your engineers can query is not an audit log as far as procurement is concerned. The requirement is that the customer's own compliance team can answer who did what, when, without asking you.

-- Append-only, tenant-scoped, and exportable without engineering help.
CREATE TABLE audit_events (
  id           bigserial PRIMARY KEY,
  tenant_id    uuid NOT NULL,
  actor_id     uuid,                    -- null for system actions
  actor_email  text,                    -- denormalised: survives user deletion
  action       text NOT NULL,           -- 'invoice.deleted', 'role.changed'
  resource     text NOT NULL,           -- 'invoice:8f3a...'
  before       jsonb,
  after        jsonb,
  ip_address   inet,
  occurred_at  timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX ON audit_events (tenant_id, occurred_at DESC);
CREATE INDEX ON audit_events (tenant_id, actor_id, occurred_at DESC);

Two details matter more than they appear. Denormalising the actor's email means the log remains meaningful after that user is deleted — otherwise a deletion request destroys your audit trail. And recording both before and after states is what makes the log useful in an actual investigation rather than merely a list of verbs.

Data residency: have an answer, even if it is no

You will be asked where data is stored and processed. A precise "all data is stored and processed in Central India, and here are the third-party processors involved" is an acceptable answer. "We are not sure" is not, and neither is a vague reference to the cloud.

1. 01List every region where primary data, backups and logs physically reside.
2. 02List every third-party processor that touches customer data — email, SMS, analytics, error reporting, AI providers — and where each one processes.
3. 03State whether per-region deployment is available, and if not, say so plainly rather than implying it.
4. 04Keep it current. This list drifts every time someone adds a SaaS tool to the stack.

Backup and recovery, stated as objectives

Procurement asks for a recovery point objective and a recovery time objective. Those are numbers you commit to, so they must be derived from a restore you have actually performed rather than from the backup schedule.

That fourth row is where shared-schema products get uncomfortable. Single-tenant restore in a shared schema means restoring a snapshot elsewhere, extracting one tenant's rows and reimporting them through an application-level path. It is workable, and it is slow — which is a legitimate reason some customers require schema or database separation.

Assembling the evidence pack once

The security questionnaire arrives repeatedly with different wording and largely identical substance. Write the answers once, keep them in version control alongside the code, and review them quarterly.

• Architecture overview and data-flow description
• Encryption in transit and at rest, and key management approach
• Access control model, including how privileged access is granted and reviewed
• Secrets management and rotation practice
• Dependency and container scanning cadence
• Incident response runbook, and the date of the last tabletop exercise
• Subprocessor list with regions
• Backup, retention and tested recovery objectives

The honest summary: none of this is exotic engineering. It is a body of work that takes months and is invariably requested with weeks of notice. Building it before the first enterprise prospect asks is the difference between a deal that closes and one that slips a quarter.