IGA RFP Scorecard: 25 Questions for Complex Joiner-Mover-Leaver Requirements

A credible IGA RFP does not ask whether a platform “supports JML” in the abstract. It asks the vendor to prove that an authoritative personnel change becomes the right access change, at the right time, with least privilege, across cloud, SaaS, on-premises, and legacy targets. That is the real test behind JML requirements, and it is why a good vendor scorecard needs weighted questions, not vague feature checkboxes.

If you are a CIO, Head of IT, or security leader, the goal is straightforward: faster access, lower service-desk effort, stronger control, and better audit readiness without hidden manual work. The worksheet below gives you a practical starting model for comparing vendor claims in demos and proofs of concept.

How to use this vendor scorecard

The scorecard works because it measures outcomes, not promises. For each question, score the vendor from 0 to 5, then multiply by the weight. Use the raw score alongside the weighted result so a strong dashboard view cannot hide a weak leaver path or a brittle hybrid connector.

A practical process is:

1. Ask the vendor to classify each response as out of the box, configuration, custom development, third-party component, manual step, roadmap, or not supported.

2. Require evidence in the demo or POC, not just a slide.

3. Test the buyer’s representative identity sources and applications, not a generic sandbox.

4. Preserve the limits, failure modes, and compensating controls in the record.

Weighted questions for the core lifecycle

The table below is the worksheet core. It stays intentionally narrow so it can be used in an RFP packet, a demo script, or a POC plan.

#	Scored RFP question	Weight
1	Can it establish authoritative identity data, correlation, and data quality?	5
2	Can it prepare joiners for the right access at the right time?	4
3	Can it execute a mover as an entitlement delta rather than accumulate access?	6
4	Can it execute urgent and scheduled leaver actions completely?	6
5	Can it model contractors, partners, rehires, leave, dual roles, and other worker states?	4
6	Can it connect to the organization’s full hybrid application estate?	5
7	Can it map, scope, match, and reconcile identities and entitlements reliably?	5
8	Can it orchestrate dependencies and recover from partial completion?	4
9	Can it handle errors with safe retries, replay, idempotency, and alerts?	4
10	Can it meet the buyer’s scale, throughput, and lifecycle-latency objectives?	4
11	Can it provide governed self-service requests, approvals, and expiration?	4
12	Can it combine RBAC and ABAC without creating unmanageable role sprawl?	4
13	Can it prevent, detect, and remediate separation-of-duties conflicts?	4
14	Can it run useful access certifications for employees and external users?	4
15	Can it govern privileged, just-in-time, emergency, and administrator access?	3
16	Can it inventory and govern service, API, machine, and other non-human identities?	4
17	Can it govern cloud workloads and AI-agent identities without confusing governance with runtime authorization?	3
18	Can it reveal dormant, duplicate, orphaned, excessive, and unowned access?	3
19	Can it produce attributable, tamper-resistant, audit-ready evidence?	4
20	Can it turn lifecycle and governance data into operational and executive metrics?	3
21	Can it protect the platform, credentials, tenant data, and administrative plane?	3
22	Can it preserve correctness through outage, connector failure, restore, and disaster recovery?	3
23	Can delegated administration and change control scale across business units and regions?	2
24	Can the user, manager, application owner, and service desk experience stay simple?	3
25	Can the customer implement, extend, test, and maintain it without excessive custom work?	6

The weights total 100. Score each question from 0 to 5, then calculate weighted points as weight × raw score ÷ 5.

Score the lifecycle, not the slideware

The most important mistake in an IGA RFP is treating joiner-mover-leaver as a single checkbox. It is not. Each lifecycle state has a different risk profile, different timing needs, and different evidence requirements.

A good vendor scorecard forces the vendor to show how the platform behaves when the source event is messy, the target is legacy, or the workflow breaks partway through. That means you should test the actual transition from source event to target state, not just the existence of a provisioning task.

1. Authoritative identity and correlation

Your first question is whether the platform can establish clean identity data before it touches access. If it cannot reliably distinguish a new person from a rehire, a duplicate, or a record with missing attributes, every downstream decision becomes weaker.

In the demo, use future hires, rehires, duplicates, and records with conflicting values. Ask the vendor to show the correlation decision, the exception queue, source precedence, and the audit history. A manual spreadsheet merge is not governed correlation.

2. Joiners at the right time

For joiners, the issue is not just whether access can be granted. It is whether the platform can stage a pre-hire, activate access on the effective date, and respect approval dependencies and time zones.

This is where many JML requirements fail in practice. A welcome email is not onboarding automation. The platform should distinguish “ready before day one” from “usable before authorization is valid,” and it should show what happens when the event is repeated.

3. Movers as deltas

Movers are where privilege creep starts. A role change should add what is needed and remove what is no longer needed. If the platform only adds new entitlements, it is not managing least privilege.

Test transfers, promotions, temporary assignments, and return-from-leave scenarios. Require the vendor to show the before-and-after entitlement delta, the policy reason for every add and remove, and the removal of obsolete access. This is one of the highest-value questions in any vendor scorecard because it exposes whether governance is really continuous.

4. Leavers without gaps

Leaver control is where business risk becomes operational risk very quickly. Your RFP should separate involuntary termination, resignation, retirement, contractor expiry, leave, and notice-period handling. Each may deserve a different path, but each still needs a complete and provable outcome.

Do not accept a generic “disable user” answer. Ask the vendor to show what happens to sessions, tokens, group memberships, application roles, shared accounts, and ownership. If a target cannot support a specific removal action, the vendor should state that boundary and the compensating control.

5. Complex worker states

Real organizations are not built on a simple active/inactive flag. Contractors, partners, external guests, rehired employees, and dual-role workers all require different rules.

The platform should handle sponsors, end dates, renewals, leave, conversion, and rehire behavior without creating duplicate accounts or accidental reactivation. This matters especially for external identities, where expiration may be the leaver event even when no HR termination exists.

Hybrid coverage, orchestration, and failure handling

The second major test in an IGA RFP is whether the platform can work across the real application estate. That means cloud, SaaS, directories, databases, APIs, file-based targets, and legacy systems. It also means connector maturity, not just protocol support.

6. Connect to the actual estate

SCIM, REST, LDAP, JDBC, SOAP, CSV, and SFTP are useful labels, but they do not prove complete JML behavior. You need to know which integrations are maintained connectors, which are standard protocols, and which depend on custom work or an agent.

In the POC, use one modern SCIM app, one directory, one legacy target, and one API or file-based target. Then run the same joiner, mover, and leaver event across all of them. This is where many JML requirements become visible as target-specific gaps.

7. Reconcile, match, and detect drift

Provisioning and reconciliation are different controls. Provisioning pushes intended state. Reconciliation reads the actual state back and checks it against governance rules.

Your RFP should ask how the platform scopes users, matches records, preserves a watermark or change token, and detects orphaned accounts or drift. If the platform says it “syncs,” that is not enough. You need to know which direction, which cycle, and what happens when the target state differs from the model.

8. Orchestrate dependencies

A real lifecycle transaction crosses systems that fail at different times. Directory creation might happen before application assignment. A license may be needed before a group membership can be added. A manager approval may block a later step.

The vendor should show how the platform branches, waits, runs in parallel, compensates for failure, and avoids false success. A request that was submitted is not the same thing as a request that fully completed.

9. Recover safely from errors

Retries are useful only when they are safe. Without idempotency and clear error classification, replay can create duplicate accounts or repeated entitlement grants.

Your vendor scorecard should force the vendor to show retryable versus permanent errors, backoff behavior, alerting, dead-letter or quarantine handling, and replay controls. Test transient failures, invalid credentials, rate limits, missing attributes, and unsupported operations. Then repeat the same event twice and see whether the result stays clean.

10. Prove scale on the buyer’s workload

Do not let the vendor define scale in the abstract. Measure latency, throughput, queue depth, and manual touches using the buyer’s own representative workload.

Ask for initial load, incremental changes, mass offboarding, concurrent workflows, and certification volume. Also ask what is a hard product limit, what is a target limit, and what is just a recommended operating range. No source in the research supports a universal benchmark, so this has to be tuned to your environment.

Governance controls beyond lifecycle

A strong identity program does more than provision and deprovision. It also governs requests, approvals, reviews, risk, and evidence. These areas matter because they show whether the platform can sustain identity security over time.

11. Govern self-service access

The platform should support request, approval, justification, expiration, renewal, and removal. It should also know who is eligible to request what, and who is allowed to approve it.

This is where service-desk volume can fall if the workflow is clean. But if the request form simply creates a ticket, it has not really reduced work. It has moved the work somewhere else.

12. Balance RBAC and ABAC

RBAC is useful for stable job-function bundles. ABAC is useful for context, such as department, location, employment type, or environment. The danger is role sprawl on one side and opaque policy logic on the other.

Ask the vendor to show how role engineering, attribute provenance, conflict precedence, simulation, and explanation all work together. Good governance should make decisions easier to understand, not harder.

13. Control separation of duties

SoD is not just a report. It should prevent, detect, and remediate toxic access combinations across applications.

The platform should block risky requests before provisioning, detect existing conflicts after aggregation, and support exceptions with owners, reasons, compensating controls, and expiry. If it only finds conflicts after the fact, you still need a remediation path.

14. Review access with evidence

Access certification needs to cover employees, external users, privileged assignments, and cloud resources when relevant. It also needs reviewer models, escalation, reminders, and evidence of action.

Do not accept a review campaign that shows recommendations but cannot prove target removal. Recommendations are not decisions. The platform should show the signals behind a recommendation and preserve the reviewer’s actual choice.

15. Govern privileged and non-human identities

Privileged access, service accounts, machine identities, API identities, cloud workloads, and AI agents all need governance. They are not solved by the same HR-driven lifecycle rules used for employees.

Your RFP should ask whether the platform can assign ownership, track purpose, manage expiry, and flag dormant or overprivileged non-human identities. It should also be clear about where governance ends and runtime authorization begins. That distinction matters for JML requirements in modern hybrid environments.

Evidence, metrics, security, and maintainability

The last set of questions separates a workable platform from a fragile one. They tell you whether the platform can be audited, secured, operated, and extended without excessive custom work.

16. Show audit-ready evidence

The platform should record the actor, subject, source event, target, time, before and after values, policy version, approver, error, and result. It should also make the evidence searchable, exportable, and protected from unauthorized alteration.

In the POC, ask an auditor to reconstruct the full timeline without vendor help. If that is difficult, the evidence model is not strong enough.

17. Turn governance into metrics

Executives will want to know whether the platform improves productivity and control. Operators will want to know where the queues and failures are. Security leaders will want risk and exception data.

Ask what is native, configurable, historical, and exportable. Then require views that show onboarding readiness, leaver latency, request cycle time, review completion, orphan count, and manual touches. The dashboard should be reproducible, not just visually attractive.

18. Protect the platform itself

An IGA platform is a concentration point for identity data and provisioning authority. Its own admin plane, secrets, tenant data, and connector credentials need least privilege and careful control.

Create separate roles for help desk, HR, application owner, auditor, and platform administrator. Then test unauthorized changes, secret handling, MFA or SSO integration, and tenant or business-unit visibility boundaries. A platform that governs identity should be governed well itself.

19. Preserve correctness during failure and recovery

Outage, connector failure, restore, and disaster recovery are not edge cases. They are part of the operating model.

The platform should queue safely, replay correctly, deduplicate events, and preserve ordering where needed. You should also ask what happens if a source, target, agent, or credential store is unavailable. No source in the dossier establishes a universal RTO or RPO, so the buyer must define those acceptance values.

20. Scale delegated administration cleanly

Delegated administration matters when business units and regions do not want every decision to flow through a central team. But delegation must not create hidden policy forks or excessive privilege.

Test region-scoped ownership, global audit visibility, workflow versioning, promotion, rollback, and role boundaries. The platform should let local owners work within clear limits while keeping central governance intact.

21. Keep the experience simple

If users, managers, application owners, and service desk agents cannot understand the process, they will route around it. That is how spreadsheets and email come back.

The best vendor scorecard asks whether each persona sees a simple, role-specific view, a clear status, and a manageable approval flow. Simplicity is not cosmetic here. It is what keeps automation usable.

22. Keep implementation maintainable

Finally, ask how much custom work is required to deploy, extend, test, and maintain the platform. A product can look strong in a demo and still create long-term technical debt.

Have the vendor build a mapping, a workflow branch, an SoD rule, and a failure path using the buyer’s own target systems. Then ask them to change, test, and roll back that logic. If only vendor engineers can do it, your operating cost will follow.

How to interpret the final score

The score is a decision aid, not a universal benchmark. Treat the highest-weight questions as the most dangerous failure points, especially movers, leavers, hybrid integration, audit evidence, and maintainability.

A practical reading is:

• A good total score still needs a strong result on the core joiner, mover, leaver, reconciliation, error-recovery, and audit questions.

• A high score in convenience features does not compensate for weak termination handling.

• Raw scores should remain visible alongside weighted totals so you can see where the risk sits.

Use the result to compare demonstrated outcomes, not vendor rhetoric. If a platform needs too much custom work to fit the buyer’s workload, it may still be the wrong fit even if the total looks attractive.

FAQ

What is the most important question in an IGA RFP?

Ask the vendor to run one complete end-to-end JML event across a cloud application and a legacy or on-premises target, including a mover that removes old access and a leaver with a forced downstream failure. That single scenario exposes workflow logic, connector behavior, error handling, reconciliation, auditability, and manual effort.

How should a buyer score a platform that supports SCIM but not a legacy application?

Score the actual target path, not the protocol name. If the legacy system needs an agent, JDBC, LDAP, API, file exchange, custom adapter, or compensating process, measure the effort, ownership, and evidence on that path. SCIM can earn credit where it genuinely works, but it cannot replace the real requirement.

Should leaver deprovisioning be required in real time?

The buyer should define a risk-based deadline and test from source event to target state. “Real time” is too vague. Require the vendor to show the event model, polling or queue interval, target response, retry behavior, and evidence. Involuntary departures may need a different path from scheduled contractor expiry.

Does access certification replace JML automation?

No. JML creates, changes, and removes access from lifecycle events. Certification is a separate control for continued need, drift, exceptions, guests, and cases automation cannot resolve. A denied review should actually change target state.

Does AI-agent governance mean the IGA platform controls what an agent can do?

Not automatically. The platform may govern inventory, ownership, policy, approval, review, expiry, and evidence, but runtime authorization may live elsewhere. The buyer should require the vendor to identify which layer performs each action and how revocation or reduction is proven.

Close

The strongest IGA RFP turns “supports JML” into observable proof: correct identity data, delta-based movers, complete leavers, hybrid connector behavior, safe failure recovery, least privilege, accountable review, non-human governance, and audit-ready evidence. A weighted 25-question worksheet gives you a practical vendor scorecard for comparing demonstrations and proofs of concept without turning the process into a winner announcement.

If you adapt this model to your own workforce, application estate, and risk posture, you will get a much better read on real fit than any slide deck can provide.