Procurement does not start when the RFP is published.
It usually starts much earlier and more quietly: someone points out that the current IAM setup no longer scales, and a new one should be tendered. At the same time, requests pile up from every direction: sign-ins, access rights, integrations, audit findings, and new digital services.
IAM is difficult because it touches almost everything. It is easy to end up in a situation where every need, idea, and requirement feels critical at once - but no one is actually sure what is being bought.
That is when an RFP becomes a long wish list. A wish list is a poor way to buy a capability that will shape daily operations, access governance, and long-term delivery for years.
In this article, I cover ten decisions that CIOs and IT leadership should make before issuing an RFP. These are not extra requirements; they are the choices that make procurement clear and delivery manageable.
Why timing matters
Many organizations only begin when the RFP "should already be written."
That timeline pressure typically causes two key mistakes:
- Scope and target state are left underdefined.
- Requirements are patched with more detail.
The result is an RFP that looks thorough, but does not guide toward the right solution. Vendors interpret it differently, bids become difficult to compare, and final decisions are often based on demo impressions.
Good procurement starts earlier - with clarity on what you are buying and why.
The most common pitfall: buying the wrong thing
The core problem is rarely too few requirements. The problem is that the requirements do not describe the real need.
IAM is primarily about decisions and processes: ownership, lifecycle, and authority. Technology follows these. That is why an RFP should first describe how your organization should operate, not only which product features should exist.
Without a shared target state, requirement lists often mix together:
- principles and implementation details in the same line
- the same requirement asked in multiple forms
- critical capabilities buried under detail
- integrations and operability treated as assumptions
In that setup, procurement measures presentation quality, not solution fit.
Ten decisions to make before the RFP
The points below are intentionally high-level. They are the foundation of a strong RFP and a controlled delivery. Details come later, in the right order.
1) Which problem are you solving - and what are you actually buying
The starting point often sounds clear: buy IGA, SSO/IdP, or CIAM. But each category has major variations that change both solution design and cost structure.
- IGA: focus on access lifecycle, approvals, role model, reporting, or auditability
- SSO/IdP: basic sign-in only, or also MFA, risk-adaptive controls, and application portfolio modernization
- CIAM: consumer CIAM, or B2B partners, organizations, and delegated authorization
Also document boundaries: what this phase does not solve, and what is explicitly moved to a later phase.
2) Who owns IAM and who has decision authority
IAM does not work as an IT-only project. It also does not work as a security-only initiative.
- a named owner for the IAM whole
- where architecture, security, and budget decisions are made
- how change requests are evaluated, approved, and prioritized
Clear ownership and decision governance keep procurement under customer control instead of vendor assumptions.
3) Who IAM serves: workforce, customers, or partners
This is often the core of the entire procurement. User groups directly shape authorization models, lifecycle rules, integrations, and risk level.
- which user groups are included in phase one
- what belongs in phase two, and by which principle it is brought in
4) Identity lifecycle and master data
Where identities originate, when they become usable, and how you ensure access is actually removed.
- which source is the master for each user group
- how changes propagate: real-time events or scheduled syncs
- how deprovisioning, role removal, session termination, and audit trails are handled
5) Integration strategy and application portfolio
In most IAM programs, cost and schedule risk come from integrations, not from IAM product configuration itself.
- which integration patterns are primary, and what "supported" means in practice
- which applications belong to phase one
- how long-tail applications are onboarded: whether they are added in planned waves, whether standard connectors are used as much as possible, or whether integrations are built case by case
6) Authorization model: roles, attributes, and delegation
Responsible IAM procurement does not only buy sign-in. It buys a working answer to: who can do what, and on what basis.
- RBAC, ABAC, or a clear combination
- who can grant access to whom
- how roles and policies are documented, approved, and audited
7) Operability and automation
IAM delivery does not end at go-live. Daily operations continue for years, so operability must be designed from the beginning.
- what is logged, for how long, and how logs are retrieved for audit
- who makes changes and how they are approved and versioned
- how provisioning, deprovisioning, reporting, alerting, and monitoring are automated
8) Security baseline choices and consistency
It is easy to list MFA, adaptive authentication, and session management in requirements. The harder part is ensuring consistent implementation across all applications.
- where MFA is always mandatory and when step-up is required
- which adaptive signals are used
- what is measured and reported, and to whom: CISO, IT leadership, service owners
9) Migration and phasing
Old and new solutions almost always run in parallel for a period of time. That is normal, so migration must be designed as its own workstream.
- the order in which user groups and applications are moved
- what remains in parallel and for how long
- what "done" means: cutover criteria, minimum test level, and rollback or exit plan
10) Evaluation criteria and PoC/demo structure
Procurement outcomes are decided in evaluation, not in the RFP text. If the model is vague, the best sales presentation wins - not the best fit.
- which five to seven critical capabilities drive the decision
- how scoring drives the right direction, and what cannot be compensated
- what PoCs and demos must prove, with clear success criteria and documented outcomes
Two practical examples
Reference
Financial-sector CIAM: when the solution was drifting into a custom build project
The organization was searching for a CIAM platform, but the approach was already drifting toward extensive customization. Cost and delivery risk increased with every new "small" need.
Returning to the core question - what are we actually buying - helped clarify target state, scope, and critical capabilities. Vendor options changed, and the chosen path became both fit-for-purpose and cost-effective.
Reference
Public-sector IGA: when procurement was restarted
The first round led to a poor vendor selection because scope, requirements, and public procurement criteria did not form a coherent whole. Offers were hard to compare, and the decision did not land on the right outcome.
After restarting with stronger procurement material, clear boundaries, and a better evaluation model, the process got back on track and comparison began to drive decisions in the right direction.
When clarity exists on what is being bought, requirements become clearer, bids are comparable, PoCs prove the right things, and delivery starts in control.
Summary
A good RFP is not a document - it is a summary of decisions
Procurement rarely succeeds by adding more requirements. It succeeds by making the right decisions early. This 30-minute scoping call is free and non-binding. You will get a clear situation picture, the key decision points, and a practical recommendation for next steps before the RFP.
