A CIO Checklist for Evaluating Identity Governance Total Cost of Ownership

That IGA quote looks tidy on the slide. The problem is that it rarely is the full cost.

If you are a CIO, Head of IT, or CISO in Indian BFSI, you are not buying a license line. You are approving a program that will touch implementation, connectors, data cleanup, internal labor, audit work, support, infrastructure, and the cost of growing the program later. This identity governance TCO checklist will help you ask every vendor the same hard questions before you sign.

What belongs in an IGA TCO model?

The full cost is bigger than the subscription. A useful model separates one-time work from recurring work, then forces every assumption into the open.

Use this structure in your CIO identity governance budget:

• One-time cost

  • implementation services

  • discovery and current-state assessment

  • integration and onboarding work

  • data remediation

  • testing, pilot, cutover, rollback, and hypercare

  • documentation, training, and handover

• Recurring cost

  • subscription or license

  • internal operating labor

  • infrastructure and security operations

  • support and maintenance

  • audit and certification effort

  • change management

  • expansion into new applications, entities, regions, and identity populations

The simplest way to pressure-test a proposal is to ask the vendor to show a three-year base case and a five-year sensitivity view. Not as a universal standard. Just as a planning discipline. If a quote only models year one, it is incomplete by design.

Cost bucket	One-time or recurring	Vendor amount	Integrator amount	Internal FTE estimate	Dependency	Identity/app/entitlement volume	Assumption	Included/excluded	Owner	Year 1	Year 2	Year 3	Expansion scenario	Confidence level	Evidence required
License / subscription	Recurring				Population definition									Quote and term sheet
Implementation	One-time				Data readiness									SoW and acceptance criteria
Integrations and remediation	One-time				App inventory									Connector plan
Internal operations	Recurring				Business ownership									RACI and staffing plan
Audit and access review effort	Recurring				Control scope									Campaign and evidence plan
Expansion	Recurring				Growth scenario									Roadmap assumptions

Keep taxes, currency assumptions, and annual price changes as explicit line items. Do not let them disappear into a blended total.

Which licensing metric is the vendor actually charging for?

“User” is usually not a precise unit. That is where many business cases go wrong.

Your identity governance TCO checklist should force the vendor to define exactly what is billable, then show how the count changes over time.

Ask these questions in writing:

Question to ask	Evidence to request
What exactly is a billable identity: person, account, managed identity, governed identity, requester, reviewer, or admin?	Written definition in the quote or order form
Are employees, contractors, vendors, partners, temporary users, and privileged users counted the same way?	Population mapping
Are service accounts, API identities, workload identities, bots, and AI agents included, excluded, or charged separately?	Scope statement for human and non-human identities
Are inactive, suspended, archived, duplicate, orphaned, or break-glass accounts counted?	Counting rules
Is pricing based on named users, active users, average monthly users, peak users, governed identities, applications, connectors, transactions, API calls, or storage?	Metric description
What happens when a monthly peak crosses a tier?	Tier logic and renewal treatment
Are there minimums, overage rates, or commitments for temporary spikes?	Commercial terms

Also ask which functions sit in the base edition and which are separate modules. Lifecycle, access requests, certifications, role management, SoD, risk analytics, privileged access, non-human governance, AI features, APIs, workflow automation, and reporting are often not all packaged the same way.

The point is not to find the cheapest metric. The point is to avoid being surprised by the way the metric expands as your estate grows.

What does “out-of-the-box connector” really cover?

A connector is not production-ready just because it worked in a demo.

That is one of the easiest traps in an IGA vendor evaluation checklist. A buyer sees a successful connection to a directory or SaaS app and assumes onboarding is solved. It is not. Production readiness means the connector supports the buyer’s actual identity, entitlement, workflow, review, error-handling, and upgrade needs.

For every application, ask the vendor to classify the integration as standard, configurable, partner-built, custom, file-based, API-based, or manual. Then require separate estimates for discovery, build or configuration, testing, certification, production deployment, and ongoing maintenance.

A production-ready integration should be tested against the buyer’s real use cases, including:

• authoritative identity import and reconciliation

• create, update, disable, delete, and re-enable operations

• joiner, mover, and leaver triggers

• group, role, license, and entitlement aggregation

• access request and approval routing

• access review and certification campaigns

• separation-of-duties checks and remediation

• attribute mapping, manager hierarchy, and organizational changes

• incremental and full reconciliation

• error queues, retries, duplicate handling, and rollback

• rate limits, pagination, API failures, and target-system outages

• audit evidence, timestamps, and source-to-target traceability

• monitoring, alerting, certificate rotation, and credential management

• target-system version upgrades and connector support

This matters especially in Indian BFSI, where the application estate is rarely simple. A proof of concept should not stop at one modern SaaS app and a directory. It should include representative systems from HR, core banking, lending, payments, treasury, cards, insurance, brokerage, pensions, enterprise SaaS, cloud workloads, databases, and legacy systems.

If the vendor says a connector is “included,” ask what that actually includes. Binary only? Configuration? Production support? Future upgrades? The answer changes the cost.

Which implementation assumptions become internal cost?

The SoW must separate vendor work, integrator work, and customer work. If it does not, the internal labor will surface later as “small tasks” that are not small at all.

Here is the cleanest way to frame implementation risk without turning the review into a negotiation:

Area	Vendor	Systems integrator	Customer
Current-state discovery
Application inventory
HR and directory data quality
Role and policy design
Connector configuration or custom development
Network, firewall, certificates, secrets, test environments
Workflow and approval design
Access-review campaign setup
Data migration and historical evidence
Testing, defects, cutover, rollback
Training, communications, service-desk enablement
Hypercare, production support, and handover

Then ask for the assumptions behind the fee and timeline:

• number of applications

• number of identities

• number of entitlements

• number of workflows

• number of roles and policies

• number of environments

• number of legal entities

Also ask what “complete” means. A connection is not the same as successful provisioning. Successful provisioning is not the same as automated deprovisioning. A completed review is not the same as an accepted audit report.

If the vendor is vague about ownership, you will pay for the gap in internal hours.

How much will support, audit, and adoption really cost?

Support response time is not the same as resolution. And resolution is not the same as the business owning the process without outside help.

This is where many buyers underestimate the real TCO. The platform may be SaaS, but the operating model is still yours.

Ask about the support model in plain language:

• severity definitions and examples

• initial response, acknowledgement, workaround, and resolution targets, separately

• 24x7 coverage for critical incidents

• support geography and time zone

• named technical-account coverage

• escalation path

• whether connector failures are product support, professional services, or customer responsibility

• support for custom connectors, workflows, APIs, scripts, and target-system changes

• upgrade notices, maintenance windows, backward compatibility, and regression support

• backup, disaster recovery, and service continuity

• exit assistance, data export, audit-log access, and knowledge transfer

For Indian BFSI, audit and evidence effort is not optional overhead. The platform must make it easy to produce evidence for joiner, mover, and leaver events, approvals, revocations, privileged access, policy changes, exceptions, and access reviews. It should also make it clear who collects evidence, who remediates exceptions, and who answers auditor questions.

Use these questions to expose hidden labor:

Question to ask	Evidence to request
How many auditor-ready reports are included?	Report catalog and licensing terms
Can compliance configure reports without vendor services?	Demo or admin guide
Are custom reports, regulatory mappings, and evidence exports extra?	Service schedule
How much reviewer follow-up is automated?	Campaign workflow design
What is the labor required for each access review cycle?	Operating model and owner list
Can an auditor get read-only access without a new license?	Access policy
How are logs from the IGA platform, connectors, and target systems correlated?	Logging and export design

This is also where regulation matters. RBI, SEBI, IRDAI, PFRDA, CERT-In, and DPDP obligations can change, and they create real workload around logs, reviews, evidence, retention, and incident response. The cost is not just the tool. It is the team and process needed to operate it properly.

How will the cost change as the business grows?

A good business case does not freeze the company at today’s identity count.

It models what happens when the estate expands across new applications, subsidiaries, acquisitions, contractors, machine identities, API identities, cloud workloads, AI agents, regions, environments, and regulatory scope.

That is the part many CIOs miss when they first build a CIO identity governance budget. The initial user count may look manageable. The program gets expensive when the next wave arrives.

Ask the vendor to show cost impact for each of these growth events:

• new business units

• new legal entities

• branches and regions

• mergers and acquisitions

• new SaaS applications

• core banking, insurance, market infrastructure, pension, and legacy systems

• contractors, partners, and third parties

• machine, workload, API, and AI-agent identities

• additional environments and disaster-recovery instances

• new reports, controls, and review frequencies

Also test whether the platform’s growth model changes with volume. Do connector counts rise? Do environments cost extra? Do support tiers change? Are acquired companies treated as new tenants or new populations? Those answers shape the long-term cost more than the first-year quote.

If the platform includes human, machine, and AI identity governance, that may help avoid a second procurement later. Still, the buyer should model the actual populations, connector work, controls, and operating effort rather than assume future savings.

FAQ

What is included in identity governance TCO?

License or subscription, implementation, integrations, data cleanup, internal labor, infrastructure, support, audit and access-review effort, change management, and future expansion. The license quote is only one part of the total.

Which licensing metric should a CIO use for IGA?

There is no single best metric. Map the quote to your actual employees, contractors, partners, privileged users, service accounts, workloads, AI agents, applications, entitlements, environments, and usage patterns, then test peak and growth scenarios.

Does SaaS eliminate implementation cost?

No. SaaS can reduce customer-managed infrastructure, but data quality, process design, connector configuration, testing, application ownership, training, audit evidence, and ongoing governance still require effort.

How can an Indian BFSI organization estimate connector cost?

Build an application-by-application inventory and classify each integration as standard, configurable, partner-built, custom, file-based, API-based, or manual. Then validate the lifecycle operations, entitlement handling, reviews, error recovery, audit evidence, and upgrade ownership for each one.

Before you sign, the real test is simple. Can you explain every recurring and one-time cost, identify who performs the work, prove the platform against representative applications, and show how the model changes as the regulated business grows? If not, pause. You do not need a bigger team. You need a clearer checklist and a costed operating model.