A Strategy to Implement IGA in Your Organization

Most IGA implementations fail. And the problem isn't the technology.

It's that:

most IT teams don't know where to start, and
they definitely don't know how to sequence things properly.

IGA has so many interdependent pieces that without a clear strategy, you'll end up with a half-implemented system that nobody uses and auditors still don't trust.

Here's what actually works: a phased approach that gets you quick wins early, then builds sophistication over time. Each phase sets you up for the next one, so you're not trying to boil the ocean on day one.

Before we get into the specifics, let's be clear about what we're trying to achieve. As we have said multiple times before, the goal of IGA is to ensure the right people have the right level of access to the right tools at the right time.

That's it. Everything else is just implementation details.

Phase 1: Start With User Access Reviews

If you're wondering where to begin, start here. Not because access reviews solve everything—they don't—but because they give you momentum and prove value quickly.

Access reviews are already happening at most organizations because compliance frameworks demand them. SOX, HIPAA, GDPR—they all require some version of "prove that you know who has access to what." So you're not introducing something completely new. You're just doing it better and more systematically.

Here's why this works as a starting point.

First, you get compliance wins fast. Auditors want to see that you're actively monitoring who has access to sensitive systems. Access reviews give you that proof.

Second, the process is relatively straightforward—managers review lists of who has what access, then approve or revoke.

Third, you build momentum. When you show senior leadership that you've eliminated orphaned accounts and tightened controls on financial systems, suddenly your IGA project has executive support.

The practical steps are simple. Start with high-value applications—your HRMS, CRM, financial systems, identity providers. These hold your most sensitive data, so they're where you need visibility first.

Then identify clear owners for each application. Someone needs to know who should have access and who shouldn't. Run the review process with those owners, documenting what changes you make and why.

You'll start to see patterns—maybe the sales team always over-provisions Salesforce access, or the engineering team has way too many people with admin rights.

Track everything. How many accounts did you revoke? How many licenses did you reclaim? What compliance gaps did you close? These metrics matter because they prove ROI and keep your project funded.

The side benefit that finance teams love: you'll probably find a bunch of licenses you can reclaim. Someone left six months ago but still has an active Salesforce seat? That's $1,800 a year you just saved.

But—and this is critical—don't stop here. Access reviews are a great starting point, but they're not the end goal. They have serious limitations that you need to understand.

Why Access Reviews Alone Won't Cut It

Access reviews are point-in-time snapshots. You run them quarterly or annually, which means there's a massive gap between reviews where access can drift.

Someone gets promoted? They keep their old access and get new access. Someone leaves? Their accounts sit there until the next review cycle. Someone changes departments? Nobody remembers to update their permissions.

Most organizations run access reviews only on their "in-scope" applications—the ones that auditors care about. That's fine for compliance, but it leaves huge security blind spots. Your cloud infrastructure, your SaaS tools, your development environments—none of those are getting reviewed, and they're probably where your biggest risks live.

Here's the other problem: access reviews are inherently restrictive. They're designed to find and remove excess access. That's good for security, but it creates a cultural problem. Managers start under-provisioning access because they're worried about the next audit. New hires don't get everything they need because "we'll add it if they really need it." Productivity suffers.

The real issue is that access reviews don't help you ensure that people have the right access when they need it. They only help you clean up after the fact. That's not governance—that's cleanup.

So what's the logical next step? Automate the processes that create access drift in the first place.

Phase 2: Automate Lifecycle Management

This is where IGA starts to feel like actual governance instead of periodic housekeeping.

User lifecycle management means automating what happens when someone joins your company, changes roles, or leaves. These are your joiner-mover-leaver processes, and if you're doing them manually, you're wasting massive amounts of time while creating security gaps.

Think about what happens today when someone joins. IT gets a ticket, manually provisions their accounts one by one, probably forgets something, then has to circle back when the new hire complains they can't access Slack.
When someone leaves, their manager maybe remembers to tell IT, who hopefully gets around to deprovisioning their accounts before the next audit.
When someone changes departments, their access just accumulates because nobody wants to be responsible for breaking something.

Automation fixes all of this, and it fixes it continuously—not just at quarterly review checkpoints.

The way this works in practice: your HR system becomes your source of truth.

When HR creates a new employee record, that triggers automatic provisioning in your identity provider.

The new hire gets their baseline access immediately—email, collaboration tools, the standard stuff everyone needs. They also get department-specific access based on their role. Engineering gets GitHub, sales gets Salesforce, finance gets your ERP.

When someone changes roles, the system detects that change and automatically adjusts their access. When someone leaves, their accounts get deprovisioned immediately—not in three months when someone finally gets around to it.

This typically handles 50% or more of your provisioning work with zero manual intervention. More importantly, it shrinks the window of risk. Instead of waiting weeks or months to remove access from departed employees, it happens the same day.

The practical setup involves connecting your HR system to your identity provider with real-time or scheduled syncing. You define your "birthright access"—what everyone gets by default. You map department and role attributes to application access. You set up triggers for new hires, transfers, and exits. Then you monitor and refine as your organization changes.

The end result is that your next access review is dramatically easier because access is already mostly correct. You're not spending hours cleaning up orphaned accounts or figuring out why someone has access to three different departments' tools.

Phase 3: Granular Access Management

So far we've been working at the application level—does this person have access to Salesforce or not? But that's too coarse-grained for real least privilege.

Inside Salesforce, what can they actually see? Can they view all opportunities or just their own? Can they delete records or just read them? Same thing with Slack—are they in the company-wide channels or also the executive planning channel? Your CRM—can they see financial data or just contact information?

This is where you move from application-level access to entitlement-level access. It's more complex, but it's where real security happens.

The challenge is that every application structures permissions differently. Salesforce uses profiles and permission sets. Slack uses channels and user groups. GitHub uses repository permissions and team memberships. Your ERP probably has some byzantine role hierarchy that three people in the entire company understand.

You need to map all of this out. For each critical application, document how permissions work and who owns what resources. The sales VP should own Salesforce access. The engineering director should own GitHub repositories. The finance controller should own ERP modules.

Then you extend your automation to include these granular permissions. When someone joins as a sales rep, they don't just get Salesforce—they get the specific profile and permission sets that sales reps need, access to their territory's accounts, and membership in the appropriate Slack channels. High-risk permissions require additional approval workflows.

This is also where role-based (and other types of) access control starts to matter. You're no longer thinking about departments—you're thinking about job functions. Account executives need different Salesforce access than sales engineers. Backend engineers need different GitHub permissions than frontend engineers.

Use the data from your access reviews to inform this. You ran reviews on who has what access. Now use that information to define standard roles and entitlements that you can automate going forward.

The result is true least privilege at scale. People have exactly what they need to do their jobs, and nothing more. Your attack surface shrinks dramatically.

Phase 4: Strengthen Identity Security

At this point you've got solid governance in place. Users get provisioned correctly, deprovisioned quickly, and have granular access aligned to their roles. But you're still vulnerable to identity-based attacks—privilege escalation, lateral movement, compromised credentials.

Time to layer in security controls.

Start with a risk-based approach. Not all applications are equally sensitive. Your HR system with salary data is high-risk. Your company wiki is low-risk. Your production database is high-risk. Your staging environment is medium-risk. Classify everything, then apply controls proportionally.

High-risk systems get MFA enforced, stricter approval workflows, and additional monitoring. Medium-risk systems get standard controls. Low-risk systems get basic security hygiene.

For privileged users—database admins, infrastructure engineers, security team members—implement time-bound access to critical systems with full audit trails. When a DBA needs production database access, they request it, get approval, the access is granted for exactly as long as needed (maybe four hours), then automatically revoked.

Deploy continuous monitoring and anomaly detection. If someone who normally accesses three applications suddenly starts accessing twenty, that's suspicious. If someone is logging in from a new country, that deserves investigation. If permissions are being changed outside of your standard workflows, you need to know immediately.

Don't forget shadow IT. You've secured all your known applications, but your teams are probably using SaaS tools you don't even know about. Deploy discovery tools to find these, then decide whether to onboard them into your IGA framework or block them. Either way, you need visibility.

The result is defense in depth. Even if someone's credentials are compromised, you have controls in place to limit the damage and detect the attack quickly.

Phase 5: Enable Self-Service Access Requests

Here's where you shift from controlling access to enabling business velocity—without sacrificing security.

Right now, when someone needs access to a new tool, they probably submit a ticket, wait for IT to see it, wait for approvals, wait for provisioning. This takes days or weeks. People work around it by sharing credentials (terrible) or just not using the tools they need (also terrible).

Self-service fixes this. Build a portal where employees can request access to applications, roles, or specific resources. They select what they need, provide justification, and submit.

The request routes automatically to the appropriate approvers—their manager, the application owner, maybe a security review for high-risk access. Once approved, the access is provisioned automatically through your existing workflows.

This isn't a free-for-all access. You're still enforcing policy and approval chains. High-risk requests require thorough justification and multiple approvals. But you're eliminating the manual ticket shuffle and reducing wait times from weeks to hours.

Track everything. Who's requesting what? Are there patterns you should automate? Are certain requests consistently denied? Are there bottlenecks in the approval process? Use this data to continuously improve.

The result is faster onboarding, better productivity, and happier employees—all while maintaining security and compliance controls. Your IT team stops being a bottleneck and starts being an enabler.

How the Five Phases Build on Each Other

Here's how these phases build on each other:

Access reviews give you visibility and quick compliance wins. You now know who has what access, and you've cleaned up the worst problems.

Lifecycle management automates the processes that create access drift. New hires get provisioned correctly, departing employees get deprovisioned immediately, and role changes update access automatically.

Granular access management extends governance into applications themselves. You're not just controlling who has Salesforce—you're controlling what they can do in Salesforce.

Identity security adds threat prevention and monitoring. You're not just managing access—you're detecting and preventing misuse.

Self-service requests give business teams agility while maintaining oversight. You're enabling productivity, not blocking it.

Five Implementation Principles That Determine Success

Phase your rollout. Don't try to implement everything everywhere at once. Start with a pilot group or a single department, learn what works, fix what doesn't, then expand. IGA implementations fail when organizations try to boil the ocean on day one.

Your IGA is only as good as your identity data. If your HR system has stale information, wrong departments, or missing role data, everything downstream breaks. Invest in data cleanup early. It's boring work, but it's foundational.

Define clear ownership. Who owns each application? Who approves access requests? Who's responsible for reviewing entitlements? Without clear ownership, your governance framework becomes a bureaucratic mess where nobody takes responsibility for anything.

Track metrics that matter. Don't just count the number of access reviews you completed. Track time saved, orphaned accounts removed, policy violations detected, and time-to-provision for new hires. These metrics prove ROI and help you continuously improve.

Stay agile. Your identity landscape changes constantly—new applications, acquisitions, organizational changes, new compliance requirements. Your IGA program needs to adapt. This isn't a "set it and forget it" project.

IGA as Business Enabler, Not Just Security Control

IGA isn't about implementing tools or checking compliance boxes. It's about building a framework that enables your business to move fast while staying secure.

Good IGA means your sales team can provision a new rep and have them productive on day one. It means your finance team knows exactly who can access sensitive financial data. It means your security team can prove to auditors that you have appropriate controls in place. It means when someone leaves, they lose access immediately instead of lingering in your systems for months.

Most importantly, good IGA means your organization can adopt new technologies, enter new markets, and respond to opportunities without security becoming a bottleneck.

Start with quick wins, build momentum, automate the boring stuff, then layer in sophistication over time. That's how you build IGA that actually works.

‍