Best Practices for Automating SoD Lists Maintenance in SailPoint ISC (v2025 APIs) — Seeking Ideas and Insights

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi everyone, hope you’re doing great and wishing you all a productive week!

We are currently working on an initiative to automate the maintenance of SoD policies in ISC, leveraging the new v2025 API framework.
I would love to share our approach and challenges here, and seek your input or any best practices you might have.

What We Have Done

We developed a Java-based automation that:

  • Authenticates using OAuth2.0 Client Credentials.
  • Fetches all entitlements (GET /v2025/entitlements) — including parsing custom classifications like Test SoD Classification inside accessModelMetadata.
  • Fetches all existing SoD policies (GET /v2025/sod-policies).
  • Dynamically updates the leftCriteria and rightCriteria based on the SoD classification mappings.
  • Retains the original policyQuery and metadata to avoid impacting existing workflows.
  • Updates policies using PUT /v2025/sod-policies/{id}.

Challenges and Open Questions

1. Entitlements API is Experimental

  • We noticed that GET /v2025/entitlements is still experimental, requiring the X-SailPoint-Experimental: true header.
  • Question: Is there any roadmap or stability assurance for this API? Should we plan periodic validation against future SailPoint releases?

2. Platform Limits: 500 Policies and 50 Entitlements per List

  • ISC limits us to 500 SoD policies maximum and 50 entitlements per access list (left or right).
  • Our current idea:
    • If a list exceeds 50 entitlements, split the policy into multiple sub-policies with suffixes like Policy Name - Part 1, Policy Name - Part 2, etc.
    • However, this won’t fully solve the issue if both sides exceed 50 entitlements.
  • Question: Has anyone implemented a better approach to handle scenarios where both sides exceed 50 entitlements?
    Is there any recommended design pattern for scaling SoD rules under these platform constraints?

3. Policy Violation Resets on Update

  • When a policy is updated, all existing violations are cleared, and new violations are only generated in the next run.
  • To mitigate this, we are planning to:
    • Export and archive violation reports before every policy update.
    • Apply versioning and change tagging in the policy metadata.
  • Open questions we have:
    • What is the exact technical reason behind this violation reset behavior in ISC?
      Is it tied to how the access graph or violation engine treats policy IDs internally?
    • Are there any best practices to avoid loss of important violation history after updating a policy?

Conclusion

I would greatly appreciate it if anyone could share:

  • Any ideas to improve the SoD automation process?
  • How you are handling the 50-entitlements-per-list limitation?
  • How to manage or reduce the impact of policy violation resets?

Thank you so much in advance for your valuable insights!

Regards,
Muhammad

2

Regarding the platform SOD limits, reach out to your CSM to request an increase. We have been able to increase both the total number of policies and the total entitlements in each access list in the past.

1 Like
3

Thank you so much, @nsorlien, really appreciate your input!

Do you happen to recall what limits were approved in your case? Specifically, the maximum number of SoD policies and the entitlements allowed per list?
It would be really helpful to know what ceiling SailPoint has supported in practice.

Over and over again thanks for sharing your experience :slight_smile: !

4

We were able to get the limits increased to 1200 total policies and 400 entitlements per list, but I’m not sure how close that is to SailPoint’s absolute maximum. We requested increases that allowed some growth beyond what was already in place in the previous identity governance system being replaced by ISC.

1 Like
5

Thank you so much @nsorlien this is really helpful and appreciated!

1 Like