---
updatedAt: 2026-08-27T14:43:29.000Z
agentTools:
projectIndex: https://help.zluri.com/llms.txt
---
# SoD Overview
### **Early Access**
Segregation of Duties is currently available to a limited set of customers. Contact your Zluri account team to request access.
**Segregation of Duties (SoD)** detects identities that simultaneously hold conflicting entitlements across your SaaS stack and remediates violations through automated Playbooks, all from a single policy engine inside Zluri.
SoD policies live in the **SoD** section of the **IGA** product. Owner, Admin, and IT Admin roles can author and publish SoD policies. The Internal Auditor role has read-only access for evidence export.
## What this feature enables
The table below summarizes the capabilities available in Segregation of Duties.
| Capability | Description |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Two-list rule authoring | Define conflicting entitlements as Set A and Set B. Zluri raises a violation when an identity holds entitlements from both sets simultaneously. |
| Dual-input rule building | Add specific entitlements from a searchable picker, or define criteria-based patterns that auto-adapt as entitlements change in the source app. Both modes can coexist in the same rule set. |
| Cross-application detection | A single policy can span multiple applications. Zluri raises a consolidated violation when an identity holds Set A entitlements in one app and Set B entitlements in another. |
| Identity-centric violations | Zluri raises violations against identities, not accounts. One identity with conflicting access across multiple accounts produces one violation. Zluri surfaces all offending accounts as context. |
| Monitor and Enforce modes | Start in Monitor mode to detect and log violations only. Promote to Enforce mode to trigger automated remediation via Playbooks or route decision tasks to an assignee. |
| Per-set Playbooks | Each side of the conflict has its own Playbook. When an assignee or the system selects which set to revoke, Zluri runs the corresponding Playbook. |
| Time-bound exemptions | Grant exemptions with a maximum duration. Zluri automatically re-opens the violation when the exemption expires. |
| Dual-mode simulation | Quick Validation checks a single identity in seconds. Full Simulate runs across the entire matched scope in the background with CSV export. Neither mode writes to the live violation store. |
| Scheduled triggers | Run SoD detection on a recurring schedule using interval-based or cron-based triggers. |
| Audit trail | Zluri versions every policy edit, publish, exemption grant, and violation state change with author, timestamp, and Publish Note. |
## Key concepts
### Entitlements
An entitlement is anything that grants an identity the ability to perform an action on a resource. Zluri recognizes three entitlement types:
* **Roles**: a named role assigned to a user on an application (for example, “Accounts Payable Manager” in SAP).
* **Permissions**: a specific permission granted to a user (for example, “Approve Invoice” in NetSuite).
* **Group memberships**: membership in a group that grants downstream access (for example, the “Payroll Managers” group in Okta).
### Toxic combinations
A toxic combination is a pair of entitlements that, when held by the same identity, create an unacceptable risk. For example, an identity that can both create a purchase order and approve that same purchase order holds a toxic combination. SoD policies detect these combinations.
### Rule Sets
Every SoD policy defines exactly two rule sets. Set A contains entitlements on one side of the conflict; Set B contains entitlements on the other side. Zluri raises a violation when an identity holds at least one entitlement from Set A and at least one entitlement from Set B at the same time.
### Monitor and Enforce modes
Two enforcement modes control what Zluri does when it detects a violation.
* **Monitor**: Zluri detects violations, logs them, and sends email and in-app notifications to the policy owner on scan completion. Zluri does not run automated remediation.
* **Enforce**: Zluri detects violations and acts on them. Two enforcement shapes apply: the assignee decides which set to revoke, or the system automatically revokes a pre-selected default set via a Playbook.
Zluri automatically back-tests existing violations when you promote a policy from Monitor to Enforce.
### Inclusion and exclusion
Each rule set has an **Inclusion** section (entitlements that count toward a match) and an optional **Exclusion** section (entitlements that override inclusion and remove specific items from the match). If you add no exclusions, Zluri displays “No exclusions configured” in the rule set summary.
## Permissions and access control
The following table lists the roles that can interact with SoD policies.
| Role | Access | Notes |
| ---------------- | --------------------- | -------------------------------------------------------------------------------------------------------------- |
| Owner | Full access | Can author, publish, edit, and delete SoD policies. Can view violations and act on them. |
| Admin | Full access | Same as Owner. |
| IT Admin | Full access | Same as Owner. Primary role for SoD policy authoring. |
| App Owner | Violation action only | Receives decision tasks in Enforce mode (Assignee decides). Cannot author or edit policies. |
| Internal Auditor | Read-only | Can view policies, violations, and version history. Can export CSV for audit evidence. Cannot edit or publish. |
| All other roles | No access | Cannot view or configure SoD policies. |
## Limits
The following limits apply to SoD policies.
| Item | Limit | Notes |
| ---------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------- |
| Rule sets per policy | 2 | Hard cap: one Set A and one Set B. |
| Trigger types | Scheduled only | Interval and Cron triggers are configurable. Event-based triggers show a **Coming soon** label in the trigger picker. |
| Publish Note character limit | 512 characters | Required on every publish. |
| Description character limit | 512 characters | Optional field on Step 1. |
## Constraints
The following constraints apply to the current release of SoD.
* SoD policies are available in the **IGA** product only. They do not appear in the SaaS Management product.
* Simulation results are temporary. Running a new simulation replaces the previous results.
* Exemptions require a duration. You cannot create indefinite exemptions.
* The **Allow Exemptions** toggle is off by default. Exemptions are unavailable on a policy unless you turn this on in the Remediation step.
## Where SoD data appears
The following table lists the surfaces where SoD policy data and violations appear.
| Surface | What appears |
| ------------------- | ---------------------------------------------------------------------------------------------------- |
| SoD section (IGA) | Policy Library, policy detail, violations list, exemptions list, policy runs, and version history |
| In-app task queue | Decision tasks for Assignee decides violations in Enforce mode, visible to the configured assignee |
| Email notifications | Scan completion notifications to the policy owner on each detection run |
| Audit log | Policy creates, edits, publishes, violation state changes, exemption grants, and Playbook executions |
| CSV export | Violation records and simulation results |