Running an Enterprise IGA Platform RFP: What Actually Differentiated SailPoint, Saviynt, and Oracle IDM

I authored the enterprise Request for Bid for our next-generation IGA platform selection, evaluating SailPoint IdentityIQ, Saviynt, and Oracle IDM against a real requirements set for a large financial services environment. For SailPoint and Saviynt, that included leading hands-on proof-of-concept builds, not just scoring vendor responses on paper; Oracle IDM was evaluated at the requirements level only. This isn’t a platform review — a POC isn’t a production deployment, and I’m not going to pretend otherwise. It’s what the evaluation and POC process together taught me about what actually differentiates IGA platforms when you’re the one who has to defend the requirements and the outcome.

The feature matrix converges faster than you’d expect

All three platforms could do certification campaigns, SoD analysis, role management, and provisioning. A capability checklist alone doesn’t separate them — vendors have converged on the same feature set, more or less, because customers ask for the same things. If the RFP evaluation criteria stop at “does it do X,” every platform passes.

What the POC caught that the paper evaluation didn’t

Oracle IDM was scored on requirements documents and vendor responses alone. SailPoint and Saviynt got a proof-of-concept build against a representative slice of our actual environment — a handful of real connector types, a real (if simplified) role and SoD structure, real HR data patterns. The gap between what a vendor’s response document claimed and what the POC actually surfaced was bigger than I expected going in: connector configuration that looked trivial in the RFP response took real effort against our specific JDBC and disconnected-app patterns, and SoD rule authoring exposed UI and data-model differences between the two platforms that no capability checklist would have caught. A paper evaluation is necessary but not sufficient — for any platform decision this size, I’d push for a POC on the finalists every time.

What actually separated them: fit to the existing landscape

The differentiators that mattered were less glamorous than any feature:

• Connector coverage and integration model fit. How well did each platform’s connector framework match our actual application portfolio — direct connectors, JDBC, web services, and a meaningful number of disconnected legacy applications that needed a manual fulfillment path either way.
• Data model assumptions. Each platform makes implicit assumptions about identity and entitlement data structure. Where those assumptions matched our existing data quality and structure, implementation risk dropped substantially; where they didn’t, the gap became a hidden migration cost that doesn’t show up in a demo.
• Migration path from the incumbent platform. Moving off an entrenched, heavily customized platform isn’t a swap — it’s a multi-year program. Evaluation criteria needed to weight migration complexity and sequencing, not just target-state capability.

Writing evaluation criteria that survive vendor demos

Vendor demos are optimized to look good. The evaluation criteria and success metrics need to be specific enough that they can’t be satisfied by a well-rehearsed demo — tied to our actual use cases (our JML workflows, our SoD rule structure, our certification cadence) rather than generic capability statements. Writing those criteria before the demos, not after, was what kept the evaluation grounded.

The takeaway

An RFP process is as much a discipline exercise for the organization running it as it is a vendor comparison. The requirements document forces you to articulate what your actual governance model needs to look like — role granularity, SoD rule ownership, certification cadence — independent of any platform. That clarity turned out to matter more than which platform won.