The 25-Question IGA RFP Checklist: Surface Every Coverage Gap Before You Sign

Most IGA demos look great. The workflows are clean, the dashboards are polished, and the compliance reports generate in seconds. The problem is that a demo is a controlled environment - and your stack isn't.

57% of organizations report that the high cost of professional services needed for integration is a major barrier to completing their IGA implementation. ^[1] Only 15% of organizations have integrated more than 80% of their applications into their IGA platform. ^[1] The gap between "what the vendor showed us" and "what actually governs our stack" is where access risk lives.

This checklist is designed to close that gap before you sign. Copy it into your RFP. Score every vendor response against the guidance. The questions are deliberately neutral - but they're written to surface the limitations that SCIM-only and legacy tools would rather you discovered in month seven of implementation, not month one of evaluation.

For context on how vendors compare across these dimensions, see our ^[2] and the ^[3].

---

Section 1: App Coverage & Connectors

Q1. Provide a list of the exact applications in our stack that you support today. For each, specify whether the integration uses SCIM, a proprietary API, or another mechanism.

Strong answer: Vendor maps your specific app list - not a generic catalog - and clearly distinguishes SCIM from non-SCIM connectors. Vague references to "thousands of integrations" without specifics are a red flag.

Q2. For applications in our stack that have no SCIM endpoint, what does your platform do? Walk us through a specific example.

Strong answer: Vendor describes a concrete alternative mechanism (direct API, RPA, UI automation) with a named example. "We'd need to scope that" or "we'd build a custom connector" means manual work or PS fees for you.

Q3. What percentage of our current app inventory would be fully automated on day one, versus requiring manual provisioning or a future phase?

Strong answer: A specific percentage with a clear methodology. SCIM coverage typically tops out at 15-25% of a company's SaaS stack when enterprise-tier upgrade costs are factored in. ^[4] Any vendor claiming full coverage without addressing the long tail deserves scrutiny.

Q4. Do any of your connectors require the target application to be on an enterprise or premium pricing tier? List which ones.

Strong answer: A transparent list. Most SaaS vendors lock SCIM behind enterprise-tier plans, with upgrades inflating per-app costs by 3-10x just to unlock provisioning. ^[4] A vendor that can't answer this question clearly is passing that cost to you.

Q5. How do you handle connector maintenance when a SaaS vendor changes their API or UI? Who is responsible, and what is the SLA for restoring a broken connector?

Strong answer: Vendor owns maintenance, with a defined SLA (e.g., 48-72 hours for critical connectors). Custom or brittle connectors that break silently are a common hidden cost in legacy deployments.

---

Section 2: Joiner-Mover-Leaver & the Mover Problem

Q6. When an employee changes roles - say, from Sales to Engineering - describe exactly what happens to their existing access. Is it automatically revoked, flagged for review, or carried forward?

Strong answer: Existing access is automatically flagged or revoked based on policy, not carried forward by default. "Carry forward with a review campaign" is the answer that creates access accumulation over time.

Q7. How does your platform handle partial role changes - for example, a user who moves teams but retains one legacy project assignment?

Strong answer: Granular policy controls that can preserve specific entitlements while revoking others, with an auditable approval trail. Binary joiner/leaver logic that can't handle nuance is a mover problem waiting to happen.

Q8. What is the average time between an HR termination event and complete access revocation across all connected applications?

Strong answer: Near-real-time (minutes, not hours) with a documented SLA. 87% of organizations still depend on manual efforts for core IGA tasks despite the availability of automation tools. ^[1] Delayed offboarding is one of the most common audit findings.

Q9. How does your platform detect and remediate orphaned accounts - accounts that exist in applications but have no corresponding active identity in your HR or IdP source of truth?

Strong answer: Automated discovery and reconciliation on a defined schedule, with evidence of remediation. Manual reconciliation processes or quarterly flat-file comparisons are not sufficient at scale.

---

Section 3: Access Reviews & Certification

Q10. Describe the reviewer experience for an access certification campaign. What information does a manager see, and what actions can they take?

Strong answer: Reviewers see contextual information (last login, entitlement description, peer comparison) - not just a list of checkboxes. In a typical quarterly review, most managers rubber-stamp every line item without reading a single one. ^[5] Reviewer fatigue is a governance failure mode, not a user problem.

Q11. Can you configure risk-based certification - where high-risk entitlements are reviewed more frequently than low-risk ones? How is risk scored?

Strong answer: Yes, with configurable risk scoring based on entitlement sensitivity, last-used date, and peer group analysis. Annual blanket reviews for all entitlements are a compliance checkbox, not a security control.

Q12. What happens when a reviewer misses a certification deadline? Is access automatically revoked, extended, or escalated?

Strong answer: Configurable policy - ideally with auto-revocation as the default for high-risk entitlements and escalation for others. "Access is extended pending review" as the default is a risk accumulation pattern.

---

Section 4: Fine-Grained Entitlements

Q13. For Slack, GitHub, Jira, and Notion - can your platform provision and deprovision at the channel, repository, project, and page level? Demonstrate this in a live environment.

Strong answer: Live demonstration of sub-resource provisioning for each named app. SCIM creates accounts but doesn't handle granular access provisioning - like adding users to specific groups, channels, or projects based on their role, department, or location. ^[6] Vendors that can only provision at the account level leave the most sensitive access decisions manual.

Q14. When a user is deprovisioned, does your platform revoke API tokens, active sessions, and OAuth grants - or only disable the primary account login?

Strong answer: Full revocation including tokens, sessions, and OAuth scopes. Many systems only disable UI login when deprovisioning, which is insufficient for enterprise security. ^[7] A disabled login with live API tokens is not a deprovisioned identity.

Q15. How does your platform handle Separation of Duties (SoD) conflicts at the entitlement level - not just the role level?

Strong answer: SoD policy enforcement at the entitlement level with real-time conflict detection during access requests, not just periodic batch checks. Role-level SoD misses the conflicts that actually cause audit findings.

---

Section 5: Non-Human & AI-Agent Identities

Q16. How does your platform discover, inventory, and govern service accounts, API keys, and OAuth tokens - not just human user accounts?

Strong answer: Automated discovery with ownership assignment, expiration policies, and access reviews for non-human identities. Research from Rubrik Zero Labs puts the non-human-to-human identity ratio at 45:1 in the modern enterprise. ^[8] A platform that only governs human identities is governing a small fraction of your actual attack surface.

Q17. For AI agents and automation bots that request access to production systems - what is your governance model? How are they enrolled, reviewed, and decommissioned?

Strong answer: A defined lifecycle for AI agent identities with ownership, scoped permissions, and periodic review. A 2025 WEF analysis found that 51% of organizations report no clear ownership of AI identities. ^[9] "We're working on it" is not an acceptable answer in 2026.

---

Section 6: Deployment & Time-to-Value

Q18. What does a realistic deployment timeline look like for an organization of our size and stack complexity? Break it down by phase, and tell us what your team delivers versus what we need to provide.

Strong answer: A phased timeline with specific milestones, clear ownership split, and a named reference customer at similar scale. Legacy IGA implementations typically take between 12 and 18 months to deliver full value. ^[10] Any vendor quoting "6-18 months" for a mid-market deployment should explain why.

Q19. What internal resources - headcount, engineering hours, dedicated IAM staff - are required to maintain the platform post-deployment?

Strong answer: Specific estimate in hours per week, with a reference customer running a similar-sized team. Platforms that require a dedicated IAM engineer to stay operational are not designed for lean teams.

Q20. Can we run a proof-of-concept against our actual app inventory - not a sandbox - within 30 days? What does that require from us?

Strong answer: Yes, with a defined PoC scope and a clear list of prerequisites. Vendors who can't demonstrate value against your real stack in 30 days are telling you something about their deployment complexity.

---

Section 7: Pricing & Total Cost

Q21. Break down your pricing model: what is included in the base subscription, and what triggers additional fees? Specifically: per-connector fees, enterprise-tier upgrades required for specific apps, and professional services costs.

Strong answer: A fully itemized breakdown with no "it depends" answers. Professional services costs for IGA implementations typically run 20-40% of total project costs. ^[11] Ask for year-one and year-three cost projections separately.

Q22. Are there connectors or features that are only available on higher pricing tiers? List them.

Strong answer: A complete list. Pricing models that gate governance features behind enterprise tiers create a situation where the platform you evaluated is not the platform you can afford to run. See our ^[12] for a detailed comparison of how vendors structure these costs.

Q23. What is the total cost of ownership for a company of our size over three years, including software, implementation, professional services, and internal headcount?

Strong answer: A specific three-year TCO model with assumptions stated. Vendors who can only quote year-one software costs are obscuring the real number.

---

Section 8: Compliance & Audit Evidence

Q24. For a SOC 2 Type II or ISO 27001 audit, what evidence does your platform produce automatically? Show us a sample access review report and a sample provisioning/deprovisioning log.

Strong answer: Live demonstration of audit-ready exports - timestamped, reviewer-attributed, and exportable in auditor-friendly formats. "We can generate that" is different from "here it is."

Q25. If an auditor asks about access to an application that is not connected to your platform - a tool your platform doesn't govern - what is your answer?

Strong answer: The vendor acknowledges the gap and explains how they handle ungoverned apps (discovery, manual attestation workflow, or native coverage). A vendor who claims this scenario doesn't apply to their platform hasn't understood your stack.

---

How to Score Vendor Responses

Use this widget to score each vendor across the eight sections and generate a weighted comparison.

---

What to Do With the Responses

A strong RFP response isn't a marketing document - it's a set of specific, demonstrable claims. For every answer that matters, ask the vendor to prove it in a live environment against your actual app inventory, not a pre-configured demo tenant.

The questions in Section 1 (App Coverage) and Section 7 (Pricing) tend to produce the most differentiation. Vendors who can't answer Q1, Q4, and Q21 with specifics are telling you that the gaps and costs are real - they just don't want to name them before you sign.

For a deeper look at how the leading platforms compare on these dimensions, see the ^[2] and the ^[3].