SoD Overview
Early AccessSegregation 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.
Set A and Set B
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 |