Build vs Buy for Identity Governance: The Hidden Cost of Middle Ground

The decision that breaks after the demo

A 2026 identity governance pilot can look absurdly cheap: a SaaS quote, a SAML connector, and a six-week implementation plan. Then the first audit asks for SoD evidence across Workday, Entra ID, Okta, Snowflake, and three homegrown apps, and your team discovers the real bill is not the license. It is the policy logic, exception handling, data normalization, and workflow maintenance that nobody priced.

In one enterprise rollout, the vendor quote was $180,000 per year for 25,000 identities. The internal program cost landed near $740,000 in year one once you added two IAM engineers, one data engineer, one security architect, integration work, and remediation for 14 legacy roles that did not map cleanly. That gap is why build versus buy for identity governance is still a live architecture decision in 2026.

The expensive choice is often not build or buy. It is the middle option: "buy the platform, build the governance layer, and keep the messy integrations forever."

What you are really deciding: product, platform, or program

Identity governance is not one thing. You are choosing among three operating models.

1. Build the full stack

You own policy engine, access request flows, certifications, provisioning, audit trails, and reporting. This works only if identity is a core product capability or you have unusually complex regulatory needs.

A global fintech with 80,000 identities and 240 applications may justify this if it already runs a mature internal platform team. In that case, a custom service built on PostgreSQL, Temporal, and OPA can keep policy evaluation under 150 ms and avoid vendor constraints. But the team will still spend months on connectors and audit exports.

2. Buy the full product

You adopt SailPoint, Saviynt, Microsoft Entra ID Governance, or a similar platform and accept its opinionated workflows. This is usually the fastest path to audit coverage.

A realistic 2026 benchmark: a mid-market deployment with 10,000 identities and 40 applications can reach first certification in 10 to 14 weeks if source data is clean and the app portfolio is modern. If you have 12 legacy systems with custom entitlements, expect 4 to 6 months.

3. The middle option most teams never price

This is the common trap. You buy a governance suite, then build custom connectors, custom entitlement models, custom approval logic, custom reporting, and custom exception handling around it.

The platform license is only 35% to 55% of total cost over three years in this model. The rest is integration engineering, identity data cleanup, change management, and ongoing policy maintenance.

Why the middle option is so expensive

The middle option survives because it looks modular. Each custom piece seems small. Together, they create a second product you now have to own.

The hidden cost stack

Here is what teams usually miss:

• Identity data normalization: HR, ERP, and directory records rarely agree on job codes, manager chains, or locations.
• Entitlement modeling: Legacy apps often expose permissions in ways the vendor cannot understand without custom mapping.
• Policy exceptions: Temporary access, emergency elevation, and contractor expiry rules create edge cases that never fit the default workflow.
• Reporting for auditors: Evidence requests are rarely the same as dashboard metrics.
• Connector upkeep: Every app upgrade can break SCIM, API auth, or attribute mappings.

A large healthcare provider in 2026 reported that 41% of IAM engineering time went to connector maintenance after the first 18 apps were onboarded. The software worked. The operating model did not.

A simple cost model you can actually use

Use this rough formula for build versus buy for identity governance:

3-year TCO = license + implementation + integrations + data cleanup + admin + policy maintenance + audit support + change backlog

Example for 20,000 identities and 60 applications:

• License: $240,000/year = $720,000 over 3 years
• Initial implementation: $180,000
• Custom integrations: $320,000
• Data cleanup and role remediation: $140,000
• Ongoing admin and policy maintenance: $210,000
• Audit support and evidence prep: $90,000

3-year TCO: $1.66M

If you try to build the same capability internally, the first-year cost may look similar, but the second and third years usually shift toward higher fixed engineering load. That is where buy often wins.

When build wins, and when it absolutely does not

Build versus buy for identity governance is not ideological. It is a portfolio decision.

Build if these are true

• You have 100+ apps with highly unique entitlement semantics.
• Your compliance model requires policy logic the vendor cannot express.
• Identity workflows are part of your core product or customer-facing platform.
• You already run a platform engineering team that owns workflow engines, eventing, and audit-grade observability.

A payments company with strict segregation rules across regions may build because a vendor workflow cannot express "four-eyes approval plus local legal review plus time-boxed token issuance" without awkward workarounds. If the policy engine is your moat, build can be justified.

Buy if these are true

• You need audit coverage in under 90 days.
• Your app estate is mostly SaaS and supports SCIM or modern APIs.
• Your security team is small and cannot absorb a custom product.
• You want vendor-supported connectors and standard certification workflows.

A 2026 enterprise with 8,000 employees and 30 SaaS apps can often cut access review time from 18 hours per manager per quarter to 4 to 6 hours with a commercial platform. That is a real productivity gain.

Avoid build when the goal is "control"

Control is not the same as ownership. If your team spends 1,200 engineering hours a year on governance plumbing, you do not own the system; it owns your roadmap.

The middle option architecture that most teams never price

The middle option is not always wrong. It is just underbudgeted.

What it looks like

You buy the governance engine but build the control plane around it:

[HRIS] -> [Identity Data Hub] -> [IGA Platform] -> [Provisioning Connectors]
   |              |                    |                    |
   |              |                    |                    +--> SaaS apps via SCIM/API
   |              |                    +--> Access reviews, SoD, certifications
   |              +--> Role mining, normalization, manager hierarchy fixes
   +--> Source of truth for employment state

This architecture can work well if you treat the identity data hub as a product. It fails when the hub becomes a side project.

Price the control plane separately

Most teams price the platform and forget the glue. Price these items explicitly:

1. Identity graph or data hub
2. Attribute normalization service
3. Policy-as-code layer
4. Connector framework
5. Evidence export pipeline
6. Observability and alerting

A practical benchmark: if your integration layer exceeds 0.5 FTE per 10 applications, your middle option is drifting into custom-build territory.

Example policy-as-code snippet

A lightweight policy layer can reduce vendor lock-in and keep exceptions visible.

package iam.access

default allow = false

allow {
  input.request.type == "temporary"
  input.request.duration_hours <= 8
  input.request.approver_count >= 2
  input.user.risk_score < 40
}

allow {
  input.request.type == "standard"
  input.user.manager_approved
  input.entitlement.sensitivity != "restricted"
}

This kind of rule is easy to audit, but only if your upstream identity data is reliable. If manager chains are wrong 7% of the time, the policy engine just automates bad decisions faster.

How to compare options with numbers, not opinions

Use a scorecard that combines cost, speed, and operational burden.

A practical scoring model

Score each option from 1 to 5:

• Time to first audit-ready workflow
• Connector coverage for your top 20 apps
• Policy flexibility
• Ongoing engineering load
• Vendor lock-in risk
• Evidence quality

Example comparison for a 50-app enterprise:

• Build: speed 2, flexibility 5, load 2, lock-in 5, evidence 4
• Buy: speed 5, flexibility 3, load 4, lock-in 2, evidence 5
• Middle option: speed 4, flexibility 4, load 2, lock-in 3, evidence 4

The middle option only wins if you can keep the load low. If not, it slides toward the worst of both worlds.

Benchmark what matters

Track these metrics from day one:

• Access review completion rate: target 85%+ within 10 business days
• Provisioning success rate: target 98%+ for standard apps
• Policy evaluation latency: target under 200 ms for interactive requests
• Connector failure rate: target under 1% per month
• Exception backlog age: target under 14 days

One retail enterprise cut certification cycle time from 21 days to 8 days after standardizing role data and removing 140 duplicate entitlements. The software mattered less than the data model.

Common Pitfalls

1. Buying before cleaning identity data

If your HR titles, department codes, and manager fields are inconsistent, your governance rollout will stall. Fix source data first or budget a cleanup sprint that lasts 4 to 8 weeks.

2. Treating connectors as one-time work

APIs change. SCIM schemas drift. App owners rename groups. Plan for ongoing connector maintenance or you will lose trust in the platform within a year.

3. Ignoring exception workflows

Emergency access, contractors, and break-glass approvals create most audit pain. If the exception path is manual, your "automated" governance is partial at best.

4. Pricing only the software license

This is the most common mistake. In many 2026 enterprise cases, the license is under half the 3-year TCO.

5. Letting security own it alone

Identity governance needs HR, IT, app owners, and compliance. If only security cares, the workflow will be too strict, too slow, or both.

A decision framework you can use this quarter

Use this sequence before you sign anything:

1. Map your top 20 apps by entitlement complexity.
2. Classify each app as standard, semi-standard, or custom.
3. Estimate integration effort in hours, not optimism.
4. Separate platform cost from control-plane cost.
5. Decide who owns policy data, connector health, and audit exports.
6. Run a 30-day pilot with real users and real exceptions.

pilot_success_criteria:
  identities: 2000
  apps: 8
  certification_completion_days: 10
  provisioning_success_rate: 0.98
  exception_handling_time_days: 3
  connector_breakages: 0

If your pilot cannot hit those numbers, do not scale the program. Fix the data model, the workflow, or the operating ownership first.

Key Takeaways

• Build versus buy for identity governance is really a decision about who owns policy, data, and connector upkeep.
• The middle option is usually the most expensive because teams buy the platform but still build the control plane.
• Price the full 3-year TCO, not just the license, and include cleanup, exceptions, audits, and ongoing integration work.
• Build only when identity logic is a core differentiator or your policy needs exceed vendor limits.
• Buy when you need audit-ready coverage quickly and your app estate is mostly standard SaaS.
• If you choose the middle option, treat the identity data hub and policy layer as products with named owners and measurable SLAs.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.