TTechclick ⚡ XP 0% All lessons
SailPoint · Identity Governance · IGAInteractive · L1 / L2 / L3

SailPoint Identity Governance (IGA) — Certifications, Provisioning, Roles & SoD

SailPoint IGA answers one question across every app: who has access to what, should they, and can you prove it? This lesson maps how SailPoint aggregates identities into the warehouse, provisions and deprovisions access through lifecycle events, runs access certification campaigns, builds roles by mining real access, and enforces Separation of Duties — so you can explain certification and SoD cleanly in an interview.

📅 2026-06-19 · ⏱ 17 min · 5 infographics · live request demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to SailPoint Identity Governance & Administration (2026): how IGA differs from SSO and PAM, Identity Security Cloud vs IdentityIQ, aggregation into the identity warehouse, access requests with automated provisioning and deprovisioning, access certification campaigns, roles and role mining, Separation of Duties (SoD) policies, and AI-driven access recommendations.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

What IGA is

Who has access, should they, can you prove it.

2

Sources & warehouse

Aggregation, correlation, the identity model.

3

Requests & certify

Provisioning, lifecycle, certification campaigns.

4

Roles & SoD

RBAC, role mining, Separation of Duties.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. Does IGA log users in like SSO does?

Answered in What IGA is.

2. Where do all the accounts and entitlements get collected?

Answered in Sources & warehouse.

3. What is an access certification campaign for?

Answered in Requests & certify.

Most engineers think…

Most people lump 'identity' into one bucket and assume SailPoint is just another login tool. That mental model fails you in an interview and in an audit.

SailPoint IGA does not authenticate users — that is SSO. It does not broker privileged sessions — that is PAM. IGA is the governance layer: it aggregates every account and entitlement into a central identity model, automates joiner-mover-leaver provisioning, runs access certification campaigns so owners recertify or revoke access, models roles from real usage, and enforces Separation of Duties so no one holds a toxic combination. The interview-winning line is: SSO answers can you log in, PAM answers how privileged sessions are controlled, and IGA answers should you have this access at all — and can we prove it.

① What IGA actually is — and how it differs from SSO and PAM

The single most important idea: Identity Governance & Administration (IGA) is about who should have access to what, and proving it — not about logging people in. SailPoint IGA continuously answers three questions an auditor will ask: who has access, is that access appropriate, and can you show the evidence.

IGA vs SSO vs PAM

SSO (single sign-on, e.g. Okta or Entra ID) handles authentication — it lets you log in once. PAM (privileged access management) controls and records what admins do in privileged sessions. IGA sits above both: it governs the lifecycle of access — granting, reviewing, certifying and revoking entitlements across every connected app — and is the system of record for compliance. They are complementary, not interchangeable.

Figure 1 — The IGA loop — aggregate, request, provision, certify, govern
SailPoint IGA runs the same governance loop over every connected source.The IGA loop — aggregate, request, provision, certify, governAggregateread accounts inRequestask + approveProvisiongrant / revokeCertifyreview + sign offGovernroles + SoD
SailPoint IGA runs the same governance loop over every connected source.
Figure 2 — Three identity layers, one question
SSO, PAM and IGA each answer a different access question — IGA owns governance.Three identity layers, one questionSSO — authenticationCan you log in? (Okta, Entra ID)PAM — privileged accessControl + record admin sessionsIGA — governanceShould you have this access? Prove it
SSO, PAM and IGA each answer a different access question — IGA owns governance.
Quick check · Q1 of 10 · Understand

How does IGA differ from SSO?

Correct: b. SSO answers authentication — can you log in. IGA is the governance layer: it decides whether access is appropriate, manages its lifecycle, and produces audit evidence. PAM separately controls privileged sessions.
👉 So far: IGA = governance: who should have access and proof of it. SSO authenticates (can you log in), PAM controls privileged sessions, IGA owns the access lifecycle and audit.

② Sources, aggregation and the identity warehouse

Before SailPoint can govern anything, it has to see everything. A source is any connected system — Active Directory, Workday, SAP, a SaaS app. SailPoint uses connectors to aggregate (read in) the accounts and entitlements from each source on a schedule.

Cube, warehouse and correlation

Those accounts are correlated to a single person and stored as one model. In IdentityIQ this is the Identity Cube — a complete picture of a user's attributes, accounts, entitlements, roles, policy violations and risk — held in the identity warehouse. An authoritative source (usually HR/Workday) defines who the person is; other sources contribute the accounts they own. SailPoint ships this two ways: Identity Security Cloud (SaaS, built on the Atlas platform) and IdentityIQ (on-prem, deepest customization). Same governance ideas, different delivery.

Figure 3 — One identity warehouse, every source
Accounts from each source are correlated to one identity model so governance is consistent everywhere.One identity warehouse, every sourceIdentity Cube+ warehouseHR / Workday (auth)Active DirectorySAP / ERPSaaS appsDatabasesCloud (AWS/Azure)
Accounts from each source are correlated to one identity model so governance is consistent everywhere.
Figure 4 — Identity Security Cloud vs IdentityIQ
Same IGA model, two delivery options — SaaS on the Atlas platform or on-prem with deep customization.Identity Security Cloud vs IdentityIQIdentity Security CloudSaaS on the Atlas platformAuto-updated, faster to deployAI access recommendations built inBest for cloud-first estatesIdentityIQOn-prem / hybrid softwareDeepest customization (Java)You own sizing and upgradesBest for heavy legacy / control
Same IGA model, two delivery options — SaaS on the Atlas platform or on-prem with deep customization.
🗄️
Identity warehouse
tap to flip

The central store of every Identity Cube — each user's attributes, accounts, entitlements, roles, violations and risk, correlated from all sources.

🔄
Aggregation
tap to flip

The scheduled process of reading accounts and entitlements in from each connected source, then correlating them to the right identity.

Access certification
tap to flip

A periodic campaign where reviewers certify (keep) or revoke each person's access, producing an audit trail of sign-offs and removals.

⚖️
Separation of Duties
tap to flip

An SoD policy defines two lists of conflicting access; holding both raises a violation, stopping fraud-enabling combinations.

Name the authoritative source

In an interview, say it out loud: the authoritative source (usually HR/Workday) defines who a person is and drives joiner-mover-leaver events; other sources only contribute the accounts they own. Aggregation reads them in, correlation ties them to one Identity Cube. That sentence shows you understand the data model, not just the buttons.

Quick check · Q2 of 10 · Remember

In IdentityIQ, what is the single combined model of one user's accounts, entitlements, roles and risk called?

Correct: c. The Identity Cube is the multi-dimensional model of a user — attributes, accounts, entitlements, roles, policy violations and risk — built by aggregating from sources and held in the identity warehouse.
👉 So far: Aggregation reads accounts/entitlements from each source; correlation ties them to one Identity Cube in the warehouse. Identity Security Cloud is SaaS (Atlas); IdentityIQ is on-prem.

③ Access requests, provisioning and certification campaigns

Once identities are correlated, governance gets active. A user (or their manager) submits an access request; it routes through approvals; on approval SailPoint provisions the access automatically into the target system. Lifecycle states — joiner, mover, leaver — drive this without tickets: a new hire is auto-provisioned baseline access, a transfer gets access updated, and a termination triggers automatic deprovisioning so orphaned access does not linger.

Access certification

Periodically SailPoint launches an access certification campaign (a recertification): reviewers — usually managers or app owners — are shown each person's access and must certify (keep) or revoke it. Revokes can auto-provision the removal. The campaign produces a full audit trail of every decision, which is exactly what SOX, GDPR, HIPAA and similar audits demand. In an interview this is the headline: certification = periodic review of who has access, with sign-off and revocation, all evidenced.

'Certification is just rubber-stamping' under-sell

Reviewers clicking 'approve all' is the real-world failure of certification. The point is genuine review with revocation that actually deprovisions, plus AI recommendations that flag risky or unused access for attention. Describe certification as evidence-producing review, not a formality, and mention micro-certifications triggered by changes.

▶ Watch an access request get provisioned end-to-end

How one request becomes real access in a target app. Press Play for the healthy path, then Break it to see the classic failure.

① RequestA new analyst requests access to the finance reporting app through the SailPoint access request portal.
② Approve + checkThe manager approves; SailPoint runs the SoD policy check and confirms no conflicting access exists.
③ ProvisionSailPoint provisions the entitlement into the target app automatically via its connector — no manual ticket.
④ Certify laterAt the next certification campaign the manager recertifies the access, leaving an audit trail.
Press Play to step through the healthy provisioning path. Then press Break it.
Quick check · Q3 of 10 · Apply

An employee leaves the company. What should SailPoint do automatically?

Correct: a. The leaver lifecycle state triggers automatic deprovisioning so access is removed across connected systems — preventing orphaned accounts. Joiner/mover states grant or update access the same way.
👉 So far: Requests are approved then auto-provisioned; lifecycle states (joiner/mover/leaver) drive provisioning and deprovisioning; certification campaigns recertify or revoke access with a full audit trail.

④ Roles, role mining and Separation of Duties (SoD)

Granting access one entitlement at a time does not scale. Roles (RBAC) bundle the entitlements a job needs so a 'Teller' role grants the right access in one move. Building roles by hand is painful, so SailPoint uses role mining — AI/ML analyzes who actually has what, finds common patterns, and suggests candidate roles, cutting role explosion dramatically.

Separation of Duties

Some access combinations are dangerous together. Separation of Duties (SoD) is the principle that no one person should control a whole sensitive process — e.g. the same user should not both create a vendor and approve its payments. A SoD policy defines two lists of conflicting access; if any identity holds access from both lists, SailPoint flags a policy violation — at request time (prevent) and during certification (detect). The interview line: SoD stops toxic combinations that enable fraud; roles and AI recommendations make the right access fast while SoD keeps it safe.

Figure 5 — How a risky request gets caught by SoD
An access request is checked against SoD policies before it is ever provisioned, so a toxic combination is blocked or flagged.How a risky request gets caught by SoDRequestuser asks for accessSoD checktwo conflict listsViolationtoxic combo foundDecisionblock or approveAuditlogged for review
An access request is checked against SoD policies before it is ever provisioned, so a toxic combination is blocked or flagged.

Priya at a Mumbai bank faces this

An internal auditor finds a finance clerk who can both create new vendors and approve payments to them — a classic fraud risk that slipped through.

Likely cause

There was no SoD policy defined for that pair, and access was granted ad hoc one entitlement at a time with no role model.

Diagnosis

Open the identity warehouse — the clerk's Identity Cube shows both entitlements; no SoD policy ever flagged the combination at request time.

Identity Security Cloud ▸ Policies ▸ Separation of Duties + Access Requests
Fix

Define an SoD policy with the two conflicting-access lists, run it across all identities to surface existing violations, remediate via certification, and enforce the check at request time so future requests are blocked.

Verify

Re-run the policy: the clerk's violation is remediated, and a fresh request for both entitlements is now stopped before provisioning.

Prove access from the Cube, not a hunch

Never answer an access question with 'should be fine'. The Identity Cube in the warehouse shows exactly what entitlements and roles a user holds, every policy violation, and their certification history. That single read settles most governance questions without guessing.

Quick check · Q4 of 10 · Analyze

A SoD policy says 'create vendor' and 'approve vendor payments' must not be held together. A user requests both. What happens?

Correct: c. SoD defines two conflicting-access lists. Holding both is a toxic combination, so SailPoint raises a policy violation — at request time to prevent it, or during certification to detect it — which an owner then decides on.
👉 So far: Roles (RBAC) bundle access; role mining uses AI to discover roles from real usage; SoD policies define conflicting-access lists and flag toxic combinations at request and certification time.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Which layer answers 'should this user have this access at all, and can we prove it?'

Correct: b. IGA is the governance layer that decides whether access is appropriate and produces audit evidence. SSO authenticates, PAM controls privileged sessions, MFA strengthens login.
Q6 · Understand

What does aggregation do in SailPoint?

Correct: a. Aggregation is the scheduled reading-in of accounts and access rights from each source; correlation then ties them to the right Identity Cube in the warehouse.
Q7 · Apply

You must satisfy an auditor that access is still appropriate every quarter. Which SailPoint capability do you use?

Correct: c. Certification campaigns have reviewers recertify or revoke each user's access on a schedule, producing the audit trail of sign-offs and removals auditors require.
Q8 · Analyze

Why use role mining instead of building roles by hand?

Correct: b. Role mining uses AI/ML to examine who actually holds what, finds common patterns, and proposes candidate roles — far faster and cleaner than manual modeling, and it reduces role explosion.
Q9 · Evaluate

An interviewer asks the best way to stop one person both creating vendors and approving their payments. Best answer?

Correct: b. That toxic combination is exactly what Separation of Duties prevents: an SoD policy with two conflicting lists raises a violation when both are held, blocking it at request time and detecting it in certification.
Q10 · Evaluate

Why is automatic deprovisioning on the leaver lifecycle state important?

Correct: c. The leaver state triggers automatic removal of access across connected systems, so access does not linger after someone departs — orphaned access is a top audit finding and a real breach risk.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is SailPoint IGA described as 'who should have access, and prove it' rather than a login tool? Then compare with the expert version.

Expert version: Because IGA does not authenticate users — that is SSO — and it does not broker privileged sessions — that is PAM. SailPoint aggregates every account and entitlement into a central identity model (the Identity Cube in the warehouse), automates joiner-mover-leaver provisioning and deprovisioning, runs access certification campaigns where owners recertify or revoke access, models roles from real usage with role mining, and enforces Separation of Duties so no one holds a toxic combination. Every one of those actions is logged, which is why IGA is the governance and audit system of record — it answers should you have this access, and can we prove it, across every connected app.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

IGA
Identity Governance & Administration — the discipline of deciding who should have access to what, automating its lifecycle, and proving it for audit.
Source
A connected system (app, directory or database) that holds its own accounts, reached through a SailPoint connector.
Aggregation
The scheduled process of reading accounts and entitlements in from a source so SailPoint can govern them.
Identity Cube
In IdentityIQ, the single model of one user — attributes, accounts, entitlements, roles, policy violations and risk — held in the warehouse.
Correlation
Matching aggregated accounts to the right person, using an authoritative source to define each identity.
Provisioning / Deprovisioning
Automatically granting access on approval or lifecycle event, and automatically removing it when no longer needed.
Access certification
A periodic campaign where reviewers certify (keep) or revoke each person's access, leaving an audit trail.
Role / Role mining
A role bundles the entitlements a job needs (RBAC); role mining uses AI/ML to discover candidate roles from real access patterns.
Separation of Duties (SoD)
A policy of two conflicting-access lists; holding both raises a violation to stop fraud-enabling combinations.
Identity Security Cloud / IdentityIQ
SailPoint's SaaS IGA on the Atlas platform vs the on-prem software with the deepest customization.

📚 Sources

  1. SailPoint Identity Services — Managing Sources Overview (aggregation, connectors, correlation). documentation.sailpoint.com/saas/help/sources
  2. SailPoint Identity Services — Provisioning Overview & Setting Up Lifecycle States (joiner/mover/leaver). documentation.sailpoint.com/saas/help/provisioning
  3. SailPoint Identity Services — Separation of Duties Overview & Managing Policies. documentation.sailpoint.com/saas/help/sod
  4. SailPoint IdentityIQ — Identity Management: Identity Cubes, the identity warehouse & correlation. documentation.sailpoint.com/identityiq
  5. SailPoint — Compliance management: access certifications with AI-driven insights. sailpoint.com/products/identity-security-cloud/atlas/capabilities/compliance-management
  6. SailPoint — Modernize Access Modeling: role discovery and mining with AI and machine learning. sailpoint.com/blog/modernize-access-modeling-ai-ml

What's next?

Got governance? Next, go deeper on connectors and provisioning — how SailPoint talks to Active Directory, Workday, SAP and SaaS apps, and how a request becomes an actual account change in the target system.