RFP builder.

# Customer Identity & Access Management (CIAM), Request for Proposal

**Company:** [Company name]
**Contact:** [Contact name]
**Submission deadline:** [Date]

## 1. About us

[Brief description of company, product, and current identity stack.]

## 2. Project scope

- **Customer segment:** B2B SaaS / enterprise
- **Current MAU:** 10,000
- **12-month projected MAU:** 100,000
- **Geographic region:** US + EU
- **Deployment preference:** Managed SaaS only

## 3. Functional requirements

45 requirement(s), of which 23 are MUST. A MUST that
cannot be met should be called out explicitly in your response rather than
answered generally, because we will treat an unqualified "yes" against a
requirement that fails its acceptance test as a disqualifying answer.

Each requirement below carries the acceptance test we intend to run during
evaluation. Please respond per requirement ID with one of:

- **Met**: shipped today, and we can demonstrate the acceptance test.
- **Partial**: describe exactly what is and is not covered.
- **Roadmap**: give a date and say whether it is committed or aspirational.
- **Not met**, and tell us what you would suggest instead.

### Authentication and federation

How an enterprise user proves who they are, and what the platform does with the assertion afterwards.

#### AUTH-01 · MUST

Enterprise users can sign in with SAML 2.0 or OIDC against their own identity provider.

*Why this is on the list:* This is the line item that unblocks enterprise deals. Everything else in this document assumes it works.

*How we will verify it:* Complete an end-to-end login against both a Microsoft Entra test tenant and an Okta developer org. Two IdPs, because supporting one is not supporting SSO.

#### AUTH-02 · MUST

Assertions are cryptographically verified (signature, issuer, audience, recipient, expiry) before any identity is resolved.

*Why this is on the list:* An assertion accepted before validation is an authentication bypass. Verification after identity resolution is the same bug with extra steps.

*How we will verify it:* Submit a tampered signature, a wrong audience, an expired assertion, and a replay of a previously valid one. All four must be rejected, and each rejection must appear in a log you can query.

#### AUTH-03 · MUST

The assertion carries the organization or connection identifier, so the application can resolve which workspace the user lands in.

*Why this is on the list:* Without it you are inferring tenancy from the email domain, which breaks on shared domains, acquisitions, and contractors.

*How we will verify it:* Inspect the callback payload. Confirm a connection or organization identifier is present and stable across logins, and that it is not the email domain.

#### AUTH-04 · SHOULD

The login flow supports identifier-first SSO detection: the user types an email, the platform detects an enterprise account, and routes to SSO.

*Why this is on the list:* The alternative is a separate 'Sign in with SSO' button that enterprise users never find, which turns into a support ticket per new employee.

*How we will verify it:* Enter an address on a claimed domain and confirm the redirect happens with no password field shown. Enter an unclaimed address and confirm the self-serve path is offered instead.

#### AUTH-05 · SHOULD

Multi-factor policy is enforceable per organization, not only globally.

*Why this is on the list:* One enterprise customer's security team will require MFA before another customer is ready for it. A global switch means you cannot satisfy both.

*How we will verify it:* Enforce MFA on tenant A and not on tenant B in the same environment. Confirm enforcement at login and at step-up, and confirm tenant B is unaffected.

#### AUTH-06 · SHOULD

SSO is enablable per tenant and per environment behind a flag, with a kill switch that stops new SSO logins and falls back to the incumbent path without destroying provisioned users or workspaces.

*Why this is on the list:* A federation rollout that cannot be turned off is a rollout you cannot start. The destructive version of a kill switch, where disabling SSO deletes the users it created, is worse than having none.

*How we will verify it:* Enable for one tenant in staging, provision users, then throw the kill switch. Confirm users, workspaces, memberships, and roles all survive, and confirm the documented behaviour of sessions already in flight.

### Identity model and account linking

Who owns the canonical user record, and the rules that decide when two identities are the same person.

#### IDM-01 · MUST

A user who signs in resolves to an identity native to your own user space, not to a vendor-owned user object you are required to adopt as your own.

*Why this is on the list:* This is the deepest lock-in vector in the category, and it does not look like lock-in on day one. If the vendor's user object is your user object, your data model is rented and your migration cost grows with every feature you ship.

*How we will verify it:* Confirm you can hold your own user row, keyed by your own identifier, with the vendor's subject stored as one more foreign key on it. If the integration guide tells you to key application tables on the vendor's ID, that is the finding.

#### IDM-02 · MUST

Your own generated identifier remains the canonical user ID. Nothing in the flow requires your user ID to equal the vendor's subject.

*Why this is on the list:* Identifiers propagate. Once a vendor subject is in your URLs, your API responses, your data warehouse, and your customers' integrations, it is no longer a vendor identifier, it is your public contract.

*How we will verify it:* Create a user carrying your own identifier and confirm every relevant API accepts a lookup by it, or by an external-ID mapping you control.

#### IDM-03 · MUST

The platform reports, per connection, whether the asserted email is verified and whether domain ownership has been established.

*Why this is on the list:* Automatically linking an unverified asserted email to an existing account is an account-takeover primitive. You cannot make a safe linking decision without knowing which of the two facts the platform is actually asserting.

*How we will verify it:* Ask for the exact field names and their semantics, then configure a connection that asserts an unverified address and confirm the flag changes.

#### IDM-04 · SHOULD

Account-linking rules are deterministic, documented, and never silently merge two accounts on an email match alone.

*Why this is on the list:* Silent merges are unrecoverable. Two humans become one record, and the audit trail that would let you unpick it is the thing you just merged.

*How we will verify it:* Sign in through a second connection with an address that already exists locally. Confirm the outcome is the documented one, and that a merge, if it happens at all, is an explicit action you triggered.

### Organization modelling and provisioning

Tenancy, membership, and what happens the first time an unknown company signs in.

#### ORG-01 · MUST

The platform models organizations and memberships as first-class objects, with a user able to belong to zero, one, or many organizations.

*Why this is on the list:* One membership per user is the assumption that is cheapest to adopt and most expensive to remove. Contractors, agencies, and acquisitions all produce a legitimate two-organization human.

*How we will verify it:* Put one identity into two organizations. Confirm both memberships exist with independent roles, and that the platform can tell you which one a given session is acting in.

#### ORG-02 · SHOULD

Just-in-time provisioning is supported: the first SSO login from an unknown organization creates a workspace and seeds that first user as its owner.

*Why this is on the list:* Without it, every new enterprise connection needs an operator to pre-create the workspace, which puts your team on the critical path of your customer's rollout.

*How we will verify it:* Sign in from a fresh domain. Inspect the resulting organization, membership, and role assignment, and confirm the first user is an owner rather than a member with no administrative path.

#### ORG-03 · SHOULD

An operator can attach an organization to an existing contracted workspace, after which that organization's users resolve into it.

*Why this is on the list:* The customer you already signed has a workspace, users, and data. Their first SSO login must land there rather than somewhere new.

*How we will verify it:* Attach a connection to a pre-existing workspace that already has content, then sign in. Confirm the user lands in the existing workspace with the existing data intact.

#### ORG-04 · SHOULD

Domain gating is supported, so designated contracted domains are excluded from just-in-time creation and attach to the right workspace instead.

*Why this is on the list:* This is the control that stops your largest customer from silently acquiring a second, empty, shadow workspace on the day they turn on SSO. Support finds out when the customer asks where their data went.

*How we will verify it:* Add a domain to the gated list, then attempt a JIT login from it. Confirm the attach path runs and no new workspace is created.

### Customer self-service onboarding

Whether your customer's IT admin can configure and debug their own connection without opening a ticket with you.

#### ONB-01 · SHOULD

New enterprise connections can be configured by the customer through a hosted admin portal you link them to, for both SSO and directory sync.

*Why this is on the list:* Connection setup is the single largest source of implementation support load in B2B identity, and it is work only the customer's IT admin can do.

*How we will verify it:* Generate a portal link as an operator, then complete a full connection as the customer with no involvement from your team. Time it.

#### ONB-02 · SHOULD

Customers can diagnose their own SSO login failures without contacting you.

*Why this is on the list:* Otherwise every misconfigured attribute mapping in your customer base becomes a ticket in your queue, escalated to a vendor you are relaying for.

*How we will verify it:* Deliberately misconfigure an attribute mapping and a certificate, then read the error as the customer admin sees it. An opaque failure code is the finding.

#### ONB-03 · SHOULD

Certificate expiry is notified ahead of time, and rotation is self-serve.

*Why this is on the list:* A SAML signing certificate expires on a date nobody has in a calendar, and the first symptom is an enterprise customer unable to log in on a Monday morning.

*How we will verify it:* Establish the notification lead time, the channel, and who receives it. 'It is visible in the dashboard' means nobody receives it.

### Directory sync and deprovisioning

The lifecycle half of enterprise identity, and the half that fails silently.

#### SCIM-01 · MUST

The SCIM 2.0 endpoint is hosted and maintained by the vendor, with lifecycle events consumed by you over an API or webhooks.

*Why this is on the list:* SCIM conformance is a long tail of per-IdP quirks. Hosting the endpoint yourself means owning that tail forever.

*How we will verify it:* Confirm the endpoint is theirs, and that the events reaching you are normalized rather than raw per-IdP payloads you have to reconcile.

#### SCIM-02 · MUST

Deprovisioning arrives as an event you act on, not as a deletion the vendor performs on your user record.

*Why this is on the list:* Your user row has foreign keys, content ownership, and audit history hanging off it. A forced delete originating outside your system is a data-integrity incident, not a lifecycle feature.

*How we will verify it:* Deprovision a user who owns content. Confirm you received an event and that nothing was removed on your side until you acted on it.

#### SCIM-03 · MUST

The soft signal (user updated, active set to false) and the hard signal (user deleted) are surfaced as distinct events.

*Why this is on the list:* They mean different things. One is an offboarding you should reflect by suspending access and keeping the record; the other is a deletion request. Collapsing them forces you to guess.

*How we will verify it:* Trigger each separately from the IdP and confirm two distinguishable events arrive, with the distinction visible in the payload rather than inferred.

#### SCIM-04 · SHOULD

Directory group membership changes map to application roles.

*Why this is on the list:* Group-driven roles are what makes access management self-service for the customer. Without it, IT provisions the user and then emails you about their permissions.

*How we will verify it:* Add to a group, remove from a group, and rename a group. Removal and rename are handled less reliably than addition in most implementations, and rename breaks anything keyed on display name.

#### SCIM-05 · SHOULD

End-to-end deprovisioning latency is documented, split into the portion the vendor owns and the portion determined by the IdP's own push behaviour.

*Why this is on the list:* This number goes into your security questionnaire answers and your customer contracts. Half of it is not yours to control, and you need to know which half before you commit to it in writing.

*How we will verify it:* Ask for the split explicitly. Then measure it yourself against both IdPs, because the documented figure is rarely the one you will observe.

#### SCIM-06 · MUST

SCIM operations are idempotent and replay-safe.

*Why this is on the list:* Retries happen. A non-idempotent provisioning pipeline turns a transient network failure into duplicate users or a double role grant.

*How we will verify it:* Replay an identical operation several times. Confirm exactly one state change, no duplicate records, and no additional outbound events.

#### SCIM-07 · MUST

Every SCIM request is authenticated against a per-connection bearer token, failing closed before any mutation, with tokens rotatable without downtime.

*Why this is on the list:* A shared token across connections means one customer's leaked credential is every customer's exposure. Failing open on an auth error means an unauthenticated request can mutate your directory.

*How we will verify it:* Send a request with a revoked token and confirm it fails before any state change. Then rotate a live token and confirm provisioning continues.

#### SCIM-08 · SHOULD

Deprovisioning the last owner of a workspace is visible to you, so you can refuse it or require a replacement owner.

*Why this is on the list:* An IdP offboarding an administrator will happily orphan a paying workspace, and nobody notices until someone needs to change a billing detail nobody can reach.

*How we will verify it:* Deprovision the sole owner of a test workspace. Confirm you can detect the condition before applying it, rather than discovering it afterwards.

#### SCIM-09 · MUST

Both common PATCH request shapes for user deactivation are handled, as sent by Microsoft Entra and by Okta.

*Why this is on the list:* RFC 7644 permits both a pathed and an unpathed replace operation. A platform that handles one and rejects the other works for half your enterprise customers and fails for the rest.

*How we will verify it:* Send both shapes. Each must deactivate the user rather than return a 400, and each must produce the same local state.

### Sessions

Session ownership, lifetime, revocation, and logout across two systems that both think they own the browser.

#### SESS-01 · MUST

Nothing in the flow requires you to adopt a second browser cookie, or to make the vendor's session your browser session.

*Why this is on the list:* Two session authorities in one browser means two expiry policies, two logout paths, and a class of bug where a user is signed out of one and not the other.

*How we will verify it:* Complete a login and inspect the cookie jar. Confirm your own session cookie remains authoritative and that the vendor's is either absent or not load-bearing.

#### SESS-02 · SHOULD

Session lifetime is configurable, forced re-authentication is supported, and IdP-driven single logout works.

*Why this is on the list:* Enterprise security teams ask for all three by name, and single logout in particular is frequently claimed and rarely tested.

*How we will verify it:* Trigger a logout from the IdP side and confirm the application session actually ends, rather than surviving until its own expiry.

#### SESS-03 · SHOULD

Revocation-to-effect latency is measurable and documented, per user, per device, and per tenant.

*Why this is on the list:* A revocation you cannot time is a revocation you cannot put in an incident-response runbook. Cached access tokens frequently remain valid well past the revocation call.

*How we will verify it:* Revoke an active session and measure, on a real client, how long until requests actually fail.

### Audit and observability

What the platform records, what it will hand you, and what it will tell you when something stops working.

#### AUDIT-01 · MUST

An event stream, by pull API or webhook, covers SSO connection lifecycle and directory sync events, and can be forwarded into your own audit store.

*Why this is on the list:* Identity events are evidence. Evidence that lives only in a vendor console, under that vendor's retention policy, is evidence you will not have when you need it.

*How we will verify it:* Subscribe, trigger a connection change and a sync, and confirm both arrive with enough detail to reconstruct what happened.

#### AUDIT-02 · MUST

SSO and directory sync failures are observable and alertable to your operators, including the case where a connection simply stops producing events.

*Why this is on the list:* Provisioning breaks silently. An expired token or a changed mapping produces no failing request, so there is nothing to alert on unless absence itself is the signal.

*How we will verify it:* Revoke a working sync token without telling anyone, wait 48 hours, and record what arrived. Usually nothing does, and that tells you which alarm you have to build.

#### AUDIT-03 · SHOULD

Customer-facing audit export is available, with a stated retention window in days on the tier you are actually buying.

*Why this is on the list:* Retention is a pricing lever rather than a security decision, and the tier with a usable window is rarely the tier in the quote.

*How we will verify it:* Get the number in days for your specific tier, in writing, alongside whether streaming is available on it.

#### AUDIT-04 · SHOULD

The vendor states clearly whether the audit log is automatically populated by the platform or emitted by your application.

*Why this is on the list:* An audit log you have to populate yourself is a storage product. Both models are defensible, and discovering which one you bought after the compliance review has started is not.

*How we will verify it:* Ask directly, then check an event you did not emit. If nothing is there, you have your answer.

### Privacy and data lifecycle

Erasure, export, residency, and the fan-out problem when one human has five linked subjects.

#### PRIV-01 · MUST

The platform exposes a provider-agnostic enumeration of every subject linked to one user, so your deletion fan-out is not one provider at a time.

*Why this is on the list:* A single human may be a password identity, two social subjects, and a federated identity. An erasure obligation covers all of them, and an API that only answers per-provider makes completeness impossible to prove.

*How we will verify it:* Link several identities to one user, then call the enumeration and confirm every subject is returned in one response.

#### PRIV-02 · MUST

Vendor-side user deletion is callable from your own workflow and confirms completion, so you can evidence an erasure request.

*Why this is on the list:* Under GDPR the controller has to demonstrate erasure, not merely request it. A deletion with no confirmation is not evidence.

*How we will verify it:* Delete through the API and capture the response. Then confirm the record is genuinely gone rather than flagged, and establish the backup retention window.

#### PRIV-03 · SHOULD

Data residency or region controls for identity data are stated, along with the sub-processor list and its change-notification policy.

*Why this is on the list:* Residency is frequently available for the primary store and not for logs, backups, or support tooling, and the gap is what an auditor finds.

*How we will verify it:* Ask specifically where logs and backups live, not only the primary datastore.

### Security posture

The attestations, the controls behind them, and the limits that apply to you in production.

#### SEC-01 · MUST

A current SOC 2 Type II report and a signable data processing agreement are available.

*Why this is on the list:* Your own enterprise customers will ask for evidence about your sub-processors, and you cannot answer for a vendor that cannot answer for itself.

*How we will verify it:* Read the report rather than the badge. Check the observation period, the exceptions, and whether the identity product is actually in scope.

#### SEC-02 · MUST

Data is encrypted at rest and in transit, with documented key management and a stated password hashing algorithm and work factor.

*Why this is on the list:* 'Encrypted at rest' is universally claimed and describes disk encryption as readily as it describes a considered key hierarchy.

*How we will verify it:* Ask which algorithm hashes passwords, at what cost parameters, and who can access the keys.

#### SEC-03 · MUST

The platform defends against bots, credential stuffing, brute force, and volumetric attack, with controls you can tune per endpoint.

*Why this is on the list:* Registration, login, and recovery have different abuse profiles, and a single global threshold is either too loose for login or too tight for recovery.

*How we will verify it:* Run a credential-stuffing traffic pattern rather than a clean load test, and observe what engages and what it returns.

#### SEC-04 · MUST

API rate limits are documented, including per-tenant dimensions and the process for raising them.

*Why this is on the list:* An undocumented limit is discovered in production, usually during your largest customer's onboarding, when their initial directory sync fires thousands of requests at once.

*How we will verify it:* Get the numbers and the dimensions in writing. Then confirm one large tenant cannot exhaust a limit on behalf of every other tenant.

### Portability and exit

What you can take with you. Ask before signing, because the answer never improves afterwards.

#### EXIT-01 · MUST

Password hashes are exportable, with the algorithm, parameters, and encoding documented, and the entitlement stated in the contract.

*Why this is on the list:* Import tooling is a sales function and export tooling is a retention risk, so the two are rarely built to the same standard. Without hash export, leaving means a forced password reset for your entire user base.

*How we will verify it:* Request an export during evaluation and import one hash into a sandbox elsewhere. Confirm the contract clause covers credentials and not only 'customer data'.

#### EXIT-02 · SHOULD

Users, organizations, memberships, roles, and connection configuration are all exportable as data.

*Why this is on the list:* A profile-only export leaves the structure behind, and the structure is the part you spent two years building.

*How we will verify it:* Export everything during the POC and check what is missing. Configuration is usually the gap.

### Commercial and support

Cost behaviour at the scale you expect, and who is in the room during implementation.

#### COMM-01 · SHOULD

Pricing is modelled against your own three-year projection, including which of the requirements above sit behind a higher tier.

*Why this is on the list:* Cost failures in this category are almost never the unit price. They are a feature gate discovered in year two, when the enterprise customer who needs it is already signed.

*How we will verify it:* Take your MAU curve, enterprise-tenant count, and this requirement list to each vendor, and ask which lines change the tier.

#### COMM-02 · SHOULD

Solutions engineering works alongside your engineers during implementation, through a shared channel.

*Why this is on the list:* The first federated customer surfaces every ambiguity in the integration at once, and usually on the customer's timeline rather than yours.

*How we will verify it:* Confirm it is contractual rather than a POC courtesy, and establish what happens to the channel after go-live.

#### COMM-03 · SHOULD

The vendor gives a realistic estimate of time to first enterprise customer live and engineer-days required on your side, against this requirement list.

*Why this is on the list:* An estimate given against a feature list is always weeks. An estimate given against acceptance tests is the honest number, and the difference between the two is the most useful thing you will learn during evaluation.

*How we will verify it:* Ask for it in writing with the requirement IDs referenced, then compare it against what the POC actually took.

## 4. Non-functional requirements

### Compliance and certifications

The platform must demonstrate the following certifications or attestations:

- [ ] SOC 2 Type II attestation / certification
- [ ] GDPR attestation / certification

Please attach the most recent attestation reports under NDA.

### Security

- Encryption at rest and in transit (specify algorithms and key management).
- Logging, monitoring, and incident response posture.
- Vulnerability disclosure program.
- Penetration test cadence and access to redacted reports.

### Reliability

- Documented SLA for authentication endpoints (target: 99.99% monthly).
- Multi-region failover architecture.
- Recent incident history (12 months) with public post-mortems if any.

### Data handling

- Data residency guarantees for our region (US + EU).
- Sub-processor list and change-notification policy.
- GDPR/CCPA data export and deletion endpoints.

## 5. Integration and developer experience

- SDK availability for our application stack.
- Authentication API documentation and reference architecture.
- Migration tooling from our current identity store.
- Sandbox / preview environment for evaluation.

## 6. Commercial terms

Please provide:
- **Pricing model** at our current MAU and at 12-month projected MAU.
- **Effective per-MAU rate** at each band, including any feature upcharges.
- **Multi-year commitment discounts** if applicable.
- **Free trial or POC structure** for evaluation.
- **Contract terms** including data ownership, termination, and exit assistance.

## 7. Timeline

- **Pilot deployment:** 6 weeks from contract
- **Full production cutover:** 12 weeks from contract

## 8. Evaluation criteria

Vendors will be evaluated on:

1. Capability coverage of the functional requirements (35%).
2. Total cost of ownership over 3 years (25%).
3. Compliance and security posture (15%).
4. Integration / migration effort (15%).
5. Reference customer feedback at our MAU band and segment (10%).

## 9. Submission instructions

Please submit your response in PDF format to [Contact email] no later than [Date]. Include:

- Completed responses to sections 3 and 4 with capability evidence.
- Pricing detail per section 6.
- Two reference customer contacts at our MAU band and segment.
- Sample contract for review.

We will respond within 10 business days of submission with shortlist results and interview invitations.

---

*Generated with the CIAM Compass RFP builder, https://guptadeepak.com/ciam-compass/tools/rfp-builder/*