Identity Governance Program Guide: Building an Effective IGA Framework

Identity Governance and Administration (IGA) is the discipline of ensuring the right people have the right access to the right resources at the right time — and proving it. While Identity and Access Management (IAM) handles the mechanics of authentication and authorization, IGA provides the oversight layer: who approved this access, is it still appropriate, does it violate any policies, and can we demonstrate compliance to auditors?

Organizations that lack a formal IGA program accumulate access debt over time. Permissions granted for a project three years ago remain active. Users who changed roles retain entitlements from both positions. Segregation of duties violations go undetected. When auditors arrive, the scramble to produce evidence consumes weeks of effort.

This guide walks you through building an IGA program from the ground up.

Prerequisites

• Executive sponsor — IGA programs require sustained investment and organizational change. Without executive backing, they stall.
• Identity data foundation — You need a reasonably accurate directory of who exists in your organization and what access they have. Perfect data is not required to start, but you need a baseline.
• Application inventory — A catalog of applications, their owners, and the entitlements they provide.
• Regulatory context — Understanding of which regulations apply to your organization (SOX, HIPAA, SOC 2, GDPR, PCI DSS) and their access governance requirements.
• IGA tooling — SailPoint, Saviynt, One Identity, or similar IGA platform. Microsoft Entra ID Governance is an option for Microsoft-centric environments.

Architecture: The IGA Framework

The Four Pillars of Identity Governance

1. Access Lifecycle Management Managing access from request through approval, provisioning, review, and eventual revocation. This encompasses:

• Access request workflows
• Approval chains with business context
• Time-bound access grants
• Automated provisioning and deprovisioning

2. Access Certification (Reviews) Periodic validation that existing access is still appropriate:

• Manager certifications (does this person still need this access?)
• Application owner certifications (should this role exist?)
• Entitlement owner certifications (is this permission still valid?)

3. Segregation of Duties (SoD) Preventing toxic combinations of access that create fraud or compliance risk:

• Define conflicting entitlements
• Detect violations in real time
• Enforce preventive controls
• Manage exceptions with compensating controls

4. Policy and Role Management Defining and maintaining the rules that govern access:

• Role mining and engineering
• Access policies and standards
• Entitlement catalogs
• Governance workflows

The Governance Operating Model

Board / Audit Committee
    ↓ (oversight)
CISO / CIO (Executive Sponsors)
    ↓ (direction)
Identity Governance Committee
    ↓ (policy, standards)
IGA Operations Team
    ↓ (execution)
Business Unit Access Owners ←→ Application Owners
    ↓ (certification, approval)
End Users (request access, participate in reviews)

Step-by-Step Implementation

Step 1: Establish Governance Structure

Form an Identity Governance Committee with representatives from:

• Information Security (chair)
• IT Operations
• Internal Audit
• Compliance / Legal
• HR
• Key business units (Finance, Engineering, Sales)

This committee meets monthly to:

• Review IGA program metrics and health
• Approve new governance policies
• Adjudicate escalated SoD exceptions
• Prioritize application onboarding

Define roles and responsibilities:

| Role | Responsibility | |---|---| | IGA Program Manager | Overall program execution, reporting, stakeholder management | | Access Certification Manager | Certification campaign design, scheduling, completion tracking | | SoD Analyst | Rule definition, violation analysis, exception management | | Application Owner | Certify application access, define entitlements, approve requests | | Business Manager | Certify direct reports' access, approve access requests | | Data Owner | Define data classification, approve access to sensitive data |

Step 2: Build Your Application and Entitlement Inventory

You cannot govern what you cannot see. Build a comprehensive inventory:

Application inventory fields:

• Application name and identifier
• Business owner and technical owner
• Criticality rating (critical, high, medium, low)
• Regulatory scope (SOX, HIPAA, PCI, etc.)
• Number of users and entitlements
• Integration method (SCIM, API, manual)
• Last certification date

Entitlement inventory fields:

• Entitlement name and description
• Application association
• Risk level (high, medium, low)
• SoD relevance (is this entitlement part of any SoD rule?)
• Business meaning (not just the technical name, but what this entitlement allows the user to do)

Prioritization: Start with applications in regulatory scope. SOX-relevant financial systems, HIPAA-covered health systems, and PCI-scoped payment systems should be onboarded first.

Step 3: Design Access Certification Campaigns

Access certifications are the core activity of identity governance. Design them for effectiveness, not just compliance.

Campaign types:

Manager certification — Each manager reviews all access held by their direct reports.

• Frequency: Quarterly for high-risk applications, semi-annually for others.
• Scope: All entitlements across all applications for each direct report.
• Decision: Certify (access is appropriate), Revoke (access should be removed), Delegate (another reviewer should decide).

Application owner certification — Each application owner reviews all users with access to their application.

• Frequency: Semi-annually.
• Scope: All users and their entitlements within the application.
• Best for: Applications with many users where the app owner understands access better than individual managers.

Entitlement certification — Review specific high-risk entitlements across all holders.

• Frequency: Quarterly or as triggered by events.
• Scope: A specific entitlement (e.g., "Domain Admin" or "Financial System Approver") and every user who holds it.
• Best for: Privileged access and SoD-relevant entitlements.

Event-triggered certification — Triggered by lifecycle events rather than schedule.

• Trigger: Role change (mover event), extended leave return, project completion.
• Scope: All access held by the affected user.
• Rationale: Access that was appropriate before the event may no longer be appropriate after.

Step 4: Implement Segregation of Duties

SoD prevents any single person from controlling all aspects of a critical business process. The classic example: the person who creates a purchase order should not also be able to approve it and process the payment.

Defining SoD rules:

Work with business process owners to identify toxic combinations:

Rule: Financial SoD - AP Processing
Conflicting Entitlements:
  Side A: "Create Vendor" OR "Modify Vendor Bank Details"
  Side B: "Approve Payment" OR "Process Payment Run"
Risk Level: Critical
Compensating Control: Monthly reconciliation by Finance Director

Rule: IT SoD - Change Management
Conflicting Entitlements:
  Side A: "Deploy to Production"
  Side B: "Approve Change Request"
Risk Level: High
Compensating Control: Automated deployment audit log review

SoD enforcement levels:

1. Preventive — Block the access request if it would create a violation. This is the strongest control but requires complete SoD rule coverage.
2. Detective — Allow the access but generate an alert. An analyst reviews the violation and either requires remediation or approves an exception with compensating controls.
3. Monitoring — Run periodic SoD scans across all access. Report violations for remediation. This is the starting point for most organizations.

Step 5: Build Access Request Workflows

Replace ad-hoc access requests (email, tickets) with structured governance workflows.

Request workflow design:

1. User initiates request — From a self-service portal or catalog. The catalog shows only entitlements the user is eligible to request.
2. Risk assessment — The system automatically evaluates the request against SoD rules and policy. Flag any violations.
3. Approval routing — Route to the appropriate approver(s) based on the entitlement risk level:
   • Low risk: Manager approval only
   • Medium risk: Manager + application owner approval
   • High risk: Manager + application owner + security team approval
   • SoD violation: All of the above + IGA committee or designated exception approver
4. Time-bound option — Allow requesters to specify an end date. Encourage time-bound access for project-based needs.
5. Provisioning — Upon approval, automatically provision the access through SCIM, API, or ticketed manual provisioning.
6. Confirmation — Notify the requester that access is provisioned and remind them of the expiration date if time-bound.

Step 6: Configure Governance Reporting

Operational dashboards:

• Certification campaign completion rates (target: 95%+ on-time completion)
• Open SoD violations by risk level
• Access request volume and average fulfillment time
• Orphan account count
• Accounts with no manager assigned

Compliance reports:

• Certification history for each user (when was their access last reviewed, by whom, what was the decision?)
• SoD violation inventory with exception approvals and compensating controls
• Access provisioning and deprovisioning audit trail
• Policy violation summary

Executive metrics:

• Overall governance program maturity score
• Percentage of applications under governance
• Trend in excess access (permissions revoked during certifications)
• Audit finding trends related to access governance

Step 7: Launch and Iterate

Phase 1: Foundation (Months 1-3)

• Establish governance committee
• Deploy IGA platform
• Onboard first 5 applications (highest risk/regulatory priority)
• Run first manager certification campaign
• Define first 10 SoD rules

Phase 2: Expansion (Months 4-8)

• Onboard next 15-20 applications
• Implement access request workflows
• Enable preventive SoD controls for critical rules
• Run application owner certifications
• Begin entitlement cleanup based on certification results

Phase 3: Maturity (Months 9-12)

• Onboard remaining in-scope applications
• Implement role mining and engineering
• Automate event-triggered certifications
• Establish governance reporting cadence
• Conduct first program maturity assessment

Best Practices

Make Certifications Meaningful

The biggest failure mode in access certification is rubber-stamping — reviewers approve everything without actually evaluating access. Combat this by:

• Providing business-readable descriptions of each entitlement (not just technical names).
• Showing usage data alongside entitlements (this user has not accessed this application in 180 days).
• Keeping certification scopes manageable (no more than 50 decisions per reviewer per campaign).
• Implementing a "micro-certification" model with smaller, more frequent reviews.
• Tracking and reporting rubber-stamping patterns (reviewers who certify 100% of access in under 2 minutes).

Start with Detective SoD, Not Preventive

Preventive SoD controls (blocking requests that create violations) sound ideal but can paralyze operations if your SoD rules are not perfectly tuned. Start with detective controls — allow access but flag violations for review. Once you have validated your rules over 2-3 cycles and understand your exception patterns, graduate to preventive controls.

Treat Exceptions as First-Class Citizens

SoD exceptions are not failures — they are business decisions to accept risk with compensating controls. Manage exceptions formally:

• Require documented business justification.
• Require a compensating control for every exception.
• Set expiration dates on exceptions (maximum 12 months, then re-approve).
• Track exception trends and address root causes.

Govern Service Accounts Too

Service accounts and technical identities are often excluded from governance programs because they do not have human managers. This is a mistake. Service accounts frequently have the most powerful access. Assign technical owners to every service account and include them in certification campaigns.

Testing

Certification Campaign Testing

Before launching your first production campaign:

1. Run a pilot campaign with a friendly department (IT or Security).
2. Gather feedback on the reviewer experience — is the interface intuitive, are descriptions meaningful, is the scope manageable?
3. Test the revocation workflow — when access is revoked during certification, is it actually deprovisioned?
4. Verify escalation — what happens when a reviewer does not complete their certification by the deadline?

SoD Rule Testing

1. Create test accounts with known access combinations.
2. Verify that SoD rules detect the violations correctly.
3. Test false positive scenarios — access combinations that look like violations but are business-legitimate.
4. Validate that exception workflows function correctly.

Common Pitfalls

Boiling the Ocean

Trying to onboard all applications simultaneously overwhelms the team and produces low-quality governance. Start with 5-10 critical applications and expand methodically.

Ignoring Data Quality

Governance is only as good as the data it operates on. If entitlement names are meaningless technical strings, reviewers cannot make informed decisions. Invest in entitlement cataloging and business-readable descriptions before launching certifications.

Making It a Technology Project

IGA is an organizational change initiative that uses technology, not a technology implementation. If you focus only on deploying the platform without building the governance processes, culture, and accountability, the program will fail.

Not Closing the Loop

Certifications that revoke access on paper but do not actually deprovision the access are worse than no certifications at all — they create a false sense of security. Ensure automated deprovisioning for every revocation decision.

Conclusion

An effective identity governance program is the backbone of access compliance and risk management. It transforms access management from an ad-hoc, trust-based system into a structured, evidence-based discipline. The investment is significant — in technology, process design, and organizational change — but the returns are tangible: clean audit findings, reduced access risk, faster access provisioning, and demonstrable compliance.

Start with the governance committee and a handful of critical applications. Build credibility through successful certification campaigns and visible SoD violation remediation. Expand methodically, measure relentlessly, and treat governance as an ongoing program, not a one-time project.

Frequently Asked Questions

Q: How often should we run access certifications? A: Quarterly for high-risk and regulated applications, semi-annually for standard applications. Event-triggered certifications (role changes, extended leave returns) should supplement scheduled campaigns.

Q: What is a reasonable certification campaign completion rate target? A: Target 95% on-time completion. Below 90% indicates either unrealistic scopes, poor reviewer engagement, or inadequate escalation. Escalate incomplete certifications to the reviewer's manager and ultimately to the governance committee.

Q: How do we handle access that is revoked during certification but the user still needs it? A: The user should re-request the access through the standard request workflow. This ensures the new access grant has a fresh approval, current business justification, and SoD evaluation. This is governance working as designed.

Q: Should we buy an IGA platform or build on our IdP's governance features? A: If your environment is predominantly one vendor ecosystem (e.g., all Microsoft), the IdP's built-in governance features (Entra ID Governance) may be sufficient. For multi-vendor, multi-platform environments with complex SoD requirements, a dedicated IGA platform (SailPoint, Saviynt) provides more comprehensive capabilities.

Q: How many SoD rules should we start with? A: Start with 10-20 rules focused on your highest-risk business processes (financial transactions, IT change management, data access). Quality matters more than quantity. Poorly defined rules generate false positives that erode trust in the program.