Identity governance and administration (IGA) is the set of tools and processes that decides who should have access to which systems and data, grants and removes that access as people join, change roles and leave, and records it all so it can be reviewed and proven to auditors. It combines identity administration, the day-to-day work of creating accounts and assigning permissions, with identity governance, the policies, approvals and reviews that keep access appropriate. IGA is one part of the wider field of identity and access management (IAM).
At a glance
- IGA covers the access lifecycle: provisioning on hire, changes on role moves, and removal on exit.
- It adds governance on top: access requests and approvals, periodic access reviews, and policies such as separation of duties.
- It typically uses the HR system as the source of truth and connects to the identity provider and business applications.
- Its outputs, who approved what and when access was reviewed or removed, are the evidence many audits ask for.
- Coverage depends on connectors: applications that can’t be connected still need manual steps.
What problem it solves
Access tends to grow and rarely shrinks. New hires get set up by copying a colleague’s permissions, people keep old access when they change roles, and leavers’ accounts linger in applications nobody remembered to check. Each extra permission is another way for a mistake, an insider threat or a stolen password to do damage, and contractors, partners and service accounts add to the sprawl.
At the same time, auditors and regulators expect you to show that access to financial, health or payment systems is approved, appropriate and reviewed. Without IGA, that often means weeks of exporting user lists into spreadsheets and chasing managers to sign off.
IGA automates the routine work and makes the governance repeatable. Access follows a defined joiner, mover and leaver process, permissions are tied to roles, and reviews and evidence come out of the system rather than a spreadsheet.
How it works
Source of truth. IGA tools usually take employee data from the HR system. A new record, a job change or a termination triggers the matching access changes.
Provisioning and deprovisioning. Through connectors to the identity provider, directory and applications, often using SCIM or application APIs, the tool creates accounts and assigns permissions based on rules or roles, then removes them when they are no longer needed.
Access requests. Users request extra access through a portal, and the request goes to the right approver, such as a manager or the application owner, with the decision recorded.
Roles and policies. Permissions are grouped into roles, as in role-based access control (RBAC), to support least privilege. Policies flag toxic combinations, such as one person being able to both create and approve payments.
Access reviews. On a schedule, managers or application owners are asked to confirm or revoke each person’s access in a formal access review, sometimes called certification. Revocations can be carried out automatically.
Reporting. The tool records requests, approvals, reviews and changes, and produces reports for auditors and security teams.
When it matters for buyers
- When audits get painful. If access reviews for SOX, HIPAA, PCI DSS or customer security questionnaires are manual and slow, IGA is often the fix.
- When application count grows. More SaaS apps mean more places for access to go stale.
- After a leaver incident. A former employee or contractor still having access is a common trigger.
- During mergers and reorganizations. Large numbers of people change roles or systems at once.
- When choosing a product. Check connector coverage for your actual applications, since that decides how much is automated.
Questions to ask vendors
- Which of our applications do you connect to out of the box, and how are the rest handled?
- How does the tool integrate with our HR system and identity provider?
- How are access reviews run, and what do reviewers actually see?
- Can it detect accounts and permissions that were granted outside the tool?
- How are roles defined and maintained, and do you help with role design?
- What reports and evidence can we hand directly to auditors?
- How is it priced: per employee, per identity including contractors and service accounts, or per connected application?
How it differs from Identity and Access Management (IAM)
IAM is the umbrella for everything about digital identities and access. In everyday use, IAM often refers to the access side: single sign-on (SSO), multi-factor authentication and the policies that decide, at login, whether a user can get in. IGA is the governance side: deciding what access each person should have, keeping it current as they change roles, and reviewing and proving it over time. Put simply, access management checks the badge at the door, and IGA decides who gets a badge and for which doors. Privileged access management (PAM) is a third, narrower discipline for administrator and other high-risk accounts. Our access management page covers how these fit together.