The GSI Tax: What's Underneath Your IAM Budget

Most CISOs I talk to recognize the phrase "GSI tax" before I finish saying it. They have lived it across two or three identity programs, sometimes at the same company.

None of them can tell me how their organization stopped paying it, because for most of the history of identity governance, there has not been a way to stop paying it. Part of the reason is the complexity of the enterprise itself. The other part is the architecture of the platforms doing the governing. Both demanded consultants, and both still do.

That is what I want to write about here, because the structure is finally changing, and the math underneath an Identity Security program is about to change with it.

The Tax Is Real, and It Has a Number

The gap between the price on the contract and what the governance program costs to operate is what the industry now calls the GSI tax. It is what enterprises pay to the global systems integrators, the Deloittes and Accentures, to make the identity software they bought work on the applications they need it to govern.

The procurement data is consistent with what practitioners feel. Vendr's analysis of verified IGA purchases puts implementation services at 30 to 60 percent of Year 1 total spend, on top of a median annual contract of around $113,000. Across the channel, GSIs build their businesses on a roughly three to five times services-to-license ratio, which is the operating model of the IGA industry rather than a scandal within it.

The question worth asking is not whether GSIs charge a lot, because they do, and they are open about it. The question is what most of those service hours are spent on, and whether that work still needs to be done by people.

The Iceberg Below the Tax

Every CISO who has bought identity governance has had some version of the same experience: the quote in front of you shows a license cost, the five-year cost is a small multiple of that license, and the program is still not finished when the five years are up. The license is the part of the iceberg above the water, and everything that determines whether the program succeeds sits underneath it.

Total cost of ownership research across enterprise software broadly puts visible costs at 15 to 25 percent of the total, with the rest invisible at the time of purchase. For IGA, the picture is darker. Gartner has found that more than half of IGA deployments are distressed, meaning they miss functional, budget, or timing commitments. Half the programs running today will not get where they were supposed to go.

What lives below the waterline, the mass of work that decides the outcome, is two very different kinds of work, and the difference between them is the most important distinction in the entire conversation.

What Is Worth Paying For

Some of the work GSIs do is real, hard, and worth what good ones charge for it.

Role design that survives an organizational restructure is one example. Compliance architecture that maps cleanly to SOX, HIPAA, ISO 27001, DORA, or whichever auditor shows up in your jurisdiction is another. Change management across thousands of users whose access is about to be reorganized. Program governance that holds together when the CISO rotates and the sponsor moves business units. These are intellectual, contextual, judgment-driven engagements that pay back across years.

I have hired GSIs to do this kind of work, and I would do it again. If an Identity Governance program does not have a strategist holding the architecture together, the cost of failure runs higher than the GSI tax ever could.

What Is Not

The other half of the work below the waterline is mechanical, repetitive, and operationally endless.

It is the custom connector that has to be written because the application has no SCIM endpoint, no direct APIs, and no plans to ship one. Three months later, the same connector breaks when the vendor pushes an API or UI update, and an engineer has to rebuild it. It is the provisioning script that runs against a partner portal until the portal redesigns its sitemap. It is the manual access review for the application that nobody could integrate into the IGA tool, conducted via spreadsheet and signed off via email.

Most of the GSI tax is paying for this work rather than the strategy work above it. The structural reason is one of the under-discussed facts of the industry: fewer than 7 percent of enterprise applications support SCIM, the standard protocol that lets identity tools talk to applications natively.

Everything outside that 7 percent is the long tail: legacy systems, internal applications, partner portals, vendor-locked SaaS. All of it requires bespoke integration work, and then it requires maintenance, because the targets keep moving.

The pattern that results is what I have come to call the connector treadmill. New applications get added to the onboarding queue faster than old ones can be integrated. The integrations that exist break and have to be rebuilt. The budget meant for the next year of the program ends up keeping last year's work running.

At large enterprises, I have seen onboarding queues with hundreds of applications waiting and projected timelines measured in years rather than months. Long enough that the applications at the front of the queue have been deprecated by the time they reach it.

The treadmill is the part of the iceberg that does not need to be the size it is, and most of the budget below the waterline is currently going toward it.

Why It Got This Way

Identity governance grew up around an assumption that has not been true for at least a decade: that integration is a one-time project. You bought the platform, connected the applications, built the workflows, and shipped. What you ended up with was an operating system you could run for years.

In practice, integration is a permanent operating condition. Applications change, acquisitions add stacks, Shadow IT, and the team that built the original integration moves on, with the documentation in their heads. The thing the industry calls "implementation" is closer to a job that somebody has to do continuously, and for the last fifteen years, the obvious option for that job has been a consultant. The work was manual, the targets heterogeneous, and adapting to each new application meant a person had to do it by hand.

That is finally changing. AI for IAM is the shift underneath everything I am describing. AI agents can now complete the integration and workflow together, adapting as the target application changes rather than breaking on it. The long tail of disconnected applications, the part of the budget the connector treadmill has consumed, becomes governable without bespoke code and without the maintenance bill that follows.

The strategic work above the waterline still belongs to people and will keep belonging to them. The GSIs who do it well will keep being worth what they charge. The toil below it is the part of the GSI tax that no longer has to be paid.

What I Would Ask Before the Next Renewal

For any identity leader planning an IGA renewal, an expansion, or a fresh deployment, the practical question has shifted to what shape the iceberg underneath the license is going to take across the life of the program.

Three numbers usually tell you most of what you need to know:

• How many of the applications you need to govern have a native, supported connector to your IGA platform today? If the answer is less than half, the rest is custom work, and custom work is the part of the tax that compounds across renewal cycles.
• How long is your application-onboarding queue, and how old is its oldest item? A queue measured in years is a leading indicator that the program is no longer able to keep up with the business it serves.
• How much of last year's identity budget went to maintaining integrations that already existed versus building new ones? When maintenance is consuming new-program budget, the treadmill is already winning, and no amount of additional license spend will change that.

The GSI tax was once unavoidable. It is the part of identity governance I have spent the last couple of years working on making smaller.