Identity Governance Forgot About the IT Admin

IGA vendors built for compliance, not for operations.

Six IGA vendor demos in one quarter. Each opened with impressive dashboards. Compliance posture scores. Risk heat maps. Access certification workflows. Audit-ready reports. Executives nodded approvingly.

Then came the real question: “How does this automate which users belong to which groups?”

The sales engineer paused. They talked about access requests. They talked about approval workflows. They talked about access reviews where managers certify existing access.

But group membership automation? Policy-based provisioning? Eliminating the manual work of adding users to the right resources based on their role?

“Well, that would be configured in the IdP. We integrate with Okta.”

In other words: that’s not their problem.

The IGA Value Proposition

Identity Governance and Administration (IGA) vendors solve real problems. The market exists because organizations need access requests (a way for employees to request access to resources they don’t have), approval workflows (routing requests to the right people for authorization), access reviews (periodic certification that existing access is still appropriate), audit reporting (evidence for compliance requirements), and lifecycle orchestration (triggering processes when employees join, move, or leave).

These are legitimate needs. Compliance frameworks like SOC 2, ISO 27001, and SOX require evidence of access governance. IGA vendors provide that evidence.

The problem isn’t that IGA vendors are bad. The problem is what they optimize for.

Built for Compliance, Not Operations

IGA vendors are built to satisfy auditors and executives. Their dashboards answer questions like “What is our compliance posture?” and “How many access requests are pending?” and “What percentage of access reviews are complete?” and “Can we demonstrate least privilege?”

These are important questions. They’re not the questions IT administrators ask.

IT administrators ask different questions: “How do I automate the 50 onboarding access grants we do every week?” and “How do I keep 15 Google Groups in sync with our team structure?” and “How do I handle the quarterly reorg without rebuilding all my automation?” and “How do I stop processing the same predictable access requests over and over?”

IGA vendors don’t optimize for these questions. Their core value proposition assumes access requests and reviews are permanent fixtures. They make those processes more efficient, but they don’t eliminate them.

The incentive structure is revealing: if an IGA vendor eliminated the need for access requests, they’d be undermining their own value proposition. “Fewer access request workflows are needed now” isn’t a compelling renewal conversation.

The Access Request Treadmill (Revisited)

Consider a typical IGA workflow:

1. Employee needs access. They can’t do their job without access to a resource.
2. Employee submits request. Through the IGA portal, they request access.
3. Request is routed. Based on the resource, it goes to the appropriate approver(s).
4. Approver reviews. Manager or resource owner evaluates the request.
5. Access is granted. IGA triggers provisioning (often via the IdP).
6. Access is reviewed. Periodically, the access is recertified.

Every step is tracked. Auditors are happy. Compliance boxes are checked.

But here’s the question: why did step 1 happen?

If the employee is on the Sales team and needed access to the Sales Google Group—why didn’t they have it already? The system knew they were on the Sales team. It knew what the Sales team needs access to. The request was predictable, the approval was rubber-stamped, and the provisioning was routine.

The entire workflow exists because the access wasn’t pre-provisioned according to a policy that should already exist.

IGA vendors treat this as normal. Access requests are the core of their product. From an operational perspective, every routine request is evidence of a missing policy.

Access requests create audit evidence, but they also create audit findings. When auditors see high volumes of routine access requests—especially for baseline entitlements that should be automatic—they question whether adequate provisioning controls exist. Policy-based provisioning demonstrates stronger CC6.1 compliance than request-based provisioning for predictable access needs.

The Policy Engine Gap

Our founder has has sat through those same IGA demos. And he kept asking the same question: “I understand the access request approvals, but where’s the entitlement policy engine?”

Not the approval policy. Not the review policy. The membership policy — the thing that says “users with these attributes belong in this group.”

The answers were revealing:

• “That would be set up in the IdP group rules.”
• “We integrate with the IdP for provisioning.”
• “Our professional services team can help configure that.”
• “That’s on our roadmap.”

IGA vendors had sophisticated workflows for managing access requests. They had audit trails and compliance reports. What they didn’t have was a way to define “who should have access based on their role” and automatically provision it.

That’s the gap. IGA handles access requests (reactive). It doesn’t handle access policy (proactive).

The Workflow Comparison

Compare how access works in a request-centric model vs. a policy-centric model:

Request-Centric (Traditional IGA):

1. New hire joins the Sales team
2. New hire discovers they can’t access the Sales shared drive
3. New hire submits access request through IGA portal
4. Request is routed to manager for approval
5. Manager approves (because of course the sales person needs sales access)
6. IGA triggers provisioning
7. Access is granted (hours or days later)
8. Quarterly access review recertifies this access
9. Repeat for every resource, every new hire, forever

Policy-Centric:

1. Admin defines Ruleset: “Sales shared drive should contain users where department = Sales”
2. New hire joins the Sales team
3. Directory sync picks up the new user with department = Sales
4. Policy engine evaluates all Rulesets—user matches Sales shared drive Ruleset
5. Sync job provisions access
6. Access is granted (minutes after directory sync)
7. Audit queries the policy database for compliance evidence

The request never happens. The approval never happens. The access is provisioned because the policy already defined that Sales people get Sales access.

The audit evidence still exists—it’s in the policy definition and the sync logs. No human had to process a request for something that was already known.

Policy-based provisioning provides continuous evidence of least-privilege enforcement. Instead of point-in-time attestation spreadsheets, auditors receive system-generated proof that access matches policy—satisfying SOC 2 CC6.1 (logical access controls) and ISO 27001 A.9.2.1 (user registration and de-registration) with stronger controls than request-based workflows.

What IT Admins Actually Need

Based on conversations with dozens of IT teams, here’s what they’re looking for:

1. Policy management

   A way to define “who belongs where” based on attributes, not individual requests. Rules that survive reorgs and renames.

2. Cross-system sync

   The same policy should control Google Groups, Okta Groups, Slack channels, and GitLab access. One definition, multiple systems.

3. Visibility into what's automated

   What’s managed by policy vs. what’s manual? Where are the gaps in automation?

4. Handling for edge cases

   Policies cover the 90%. A way to handle the 10% exceptions without abandoning the automation.

5. Audit trails that don't require forensics

   Who has access, why, when was it granted, based on what policy. Queryable, not reconstructed from ticket history.

6. Reducing request volume, not just managing it

   The goal is fewer requests, not more efficient processing of the same volume.

IGA vendors optimize for audit trails and efficient processing of requests. They don’t optimize for policy management, cross-system sync, automation visibility, edge case handling, or request volume reduction.

The Coexistence Model

Here’s the reality: most organizations still need IGA. Compliance requirements aren’t going away. Access reviews are mandated by auditors. Sensitive access genuinely needs approval workflows.

But IGA shouldn’t be the only tool. The model that works:

IGA handles: sensitive access that requires human approval, compliance reporting and audit evidence, access reviews for high-risk resources, and exceptions that genuinely need manager judgment.

Policy engine handles:

• Baseline access that’s predictable by role
• Cross-system group membership
• Automatic provisioning and deprovisioning based on attributes
• The 90% of access that doesn’t need human approval

At some companies, an IGA is the front-end for access requests, and Provisionr is the policy engine is the back-end that actually provisions most access automatically.

For example, access requests that go through ConductorOne or Lumos should decrease over time—each one is a signal that a policy is missing. As policies mature, request volume drops. IGA becomes the exception handler, not the primary workflow.

Vendors Don’t Want to Solve This

Here’s the uncomfortable truth: most IGA vendors don’t want to solve the policy problem.

If policy-based automation reduces access request volume by 80%, that’s 80% fewer workflows running through their platform. That’s 80% fewer approval notifications. That’s 80% less “value” being demonstrated in their dashboards.

Their business model depends on access requests being a permanent fixture. They’ll make requests faster. They’ll add AI to auto-approve routine requests. They’ll streamline the approval UX. But they won’t eliminate the need for requests, because requests are the product.

This isn’t a criticism of the companies—they’re rationally following their incentives. But it means the policy problem won’t be solved by IGA vendors. It requires a different tool with different incentives.

Finding the Missing Piece

IGA is not the enemy. Compliance matters. Audit trails matter. Approval workflows for sensitive access matter.

But IGA isn’t the complete solution. The missing piece is policy-based automation—the thing that provisions 90% of access automatically so workflows are only needed for the exceptions.

If an IGA investment isn’t reducing the operational burden on the IT team, it’s because IGA wasn’t designed for operational efficiency. It was designed for compliance. Those are different goals that require different tools.

IT administrators deserve tools built for their actual work: keeping access in sync with organizational reality, automatically, without drowning in tickets.

That’s what identity governance looks like when it remembers the IT admin.

---

Ready for policy-based automation alongside IGA? See how Provisionr complements existing tools →