What Is IGA, and Why It Matters

A question nobody can answer quickly

Ask the IT team of a growing company who has access to the payroll system, and the answer usually starts with “let me check.” Someone exports the user list. Someone else points out that the export doesn’t include the people who reach payroll through the HR portal. A third person remembers that two contractors were given temporary access during the migration last year, and isn’t sure it was ever removed. By the end of the afternoon there’s a spreadsheet, and nobody is fully confident in it.

That afternoon is the problem IGA exists to solve. In the five domains of IAM we described IGA briefly as the department that keeps the list of who can come in and checks that the list is still right. That was enough to place it on the map next to access management, privileged access, customer identity, and threat detection. It isn’t enough to run a program, size a budget, or explain to a finance director why an IGA platform deserves money.

This article goes further, around two questions that carry the rest of the module. What exactly is the difference between administering identities and governing them, two things people tend to blur together? And what makes an organization decide, on a particular day, that this is the year it funds IGA?

Administration and governance are different jobs

“Identity Governance and Administration” is usually said quickly, as one phrase. The two halves answer different questions, belong to different people in a mature program, and confusing them is one of the most common reasons IGA projects stall.

Identity administration is the operational side. It carries out changes to access: creating an account, adding someone to a group, running a connector against Active Directory, fulfilling an approved request, disabling a leaver. If you can point to a log line that says something changed at 14:03, you’re looking at administration.

Identity governance is the oversight side. It decides whether a change should happen and checks afterwards that what happened was right. That covers policy, access reviews, separation-of-duties rules, role design, and the evidence auditors ask for. If you can point to a decision, such as “this access is still justified” or “these two permissions must never be held together,” you’re looking at governance.

The two form a loop rather than a stack. Administration carries out what governance approves, and governance reviews what administration carried out. Either one alone fails in a recognizable way. A company with administration and no governance provisions access quickly and never checks whether any of it still makes sense; the contractor account is still active eighteen months after the contract ended because nobody’s job is to look. A company with governance and no administration has a well-written policy it can’t enforce, because removing the access the policy flags still means emailing an application owner and waiting three weeks.

flowchart LR
  accTitle: Identity administration and identity governance form a loop
  accDescr: A need for access leads identity administration to provision it. The person uses the access, and identity governance reviews it, audits it, and checks it against separation-of-duties rules. If governance confirms the access is still needed, the person keeps using it. If it is no longer justified, administration removes it.
  REQ([Need for access]) --> IA[Administration<br/>provisions, assigns, connects]
  IA --> USE[Person uses the access]
  USE --> IG[Governance<br/>reviews, audits, checks SoD]
  IG -->|Still needed| USE
  IG -->|No longer justified| REVOKE[Administration<br/>removes access]
  REVOKE --> DONE([Access gone])

The split usually maps onto real teams. IAM engineering and IT operations tend to own administration: they configure connectors, build workflows, and keep provisioning running. Compliance, risk, and the business and application owners tend to own governance: they decide what correct access means for their systems and sign off on reviews. That boundary between teams is also where programs most often get stuck, with one side waiting for the other to respond.

When an IGA vendor says “we do IGA,” it’s worth asking which half of the loop they’re strongest at. Some products began as provisioning engines and added governance features later; others began as review and analytics tools and added connectors later. Neither history is wrong, but it tells you where the product is mature and where your program will have to make up the difference with process.

What IGA is not

Three misunderstandings do more damage to IGA programs than any technical mistake, because they shape what a team decides to build in the first place.

The first is that IGA is just access certification. Reviews are the most visible part of governance, the campaign that lands in every manager’s inbox each quarter, so it’s easy to mistake them for the whole thing. A program that only runs reviews, without fixing slow provisioning, missing connectors, or roles too vague to judge, produces campaigns that managers approve without reading, because they have no real way to tell what they’re approving. Reviews are one output of governance, not the discipline.

The second is that IGA is only for large enterprises. Size helps predict the need, but complexity is what actually triggers it. A 200-person fintech with fifteen regulated integrations and a rotating bench of contractors can outgrow spreadsheet access management long before a 2,000-person manufacturer with a stable workforce does. The useful question isn’t how many employees there are. It’s whether anyone can answer “who has access to what, and why” without days of digging.

The third is that buying a platform is the governance. A tool doesn’t decide whether a role makes sense, whether a risky combination of access is tolerable for this business, or whether a reviewer is really looking at what they approve. Those stay human judgments even with a fully deployed platform. What the tool does is make them visible, repeatable, and recorded.

Who IGA covers

IGA grew up around employees, and employees are still most of its work. But the identities it has to govern in a modern organization go well beyond the payroll.

Contractors and vendors are the obvious second group. They often do the same work as employees, with the same access, but they arrive through procurement rather than HR, their engagements end on dates nobody in IT is told about, and they’re disproportionately represented in the “account still active months later” findings auditors love. Partners who sign in through federation from their own organization are a third group, governed differently because someone else is authoritative for who they are. And then there are the identities that aren’t people at all: service accounts, integration users, API clients, automation. They have no manager and no HR record, they tend to collect broad access because someone needed an integration to work quickly, and they’re increasingly the target attackers go after first. AI agents acting on someone’s behalf are the newest arrivals in this group, and governing them raises the same questions in a sharper form: who owns this agent, what can it reach, and who decided that was appropriate.

Customers, on the other hand, are usually outside IGA’s scope. Their identities are managed by customer IAM, with very different priorities: self-registration, consent, scale in the millions. The governance questions IGA asks, such as who approved this access and is it still needed, don’t really apply to someone signing up for an app.

Signs a spreadsheet is no longer enough

Small organizations manage access perfectly well with a spreadsheet and a careful IT lead. The point where that stops working is rarely announced; it shows up as a pattern of small symptoms.

Access requests arrive as free-text emails and get fulfilled by copying a colleague’s access. Nobody can say, without a day of digging, which accounts belong to people who have left. The same person has three different usernames in three systems, and nobody is sure they’re the same person. Access reviews, if they happen, are spreadsheets emailed to managers who reply “looks fine.” Auditors ask for evidence and get screenshots. And when someone changes jobs, they keep everything from the old job, because removing it is nobody’s task.

Any one of these is manageable. Three or four together usually mean the organization has crossed the complexity threshold, and the cost of the manual approach, in time, audit findings, and risk, is now higher than the cost of a program.

Where IGA stops and other domains begin

A simple test clears up most of the confusion with neighboring domains. If the ticket says “I can’t log in,” it belongs to access management, the domain covered before this one. If it says “why does this account still have admin rights on a production database,” it starts in IGA, with the question of whether that access should exist and who last reviewed it, and usually ends in privileged access management, because an administrator account that needs a vault, session recording, and time-limited elevation has outgrown what IGA governs well on its own. IGA decides whether an identity should hold an entitlement. PAM adds controls over how a privileged entitlement is used once it’s granted. Later in this domain there’s an article about exactly that handoff.

The same Tuesday, twice

The difference IGA makes is easier to see in a single company than in definitions. Daniel runs IT operations at a 900-person logistics company that grew quickly through three regional acquisitions and still handles access requests through a shared inbox.

On a Monday, Sara joins the customer operations team. Her manager emails Daniel’s team asking for “the usual access,” a phrase that means something different to everyone who reads it. Daniel’s team copies whatever the last hire in that role received six months ago, before two of the systems involved changed their permission model. Sara gets part of her access on Wednesday, finds out on Thursday that nobody asked for the warehouse visibility module she needs, and is fully productive the following Monday, a week late.

Meanwhile, a contractor from one of the acquired offices, whose engagement ended in March, still has an active account in July. Nobody notices, because no process exists whose job it is to notice. The account turns up four months later in an external audit as a finding: access without a documented business reason. The audit runs six weeks over, because reconstructing who had access to what, and who approved it, means piecing together email threads and spreadsheets that were only ever meant as to-do lists.

Now picture the same company eighteen months into an IGA program. Sara’s manager requests her access from a catalog that already knows what a customer operations analyst needs, because the application owners defined that bundle once and it gets reused every time. The request routes for approval on its own, the access is provisioned the same day, and Sara is working on Tuesday morning.

The contractor’s account doesn’t linger, because the contract’s end date was attached to it when it was created, so the access ends with the engagement. When the auditors arrive, every grant, approval, and review already exists as a report. The audit takes the two weeks it was planned for.

The people, applications, and regulations are identical in both versions. What changed is the process, and that process is what IGA names and puts into practice.

What actually gets a program funded

Nobody funds “better identity hygiene” in the abstract. IGA programs get money when a specific event makes the cost of not having one suddenly concrete. Four kinds of event come up again and again.

Compliance is the most common. An audit is coming, under SOX, HIPAA, PCI DSS, or GDPR, or a previous one went badly. Auditors ask some version of the same question whatever the framework: show me who has access to this system, who approved it, and when it was last reviewed. An organization that can only answer with a live query against production and a week of manual reconciliation has just shown that the control doesn’t really exist, whatever its policy says.

Risk is the second. A breach at a competitor, a penetration test finding, or an internal incident where “who has admin on that database” turned out to be a question nobody in the room could answer. Programs that start from risk tend to begin narrowly, cleaning up standing administrator access and the most obvious dangerous combinations before attempting reviews across the whole company.

Efficiency is the third, and it usually comes from IT operations or HR rather than security. IT is buried in access tickets, onboarding drags, and every new hire’s first week is partly spent waiting. The pitch here is about speed and staff time, not risk.

Mergers and acquisitions are the fourth. Two directories, two naming conventions, two ideas of what a “manager” is, and a deadline to show the board or a regulator a single picture of who can access what. This kind of IGA work is compressed and unforgiving; there’s rarely time to design roles carefully, only to reconcile what exists well enough to govern it.

Two short cases make the risk and merger drivers concrete. A payments company runs a routine penetration test, and the finding that reaches the CISO isn’t a clever exploit. It’s that eleven service accounts across three systems have the equivalent of domain administrator rights, and nobody can explain why more than four of them still need it. That finding, not a breach, gets a cleanup of privileged accounts and conflicting access funded within the quarter. In the other case, a mid-sized insurer buys a regional competitor and discovers during integration planning that both companies use the title “underwriter” for jobs with very different approval limits. Nobody planned to solve role design during a 90-day integration, but the board wants a single access report before the deal closes, so the work happens anyway: rushed, imperfect, and done properly the following year.

flowchart LR
  accTitle: Business drivers, the failures behind them, and the IGA capability that fixes each
  accDescr: Four business drivers each lead to a concrete failure, which a specific IGA capability resolves. A compliance deadline leads to audit evidence that takes weeks to rebuild, fixed by access reviews and an audit trail. A risk incident leads to nobody knowing who has admin rights, fixed by separation-of-duties checks and cleanup of orphaned accounts. A request backlog leads to new hires waiting days for access, fixed by a self-service catalog and an automated lifecycle. A merger leads to duplicate accounts in two directories, fixed by a single identity lifecycle across sources.
  C[Compliance deadline] --> CB[Audit evidence takes weeks to rebuild]
  R[Risk incident or pen test] --> RB[Nobody knows who has admin rights]
  E[Request backlog] --> EB[New hires wait days for access]
  M[Merger] --> MB[Duplicate accounts in two directories]
  CB --> CF[Access reviews + audit trail]
  RB --> RF[SoD checks + orphan cleanup]
  EB --> EF[Self-service catalog + automated lifecycle]
  MB --> MF[One lifecycle across sources]

Real programs rarely have a single driver. Most business cases combine two, usually compliance with one of the others. Compliance is what starts the budget conversation; operational pain is what keeps the program funded after the first year.

Who sponsors the program tends to follow the driver. Compliance-driven programs are usually sponsored by the CISO or the head of risk and start with access reviews and audit reporting. Risk-driven ones are also security-sponsored but start with separation-of-duties checks and cleaning up orphaned accounts. Efficiency-driven programs are sponsored by IT operations or HR and start with self-service requests and an automated joiner-mover-leaver process. Merger-driven ones are sponsored by IT leadership or the integration office and start by unifying identities across the two organizations’ sources. Knowing which of these you’re in helps explain why a program’s first phase looks the way it does.

Governance before there’s a platform

Plenty of organizations need governance before they can justify buying anything, and the absence of a platform isn’t a reason to skip it. Most of what matters can be started by hand.

Name an owner for each important application, someone in the business who can say who should have access and why. Agree that leavers are removed from the directory and the most sensitive systems on their last day, and keep a simple checklist that proves it. Once a quarter, export the users of the two or three most sensitive systems, send each list to its owner with a request to mark what should go, and keep the reply along with proof that the removals happened. Ask for access through a form with a few required fields instead of a free-text email.

None of this scales well, and that’s fine. It builds the habits and the ownership a platform will later automate, and it produces the records that show an auditor the controls exist. When the program does get funded, it starts with owners who already know their role and data about where the problems are.

Measuring the governance half

The return figures below mostly describe administration: tickets, hours, days. Governance needs its own measures, because a program can provision quickly and still govern badly.

Useful ones include the share of sensitive access reviewed within its scheduled cycle, the number of separation-of-duties conflicts that are open and how long they’ve been open, the share of entitlements and applications with a named owner, and the share of access that can be traced back to an approval, a rule, or a review. These numbers rarely appear in the first business case, but they’re the ones a steering committee should watch once the program is running, because they show whether the loop is actually closing. A program whose ticket queue has shrunk while the share of reviewed sensitive access hasn’t moved has automated administration and left governance where it was.

What the return looks like once it runs

IGA is unusual among security investments because much of its return shows up in operational numbers, not just in losses avoided. Three figures appear in nearly every mature program’s reporting.

The first is how many access requests and changes still need a person to interpret, route, and carry out by hand. With a self-service catalog and automated fulfillment, routine requests stop needing a human at all, and the remaining queue is the genuinely unusual cases.

The second is how many hours go into preparing for an audit. The gap between running a report and rebuilding history from email gets multiplied by every framework the organization is audited against each year.

The third is how long it takes to remove someone’s access everywhere after they leave or their contract ends. Regulators and insurers care about this one most directly, because it measures how long a former employee’s access stays open as a way in.

A worked sizing example

Back to Daniel’s company. It has about 40 connected applications and 15% annual turnover, which is ordinary at that size. Before the program, IT handled around 60 access tickets a week, almost all by hand. Each SOX audit cycle took a compliance analyst about three weeks of rebuilding who had access when. And the average gap between someone leaving and their access being gone from every system was close to nine days.

Eighteen months in, about 70% of routine requests are self-service, and the manual queue is down to roughly 20 a week, mostly the unusual cases a human queue should be handling. Audit preparation takes about four days, because the review history already exists. Access removal is same-day for anything triggered by the HR termination, with only a few systems that have no connector yet still taking longer. The IT team didn’t grow. Routine work was moved away from people, and their judgment was kept for the exceptions.

None of these numbers are constants. They depend on how many applications are connected, how well roles are designed, and how disciplined the review cycle is, so treat them as the shape of the return rather than figures to copy into a business case. Organizations such as the Identity Defined Security Alliance publish research on identity program maturity if you need numbers you can cite.

The practical lesson for a new program is to record the starting point for these measures in the first month, before any tool is deployed, even if it’s rough and manual. Programs that skip this often can’t show their return eighteen months later, not because nothing improved but because nobody wrote down what the ticket queue or audit preparation looked like before. A rough baseline beats no baseline every time a steering committee asks whether the program was worth it.

How long it takes, and why

Executives sometimes expect an IGA program to take a quarter. Most mid-sized organizations need eighteen to twenty-four months to reach a steady state, and the reasons are worth knowing in advance, because they shape the plan.

Much of the time goes into data, not software. The HR system has to become a reliable source for who people are and what job they do, and that usually means cleaning up years of inconsistent entries. Correlating accounts in dozens of applications to the right people is slow, manual work for the first pass.

Another large share goes into people’s time. Application owners have to define what their entitlements mean and who should have them. Managers have to learn to review access rather than approve it by reflex. Each of those conversations competes with everyone’s day job.

And connectors arrive gradually. A program usually starts with the directory and a handful of critical systems, then adds applications in waves, each with its own testing and its own owner to bring along. The early waves show results within months; the full scope takes longer. Saying so at the start, and showing early numbers from the first wave, protects the program from being judged on a timeline it was never going to meet.

What the first ninety days usually look like

Programs that start well tend to spend their first three months on a short, unglamorous list rather than on deploying everything at once.

They record the baseline described above: the ticket queue, the audit preparation time, the time to remove leavers. They agree with HR that the HR system will be the authoritative source for employees, and with procurement on where contractor records come from. They make an inventory of applications, even a rough one, and rank them by risk, so the first connectors go to the systems that matter most.

They also pick one visible quick win. The most common is leavers: connect the HR termination event to the directory and the handful of most sensitive applications, so access disappears the day someone leaves. It’s a contained piece of work, it’s easy to measure, and it addresses the finding auditors raise most often. A second common choice is a single access review of one critical system, run properly with context and with every revocation confirmed, which both cleans up real risk and shows managers what a meaningful review looks like.

What they don’t do in the first ninety days is design every role in the company or connect every application. Those come later, in waves, with the credibility the early wins earn.

Where this maps to standards and frameworks

The split between administration and governance, and the obligations behind it, come straight from the frameworks auditors and practitioners cite:

• NIST SP 800-53, control AC-6 (least privilege) is the control language most SOX and FedRAMP audits refer to when they ask for evidence that access is reviewed and unneeded privilege removed, which is the governance half of this article written as a control.
• ISO/IEC 27001, Annex A, requires a documented access control policy and periodic review of user access rights, the same obligation phrased for a management-system audit.
• The IDPro Body of Knowledge chapters on identity governance and on lifecycle management are the closest thing the profession has to a shared, practitioner-written definition of the split used here.
• ISACA publishes audit and assurance guidance for IAM programs, useful when a business case needs to speak the language an auditor will use.

You don’t need to memorize control numbers to run a program well. Knowing that “review access every quarter” traces back to a specific control, and isn’t just someone’s opinion of good practice, is what turns a governance requirement into something a business owner can’t simply decline.

Back to the two questions

What’s the difference between administering identities and governing them? Administration does the work: creates the account, assigns the entitlement, runs the connector. Governance decides whether the work should happen and checks that it was done right: the policy, the review, the audit trail. Neither one is the real IGA on its own. The discipline is the loop between them.

And what makes an organization fund that loop? Almost always a deadline with a name on it: an audit, an incident, a backlog someone finally counted, a merger with a closing date. At that moment the technology matters much less than having an honest answer to who has access to what, and why. That’s the question every driver in this article comes back to, and the rest of this module is about answering it reliably: where the data comes from, how joiner, mover, and leaver events work, what is actually being granted, and who is accountable for each part.

Recap

• Identity administration carries out changes to access: provisioning, connectors, fulfillment.
• Identity governance decides whether those changes should happen and checks they were right: policy, reviews, separation of duties, audit evidence.
• IGA is the loop between the two, and the boundary between them is usually a boundary between teams.
• IGA is not just reviews, not only for large companies, and not something a tool provides by itself. It covers employees, contractors, partners, and non-human identities, but usually not customers.
• Programs are funded by a concrete event, usually compliance combined with risk, efficiency, or a merger.
• The return shows up in manual ticket volume, audit preparation time, and time to remove a leaver’s access, and it depends on well-designed roles and a recorded baseline. Track governance measures too, such as review coverage and owned entitlements.

Three questions to test yourself

1. A colleague says, “We bought an IGA tool, so governance is covered now.” What’s missing from that sentence, and what would you ask next?
2. Which of the four drivers would you expect to produce the narrowest first phase of a program, and why?
3. In Daniel’s first Tuesday, Sara waited a week for her access. Which single capability would shorten that wait fastest, and which would take longest to pay off?

Hands-on exercise

Pick an organization you know well, your employer, your university, or a club with shared tools.

1. List five systems people use there and, for each, try to answer three questions: who has access today, who approved it, and when it was last reviewed. Note how long each answer took and where you had to look.
2. For each system, decide whether the gaps you found are administration problems (access is slow to grant or remove) or governance problems (nobody decides or checks whether access is right).
3. Count how many of the “signs a spreadsheet is no longer enough” from this article apply.
4. Write two sentences you could use to open a business case: the driver that applies, and the one measure you would record as a baseline this month.