New Capability: Roles Criteria in SoD Policy Definition

[Colin (Colin Lyth)]

New Capability

Roles Criteria in SoD Policy Definition

Aha! Ideas Portal

This Capability is brought to you by Aha! Idea GOV-I-2557

Description

Identity Security Cloud now supports defining Separation of Duty (SoD) policy criteria with SailPoint Roles, Access Profiles, and Entitlements. Policy owners can align SoD definitions with their access model — including mixed Role, Access Profile, and entitlement criteria in List A and List B — instead of maintaining entitlement-only criteria.

Existing conflict detection, access-request approval visibility, and violation management workflows are preserved.

Problem

Defining and maintaining entitlement-only SoD criteria creates ongoing burden between compliance and access teams. Policies must keep pace with changing entitlements, non-intuitive entitlement names, and new entitlements from newly onboarded application sources.

Solution

You can now:

• Include SailPoint Roles in SoD List A and List B policy criteria
• Include Access Profiles and entitlements in policy criteria
• Define mixed criteria across lists (e.g., entitlements in List A and a Role in List B)
• Continue using existing conflict detection, approval, and violation management for policies with Role criteria

Configure criteria in Admin → Policies → Separation of Duty.

Who is affected?

This capability is available to:

• IdentityNow customers (non-suites) who own SoD
• All SailPoint Human Fabric (previously known as Identity Security Cloud) customers

SoD policy owners, compliance teams, access approvers, and violation owners benefit from access-model-aligned criteria and reduced entitlement-level maintenance.

Action required

Review existing entitlement-only SoD policies and consider migrating criteria to SailPoint Roles or Access Profiles where that better reflects your access model. No configuration is required to preserve existing entitlement-based policies — they continue to work as before.

New or updated policies can include Role, Access Profile, and entitlement criteria in Admin → Policies → Separation of Duty.

Important dates

Region / milestone	Date
Staging	Week of Aug 17
Production	Week of Sept 7

[angelo_mekenkamp]

Hi @Colin,

Suppose we have identities X and Y that both have entitlements A and B and both don’t have entitlement C

I now create role R that points to A and B, and only request this role for identity X (with end date next year).

I now define an SOD policy with role R in the left bucket and entitlement C in the right bucket.

I now request entitlement C for identities X and Y. Will the SOD policy trigger for both identities, because they both have all the access belonging to role R, or will it only trigger for identity X, because this identity is the only identity with the role R?

Now same question but replace the role in the question by an access profile?

[sushantkulkarni]

Unlike APs, requestable Roles are not “detected”, right? (I’m not super sure)
In your scenario if it was AP, @angelo_mekenkamp the user Y would get it automatically on next refresh.

Worth confirming this, @Colin. Does the SoD engine resolve all abstract access models down to the entitlement level? Because in that case, the scenario described by @angelo_mekenkamp should still be flagged as SoD violation.

[KRM7 (Krishna Mummadi)]

Much awaiting update, Thank you.

How about requesting conflicting accesses in a single request ? does the violation thrown or ignored >

Can we get options to control the access request if there is a violation, instead of relying on approver always ?