Skip to main content
Digital Compliance Bureau
Commerce Security logo, "All 12 PCI DSS Requirements in Plain English," "Get it now for free," "Complete Survival Guide" and a button toclick to get it
Category: Identity & Access

Identity Governance and Administration

Also known as: IGA, Identity Governance, Identity Governance & Administration
Simply put

Identity Governance and Administration (IGA) is a cybersecurity discipline concerned with managing who has access to what within an organization's digital systems, and ensuring that access is appropriate. It combines the day-to-day administration of user accounts and access rights with oversight of the policies that govern them. In practice, IGA is generally implemented through a mix of policies, processes, and supporting technology rather than a single tool.

Formal definition

IGA is a discipline and set of integrated solutions within an organization's broader Identity and Access Management (IAM) infrastructure that combines identity lifecycle management (including user provisioning and de-provisioning) with access governance. It encompasses the policies, processes, and technologies used to manage account-holder identities and their associated access rights, typically supporting functions such as automated provisioning, access review and certification, and enforcement of access policy. IGA is a component of IAM and should be distinguished from the wider IAM domain and from authentication or access-enforcement mechanisms; the descriptions of specific vendor capabilities and product versions vary and change over time, so implementers should verify current capabilities against authoritative vendor and framework documentation.

Why it matters

Access-related failures sit at the root of many security and compliance problems. When organizations lack disciplined control over who can reach which systems and data, they accumulate excessive, stale, or orphaned access rights that widen the attack surface and complicate accountability. Identity Governance and Administration (IGA) matters because it provides the structured oversight needed to keep access appropriate over time, rather than treating access decisions as one-off grants that are never revisited. This is particularly relevant as the number of identities in an organization grows to include employees, contractors, service accounts, and machine identities.

IGA also supports the demonstrability that regulatory and contractual regimes generally expect. Many data protection and security obligations require organizations to limit access to personal or sensitive data on a need-to-know basis and to be able to show that such controls exist and operate. Voluntary frameworks and certification schemes commonly used in security programs likewise expect evidence of access review and least-privilege practices. IGA capabilities such as access certification and provisioning records are frequently used to produce that evidence, though the specific obligations and their scope differ across jurisdictions, sectors, and the particular framework or law in question.

It is important to understand what IGA does not, by itself, guarantee. Implementing IGA tooling does not equate to compliance with any particular regulation, nor does it substitute for authentication or access-enforcement mechanisms that operate at the point of access. IGA is a governance and administration discipline; its effectiveness depends on the quality of the underlying policies, processes, and data, and on how it is integrated with the wider Identity and Access Management (IAM) environment. Readers should assess how any given IGA capability maps to their own regulatory and contractual requirements.

Who it's relevant to

Information security teams
Security functions use IGA to reduce the accumulation of excessive or stale access rights and to maintain least-privilege practices across a growing population of human and non-human identities. IGA complements, but does not replace, authentication and access-enforcement controls, so security teams generally treat it as one layer within a broader IAM architecture.
Identity and access management practitioners
For IAM practitioners, IGA provides the provisioning, de-provisioning, and access governance functions that keep identity data and entitlements aligned with organizational reality. Because capabilities vary across vendors and product versions, practitioners should validate specific features against current vendor and framework documentation.
Compliance officers and auditors
IGA capabilities such as access certification and provisioning records are often used to demonstrate that access to sensitive or regulated data is controlled and reviewed. The relevance of these outputs depends on the particular regulation, framework, or contractual requirement at issue, which differ by jurisdiction and sector; deploying IGA tooling does not by itself establish compliance.
IT administrators and operations
Teams responsible for managing user accounts rely on IGA processes to handle joiners, movers, and leavers consistently and to automate routine provisioning tasks. The effectiveness of these processes depends on the quality of underlying policies and data, not on the tooling alone.

Inside IGA

Identity Lifecycle Management
The processes for creating, modifying, and deprovisioning digital identities as individuals join, move within, or leave an organization. This includes onboarding, role changes, and offboarding, and is a core function distinguishing IGA from point-in-time access controls.
Access Provisioning and Deprovisioning
The granting and revocation of access rights to systems, applications, and data. IGA typically automates or coordinates these actions to align entitlements with an individual's current role and to remove access that is no longer needed.
Access Certification and Review
Periodic reviews in which managers or resource owners attest that granted access remains appropriate. These recertification campaigns support internal control objectives and are often referenced in the context of audits and assessments, though the specific cadence generally depends on organizational risk and policy.
Role and Entitlement Management
The definition and maintenance of roles, groups, and entitlements that map access rights to job functions. Role-based approaches aim to simplify administration and reduce excessive privilege accumulation, sometimes described as 'access creep.'
Segregation of Duties (SoD) Controls
Policy rules designed to prevent a single individual from holding conflicting combinations of access that could enable fraud or error. IGA platforms may detect and flag such conflicts, though the definition of what constitutes a conflict is organization- and context-specific.
Policy Enforcement and Governance
The rules, workflows, and approval chains that govern how access is requested, approved, and monitored. This governance layer is what differentiates IGA from purely operational identity administration.
Auditing, Logging, and Reporting
The recording of identity and access events and the generation of reports used to demonstrate control effectiveness. These capabilities may support compliance efforts and audit or assessment activities but do not themselves constitute certification or compliance.

Common questions

Answers to the questions practitioners most commonly ask about IGA.

Is Identity Governance and Administration (IGA) the same as Identity and Access Management (IAM)?
No. The two are related but distinct. IAM is the broader discipline concerned with authenticating users and enforcing access to systems in real time, encompassing capabilities such as authentication, single sign-on, and access enforcement. IGA is generally understood as a subset or complementary layer focused on the governance and administrative side: defining, provisioning, reviewing, certifying, and de-provisioning identities and their entitlements, and maintaining an auditable record of who has access to what and why. In practice, IGA answers policy and oversight questions (should this person have this access?), while the enforcement components of IAM answer runtime access questions (can this person get in right now?). Product boundaries vary by vendor, so readers should verify how a given tool scopes these functions.
Does implementing IGA make an organization compliant with regulations such as the GDPR or HIPAA?
Not on its own. IGA is a set of practices and tooling, not a regulation or a certification, and deploying it does not by itself establish compliance with any legal regime. Data protection and security regulations across jurisdictions, such as the GDPR in the EU or HIPAA in the United States healthcare sector, generally impose obligations around access control, accountability, and least privilege, and a well-run IGA program can support demonstrating those controls. However, compliance is fact-specific and depends on the full scope of an organization's obligations, risk profile, and other safeguards. IGA should be treated as one contributing control among many, not as evidence of compliance in itself. Application to a particular regulatory situation requires professional judgment and verification against the current official text of the applicable law.
How does an IGA program typically approach access reviews and certification?
Access reviews (often called access certification campaigns) are a core IGA function in which designated reviewers, commonly managers, application owners, or data owners, periodically confirm whether existing access remains appropriate. Programs generally define a review cadence, scope entitlements to be examined, and record approve or revoke decisions to create an audit trail. Note that 'certification' here refers to attesting that access is appropriate; it is an internal governance activity and is distinct from third-party certification against a standard. The design of review frequency and depth is typically risk-based, with higher-privilege or sensitive-data access reviewed more rigorously. Specific cadences and thresholds depend on organizational policy and any applicable requirements.
What role does role-based access control (RBAC) play in an IGA implementation?
RBAC is a common model used within IGA to group entitlements into roles that reflect job functions, so access can be granted, reviewed, and revoked at the role level rather than entitlement by entitlement. This can simplify administration and support the principle of least privilege. In practice, defining and maintaining a stable role model (often called role engineering) is a significant undertaking, and many organizations combine RBAC with attribute-based or policy-based approaches, or supplement it with exception handling for access that does not fit cleanly into roles. Role definitions require ongoing maintenance as the organization changes, and poorly maintained roles can accumulate excess entitlements over time.
How is joiner-mover-leaver (JML) lifecycle management usually handled in IGA?
IGA programs commonly automate identity lifecycle events, when a person joins, changes role, or leaves the organization, by connecting to authoritative sources such as an HR system. When a joiner event occurs, baseline access may be provisioned automatically; a mover event may trigger recalculation of entitlements; and a leaver event should prompt timely de-provisioning to reduce the risk of orphaned or lingering access. The degree of automation varies by organization and by the systems being managed, and manual steps or approvals are often retained for higher-risk access. Prompt de-provisioning on departure is generally treated as a priority because residual access is a recognized security and audit concern.
How can Segregation of Duties (SoD) controls be addressed through IGA?
SoD controls aim to prevent a single individual from holding combinations of access that could enable fraud, error, or conflicts of interest, for example, both creating and approving a payment. IGA tools often support defining SoD policies as rules that flag or block conflicting entitlement combinations during access requests and during periodic reviews. Implementation typically involves cataloguing toxic combinations relevant to the organization, deciding whether conflicts are prevented outright or handled through documented compensating controls and mitigations, and reporting on violations. The specific SoD rule sets depend on the organization's processes and any sector expectations, and rule definitions require review as systems and business processes evolve.

Common misconceptions

IGA is the same as Identity and Access Management (IAM), or the two terms are interchangeable.
IGA is generally understood as the governance-focused layer concerned with policy, lifecycle, certification, and controls, whereas IAM is a broader category that also encompasses operational functions such as authentication and access enforcement. IGA emphasizes who should have access and why, rather than only the mechanics of granting it.
Deploying an IGA platform makes an organization compliant with regulations such as the GDPR or HIPAA.
IGA is a set of tools and processes that may support compliance objectives, but it is not equivalent to compliance and confers no certification by itself. Regulatory obligations are fact-specific and depend on jurisdiction, data category, and organizational context; IGA can help evidence certain controls but does not satisfy legal requirements on its own. Readers should verify obligations against the current official text of any applicable law.
IGA is a one-time implementation project that is complete once configured.
IGA is generally an ongoing operational discipline. Identities, roles, and access needs change continuously, and controls such as access certification and lifecycle management require recurring execution. Treating it as a static deployment tends to result in stale entitlements and control drift over time.

Best practices

Automate identity lifecycle events, joiner, mover, and leaver processes, so that provisioning and deprovisioning stay aligned with an individual's current role and access is removed promptly when no longer needed.
Adopt role- and entitlement-based access models to reduce excessive privilege accumulation, and review role definitions periodically as job functions evolve.
Conduct recurring access certification campaigns in which resource owners or managers attest to the continued appropriateness of granted access, setting the cadence according to your organization's risk profile and policy.
Define and enforce segregation-of-duties rules appropriate to your context to detect and prevent conflicting access combinations, recognizing that what constitutes a conflict is organization-specific.
Maintain comprehensive audit logs and reporting on identity and access events to help evidence control effectiveness during audits or assessments, while remembering these outputs do not themselves establish compliance or certification.
Treat IGA as an ongoing program rather than a one-time project, and validate that your controls map to the specific regulatory or contractual obligations that apply to your jurisdiction and sector, verifying against current authoritative sources.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps