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:

1. One-Time Costs

• Implementation services

• Discovery and current-state assessment

• Integration and onboarding work

• Data remediation

• Testing, pilot, cutover, rollback, and hypercare

• Documentation, training, and handover

2. Recurring Costs

• 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

Pressure-Testing the Proposal

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, but as a planning discipline). If a quote only models year one, it is incomplete by design.

To build a complete TCO model, capture the following parameters across Year 1, Year 2, and Year 3, as well as under an Expansion Scenario:

• Cost Bucket & Type: Specify whether it is a one-time or recurring expense.

• Financial & Labor Commitments: Track the Vendor Amount, Integrator Amount, and Internal FTE Estimate.

• Operational Context: Identify Dependencies, Identity/App/Entitlement Volume, explicit Assumptions, and Included/Excluded items.

• Governance & Validation: Assign an Owner, define the Confidence Level, and specify the Evidence Required.

Core Cost Buckets & Key Considerations

• License / Subscription (Recurring): Focus on the population definition. Evidence Required: Quote and term sheet.

• Implementation (One-Time): Focus on data readiness. Evidence Required: SoW and acceptance criteria.

• Integrations and Remediation (One-Time): Focus on app inventory. Evidence Required: Connector plan.

• Internal Operations (Recurring): Focus on business ownership. Evidence Required: RACI and staffing plan.

• Audit and Access Review Effort (Recurring): Focus on control scope. Evidence Required: Campaign and evidence plan.

• Expansion (Recurring): Focus on growth scenarios. Evidence Required: Roadmap assumptions.

Key Rule: 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.

Questions to Ask in Writing & Evidence to Request

• What exactly is a billable identity (person, account, managed identity, governed identity, requester, reviewer, or admin)?

  • Evidence Required: Written definition in the quote or order form.

• Are employees, contractors, vendors, partners, temporary users, and privileged users counted the same way?

  • Evidence Required: Population mapping.

• Are service accounts, API identities, workload identities, bots, and AI agents included, excluded, or charged separately?

  • Evidence Required: Scope statement for human and non-human identities.

• Are inactive, suspended, archived, duplicate, orphaned, or break-glass accounts counted?

  • Evidence Required: Counting rules.

• Is pricing based on named users, active users, average monthly users, peak users, governed identities, applications, connectors, transactions, API calls, or storage?

  • Evidence Required: Metric description.

• What happens when a monthly peak crosses a tier?

  • Evidence Required: Tier logic and renewal treatment.

• Are there minimums, overage rates, or commitments for temporary spikes?

  • Evidence Required: 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/configuration, testing, certification, production deployment, and ongoing maintenance.

Use-Case Validation Checklist

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 (SoD) 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 Statement of Work (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.

Allocation of Responsibility Across Key Areas

• Current-state discovery: Shared across Vendor, Systems Integrator, and Customer.

• Application inventory: Primary responsibility of Customer; supported by Systems Integrator.

• HR and directory data quality: Primary responsibility of Customer.

• Role and policy design: Led by Systems Integrator with Customer collaboration.

• Connector configuration or custom development: Divided between Vendor and Systems Integrator.

• Network, firewall, certificates, secrets, test environments: Primary responsibility of Customer.

• Workflow and approval design: Led by Systems Integrator with Customer collaboration.

• Access-review campaign setup: Led by Systems Integrator with Customer collaboration.

• Data migration and historical evidence: Handled by Systems Integrator and Customer.

• Testing, defects, cutover, rollback: Shared effort across Vendor, Systems Integrator, and Customer.

• Training, communications, service-desk enablement: Shared effort across Vendor, Systems Integrator, and Customer.

• Hypercare, production support, and handover: Transitioned from Vendor/Systems Integrator to Customer.

Fee and Timeline Assumptions

Always demand visibility into the assumptions behind the fee and timeline:

• Number of applications, identities, and entitlements

• Number of workflows, roles, and policies

• Number of environments and 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.

Plain-Language Support Model Questions

• Severity definitions and concrete examples

• Initial response, acknowledgement, workaround, and resolution targets (evaluated separately)

• 24x7 coverage details for critical incidents

• Support geography and primary time zone

• Named technical-account coverage and escalation paths

• Ownership of connector failures (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 protocols

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

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.

Exposing Hidden Labor: Questions & Evidence

• How many auditor-ready reports are included?

  • Evidence Required: Report catalog and licensing terms.

• Can compliance configure reports without vendor services?

  • Evidence Required: Product demo or admin guide.

• Are custom reports, regulatory mappings, and evidence exports extra?

  • Evidence Required: Detailed service schedule.

• How much reviewer follow-up is automated?

  • Evidence Required: Campaign workflow design.

• What is the labor required for each access review cycle?

  • Evidence Required: Operating model and owner list.

• Can an auditor get read-only access without a new license?

  • Evidence Required: Access policy document.

• How are logs from the IGA platform, connectors, and target systems correlated?

  • Evidence Required: Logging and export design.

This is also where regulation matters. RBI, SEBI, IRDAI, PFRDA, CERT-In, and DPDP obligations can change, creating 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, but the program gets expensive when the next wave arrives.

Cost Impact Growth Events to Model

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

• New business units, legal entities, branches, and regions

• Mergers and acquisitions (M&A)

• New SaaS applications alongside core banking, insurance, market infrastructure, pension, and legacy systems

• Expansion of contractors, partners, and third parties

• Growth in 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 far 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.

Bottom Line: 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.