Most engineers think…
Most people picture SailPoint as 'a tool that provisions accounts'. That framing misses the governance half that auditors actually care about.
SailPoint IGA is a lifecycle plus policy engine: it manages the full journey from access request through approval, provisioning and ongoing certification — and it enforces Separation of Duties (SoD) rules at every stage. Understanding the request-to-provision path, and how SoD violations are caught both before and after access is granted, is what differentiates an IGA practitioner from someone who just runs joiner-mover-leaver scripts.
① The access-request lifecycle — submission to provisioning
An access request in SailPoint IGA begins when an identity (or their manager) opens the access-request portal and picks one or more roles or access profiles to request. The platform checks whether the requester is within scope of the governance policy, then routes the request into an approval workflow. Once all approvers have acted, SailPoint automatically provisions the access to the connected source — no manual tickets needed.
The request object in SailPoint carries the requester, the requested items, a comment field for business justification, an optional deadline, and a status that advances through Requested → In Review → Approved/Rejected → Provisioning → Completed. At the Approved step, SoD policy is evaluated: if a conflict is found, the reviewer sees a violation warning before confirming. Admins can configure whether a violation is a hard block or an overridable warning.
At which step in the SailPoint access-request lifecycle is the SoD policy evaluated?
② Approval workflows — single, multi-level and owner-based
SailPoint lets you configure approval schemes on each role or access profile independently. The simplest is owner approval: the person listed as role owner or access profile owner receives the request and approves or rejects it. For sensitive roles you can chain approvers — for example, direct manager first, then a governance team second — which SailPoint calls a sequential multi-level approval. You can also configure parallel approval where all approvers must act within a time window.
Approval configuration levers you must know
Key settings include: approval scheme (none, manager, owner, governance group), fallback approver (for absent managers), auto-approval for low-risk entitlements, expiration (how long a pending request waits before it times out), and escalation path (who takes over if the primary approver is inactive). Every approve or reject action is time-stamped in the audit log — this is what satisfies SOX and SOC 2 reviewers.
A formal ask for a role or access profile. Carries requester, items, justification, status and audit timestamps. Routes through the configured approval scheme before provisioning.
The configured chain of approvers on a role or access profile — owner, manager, governance group, or none. Can be sequential (all in order) or parallel (all simultaneously).
Two conflicting access lists (List A and List B). An identity holding access from both lists simultaneously triggers a policy violation with a risk weight and remediation path.
Fired when an identity holds (or would hold) access that conflicts with an SoD policy. Resolved by revoking the conflicting access, granting a time-limited exception, or noting a compensating control.
In an interview, separate the approval scheme (owner / manager / governance group) from the escalation path (what happens if they don't act) and the fallback approver (who steps in when the primary is absent). Knowing all three shows you have operated the workflow, not just read about it.
What is a 'fallback approver' in a SailPoint approval workflow?
③ SoD policies — defining conflicting-access rules
A Separation of Duties policy in SailPoint is built from two access lists. List A contains one set of roles or entitlements; List B contains a conflicting set. If an identity holds access from both lists simultaneously, a policy violation is raised. Classic examples: the ability to create a purchase order should conflict with the ability to approve a purchase order; or create a vendor should conflict with pay a vendor.
Policies are created in the Policy module of SailPoint Identity Security Cloud (formerly IdentityNow). Each policy has a name, description, risk weight (used to score the severity of violations), and an optional compensating control note. You can scope a policy to specific populations using filters, so a finance-only conflict rule does not fire against engineering identities. Policies can be set to active (enforced) or inactive (monitored but not blocking).
SoD without a risk weight and without a documented exception process is nearly worthless in an audit. Auditors want to see that violations carry a severity score, that exceptions are time-limited with justifications, and that compensating controls are noted. SailPoint supports all of this — make sure you configure it, not just create the policy.
▶ Watch an SoD violation caught at the approval step
How a single access request hits a conflict and is blocked — step by step. Press Play for the healthy catch, then Break it to see what happens when preventive SoD is off.
A finance analyst already has the 'Create Vendor' entitlement. She requests 'Pay Vendor'. What happens if an SoD policy covers those two?
④ Violations & remediation — preventive vs detective controls
SailPoint SoD operates in two modes. Preventive (proactive) mode checks a new access request against existing access before provisioning: if the combination would violate a policy, the approver is warned — or the request is hard-blocked, depending on configuration. This stops violations from entering the environment. Detective (reactive) mode runs scheduled policy scans across all identities and flags any that already hold conflicting access — these appear as violations in the Policy Violations dashboard.
Remediation paths
Each violation can be resolved in one of three ways: (1) Revoke the conflicting entitlement — the cleanest fix, SailPoint handles deprovisioning automatically; (2) Exception — a documented business justification with an expiry date, after which SailPoint re-raises the violation; (3) Compensating control — a note that a mitigating control (e.g. a monthly reconciliation or supervisor review) covers the risk. All three outcomes are recorded in the immutable audit trail, which auditors inspect during SOX or ISO 27001 reviews.
Priya at a Mumbai fintech faces this
During a SOX audit, the auditors flag that three finance team members can both create and approve purchase orders in the ERP — a classic SoD violation that was never caught.
The SoD policy existed in SailPoint but was set to inactive, so no violation scans ran and no preventive checks fired during access requests.
Open Policy module → check policy status: the PO-Create vs PO-Approve policy is marked inactive. Run an ad-hoc policy scan to see how many identities are in violation.
Policy module ▸ Policy status → Inactive; Policy Violations dashboard → 0 results (policy not scanning)Activate the policy, run a full scan, remediate violations by revoking the lower-priority entitlement (or granting a time-limited exception with a documented compensating control), then enable preventive checking on the access-request workflow.
Re-run the policy scan — violations are now raised and being worked. New access requests for PO-Approve warn approvers if the requester already holds PO-Create.
Never close an SoD violation ticket on 'I think it was fixed'. Open the Policy Violations dashboard in SailPoint and confirm the violation status is Remediated. The audit trail entry shows who took the action, when, and which path (revoke / exception / compensating control) — that single read answers most compliance queries without guessing.
An auditor asks how you caught SoD violations that existed before your SoD policy was created. Which control type surfaces those?
🤖 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.
🧠 In your own words
Type one line: why is it risky to rely only on preventive SoD controls and skip detective scans? Then compare with the expert version.
🗣 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
- Access Request
- A formal submission by an identity (or their manager) to be granted a role or access profile, routed through a configured approval workflow before provisioning.
- Approval Scheme
- The configured chain of approvers on a role or access profile — options include role owner, direct manager, or governance group, in sequential or parallel order.
- Separation of Duties (SoD)
- A governance principle preventing one identity from holding two conflicting privileges (e.g. create and approve a payment). Enforced in SailPoint via SoD policies.
- SoD Policy
- A rule in SailPoint comprising List A and List B of entitlements. An identity holding access from both lists simultaneously triggers a policy violation.
- Policy Violation
- A recorded conflict raised when an identity holds (or requests) access that matches both sides of an SoD policy. Carries a risk weight and must be remediated.
- Preventive Control
- An SoD check that evaluates a new access request before provisioning, warning or blocking the approver when a conflict would be created.
- Detective Control
- A scheduled policy scan that evaluates all identities against active SoD policies and flags any that currently hold conflicting access.
- Audit Trail
- SailPoint's tamper-evident, time-stamped log of every access event — requests, approvals, rejections, violations, exceptions and provisioning results — used as compliance evidence.
- Exception
- A time-limited documented override of an SoD violation, with a business justification and expiry date after which SailPoint automatically re-raises the violation.
- Compensating Control
- A note attached to an SoD violation acknowledging a mitigating measure (e.g. supervisor oversight or monthly reconciliation) that reduces but does not remove the risk.
📚 Sources
- SailPoint Documentation — Separation of Duties Overview (Identity Security Cloud). documentation.sailpoint.com/saas/help/sod/index.html
- SailPoint Documentation — Handling Policy Violations. documentation.sailpoint.com/saas/help/sod/policy-violations.html
- SailPoint Documentation — Managing Policies — SoD policy creation, risk weights and population scope. documentation.sailpoint.com/saas/help/sod/manage-policies.html
- SailPoint Documentation — Managing Requests for Roles and Access Profiles — approval schemes and configuration. documentation.sailpoint.com/saas/help/requests/config_ap_roles.html
- SailPoint Community — Separation of Duties best practices in IdentityIQ. community.sailpoint.com/t5/IdentityIQ-Wiki/Separation-of-duties-SoD-best-practices-in-IdentityIQ/ta-p/178004
- SailPoint Developer Community — SoD policy for access requests — discussion. developer.sailpoint.com/discuss/t/separation-of-duties-policy-for-access-request/93995
What's next?
Got access requests and SoD? Next, go deep on access certifications — how SailPoint launches campaigns, how AI recommends revoke vs certify, and how you close a certification loop cleanly.