Most identity governance RFPs ask whether a product "supports joiner, mover and leaver" or "has access reviews", every bidder answers yes, and the real differences only appear after contract signature, during connector work. This template gives you a ready-to-issue request for proposal for an identity governance and administration (IGA) platform, with numbered requirements written so that answers can be verified in a proof of concept and scored. It covers lifecycle automation, access requests, certifications, roles and segregation of duties, connectors, non-human identities and AI agents, platform security, services and commercials. It is vendor-neutral and written for IAM leads, procurement and evaluation panels. For what to look for in the market, read the IGA Buyer's Guide; for the selection process itself, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [HR system] and [number], with your own details. Remove requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example IGA-LC-03) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (weighted 0 to 5) or I informational (not scored). Keep M items few.
- Weights, volumes and timings in brackets are illustrative, not benchmarks. Set them from your own risk, audit findings and scale before issue, and do not change them after responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your panel only.
- Ask for the response in a spreadsheet with one row per requirement ID, so answers compare line by line.
1. Purpose and scope
[Organisation] invites proposals for an identity governance and administration platform and associated implementation services. The platform must establish who has access to which systems and data, why they have it, who approved it and for how long, for workforce, third-party and non-human identities.
- In scope: identity lifecycle automation driven by authoritative sources; access requests and approvals; access certification; role and policy management; segregation of duties (SoD); provisioning and reconciliation for [number] applications; governance of service accounts, OAuth applications, API keys and AI agents; audit reporting.
- Out of scope: [workforce authentication and SSO, which remain with the existing identity provider]; [privileged session management, covered by a separate procurement]; [customer identity].
- Contract term: [three] years with an option to extend by [two] years.
- Drivers: [audit findings on leaver access]; [SOX, PCI DSS, DORA or other obligations]; [manual review effort]; [growth in non-human identities].
2. Organisation background and current state
Bidders need enough context to give realistic answers and estimates. Share detail beyond this table only under a signed NDA.
| Item | [Organisation] value |
|---|---|
| Workforce identities (employees, contractors, partners) | [number], [number], [number] |
| Non-human identities known today (service accounts, service principals, OAuth apps, API keys, agents) | [number or "unknown, discovery required"] |
| Authoritative sources | [HR system], [contractor management system], [partner portal] |
| Directories and identity providers | [on-premises directory], [cloud identity provider] |
| Applications in scope, by integration type | [number] with SCIM or a standard API; [number] directory-integrated; [number] database or file based; [number] with no programmatic interface |
| Cloud platforms | [cloud providers and number of accounts, subscriptions or projects] |
| Current IGA tooling and processes | [existing product, scripts, spreadsheets, ticketing system] |
| Review cadence and population | [quarterly privileged, annual standard], [number] reviewers |
| Hosting and data residency constraints | [SaaS acceptable in named regions / on-premises required] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; answers shared with all bidders by [date]; responses due [date, time, time zone]; shortlist and proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other [Organisation] staff about this RFP during the process may lead to disqualification.
- Response scale: for each requirement state one of: available now; available with configuration; available with custom development; third-party product required (name it); roadmap (with a committed date); not supported. Roadmap answers score zero unless the date is contractually committed.
- Evidence: reference the product documentation page, screenshot or demonstration that supports each "available now" answer.
- Assumptions: list every assumption behind your implementation estimate, including [Organisation] effort.
4. Functional requirements
4.1 Identity lifecycle
| ID | Requirement | Type |
|---|---|---|
| IGA-LC-01 | Creates identities and birthright access automatically from [HR system] events for joiners, including future-dated starts. | M |
| IGA-LC-02 | On a mover event, re-evaluates all access, removes access no longer justified by policy after a configurable grace period, and records each removal. | M |
| IGA-LC-03 | On a leaver event, disables accounts in connected systems within [the time your policy sets] and creates tracked tasks for disconnected systems. Describe how completion is verified. | M |
| IGA-LC-04 | Handles rehires, name changes, multiple concurrent jobs and conversions between contractor and employee without duplicate identities. | S |
| IGA-LC-05 | Detects accounts in target systems with no matching identity (orphans) and accounts held by leavers, through scheduled reconciliation. | S |
| IGA-LC-06 | Supports non-employee lifecycle with sponsor, end date and periodic sponsor re-confirmation. | S |
See the Joiner-Mover-Leaver Guide for the process design these requirements test.
4.2 Access requests and approvals
| ID | Requirement | Type |
|---|---|---|
| IGA-AR-01 | Provides a searchable catalogue of entitlements, roles and access packages with business-readable descriptions and owners. | S |
| IGA-AR-02 | Routes approvals by policy (manager, entitlement owner, risk-based additional approver) with delegation and escalation. | M |
| IGA-AR-03 | Supports time-bound access with automatic removal at expiry. | M |
| IGA-AR-04 | Checks SoD and policy before approval and shows the approver any conflict. | S |
| IGA-AR-05 | Integrates with [ticketing system] for request intake and fulfilment of manual tasks, with status written back. | S |
4.3 Access certification
| ID | Requirement | Type |
|---|---|---|
| IGA-CR-01 | Runs manager, entitlement owner and application owner campaigns, plus event-triggered micro-certifications (for example after a mover event). | M |
| IGA-CR-02 | Shows reviewers context for each item: last use, peer comparison, risk, how and when access was granted. | S |
| IGA-CR-03 | Executes revocations automatically on connected systems and verifies removal at the next reconciliation (closed loop). | M |
| IGA-CR-04 | Detects and reports bulk approval patterns that indicate rubber-stamping. | S |
| IGA-CR-05 | Produces an evidence pack per campaign: population, reviewer decisions with timestamps, revocations and their completion. | M |
4.4 Roles, policy and segregation of duties
| ID | Requirement | Type |
|---|---|---|
| IGA-RS-01 | Provides role mining from current entitlements and attributes, with role lifecycle (owner, review, versioning). | S |
| IGA-RS-02 | Defines SoD rules across applications at entitlement level, with preventive (at request) and detective (scheduled) checks. | M |
| IGA-RS-03 | Records mitigating controls and time-limited exceptions for accepted conflicts, with an owner and expiry. | S |
| IGA-RS-04 | Supports attribute-based policies for birthright and eligibility in addition to roles. | S |
4.5 Connectors, provisioning and reconciliation
| ID | Requirement | Type |
|---|---|---|
| IGA-CN-01 | List supported connectors for the applications in Appendix A, stating for each: read only or read and write, supported objects (accounts, groups, roles, entitlements) and whether the connector is maintained by the bidder, a partner or the customer. | M |
| IGA-CN-02 | Supports SCIM 2.0 (RFC 7643 and RFC 7644) as both client and, where applicable, service provider. | S |
| IGA-CN-03 | Provides a supported method for applications with no API (file, database or tracked manual fulfilment) with reconciliation. | S |
| IGA-CN-04 | Describe the effort, skills and typical duration to build a custom connector, and who maintains it through upgrades. | I |
| IGA-CN-05 | Connector credentials stored encrypted, scoped to least privilege per target, rotatable without downtime, and usable through federated or short-lived credentials where the target supports them. | M |
See the SCIM Provisioning Guide and the Entitlement Catalogue and Application Onboarding Guide.
4.6 Non-human identities and AI agents
| ID | Requirement | Type |
|---|---|---|
| IGA-NH-01 | Discovers and imports service accounts, cloud service principals and workload identities, OAuth applications and their grants, and API keys from [platforms], and links them to the systems they access. | M |
| IGA-NH-02 | Assigns a mandatory accountable human owner to every non-human identity, with reassignment when the owner moves or leaves. | M |
| IGA-NH-03 | Includes non-human identities in certification campaigns with context: last use, credential age, permissions and consuming workload. | S |
| IGA-NH-04 | Governs AI agent identities: registration, owner, purpose, permitted tools and data, expiry and review. | S |
| IGA-NH-05 | Integrates with [secrets manager] and [NHI security platform] to show credential rotation status, without the IGA platform storing the secret values. | S |
See the NHI Security Platform Buyer's Guide for where IGA ends and specialist NHI tooling begins.
4.7 Reporting, analytics and audit
| ID | Requirement | Type |
|---|---|---|
| IGA-RP-01 | Answers "who has access to X, why, approved by whom and since when" for any identity or entitlement, including historical points in time. | M |
| IGA-RP-02 | Streams administrative and governance events to [SIEM] through a documented API or syslog. | M |
| IGA-RP-03 | Describe any machine learning or generative AI features (recommendations, natural-language requests), how outputs are explained to approvers and what customer data is used to train or prompt models. | I |
5. Platform security and non-functional requirements
| ID | Requirement | Type |
|---|---|---|
| IGA-SEC-01 | Administrator access through [Organisation] SSO (SAML 2.0 or OpenID Connect) with phishing-resistant MFA, and granular administrative roles. | M |
| IGA-SEC-02 | All administrative changes (policies, connectors, roles, SoD rules) logged with actor, time, before and after values, retained for [period]. | M |
| IGA-SEC-03 | Provide a current independent assurance report (for example ISO/IEC 27001 certificate with in-scope service, or SOC 2 Type II) and a completed [SIG or CAIQ] questionnaire. | M |
| IGA-SEC-04 | Describe how bidder staff access customer tenants, how that access is approved and logged, and whether [Organisation] can see those logs. | S |
| IGA-SEC-05 | Data stored and processed only in [regions]; list sub-processors and their locations. | M |
| IGA-NF-01 | Availability commitment of [percentage] with service credits; documented behaviour of provisioning queues during an outage. | S |
| IGA-NF-02 | Scales to [number] identities, [number] entitlements and [number] certification items per campaign without degraded reviewer experience. | S |
| IGA-NF-03 | Full export of identities, entitlements, decisions and audit history in a documented format on request and at exit. | M |
6. Implementation, services and support
- Approach: describe phases, deliverables and acceptance criteria for [HR integration plus the first [number] applications] within [months].
- Team: named roles, their experience with deployments of similar size and sector, and the split between bidder, partner and [Organisation] effort.
- Configuration versus customisation: state which requirements in section 4 need custom code, and how that code is maintained through product upgrades.
- Upgrades: release cadence, notice period, and how customer configuration is tested against new releases.
- Support: tiers, hours, response and resolution targets by severity, and escalation path.
- References: [two or three] customers of similar size or sector, with at least one using the product for non-human identity governance.
7. Commercials
Complete the pricing schedule in Appendix B. Prices must cover the full contract term so that life-cycle cost can be compared.
| Cost element | What to state |
|---|---|
| Licence metric | Per identity, per employee, per application or other; how non-human identities and AI agents are counted |
| Modules | Which section 4 requirements need additional modules or add-ons |
| Connectors | Any per-connector or premium connector charge |
| Implementation | Fixed price or time and materials, with the day rate and estimated days by phase |
| Support and training | Annual charge and what each tier includes |
| Growth and renewal | Price for [growth percentage] more identities; cap on renewal increases |
| Exit | Charges, if any, for data export and transition assistance |
8. Evaluation method and proof of concept
[Organisation] will first check mandatory requirements, then score the remaining criteria using these weights (illustrative; set your own before issue):
| Criterion | Weight | Evidence |
|---|---|---|
| Functional fit (section 4) | [35%] | Response, demonstration, proof of concept |
| Integration fit for Appendix A applications | [20%] | Connector answers, proof of concept |
| Platform security and resilience (section 5) | [15%] | Assurance reports, questionnaire |
| Implementation approach and references | [10%] | Section 6, reference calls |
| Life-cycle cost | [20%] | Appendix B |
Scores use a 0 to 5 scale: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. Shortlisted bidders will run a proof of concept of [number] weeks in a [Organisation] test environment covering, at minimum:
- Connect [HR system] and three applications, including one with no API.
- Run joiner, mover (with access removal) and leaver scenarios end to end and show the evidence trail.
- Run a certification campaign with [number] real reviewers, revoke access and show closed-loop verification.
- Block a request that violates an SoD rule and record an approved exception with expiry.
- Import [number] service accounts and OAuth applications, assign owners and certify them.
- Export the full dataset in the documented format.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Write Appendix A first: list your [20 to 30] most important applications with integration type and owner. Connector reality decides IGA projects, so make bidders answer against your list, not their catalogue.
- Keep mandatory items honest: if every bidder fails an M item, it was a scored item. Review M items with procurement before issue.
- Score independently, then moderate: each panel member scores alone, then the panel agrees a consensus score with a written rationale for each criterion.
- Control proof-of-concept access: issue bidders time-limited, least-privilege test accounts and connector credentials, record them, and revoke all of them when the proof of concept ends.
- Treat the platform as tier zero: an IGA platform holds provisioning credentials for most of your estate. Weight IGA-CN-05 and the section 5 items accordingly.
- Do not let NHI requirements become informational: service accounts and agents usually outnumber people. If no bidder meets IGA-NH-01 to NH-03, plan a complementary NHI tool rather than dropping the requirement.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Lifecycle (4.1), NHI ownership (4.6) | AC-2, AC-2(1), AC-2(3), IA-4 | PR.AA-01 | A.5.16 Identity management |
| Requests and time-bound access (4.2) | AC-2(2), AC-6 | PR.AA-05 | A.5.18 Access rights |
| Certification (4.3) | AC-2, AC-6(7) | PR.AA-05 | A.5.18 Access rights |
| SoD (4.4) | AC-5 | PR.AA-05 | A.5.3 Segregation of duties |
| Audit and reporting (4.7, 5) | AC-2(4), AU-2 | DE.CM-03 | A.8.15 Logging |
| Supplier assurance (5, 8) | SA-4, SA-9, SR-6 | GV.SC-05, GV.SC-06 | A.5.19 to A.5.22 Supplier relationships |
After award, carry the requirement IDs into the statement of work and acceptance tests, so that each scored answer becomes a deliverable. The Access Reviews Guide, Segregation of Duties Guide and Role Mining and Role Design Guide help define the policies the platform will enforce.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- IETF: RFC 7644 System for Cross-domain Identity Management: Protocol
- NIST: SP 800-161 Rev. 1 Cybersecurity Supply Chain Risk Management Practices
Related NHI Mgmt Group resources: IGA Buyer's Guide · Security Vendor Evaluation and RFP Guide · PAM RFP Template · IAM and IGA Basics · Vendor Security Assessment Template