Identity Governance and Administration - A Visibility-First Guide

Most IGA content tells you what identity governance is. They list the components—access reviews, provisioning, policies, compliance reporting. They explain the benefits—security, compliance, efficiency. They're not wrong.

They're just answering the wrong question.

The question isn't "what is IGA?" The question is: Why do most companies implement IGA and still can't answer basic questions about who has access to what?

The answer: They skipped the foundation. They implemented governance before establishing visibility.

The Question That Exposes the Gap

Who has access to your customer database?

At 200 employees, you could answer in five minutes. Pull the IdP report, scan the list, done.

At 500 employees, still manageable. Your IdP shows 89 users with access. Report delivered.

At 1,200 employees, the question becomes impossible. Your IdP shows 89. Application logs show 203. Nobody can explain the other 114.

Which of those 203 should have access?

Your last access review certified all 89 accounts in your IdP. Audit-ready, compliance documented.

Your auditor asks for evidence covering all users accessing customer data. You show reviews for 89. They show network evidence of 203.

Material weakness finding. Your reviews covered 44% of actual access.

Who is Sarah Johnson?

According to your systems:

sarah.johnson@company.com (Google Workspace)
sjohnson@company.com (Okta)
sarah.johnson (Salesforce)
s.johnson (HubSpot - pre-standardization)

Also:

sarah_username (Slack - self-selected)
sarah.johnson.contractor@company.com (never deactivated)
sjohnson2 (Jira - username collision)

Seven identities. One person. When Sarah got promoted to VP Revenue Operations, two identities got updated—the ones in your IdP. The other five still reflect her old role.

Did we fully offboard Marcus?

Six months ago, your workflow executed:

Okta disabled ✓
Google Workspace suspended ✓
156 integrated apps revoked ✓

Last week: Marcus accessed production at 2 AM. He still had credentials in 11 unfederated applications.

What applications contain customer data?

Your data governance team: "Five applications."

Your compliance team reviews those five. Complete coverage.

Your auditor runs network analysis: Customer data flows to 12 applications. You reviewed 5.

Because your IdP shows 30-40% of applications. You reviewed 100% of what you could see.

When does this become unfixable?

Below 500 employees: Gaps are manageable. Handle manually, fix reactively.

At 500-1,000 employees: Systematic failures. Can't answer basic questions. Material weaknesses. Six-figure compliance costs.

At 1,000+ employees: 500+ apps (IT knows 40%). One person = 10+ identities. Hundreds of ghost accounts. $500K-$2M remediation per finding.

What broke?

Not identity management—it works as designed for authentication and basic access management in federated environments.

What broke: the assumption your IdP sees everything.

It sees 30-40%. The other 60-70% operates in darkness.

You don't need better identity management. You need identity governance—discovering the 60-70% your IdP doesn't see, mapping identities your workflows can't touch, governing access your reviews don't cover.

You can't manage what you can't see.

What You'll Learn in This Guide

What Is Identity Governance and Administration?

The Simple Definition

The end goal of IGA is to ensure the right users have the right level of access to the right tools at the right time.

Identity Governance and Administration (IGA) is the system that makes this happen—and proves it to auditors, regulators, and stakeholders.

Breaking it down:

Right users: Current employees, contractors, partners—not former employees who left three months ago
Right level of access: Permissions appropriate for their role and responsibilities—not admin access when they need read-only, not edit when they need view-only
Right tools: Applications, systems, data they need to do their job—not everything they've ever touched or requested
Right time: From onboarding through role changes to offboarding—continuous governance, not annual checkboxes
Prove it: Audit trails, compliance reports, evidence for regulators—documentation that actually reflects reality

The Two Halves of IGA

IGA has two components that must work together. Most companies are decent at one, catastrophically weak at the other.

Identity Governance (The "What Should Be"):

Defining who should have access to what (policies, roles, rules)
Reviewing and certifying access periodically (access reviews)
Ensuring segregation of duties (no conflicting permissions that enable fraud)
Reporting and auditing (proving compliance to regulators)
Risk analysis and anomaly detection (catching unusual access patterns)

Identity Administration (The "Making It Happen"):

Creating and managing user accounts (provisioning)
Granting and modifying access (entitlements)
Revoking access when people leave or change roles (deprovisioning)
Password and credential management
Automating identity lifecycle processes

Most organizations use their IAM/SSO tools for administration—creating accounts, basic provisioning, SSO groups for simple RBAC. But this only works for 20-40% of known applications due to SSO tax (the cost and effort to federate each app).

The reality is worse: 60-70% of applications are shadow apps that IT doesn't even know about.

With AI tools, that shadow percentage jumps to 80%—teams adopt AI apps without IT involvement, creating massive blind spots.

Even for those federated apps that IAM sees, it's just basic account creation and deletion. You get SSO groups for rudimentary role-based access, but no granular entitlement control, no attribute-based or policy-based access (ABAC/PBAC).

Crucially, access reviews aren't connected to access management. Your IAM tool can create accounts. It can't tell you if those accounts should still exist or if the permissions are still appropriate.

That's governance, and it's where companies are catastrophically weak. Access accumulates like technical debt. Someone gets promoted, they keep their old access plus new access. Someone switches teams, they keep everything from both.

After two years, that person has access to systems they haven't touched in 18 months, permissions they don't remember requesting, and admin rights they definitely shouldn't have.

The Foundation: Access Visibility

The end goal of IGA is ensuring the right users have the right level of access to the right tools at the right time. Everything else—compliance, security, efficiency—flows from this.

But here's the critical truth: This starts with access visibility. Who has access to what. Unless you know this, you can't do anything else properly:

Can't review access if you don't know what access exists
Can't enforce least privilege if you don't know what permissions people hold
Can't offboard completely if you don't know what applications to revoke
Can't prove compliance if you can't show who accesses what data

Access visibility is the foundation. Not authentication. Not provisioning. Not policies. Visibility. Most companies skip this step and jump straight to governance. They implement access reviews for applications they know about. They create policies for resources they can see. They automate provisioning to federated apps.

Then they discover—usually during an audit or breach investigation—that they've been governing 30-40% of their actual application landscape while the other 60-70% operated in complete darkness.

What IGA Is NOT (And Why Your IdP Isn't Enough)

Most companies already have an identity provider. Google Workspace, Microsoft Entra ID (formerly Azure AD), Okta—these tools are excellent at what they do. Authentication works great. Administration and governance? Not so much.

Your IdP/SSO Works Great For:

Single sign-on (one password, multiple apps)
Multi-factor authentication
Basic user provisioning to connected apps
Directory services (user database)
Authentication policies (who can log in, from where, with what requirements)

Your IdP/SSO Doesn't Handle:

Discovering applications IT doesn't know about (shadow IT, team-managed tools)
Governing access to unfederated applications (apps not connected to your IdP)
Systematic access reviews across all applications
Entitlement-level control (admin vs read-only within applications)
Cross-functional workflows (HR triggers, manager approvals, compliance documentation)
Proving governance to auditors (evidence that reviews actually happened)

The Gap Grows as You Grow:

When you're 200 people with 30 applications, your IdP plus manual processes works fine. When you're 800 people with 400 applications, that same approach is drowning your IT team. The IdP didn't get worse—the scale just exceeded what it was designed to handle.

IGA ≠ Identity and Access Management (IAM)

Your IAM/IdP handles authentication (proving who you are) and basic access. IGA governs what access people have and whether it's still appropriate. Think of it this way: IAM gets you in the door. IGA decides which doors you should have keys to, whether you still need those keys, and whether anyone's using keys they shouldn't have.

IGA ≠ Single Sign-On (SSO)

You already have SSO. It makes logging into apps easier—one password, multiple apps. IGA manages whether you should have access to those apps at all. SSO without IGA is just convenient access to applications you might not need anymore. You've made unauthorized access easier to accomplish and harder to detect.

IGA ≠ Privileged Access Management (PAM)

PAM specifically manages high-risk privileged accounts (admin access, root, superuser). IGA manages all user access across the organization. Some platforms converge these functions, but they're fundamentally different problems. PAM is trauma surgery—focused, intense, high-stakes. IGA is preventive medicine—continuous, comprehensive, foundational.

Why IGA Matters Now More Than Ever

The Old Reality (Pre-2015):

50-100 applications, mostly on-premises
IT controlled all procurement
Limited user base, stable roles
Annual access reviews were actually sufficient
Network perimeter provided security

The New Reality (2025):

500+ applications in mid-market companies
Teams buy SaaS tools directly with credit cards (hello, shadow IT)
Remote work, contractors, distributed teams across geographies
Access changes constantly—roles evolve, teams shift, projects launch and sunset
No network perimeter—identity IS the perimeter

Most IGA tools were built for the old reality. They assume complete visibility exists, that applications are federated through your identity provider, that IT controls all procurement. Those assumptions are lethally wrong.

Your IGA tool can govern only what it can see—which is typically the minority of your actual application landscape. The rest is shadow IT that can't be governed.

When Does Your Company Actually Need IGA?

This is the question every IT manager and IT director asks. The uncomfortable answer: earlier than you think. Here's what actually happens at different company sizes.

Up to 200 Employees: Manual Works (But Start Thinking Ahead)

What This Looks Like:

50-100 applications in use
IT knows most of them (maybe 70%)
Manual onboarding takes a few hours per new hire
Offboarding is a checklist you maintain
Access reviews happen in spreadsheets twice a year
You know everyone, remember who has access to what

Manual processes work. Your IT team isn't drowning. But pay attention to these warning signs:

New hires waiting 2-3 days for all their access
Offboarding checklist keeps growing (and you worry about what's missing)
Access review spreadsheets getting unwieldy
First audit findings about incomplete documentation
First shadow IT discovery that surprises you

What You Should Do:

Don't implement full IGA yet. But start preparing:

Document your current provisioning process (what access does each role get?)
Build a complete application inventory (what apps exist, who owns them, who has access)
Map your stakeholders (who needs to approve what? HR for onboarding triggers, managers for access decisions, compliance for documentation)
Set up your IdP properly (federate what you can, document what you can't)

200-500 Employees: Pain Starts, Better Be Proactive

What This Looks Like:

300-400 applications in use
IT knows about maybe 30-40% of them (rest is shadow IT)
Manual onboarding takes 6-8 hours per new hire, sometimes spans 3-4 days
Offboarding checklist has 40+ items (and you still miss applications)
Access reviews take 2-3 months and everyone hates them
First security incident involving lingering access from former employee
First material weakness finding in audit related to access governance

Manual processes still technically work, but you're feeling real pain. Your team spends 30-40% of their time on access-related work. Help desk tickets are overwhelmingly "I need access to X" or "I can't access Y." Access reviews are dreaded quarterly exercises that produce spreadsheets nobody wants to review.

What You Should Do:

Start implementing IGA now. Be proactive, not reactive. Pick one component to start with:

Option 1: Automated User Provisioning/Deprovisioning

Best if your main pain is onboarding/offboarding. Connect your HRMS (Workday, BambooHR, whatever you use) to automatically provision access based on role. Most importantly, automatically revoke ALL access when someone leaves.

Quick win: New hire has access day one. Departed employees have zero access within minutes of termination.

Option 2: Access Reviews

Best if compliance is driving pressure or you've had security incidents. Implement systematic access certification for critical applications first (financial systems, customer data, production access).

Quick win: Auditors get documentation they want. You discover and revoke unnecessary access.

Don't Try To Do Everything At Once:

This is critical. Implement in phases. Start with the most painful area or highest risk systems. Get that working. Let people adapt. Then expand.

500-1000 Employees: No Longer Optional

What This Looks Like:

500+ applications in use
IT knows about maybe 30-40% of them (60-70% shadow IT, even higher for AI tools)
Manual onboarding impossible—new hires wait a week for access, productivity lost
Offboarding is terrifying—you know you're missing applications but don't know which ones
Access reviews haven't happened in 6+ months because last one took 4 months and produced unusable results
Regular security incidents involving over-provisioned access
Audit findings blocking business (can't close enterprise deals, compliance gaps preventing expansion)
License waste approaching $1K per employee annually

Manual processes have completely broken down. Your (IT) team is drowning. You're hiring more people to do access management and they're drowning too. The security team is escalating concerns about unmanaged access. The compliance/GRC team can't produce evidence auditors need. The CFO is asking why SaaS spend is out of control.

What You Should Do:

Implement IGA immediately. This is no longer optional. You're past the point where you can delay. But even now, don't try to boil the ocean:

Phase 1 (First 30 days):

Complete discovery (find all applications, map all access)
Automate offboarding (highest security risk)
Implement access requests with approval workflows (reduce IT ticket burden)

Phase 2 (Next 60 days):

Automate onboarding for top 20 applications or birthright apps
Run access reviews for critical systems
Implement basic policies (least privilege, segregation of duties for financial systems)

Phase 3 (Next 90 days):

Expand to all applications
Continuous access monitoring
Full compliance reporting

Follow the detailed implementation strategy: A Strategy to Implement IGA in Your Organization.

The Mistake Companies Make (And How to Avoid It)

Here's what happens at most companies between 500-1000 employees:

The Pattern:

Problems become unmanageable (security incidents, material weaknesses in audits, operational chaos)
Leadership says "fix this immediately"
IT teams try to implement complete IGA in one shot
Wants everything—full discovery, automated provisioning for all apps, comprehensive access reviews, complete policy enforcement, perfect compliance reporting
Aggressive timeline: 3 months to "be fully governed"
Reality: Fails miserably

Why Big-Bang IGA Implementations Fail:

Reason 1: IGA Isn't Just Technology

You're not just deploying software. You're changing how your entire organization handles access. That requires:

Process changes: How people request access, how managers approve, how IT provisions
Behavioral changes: Self-service instead of IT tickets, regular reviews instead of set-it-and-forget-it
Cultural changes: Least privilege instead of "give everyone admin because it's easier"

These changes take time to mature. People need to learn new systems, adapt to new workflows, get used to new responsibilities.

Reason 2: IGA Has Stakeholders Across the Company

This isn't just an IT project. You need:

HR: Onboarding/offboarding automation requires HRMS integration, process alignment on what triggers provisioning
Managers: They're reviewing access, approving requests—if they don't understand why or how, they'll approve everything to clear their inbox
Security team: Setting policies, monitoring violations, investigating anomalies
Compliance/GRC team: Defining requirements, reviewing evidence, working with auditors
Application owners: Each app needs an owner who understands appropriate access, reviews certifications
End users: They're requesting access through new workflows, using self-service portals

Get all these stakeholders aligned, trained, and comfortable with new processes before expanding scope.

Reason 3: You Need Time to Learn What Works

Your first access review will reveal problems you didn't know existed. Your first automated provisioning will have edge cases you didn't anticipate. Your first policies will need refinement based on real-world business needs.

Give yourself time to:

Run a review cycle, learn what works, refine the process
Automate onboarding for 10 apps, handle the exceptions, then expand to 50
Implement basic policies, see where they break real business needs, adjust

The Right Approach (From an IT Manager's Perspective):

Start with One Component:

Pick the area causing the most pain or the highest risk:

Security incidents from lingering access? Start with automated offboarding
Audit pressure? Start with access reviews for critical systems
IT team drowning in access requests? Start with self-service and automated provisioning

Get That Working:

Implement thoroughly for a subset of applications. Let people learn the system. Refine workflows based on actual usage. Document what works.

Then Expand:

Add more applications to existing component. Then add another component. Build gradually. Give processes time to mature.

Timeline Reality:

Phase 1 (one component, critical apps): 4-8 weeks
Phase 2 (expand coverage): 8-12 weeks
Phase 3 (add components): 12-16 weeks
Full maturity: 6-12 months

Critical Understanding: That 6-12 months is process maturity time, not tool implementation time. Modern tools like Zluri can be implemented in 1-2 weeks—technical setup is fast. Traditional IGA tools take 6-12 months just for implementation before you even start using them. The difference is massive.

The 6-12 months for process maturity is time for:

People learning new workflows and getting comfortable
Stakeholders understanding their roles in governance
Policies being refined based on real-world usage

Also:

Organization adapting to new ways of working
Building trust through visible wins at each stage

But the Payoff is High:

Companies that implement in phases:

Actually complete implementation (not abandon it halfway through)
Get stakeholder buy-in (people see value, not just new work)
Achieve sustainable governance (not just checking compliance boxes)
Reduce risk systematically (not creating new problems while solving old ones)

Companies that try big-bang implementation:

Overwhelm their teams
Create resistance from stakeholders
Fail to complete the project
End up with expensive shelfware

For detailed phased implementation strategy: A Strategy to Implement IGA in Your Organization

The Core Components of Identity Governance

Access Visibility (The Foundation)

What It Is:

Understanding who has access to what resources, what permissions they hold, and how they're actually using that access.

Why It Matters:

You can't govern what you can't see. Without complete visibility, governance becomes an illusion—you're certifying access to known apps while ignoring unknown ones. It's like doing a security audit of your front door while the back door is wide open and you don't know the back door exists.

The Challenge:

Traditional IGA only sees 30-40% of actual applications—the known, federated apps. Here's why:

They only see federated apps (applications connected to your SSO/IdP)
60-70% of applications are shadow IT that IT doesn't even know exists (roughly 2/3rd of your app landscape)
For AI tools specifically, 80% are shadow apps—teams adopt without IT involvement
Team-managed tools are invisible to IT (Airtable, Notion, Figma teams—purchased with credit cards, used daily, completely ungoverned)
Non-federated apps don't connect to SSO, so traditional IGA can't see them

What Complete Visibility Requires:

Multiple discovery methods, not just connectors (browser extensions, expense report analysis, network traffic, OAuth grants)
Automated shadow IT detection that runs continuously, not quarterly surveys that people ignore
Real-time usage tracking—not just "has access" but "actually uses it"
Entitlement-level visibility—not just "has access to Salesforce" but "has admin rights in Salesforce"

Access Policies (The Rules)

What They Are:

Rules and guidelines that define who should have access to what, under what conditions, and for how long.

Types of Policies:

Access Control Policies:

Who can request access (everyone? only certain departments?)
Who must approve requests (manager? app owner? both?)
What access is automatically granted based on role, department, location
When access expires (temporary contractors vs permanent employees)

Role-Based Access Control (RBAC) Policies:

Define roles (Marketing Manager, Sales Rep, Finance Analyst)
Map applications and permissions to each role
Automatically provision/deprovision based on role assignment
Handle role changes (promotion, transfer, departure)

Segregation of Duties (SoD) Policies:

Identify conflicting permissions (can't both create AND approve purchase orders)
Prevent fraud and errors through access design
Alert when violations occur
Document why violations exist if they're unavoidable

Compliance Policies:

Industry-specific requirements (HIPAA for healthcare, PCI DSS for payments, SOX for public companies)
Geographic requirements (GDPR for EU data, data localization rules)
Company-specific controls based on risk tolerance

The Challenge:

Policies only work if they're based on complete data. Incomplete visibility means incomplete governance—you're writing rules for applications you can see while shadow IT operates ungoverned.

Access Certification (The Verification)

What It Is:

Periodic reviews where managers or app owners verify that users still need their current access. Think of it as an audit, but one you do to yourself before the actual auditors show up.

Why It Matters:

Access accumulates over time like dust (people change roles, get promoted, join new projects)
Former employees sometimes retain access because offboarding missed applications
Over-provisioned permissions create security risks (more access = larger attack surface)
Auditors require evidence of regular reviews—"we do them annually" isn't evidence, documented results are

How It Works:

Traditional Approach:

Export user access data to spreadsheets (manual, painful)
Email spreadsheets to reviewers (who are busy and don't want more work)
Wait weeks for responses, send reminders, escalate
Manually process changes in each application
Document results for eventual audit

Problems: Takes 3-4 months, error-prone, incomplete data, reviewers approve everything just to clear their inbox.

Modern Approach:

Automated review campaigns with all access data in one platform
AI highlights anomalies (unusual access, dormant accounts, suspicious patterns)
Reviewers approve/deny in platform with full context about usage, risk, compliance
Closed-loop remediation—changes happen automatically based on decisions
Real-time compliance reporting—always audit-ready

The Challenge:

Reviews that only cover known, federated applications certify incomplete access. Auditors increasingly ask about applications that don't appear in reviews. When most of your application landscape isn't being governed, you won't have a good answer.

Role-Based Access Management

What It Is:

Organizing access around job roles rather than individual permissions. Instead of granting 50 individual permissions, you assign a role and the permissions come with it.

Why It Matters:

Simplifies access management (new Marketing Manager gets Marketing Manager role, automatically gets appropriate access)
Ensures consistency (all Marketing Managers get the same baseline access)
Scales better (new hire? assign role, done. No 47-step checklist)

The Challenge:

Role Engineering Is Hard:

Requires deep understanding of what each role actually needs (not what they say they need)
Roles must be maintained as business changes (reorganizations, new tools, process changes)
Too many roles = complexity that nobody maintains, too few roles = over-provisioning

Role-based access is theoretically beautiful and practically difficult. Companies start with 10 carefully designed roles and end up with 300 highly specific roles that nobody understands. Or they go the other direction—20 roles that grant way too much access because they need to cover too many edge cases.

The alternative is to implement context-based access control. Grant based on department, location, manager, seniority level, project membership—dynamic attributes that update automatically. More flexible, easier to maintain, less rigid than traditional roles. You're not maintaining role definitions, you're maintaining rules that adapt to current organizational reality.

Audit Reporting (The Evidence)

What It Is:

Documented evidence of access governance activities for compliance and audits. Not what you say you do—what you can prove you did.

What Auditors Want to See:

Complete inventory of users and their access (who has what, in which applications)
Evidence of regular access reviews (not "we do quarterly reviews" but "here are the last four quarterly reviews with decisions and remediations")
Logs of access changes (who granted or revoked what access, when, based on what approval)
Policy enforcement records (SoD violations detected and resolved, or documented exceptions with business justification)
Incident response (how unauthorized access was detected and handled)

The Challenge:

Reports are only valuable if they're complete and accurate. Partial visibility produces partial reports, which lead to audit findings. Incomplete discovery creates compliance blind spots.

The Core Components of Identity Administration

Account Administration (The Basics)

What It Is:

Creating, modifying, and deleting user accounts across applications throughout the employee lifecycle.

The Lifecycle:

Create: New employee starts, accounts created in all required applications
Modify: Employee changes roles, access adjusted accordingly
Suspend: Employee on leave, temporary access suspension without deletion
Delete: Employee leaves, all access immediately revoked everywhere

The Manual Reality (Most Companies Today):

IT creates accounts one by one for each new hire
Email requests flood in for each access need
Spreadsheets track who has what (until they don't)
Offboarding often misses applications, especially team-managed tools
Former employees retain access for days or weeks
Nobody's quite sure what access anyone has

The Automated Reality (What's Possible):

HRMS triggers account creation/deletion automatically (employee marked active in Workday = accounts provisioned)
Role-based provisioning grants appropriate access on day one
Offboarding workflows revoke ALL access immediately, including apps IT didn't know about
No manual tracking, no missed applications, no lingering access

User Provisioning

What It Is:

Automatically granting appropriate access based on user attributes like role, department, location, manager.

The Workflow:

Onboarding:

New hire added to HRMS (Workday, BambooHR, whatever you use)
IGA system detects new user via API integration
Determines required access based on role, department, location, team
Automatically provisions accounts and permissions across all applications
Sends welcome information, credentials, access instructions

Mid-Lifecycle (Role Change):

HRMS updated with new role, new department, new manager
IGA detects change through continuous synchronization
Revokes old access, grants new access based on updated attributes
Maintains audit trail of all changes with approvals and justifications

Offboarding:

Employee marked as terminated in HRMS
IGA immediately revokes ALL access across all applications
Transfers data ownership to manager (documents, emails, projects)
Documents complete offboarding for compliance and audit

The Key Requirement:

Must include ALL applications—not just federated apps that appear in your IdP. Offboarding that only revokes known access while leaving unknown access intact isn't security. It's a compliance and security risk with better documentation.

Managing Entitlements (Permissions Within Apps)

What It Is:

Controlling not just whether users can access an application, but what they can do within it.

The Distinction:

Access: Can you log into Salesforce? (Yes/No)
Entitlement: Can you view all accounts or just your territory? Can you approve discounts over $10K? Can you delete records? Can you export customer data?

Why It Matters:

Two users with "Salesforce access" might have completely different permissions. One has read-only access to their own accounts. The other has admin access to everything.

Application-level governance without entitlement-level control creates massive over-provisioning. Users get admin access when they need read-only. They get edit permissions when they need a view. They get access to everything when they need access to one module.

The Challenge:

Many IGA tools (that use SCIM connectors) manage app-level access but not entitlements. They can tell you who has access to Salesforce. They can't tell you what those people can actually do in Salesforce. This gap is where over-provisioning lives.

What Good Entitlement Management Looks Like:

Granular control (viewer vs editor vs admin)
In-app actions (add to Slack channels, set Jira project permissions, grant Google Drive folder access)
Automated adjustment based on context (role changes update entitlements automatically)
Visibility into actual permissions held (not just "has access" but "can delete production data")

Why Identity Governance Has Become Critical

The Security Perimeter Has Dissolved

The Old Perimeter: Remember the castle-and-moat model? Firewall protects internal network, users inside the network, applications on-premises in the data center. Small, defined perimeter to defend. Everything inside is trusted, everything outside is not.

That world is gone.

The New Reality: No perimeter. SaaS applications live in the cloud across multiple providers. Users work remotely from homes, cafes, airports. Contractors access systems from other countries. Partners integrate directly into your workflows. 500+ applications, each with its own security model, each accessible from anywhere.

For IGA, this means when identity is the perimeter, governance becomes critical. You're not protecting a network anymore—you're protecting access to distributed resources. The question isn't "are they inside the firewall" but "should this identity have access to this resource right now."

Every access decision becomes a security decision. Every permission grant creates risk. Every forgotten access becomes a vulnerability. Governance isn't a compliance checkbox—it's the foundation of your security model.

The Access Gap Problem

What It Is:

The difference between the access IT knows about (and can govern) and the actual access that exists across all applications.

How It Happens:

Visible/Known Apps (~30-40% of total):

Purchased through IT or at least known to IT
Integrated with SSO, connected to identity provider
IT has visibility (though maybe not full control)
Traditional IGA systems can see and govern these federated apps

Shadow IT (~60-70% of total, roughly 2/3rd):

Apps IT doesn't know exist
Bought by teams with credit cards, expensed as "software" or "subscriptions"
No SSO integration, completely outside IT purview
Traditional IGA systems can't see them at all
For AI tools specifically, 80% are shadow apps adopted without IT involvement

The Statistics:

Average mid-market company: 500+ SaaS applications in use
IT knows about and can see: ~150-200 (30-40%)
Shadow IT that IT doesn't know exists: ~300-350 (60-70%)
The gap: 60-70% of applications completely ungoverned

Why This Matters:

You're certifying 100% of visible access while actual coverage is 30-40%. That 60-70% gap (the shadow IT) is where:

Breaches happen (former employees with lingering access)
Over-provisioning creates risk (teams giving admin access because it's easier)
Compliance violations hide (regulated data accessed through ungoverned apps)
Shadow IT grows (no oversight, no controls, no visibility)

Compliance Has Gotten Stricter

Modern Regulatory Requirements:

GDPR (General Data Protection Regulation):

Know who accesses personal data
Prove appropriate access controls
Demonstrate least privilege (minimum necessary access)
Show timely access revocation upon termination or role change

SOX (Sarbanes-Oxley):

Segregation of duties in financial systems (create vs approve)
Regular access reviews with documented results
Audit trails of access changes
Evidence of controls actually working

SOC 2:

Documented access control policies
Regular access certification with evidence
Provisioning/deprovisioning processes documented and followed
Continuous monitoring of access

HIPAA (Healthcare):

Access to PHI (Protected Health Information) must be role-appropriate
Regular access reviews required and documented
Audit trails of who accessed what patient data
Immediate access revocation upon termination

PCI DSS (Payment Card Industry):

Restrict access to cardholder data
Segregation of duties for payment processing
Regular access reviews every six months minimum
Strong authentication and access controls

The Challenge:

Regulators don't accept "we governed what we could see." They expect complete visibility and control. Partial governance isn't partial compliance—it's non-compliance. The access gap is a regulatory violation waiting to be discovered.

The Cost of Getting It Wrong

Security Costs:

Average data breach cost: $4.45M (IBM 2023 Cost of a Data Breach Report)
Insider threat contribution: 60% of security incidents involve insider access (Verizon DBIR)
Former employee access: Remains active in 40% of offboardings beyond intended date
Over-provisioned access: Present in 70% of user accounts in typical organization

Compliance Costs:

GDPR fines: Up to €20M or 4% of global revenue, whichever is higher
SOX violations: Personal liability for executives, potential criminal charges
Audit findings: Remediation can cost $500K-$2M depending on scope
Material weaknesses or qualified opinions: Can block business operations, prevent customer deals, kill fundraising in regulated industries

Operational Costs:

Manual access reviews: 40-80 hours per cycle for mid-sized companies (200-500 employees)
Provisioning delays: New hires wait 3-5 days for access, productivity lost
Help desk burden: 30-40% of IT tickets are access requests
License waste: $1,000-$5,000 per employee annually in unused SaaS licenses

Reputational Costs:

Customer trust erosion after breach (hard to quantify, impossible to ignore)
Competitive disadvantage from compliance gaps (lose deals to compliant competitors)
Difficulty attracting talent (security reputation matters to engineers)
Partnership friction (enterprise customers audit your security posture)

How Identity Governance Actually Works

The Discovery Phase

Step 1: Map Your Application Landscape

What Happens:

IGA system connects to multiple data sources to build complete application inventory:

SSO/IdP integration (obvious applications, already federated)
Finance system integration (what are we paying for?)
Browser extensions (what are people actually using?)
Network traffic analysis (what domains are being accessed?)

Discovers all applications in use—federated, unfederated, shadow IT, team-managed tools. Creates complete, continuously updated inventory.

What Good Discovery Looks Like:

99%+ application coverage (not just 30-40% via SSO)
Automated (no quarterly surveys that people ignore)
Continuous (finds new apps as teams adopt them)
Multi-method (doesn't depend on single data source that can fail)

Step 2: Map User Access

What Happens:

For each discovered application, identify who has access:

Capture entitlement level (viewer vs editor vs admin)
Track usage patterns (last login, frequency of use, which features)
Identify dormant accounts (provisioned but unused)
Map access path (how did they get this access? RBAC? Manual grant? Team invitation?)

What Good Access Mapping Looks Like:

Entitlement-level detail (not just "has access to Salesforce" but "has admin rights in Salesforce with export permissions")
Real-time or near-real-time (not quarterly snapshots that are outdated immediately)
Includes service accounts, external users, contractors (not just employees)
Shows access provenance (who granted it, when, based on what approval)

The Governance Phase

Step 3: Define Policies

What Happens:

Establish rules for who should have access to what:

Define RBAC policies (Marketing Manager role gets X, Y, Z apps)
Set context-based rules (anyone in Finance department + San Francisco office gets access to regional financial system)
Create approval workflows (who approves access requests, under what conditions)
Establish SoD rules (can't have both create AND approve permissions in financial systems)
Build compliance controls (PCI data requires specific training + manager approval)

Best Practices:

Start with critical applications (financial systems, customer data, production environments)
Use context over rigid roles where possible (dynamic, adapts to reality)
Build in least privilege by default (grant minimum, expand as needed)
Make exceptions auditable (document why exceptions exist, who approved, time-limited or permanent)

Step 4: Conduct Access Reviews

What Happens:

Schedule review cycles (quarterly for critical systems, semi-annually for others):

Generate certification campaigns for reviewers
Reviewers examine each user's access to their applications
System flags anomalies (unusual access, dormant accounts, excessive permissions)
Reviewers verify access is still appropriate, revoke what isn't
Remediate findings (revoke, modify, approve with justification)

What Makes Reviews Effective:

Complete data (all applications, not just federated—otherwise you're reviewing 40% and calling it comprehensive)
Context for reviewers (usage data, risk scores, last login, peer comparisons)
AI/ML anomaly detection (highlight what actually needs attention)
Closed-loop remediation (changes happen automatically based on decisions)
Compliance reporting (always audit-ready, not scrambling to produce evidence)

Step 5: Monitor and Adjust

What Happens:

Continuous monitoring for policy violations:

Real-time alerts for high-risk access changes (admin access granted, privileged permissions added)
Anomaly detection (unusual access patterns, access outside normal hours, access from unusual locations)
Policy violation tracking (SoD violations, over-provisioned access, unnecessary elevated permissions)
Periodic policy review and refinement (policies evolve as business evolves)

The Administration Phase

Step 6: Automate Lifecycle Management

Onboarding:

HRMS integration triggers on new hire (employee status = active)
IGA determines appropriate access based on role, department, location, manager, team
Accounts created and access provisioned automatically across all applications
New hire has everything needed on day one (not day five after IT processes tickets)

Mid-Lifecycle:

Role changes detected from HRMS (promotion, transfer, department change)
Access adjusted automatically (revoke old department access, grant new)
Manager approval required for exceptions (access outside standard role)
Audit trail maintained (who changed what, when, why, with what approval)

Offboarding:

Termination triggers in HRMS (employee status = terminated)
ALL access revoked immediately across all applications
Data ownership transferred to manager
Equipment return tracked
Compliance documentation generated automatically

Step 7: Enable Self-Service

What This Looks Like:

Employee app store (catalog of pre-approved applications)
Self-service access requests (click to request, automatic routing to appropriate approver)
Automated approval workflows (manager approves, access granted automatically)
Instant provisioning for approved apps (no IT tickets, no delays)

Why It Matters:

Reduces IT burden (30-40% fewer access-related tickets)
Faster access for employees (minutes vs days)
Maintains governance (everything tracked, approved, documented)
Better user experience (employees get what they need without friction)

The Evolution of IGA—Why Old Approaches Don't Work Anymore

The Three Generations of IGA

Legacy IGA (Pre-2010):

Built for on-premises environments. Governance-first approach that assumes visibility already exists. Connector-dependent—requires SCIM, LDAP, or other federation. 12-18 month tool implementations (just getting the software deployed and configured) requiring dedicated identity teams and significant consulting budgets.

When it worked: Static environments where IT controlled all procurement and applications changed slowly.

Modern/Autonomous IGA (2010-2020):

Cloud-native architecture with better UX and faster implementation timelines. Still governance-first. Improved SaaS support but remained connector-dependent. 2-6 week tool implementations with lower resource requirements (still significant). Designed for technical users—requires coding and scripting for customization. Access reviews are semi-automatic because remediation still requires manual effort (IT manually removing access after review decisions).

Improvement: Better for cloud applications, but the same fundamental assumption—visibility exists before governance. Plus operational overhead remains high.

Next-Generation IGA (2020+):

Visibility-first approach. Built for AI tools and SaaS-dominant environments where IT doesn't control procurement. Multi-method discovery beyond connectors (finds shadow IT including AI apps). 1-2 week tool implementations (deploy and configure). Purpose-built for mid-market with lean IT teams. Closed-loop remediation for access reviews—decisions automatically trigger access changes without manual IT work.

The shift: Complete visibility BEFORE governance. Discover everything (including AI tools), then govern everything automatically.

The Enterprise IGA Problem (And Why Mid-Market Needs Different Tools)

Who Built Traditional IGA:

Legacy and modern IGA solutions were built by enterprise vendors—SailPoint, Oracle, IBM—for Fortune 500 companies with 10,000+ employees, dedicated identity teams of 10-20 people, and million-dollar budgets for identity infrastructure.

The Assumptions Baked In:

You have a full-time identity team to manage the platform
You can afford 12-18 month implementations with expensive consulting
You have time for extensive customization and integration work
IT controls all procurement (no shadow IT problem)
Applications are mostly federated (you've paid to connect everything)

Why Mid-Market Is Different:

The risks are now equal. A 500-person company faces the same compliance requirements (SOC 2, ISO 27001, GDPR), the same security threats, the same audit scrutiny as a 10,000-person enterprise. But mid-market IT teams have:

2-5 person IT team handling everything (no dedicated identity team)
Limited budgets (can't afford $200K+ annual licensing plus consulting)
Need for fast time-to-value (1-2 weeks for tool implementation, 4-6 weeks for initial results)
Shadow IT everywhere (teams buy tools directly with credit cards)
Majority of apps unfederated (can't afford SSO tax for 400+ apps)

Enterprise IGA vendors (Sailpoint, Saviynt, Omada, etc.) serve enterprises well. But their tools don't work for mid-market. The tool implementation alone takes 6-12 months (before you even start using it), the operational overhead requires dedicated teams, the discovery capabilities assume federated apps.

The Solution:

Next-Gen IGA tools like Zluri were built specifically for mid-market IT teams. Discovery-first methodology (find everything including shadow IT), fast deployment, low operational overhead (1 admin manages the platform), unified SaaS + IGA approach. Purpose-built for mid-market teams that face enterprise-scale risk with small-business resources.

Why Governance-First Fails in Modern Environments

The Assumption:

Legacy and modern IGA assume you know what applications exist and who has access. They start with governance—reviews, certifications, policies—and assume visibility is handled elsewhere (your IdP, your SSO, your CMDB that nobody updates).

Why This Breaks:

Problem 1: Incomplete Visibility

Traditional IGA governs apps visible in your IdP—typically the minority of your actual application landscape. Shadow IT remains ungoverned. For AI tools, shadow percentages are even higher. As a result, most of your applications operate completely outside governance.

Problem 2: The Access Review Illusion

You review 100% of visible access with great rigor and documentation. Auditors find applications with unreviewed access. You explain those apps aren't federated. They ask why unfederated applications aren't being governed. You don't have a good answer because there isn't one.

The end result is compliance violation despite "complete" reviews. False sense of security.

Problem 3: Offboarding Gaps

IGA revokes access to known applications when employees leave. Thorough, documented, audit-ready. Former employees retain access to team-managed tools that IGA doesn't see. Security incidents happen from "fully offboarded" ex-employees.

In the end, lingering access creates ongoing risk despite perfect execution of visible offboarding.

The Visibility-First Imperative

The Right Sequence:

Step 1: Discover Everything

Find all applications—federated, unfederated, shadow IT, team-managed tools. Identify all users and their actual access. Map all permissions and entitlements. Track usage patterns and risk indicators.

Step 2: Then Govern Based on Risks

Access reviews cover the complete application portfolio (not just 30-40% of known apps), prioritized by risk level. Policies apply to all access, not just visible access. Offboarding revokes everything, not just federated apps. Compliance evidence is actually complete. Governance decisions driven by actual risk—critical systems get more scrutiny, high-risk access gets immediate attention.

This matters because you can't fix what you can't see. Governance without discovery isn't governance—it's a compliance and security risk with better documentation. You're governing the visible portion while the invisible portion creates all your actual risk.

Identity-First Security in an AI-Driven World

Why Identity Is the New Perimeter

The old security model was to protect the network with a firewall and VPN. Users and applications operate inside trusted networks. The perimeter defense strategy is to keep bad things out and trust everything inside.

The current reality is that no network perimeter exists. SaaS apps everywhere, users everywhere, data everywhere. Identity determines access, not network location.

What Identity-First Security Means:

Verify every access request regardless of source (zero trust). Least privilege by default (minimum necessary access). Continuous validation, not one-time authentication (access doesn't mean permanent access). Context-aware access decisions (who, what, where, when, how, why).

The Zero Trust + IGA Connection

Zero trust principle says that never trust, always verify. Least privilege access (minimum necessary). Assume breach (limit blast radius if compromised). Context-aware access decisions.

How IGA Enables Zero Trust:

Continuous Verification: Regular access reviews = continuous validation of access appropriateness. Not one-time approval that persists forever. Ongoing verification that access still makes sense.

Least Privilege Enforcement: IGA ensures minimum necessary access through policy. Regular reviews catch access creep (accumulated permissions over time). Automated provisioning applies least privilege from the start.

Breach Containment: Segregation of duties limits what a compromised account can do. Rapid deprovisioning limits breach duration (detect and revoke immediately). Audit trails enable fast incident response (who accessed what when).

Context-Aware Policies: Access based on role, location, device, time, sensitivity of data, user behavior. Dynamic policies adjust to risk (unusual access patterns trigger additional verification). IGA enforces policies across all applications consistently.

What Organizations Need:

Flexibility: IGA that adapts to new application types and access patterns
Discovery: Find new tools as they emerge, not six months later
Automation: Can't manually govern 1,000+ applications (need intelligent automation)
Intelligence: AI to govern AI (detect anomalies at scale, identify risk patterns)

IGA isn't just about compliance anymore. It's the foundation of modern security in a world where identity is the perimeter and AI tools multiply access patterns exponentially.

Getting Started with Identity Governance and Administration

Signs You Need IGA Now (Not Later)

Beyond company size, here are the specific triggers that mean you need to start implementing IGA:

Security Triggers:

Former employee accessed systems after departure (caught by incident investigation)
Over-provisioned access contributed to security incident (user had access they shouldn't)
You can't answer "who has admin access to [critical system]?" without investigation
Shadow IT discovered with sensitive data (marketing team's Airtable has customer PII)

Compliance Triggers:

Auditors found access governance gaps (incomplete reviews, missing documentation)
Material weaknesses preventing SOC 2, ISO 27001 certification due to access control deficiencies
Regulatory fine or warning related to access management
Enterprise customers requiring evidence of access governance before deal closes

Operational Triggers:

IT help desk overwhelmed with access requests (30-40% of all tickets)
Onboarding takes 5+ days because access provisioning is manual
Access reviews delayed or skipped because process is too painful
No one knows complete application inventory (IT discovers new apps monthly)

Financial Triggers:

SaaS spend growing faster than headcount (more tools, same or fewer people)
License waste exceeding $100K annually (paying for users who left or don't use tools)
CFO asking why software costs are out of control

Common Mistakes to Avoid

Mistake 1: Buying Before Discovery Validation

Every IGA vendor claims discovery. The question is: Is it just based on IDP/SSO? Test it with your actual environment in proof of concept. Can it find shadow IT? Can it map access in unfederated apps? Can it discover team-managed tools? Validate before buying.

Mistake 2: Skipping Stakeholder Alignment

IGA touches HR (onboarding/offboarding), managers (reviews and approvals), security (policies and monitoring), compliance (evidence and reporting), application owners (defining appropriate access). Get them aligned before implementation, not during a crisis.

Mistake 3: Underestimating Change Management

You're changing how people work. Communicate early and often. Make new processes easier than old workarounds (otherwise people route around them). Train people properly (otherwise they misuse systems or reject them).

Mistake 4: Confusing Tool Implementation with Process Maturity

Understand two different timelines:

Tool implementation: Modern IGA tools like Zluri can be implemented in 1-2 weeks (technical setup, integrations, initial configuration). Traditional/legacy IGA tools take 6-12 months just for implementation before you can even start using them properly.

Process maturity: 6-12 months regardless of tool (people adapting, workflows refining, stakeholder buy-in, organizational change). This isn't "implementation time"—it's change management time. You can't rush human adaptation.

‍

Don't believe vendors claiming "full governance in 6 weeks" for process maturity. The tool might be ready in weeks, but your organization needs months to adapt. Ask for reference customers who actually achieved it.

Mistake 5: Forgetting This Is a Journey, Not a Project

IGA maturity takes 6-12 months even with fast tool implementation and phased rollout. You'll refine processes based on learnings, adjust policies when real-world exceptions appear, expand coverage iteratively as stakeholders see value. Plan for continuous improvement and organizational adaptation, not one-time project completion with a cutover date.

Measuring Success (What IT Directors Actually Care About)

IGA success is measured across three dimensions:

Coverage: Did you discover and govern the 60-70% of applications that were invisible? Governance of known apps isn't success if most apps remain unknown.

Automation: Did you reduce manual work? Provisioning/offboarding should take hours not days, access reviews should complete in weeks not months, access related IT tickets should drop by 80%.

Outcomes: Did security improve (fewer incidents), compliance strengthen (clean audit opinions), and costs decrease (license waste eliminated)?

The metric that matters most: % of total applications with complete access visibility and governance. If you're at 90%+ for your critical apps, you've succeeded. If you're at 30-40%, you've automated the visible portion while the shadow IT creates the actual risk.

Identity Governance Isn't Optional Anymore

When identity is the perimeter—and it is—governance becomes foundational to security, not a compliance checkbox you tick once a year.

What's Changed: Applications multiplied from 50 to 500+. Procurement decentralized from IT to teams buying with credit cards. Work distributed from office to remote/hybrid across geographies. Regulations intensified—compliance gaps block business. Threats evolved—insiders, former employees, over-provisioned access create more risk than external attackers.

What Hasn't Changed: Most IGA approaches still assume complete visibility exists. Assume applications are federated through your IdP. Assume IT controls procurement. Those assumptions were wrong five years ago. They're lethally wrong today.

The Path Forward: Start with discovery—you can't govern what you can't see. Automate aggressively—manual processes don't scale to 500+ apps. Enable self-service—reduce IT burden while maintaining control. Review continuously—annual reviews are too slow for the modern pace of change.

Measure completeness—100% of known access ≠ success if you only know about 30-40% of applications while 60-70% are shadow IT.

For Mid-Market Companies: You face enterprise-scale complexity with small-business resources. You need purpose-built solutions, not scaled-down enterprise tools that assume you have a 10-person identity team. Fast time-to-value, low administrative overhead, complete discovery—these aren't nice-to-haves, they're requirements for survival.

Identity governance and administration has evolved from compliance checkbox to security foundation. The question isn't whether you need IGA—you do. The question is whether your approach matches your reality.

Most companies are governing 30-40% of applications (the known, federated ones) and calling it comprehensive. That 60-70% gap—the shadow IT—is where breaches happen, where compliance violations hide, where former employees retain access.

Governance without discovery is a compliance and security risk. Fix visibility first. Then govern everything, not just what you can see.