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) 
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 
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).
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.
Internal
Customer Success Management (CSM): Please inform your customers about SOD Violation Management.
Support Professional Services (PS): Familiarize yourself with the new APIs and workflow event triggers to be ready to meet customers unique requirements.
Solution Engineering (SE): Make sure you have a beta demo tenant with SOD Violation Management. Familiarize yourself with the SOD user levels, UI, and SOD triggers.
NOTE: If your demo beta tenant does not have the “Controls” UI you have two options.
(1) Request a new tenant, the automation will include SOD
(2) Open a ticket with Demo Engineering to add the SOD_Violation_Management flag to the tenant. Login - The Dock
Additional suggested actions to prepare your customers to best adopt SOD Violation Management:
- Right size your compliance users with the appropriate SOD user level.
-
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.
-
Assign additional owners to existing policy to avoid orphaned policy. Assign at least one violation owner to the policy to review policy violations.
- Implement the appropriate Level for each SOD policy. NOTE: Migrated SOD Policy will default to High.
- Implement SOD workflow event triggers. Violation Reopen trigger will help catch recurring open violations.
Important Dates
Staging: Jun 15, 2026
Production: Jun 29, 2026 - Jul 9, 2026