Identity governance and administration (IGA) manages who has access to what. Full identity governance goes further: it governs what that access can actually do once someone is inside the application, down to the transaction and the field, not just the account.
Key Takeaways
- IGA governs the request-and-approval side of access: lifecycle, provisioning, certifications.
- IGA generally does not see transaction-level activity inside SAP, Oracle, or similar applications.
- Full identity governance adds four things: transaction-level SoD, usage-based risk analysis, in-application controls, and financial exposure quantification.
- The practical path for most enterprises is pairing an existing IGA platform with an in-application governance layer, not replacing either.
That distinction matters more than it sounds. Most buyers researching IGA assume “governance” is a single, complete idea: grant access, certify it periodically, done. It isn’t. What follows is a plain breakdown of what IGA covers today, where it stops, and what closing that gap actually requires.
What Is IGA?
Identity governance and administration is the discipline of managing user identities and their access rights across an organization’s systems. A typical IGA platform handles the identity lifecycle (joiner, mover, leaver), self-service access requests, role-based provisioning, and periodic access certifications, usually tied to directories like Microsoft Active Directory, Microsoft EntraID, or Okta Universal Directory.
This is foundational work, and the major IGA platforms do it well. If the question is “who has an account, and what role were they assigned,” IGA answers it.
What Does IGA Typically Cover?
Core IGA capabilities generally include:
- Joiner/mover/leaver automation
- Self-service access requests with approval workflows
- Birthright and RBAC policy assignment
- Connector breadth across SaaS and on-premise systems
- Certification campaigns for periodic access review
- Directory and identity-provider integration
All of this governs the request-and-approval side of access. It answers “was this access granted correctly,” which is a necessary question for any compliance program.
What Does IGA Miss?
Here’s the gap: granting access correctly is not the same as the access being used correctly. A certification campaign can confirm that someone was approved for a role in SAP or Oracle. It generally cannot tell you whether that role lets them execute a conflicting pair of transactions, what a service account actually did with its standing access last Tuesday, or what an access violation would cost in dollars if it went uncaught through an audit cycle.
That’s because most IGA platforms govern at a shallow level, at the coarse-grained entitlement layer. The transaction-level activity inside SAP, Oracle, Workday, or similar systems, the layer where segregation-of-duties conflicts and sensitive-data exposure actually happen, sits below what a connector-based IGA tool can see.
What Does Full Identity Governance Require?
Full identity governance requires full visibility to the entire complex business application security model in addition to the usage of it. In practice, that means four things a cursory, coarse-grained entitlement-only IGA tool typically can’t do:
- Transaction and field-level segregation-of-duties (SoD) analysis. Not “does this role conflict with that role,” but “does this specific transaction, at this specific field, conflict with another transaction this person can also run.”
- Usage-based risk analysis. What the access was actually used to do, not just what it theoretically permits.
- Real-time controls inside the system. Data masking, configuration monitoring, and code-level scanning that operate inside SAP or Oracle, not as an external policy layer.
- Financial exposure quantification. Putting a dollar figure on what an access risk would cost, which is what audit committees actually ask for.
Pathlock’s Access Risk Analysis module is built specifically for this layer: cross-application SoD down to the permission level, with usage logging that shows what access was actually executed. Pairing it with an existing IGA platform’s lifecycle and certification work, rather than replacing that work, is the practical path most enterprises take.
Coarse-Grained Entitlement Governance vs. Fine-Grained/Usage Governance
| Coarse-Grained Entitlement Governance (typical IGA) | Fine-Grained/Usage Governance | |
|---|---|---|
| Answers | Who has access? | What can that access actually do? |
| Granularity | Role or account | Transaction, field, authorization object |
| Timing | Request, approval, periodic recert | Continuous, at point of use |
| Risk visibility | Theoretical (what access permits) | Actual (what access did) |
| Typical owner | IT security, IGA admin | Audit, SOX compliance, GRC |
Where This Fits in Your Stack
If your organization already runs an IGA platform for workforce lifecycle and application provisioning, the question isn’t whether to replace it. It’s whether anything in your stack governs what happens after access is granted, specifically inside the applications where financial and operational risk occurs. Pathlock’s Application Access Governance platform is built to sit on top of that foundation and close exactly that gap, and the GRC cross-walk framework walks through how that plays out for audit-driven programs specifically. Gartner’s own Market Guide for Identity Governance and Administration is a useful independent reference for how the broader IGA market itself is evolving. For background on the underlying regulatory requirement, the SEC’s own Section 404 guide explains what internal-control evaluation is meant to accomplish.
FAQ
Does IGA cover SAP or Oracle access risk?
Most IGA platforms can provision and certify access to SAP or Oracle accounts, but they generally don’t analyze transaction-level segregation-of-duties conflicts or usage inside those systems. That requires a layer built for the application itself.
Is full identity governance the same as GRC?
They overlap but aren’t identical. GRC (governance, risk, and compliance) typically covers controls monitoring, audit evidence, and risk quantification more broadly. Full identity governance is the specific idea that access governance has to extend past the request-and-approval stage into what the access is used for.
Do I need to replace my IGA platform to get this?
No. The more common pattern is pairing an existing IGA platform’s lifecycle and certification capabilities with an in-application governance layer for ERP and business-critical systems, rather than replacing either.
What’s the risk of only governing at the entitlement level?
A coarse-grained entitlement-only view can confirm access was approved while missing that the approved access creates a segregation-of-duties conflict, exposes sensitive data, or has already been misused. Auditors increasingly expect evidence at the transaction level, not just the approval level.
Go Deeper
For a closer look at what unifying provisioning, certification, and risk analysis into one governance layer actually requires, see Pathlock’s eBook, Access Orchestration for the Digital Enterprise.
