What Is Identity Governance and Administration (IGA)?

Identity governance and administration (IGA) is the discipline, and the set of tools, that decides who should have access to what, grants and removes that access as people join, move and leave, and proves it to an auditor. Access management lets people log in. IGA answers whether they should have been able to.

That second question sounds simple until you try to answer it for 15,000 people and 400 applications. Most organizations can tell you who logged in yesterday. Far fewer can tell you why a payroll clerk still has write access to the general ledger three roles after she stopped needing it. IGA exists to close that gap.

What is identity governance and administration, in plain terms?

Split the name in half and it gets easier.

Identity administration is the plumbing: creating accounts, assigning entitlements, changing them and taking them away. It’s provisioning and deprovisioning, ideally driven automatically from an authoritative source like your HR system rather than from a ticket someone may or may not get around to.

Identity governance is the oversight: policies about who should have what, periodic reviews that confirm it, controls that stop toxic combinations of access, and the audit trail that shows all of it happened.

You need both. Administration without governance is fast but unaccountable, and access piles up. Governance without administration is a quarterly spreadsheet exercise that finds problems nobody has the machinery to fix.

What IGA actually does

A mature IGA platform covers six jobs. Not every program needs all six on day one, but these are the pieces you’ll eventually be asked about.

Joiner, mover, leaver lifecycle

This is the heart of it. When HR hires someone, an identity is created and birthright access (email, the intranet, the basics for their department) is provisioned automatically. When they change jobs, the mover event should both add the new access and remove the old. When they leave, everything comes off, promptly and completely.

Joiners are the easy part, because people complain loudly when they don’t have access. Leavers get attention because auditors check them. Movers are where access quietly accumulates. Most organizations are good at adding access for a transfer and bad at taking any away, which is how long-tenured employees end up with the combined entitlements of every job they’ve ever held.

Access requests

Anything beyond birthright access goes through a request: a catalog of applications and entitlements, an approval workflow (usually the manager, sometimes the application owner too), and automated fulfillment once it’s approved. A good request process is self-service and fast. A bad one is so slow that people share credentials or ask a friend in IT, which defeats the point.

Access certifications and user access reviews

A user access review (also called an access certification or recertification) asks a reviewer, typically a manager or application owner, to confirm that each person’s access is still appropriate. Approve what’s right, revoke what isn’t, and the platform records the decision and ideally removes the revoked access on its own.

These are the most visible part of IGA because auditors ask for them by name. They’re also the part most likely to become theater. More on that below.

What this usually looks like: Say a manager gets a certification with 1,400 line items on a Friday afternoon, most of them cryptic group names, and a Monday deadline. The approve-all button is right there, and the campaign closes on time with a 99% approval rate. Audit gets its evidence, and nobody learns anything about who should actually have access.

Role management

Roles bundle entitlements so you can grant “Accounts Payable Analyst” instead of fourteen individual permissions. Done well, roles make provisioning predictable and reviews shorter. Done badly, you end up with more roles than people. Role mining tools can suggest roles from existing access patterns, but the output still needs a human who understands the business to decide which patterns are intentional and which are years of accumulated accidents.

Separation of duties (SoD)

SoD policies define combinations of access that no single person should hold, the classic example being someone who can both create a vendor and approve payments to it. The IGA platform checks requests and existing access against those rules, blocks or flags violations, and records any approved exceptions along with their mitigating controls. If you’re subject to SOX, this section will matter to your auditors more than any other.

Audit and reporting

Every grant, approval, review decision and revocation is logged. When the auditor asks “show me that terminated users lost access within your policy window,” you run a report instead of assembling screenshots for a week.

IGA vs. IAM vs. PAM

These three get confused constantly, partly because vendors keep expanding into each other’s territory. Strictly speaking, IAM is the umbrella and IGA and PAM are disciplines inside it, but in practice “IAM” usually means access management: authentication, SSO and MFA. That’s how I use it here. (For the wider picture, see what IAM covers.)

	Access management (IAM)	IGA	PAM
Main question	Can this user log in, right now?	Should this user have this access at all?	How is admin access controlled, used and recorded?
Who it covers	Everyone	Everyone, plus their entitlements	Admins, privileged and service accounts
Time frame	The moment of login	The life of the identity	The privileged session
Core functions	SSO, MFA, adaptive access, federation	Lifecycle, requests, reviews, roles, SoD	Vaulting, rotation, session recording, elevation
Typical tools	Okta, Ping Identity, Microsoft Entra ID	SailPoint, Saviynt, Omada, Microsoft Entra ID Governance	CyberArk, BeyondTrust, Delinea
Who asks for it	Users and the help desk	Auditors and the business	Security, after an incident or a pen test

The short way to remember it: access management enforces, IGA decides, and PAM protects the accounts that could do the most damage. They work best when they share data, which is a point I’ll come back to.

What a good IGA program looks like

The programs I’ve seen work share a few traits, and none of them is about which product was bought.

HR is the source of truth, and the data is clean. IGA automation is only as good as the feed driving it. If job codes are inconsistent, managers are missing or contractors live in a spreadsheet outside HR, every downstream process inherits the mess. Fixing identity data is unglamorous and it’s usually the highest-value work in the first six months.

Applications are onboarded by risk, not alphabetically. Start with the systems that hold regulated data, move money or carry admin rights. A program that has connected 40 low-risk SaaS apps and not the ERP system is reporting progress on the wrong scoreboard.

Reviews are small and meaningful. Reviewers get access they can actually judge, described in language they understand. “SAP_FI_GL_POST_X02” means nothing to a sales director. “Can post journal entries to the general ledger” does. Smaller, targeted campaigns (high-risk apps quarterly, the rest annually, plus event-based reviews when someone moves) beat one enormous campaign that everyone clicks through in December.

Revocations actually happen. If a reviewer revokes access and it takes a ticket, three weeks and a reminder to remove it, reviewers learn their decisions don’t matter. Closed-loop remediation, where the platform removes the access directly or verifies that it was removed, is what separates governance from paperwork.

Someone owns it. IGA touches HR, IT, security, audit and every application owner. Without a named owner with the authority to make those groups agree, it stalls in committee.

What I’d look for: The mover process is the best test of whether an IGA program is real. When a transfer in HR automatically triggers a review of the old department’s access, with a short grace period before removal, access stops piling up with tenure. If your long-serving employees hold noticeably more entitlements than new hires in the same role, the mover process isn’t working yet.

Where IGA projects go wrong

I came to identity from the delivery side, years as a Scrum Master, Agile coach and program manager, so I tend to see IGA failures as delivery failures first. The technology is rarely the reason a project stalls.

Treating it as a software install. Buying an IGA platform is like buying a gym membership. The purchase is the easy part. Most of the work is process design, data cleanup and getting application owners to show up, and project plans that budget for configuration but not for that work run late from week one.

Trying to connect everything before delivering anything. The big-bang plan (all applications, full role model, every workflow, then go live) is how you spend 18 months and still have nothing in production. Deliver the joiner-leaver flow for the HR system and a handful of critical apps, prove it works, then iterate. This is where an incremental delivery mindset pays for itself.

Rubber-stamp reviews. When a manager gets 2,000 line items in a certification, the rational move is “approve all.” Approval rates near 100% aren’t evidence of a clean environment. They’re evidence that nobody is reviewing anything. Track revocation rates and time-to-decision per reviewer, and you’ll see quickly which campaigns are real.

Role explosion. Teams try to build a perfect role model up front, end up with thousands of narrowly scoped roles and then can’t maintain them. Start with a modest set of broad birthright and departmental roles, and let request data show you where finer roles are worth the upkeep.

Ignoring non-human identities. Service accounts, API keys, bots and now AI agents often outnumber people, and many IGA deployments simply leave them out because they have no manager and no HR record. They still need an owner, a purpose and a review. Someone has to be accountable when one of them has domain admin.

Where it tends to go wrong: A stalled rollout usually looks like a steering committee still debating the role model while no application has gone live. What tends to get it moving is shrinking the scope to one outcome people can feel, such as leavers losing access to the ten most critical applications the same day HR records the termination. Once that works and audit notices, attention and funding for the next phase get much easier to find.

IGA tools: a quick tour

You’ll see the same names on most shortlists. I’m not ranking them here; the right choice depends on your application mix, how much customization you need and what you already own.

• SailPoint. The name most people think of first. It offers Identity Security Cloud as SaaS and IdentityIQ for organizations that want to run it themselves. Deep connector library and a large partner ecosystem.
• Saviynt. A cloud-native platform that pulls IGA, application access governance and privileged access features together, with a strong following for governing ERP access.
• Omada. A European vendor with a SaaS platform and a reputation for a structured, best-practice implementation approach.
• Microsoft Entra ID Governance. Lifecycle workflows, entitlement management, access reviews and Privileged Identity Management for organizations already standardized on Entra ID. A natural fit for Microsoft-centric estates. Check coverage carefully if much of your critical access lives outside the Microsoft ecosystem.

Other vendors compete in the space too, and the major access management players have been adding governance features. When you evaluate IGA tools, test with your own messy data and your hardest application, not the vendor’s demo tenant.

How IGA should connect to PAM

This is the part I care about most, and the part most organizations skip. IGA and PAM are frequently bought by different teams, implemented by different partners and reviewed by different auditors. The result is two systems that each believe they know who has privileged access, and they disagree.

The fix is to make them work as one control:

• IGA governs who is entitled to privileged access. Requests for admin rights, membership in PAM safes or policies, and access to privileged roles flow through IGA, with approvals and SoD checks like any other entitlement.
• PAM enforces how that access is used. Credentials stay vaulted and rotated, sessions are brokered and recorded, and elevation happens just in time.
• Privileged access shows up in reviews. Certifications include PAM entitlements, so a manager reviewing an engineer sees “can check out domain admin credentials” alongside their SaaS apps.
• Leavers lose privileged access everywhere at once. A termination in HR flows through IGA and removes the person from PAM, not just from Active Directory.

I’ve wired SailPoint back into PAM for exactly this reason. Once the two share a model of who should have privileged access, you can finally answer the question that matters most: who, and what, can reach your most critical systems right now? For the identity side of that broader architecture, see building the identity pillar of a Zero Trust program.

In practice: The connector itself is the easy part. The work is in the data: PAM safes and policies named for the people who built them rather than for reviewers, privileged accounts with no clear owner, and group memberships that grant access indirectly. My advice is to rename and describe privileged entitlements before the first combined campaign, or reviewers will approve them for the same reason they approve everything else they can’t read.

The short answer

Identity governance and administration is how you make access decisions on purpose instead of by accident, and how you prove those decisions to someone else. The tool matters less than three things: clean HR data driving the lifecycle, access reviews small enough for a human to actually review, and revocations that really happen. If you already have PAM, connect it to your IGA program early. Two systems that disagree about who has admin rights aren’t a governance program, just two sources of audit findings.

More on the governance side of identity lives in the IGA topic hub and, for the audit and compliance angle, the GRC hub.