New Capability: Active SOD Violation Management for Identity Security Cloud

These new capabilities are brought to you by Aha Ideas GOV-I-2118, GOV-I-4084, GOV-I-3935, GOV-I-4009, GOV-I-3665, GOV-I-2406, GOV-I-3863, GOV-I-4524, GOV-I-2751, GOV-I-2869

Background

Understanding Separation of Duty (SOD) :shield:

Organization’s compliance teams utilize Separation of Duty (SOD) policy to adhere to internal and external regulations. An Identity Security Cloud (ISC) SOD policy provides the mechanism to define a risk of non-compliance derived from an identity having access items that could enable the identity to perform conflicting functions or “duties”.

For example, an SOD policy may define entitlement access assignments for write checks and cash check create an SOD conflict (aka toxic combination). An "open violation” on the SOD policy exists when an identity has been assigned both entitlements. The organization could be at risk to fraud, errors, or regulatory fines.

Managing Violations and Risk Mitigation

In some scenarios, a risk may be temporarily unavoidable.

Consider a small branch office where a single employee must perform multiple duties because a colleague is on a 2 week leave. The branch employee not on leave must both write and cash checks. But to do so this employee has an open SOD violation.

A risk owner on the compliance team may define a reasonable mitigation control for open violations. Each region can have an accounting review. This is temporary solution for when employees in small branches take leave. A risk implementer may review the open violation, notice the location and note the risk is mitigated for 2 weeks with SW Regional Accounting leave review.

When the employee returns from leave, the conflicting access is removed, and the violation then closed.

Violation State Description
Open An identity possesses conflicting permissions that breach a defined SOD policy.
Mitigated A violation exists, but a control minimizes the risk for a duration.
Re-opened The control duration was exceeded and the violation is reopened. For example, on the 15th day of a 2 week control if the conflicting access remains the violation is reopened.
Closed The conflict has been remediated, and the identity no longer has the toxic access combination.

Summary of the SOD Process :clipboard:

SOD policies define the specific conditions that trigger a violation. To be effective, these violations must be actively managed and reviewed. In larger organizations, this process involves a clear division of labor:

  • Policy Admins: Policy owners define the SOD policies to align with regulatory requirements.

  • Control Admins: Control owners (aka risk owners) define mitigating controls acceptable for an organization.

  • Violation Owner: Violation owners (aka risk implementers) know the context of an individual’s SOD violation to assign the appropriate control for an individual’s SOD violation.

  • Audit: Auditors review the entire lifecycle to validate that the system adheres to the company’s stated policies and regulatory obligations.


Current Situation

ISC IAM Administrators may view SOD violations by running an SOD policy. When an identity has assigned entitlements from both lists in an SOD policy the identity is included in a downloadable report.

The IAM Admin may schedule SOD reports and assign “subscribers” to the report. ISC will send email notification that includes a SOD violation report preview and links to the downloadable report of identities in violation of SOD policy.

Problems…

The first problem is that ISC does not provide a mechanism to manage violations. All ISC SOD violations are ‘open’. This means open and mitigated SOD violations are indistinguishable in ISC UI and SOD downloadable reports. This also means new violations difficult to identify among the violation a violation owner may have reviewed the day before.

The second problem IAM Admins identify is the permissions required to use ISC SOD. Administering SOD policy requires org admin permissions. And SOD report subscribers must be report admins. Report admins have full ISC search capability - not just SOD data.

This means IAM Admins tell us they cannot scales since ISC does not provide an acceptable way to enable their organization’s compliance team to define and manage SOD policy and SOD violations.

Solutions…

ISC SOD Violation Management includes a new SOD UI for SOD Policy, SOD Controls, and SOD Violations. SOD Violation Management includes user levels to provide the granularity and fidelity compliance teams need to operate without full org admin privileges. ISC Violation Management introduces Controls with expirations. The Violation Management UI enables visibility to open SOD violations. Violation owners may apply a mitigated control to distinguish open and mitigated violations. Additionally, SOD violation owners and SOD Compliance officers may still export the SOD violation for offline reporting.

ISC SOD Violation Management also introduces new SOD APIs, new workflow event triggers (open/closed/mitigated/reopened) to enable customers to customize violation management to their organizational requirements.

Who is affected?

Identity Now customers (non-suites).

NOTE: Violations UI will be available but not the ability to mitigate with a controls. There is no Controls service available to non-suites customers.

Identity Security Cloud customers (suites). Will have Controls.

Action Required

Customers:

Customers must use the new SOD UI for SOD policy creation. Enable and run SOD policy to populate SOD violation service with violations. Customers may now use the SOD UI to review SOD violations.

Additional suggested actions to prepare to best adopt SOD Violation Management:

  1. Right size your compliance users with the appropriate SOD user level.
  1. Create at least one Control. You will want at least one control available to SOD Policy. This will allow violation owner to put an expiration on open violations when they review open violations.

  2. Assign additional owners to existing policy to avoid orphaned policy. Assign at least one violation owner to the policy to review policy violations.

  1. Implement the appropriate Level for each SOD policy. NOTE: Migrated SOD Policy will default to High.
  1. Implement SOD workflow event triggers. Violation Reopen trigger will help catch recurring open violations.

Important Dates

Staging: Week of Jun 15, 2026
Production: Jun 29, 2026 - Jul 9, 2026

2 Likes

You should see Pendo notifications and the feature in sandboxes shortly.

1 Like

Thanks @Colin! This will improve user experience a ton!

Thanks @Colin , really excited to dig into this. Would it be possible to add the new SOD user level details to User Level Permissions - SailPoint Identity Services ?

That would help a lot with clarity around access for each one, and what each stakeholder group in our org would need to get assigned.

Thanks @trettkowski fyi @LukeD our UX star.

@talbota We will get docs updated at GA with our docs star @BeckyJorgensen

fyi Custom user levels are planned for next quarter.

1 Like

Hello,
first of all, we’re happy to see that the SoD topic is finally being addressed. This has been long overdue for a product like ISC.

Unfortunately, the approach for building the SoD policies and checking SoD conflicts, as it is currently implemented, does not meet industry standards. Instead of maintaining two lists where objects are directly excluded from each other, SoD categories should be used, which are assigned to the respective objects. On this basis, the SoD matrix should be maintained in the form of policies. Anything else results in lists of countless objects that are no longer manageable. Furthermore, from an IT perspective, this is clearly the better implementation. Assigning SoD categories can also be applied to other objects like roles and access profiles.

Is it planned to implement this usual standard in ISC, and if so, when?

3 Likes

Hello @kkoch Thank you!
Lets prevent this topic from being lost in the announcement/product news thread.

Can you please private chat me and we can discuss and/or start a new post about job functions/alternate criteria/matrix …?

I agree, this is how we manage this currently via custom automation. The main feature that would fix this is to have a new metadata tag that’s applicable to entitlements, and to expose these metadata tags to SoD Policies. (you could still allow customers to add individual items to SoD policies as this would allow for very simple implementations of SoD policies)

This approach would make it much simpler to manage, and avoid duplicate entries in many different lists.

@Colin Could you please help us point to the detailed documentation for this feature, including details on configuration options as well as explanations of the policy menu and controls menu? At present, the documentation page still links to the older search-based SOD content.

It’s allowing to delete a Control when it is being used with a Policy. That should not be the case, I think. Further, if the control doesn’t exist, and we edit and update the Policy, it throws an error that Control doesn’t find. So, control deletion should not be allowed if it is being used by any Policy.

1 Like

HI @Arshad the docs should go out Friday. fyi @BeckyJorgensen

1 Like

Hi @Colin ,

I just saw this. I really like this enhancement, it looks great and I’m really excited for the new features. Are there any plans to enhance the treatment of General policies as well? I know they often get lumped in with SOD policies, and this enhancement kind of differentiates them which I’m happy about

Thank you for posting @AjayPrincipal. It looks like you can view the policy but not edit as you point out.

Yeh basically saved searches @pillar224. No immediate plans. We will monitor interest. General Policy seem to be frequently used for data quality, but open ideas. We are looking at including identity attributes in SOD.

Hi @Colin

Thank you for this great feature. Does this push to prod tenants? We are waiting for it.