> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/governance/sod.md).

# Segregation of duties

Segregation of duties in OpenIAM — policies, segments, rule sets, mitigating controls and exemptions, with the tables behind them and where detected violations actually live.

**Segregation of duties** (**SoD**), also called separation of duties, is toxic-combination detection: the rule that one person should not hold two particular capabilities at once — raise a purchase order *and* approve it, create a vendor *and* pay one. OpenIAM expresses those rules as policies, detects who violates them, and gives you exemptions and mitigating controls for the cases that are accepted rather than fixed.

It is independent of [access certification](/administration-guide/governance/certification.md). The two meet in one place: a reviewer sees the SoD violations attached to a review item, and an open violation blocks that item's decision until it is resolved.

## Choose your outcome

| I want to…                                                                                            | Go to                                                                                                                                                 |
| ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Understand SoD policies, segments, rule sets, exemptions and mitigating controls                      | [SoD policies and rule sets](/administration-guide/governance/sod/sod-policies-and-rule-sets.md)                                                      |
| Find out what a change would do before it does it — what-if, dry run, impact analysis                 | [What you can simulate before you commit](/administration-guide/governance/sod/sod-policies-and-rule-sets.md#what-you-can-simulate-before-you-commit) |
| Build an SoD policy by hand, including a conflict that spans two applications                         | [Create an SoD policy](/administration-guide/governance/sod/sod-policies-and-rule-sets/create-an-sod-policy.md)                                       |
| Turn a shipped or imported rule set into live policies through Shadow and Enforced                    | [Activate an SoD rule set](/administration-guide/governance/sod/sod-policies-and-rule-sets/activate-an-sod-rule-set.md)                               |
| Schedule SoD detection across the population and send the violation digest                            | [SoD detection and violations](/administration-guide/governance/sod/sod-detection-and-violations.md)                                                  |
| Triage a violation, remediate it at its source, exempt or mitigate it, and produce the audit evidence | [Work an SoD violation to closure](/administration-guide/governance/sod/sod-triage-remediation-and-evidence.md)                                       |
| Analyse SAP roles and derive SoD rules from them                                                      | [SAP role and SoD analysis](/administration-guide/governance/sod/sap-sod-analysis.md)                                                                 |
| Look up an SoD enum, the rule JSON schema, the shipped catalogues or a violation-report field         | [SoD rule and policy reference](/administration-guide/reference/sod-rules-and-rule-sets.md)                                                           |

## The object model

| Concept                   | Table                                                                   | Notes                                                                                                                                                                                                                                                 |
| ------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Policy                    | `SOD_POLICY`                                                            | `SEVERITY` is `SOFT` or `HARD`; `POLICY_THRESHOLD` is how many segments a user must hit to violate; `EXCEPTIONS_ALLOWED` gates exemptions; `SOD_RULE_SET_ID` and `RULE_KEY` are set when the policy came from a rule set rather than being hand-built |
| Segment                   | `SOD_POLICY_SEGMENT` plus `SOD_SEGMENT_ROLE` / `_GRP` / `_RES` / `_ORG` | The conflicting duty sets; a segment has its own `SEGMENT_THRESHOLD` and manager group                                                                                                                                                                |
| Policy-level entitlements | `SOD_POLICY_ROLE` / `_GRP` / `_RES` / `_ORG`                            | Entitlements attached directly to the policy                                                                                                                                                                                                          |
| Rule set                  | `SOD_RULE_SET`                                                          | Catalogue content. `SOURCE` records where the rule set came from; `STATUS` is `INACTIVE`, `SHADOW` or `ENFORCED`. `SHADOW` detects without blocking, which is how you pilot a rule set                                                                |
| Mitigating control        | `SOD_MITIGATING_CONTROL`, linked by `SOD_POLICY_MC`                     | A compensating control with a named manager and owner — each identified as a `USER` or a `GROUP` — a review frequency, and effective/expiration dates                                                                                                 |
| Exemption                 | `SOD_EXEMPTION`                                                         | Per user, per policy, per entitlement (`ENTITLEMENT_TYPE`, `ENTITLEMENT_ID`), with `CREATED_BY` and `COMMENT_TEXT`. Only possible when the policy sets `EXCEPTIONS_ALLOWED`                                                                           |
| Digest state              | `SOD_DIGEST_STATE`                                                      | A single row holding the recipient config and the previous run's violation snapshot, which is the diff baseline for "new" and "resolved"                                                                                                              |

All of these live in the `openiam` schema — unlike certification, which has a database of its own.

Detected violations per user are served from the OpenSearch index `user-violated-sod-policy`, not from a relational table — so a violation query that returns nothing when you expect rows is a reindex question before it is a policy question. See [Search indexes and the authorization graph](/administration-guide/reference/search-indexes.md).

{% hint style="info" %}
**The SoD violation digest is not scheduled out of the box.** The bean that sends it, `sodViolationDigestInitializer`, is present, but no `BATCH_CONFIG` row ships for it, so nothing runs it until a task exists. Confirm this on your own system: open **Administration → Batch Tasks** and search for a row whose Spring bean is `sodViolationDigestInitializer`. On a default installation there is none, and no digest mail has ever been sent. Contrast `RISK_NIGHTLY_SWEEP`, which does ship a row and appears in that same list. [SoD detection and violations](/administration-guide/governance/sod/sod-detection-and-violations.md) covers how the task gets created.
{% endhint %}

## Where SoD meets certification

One table joins the two subsystems: `ACCESS_REVIEW_ITEM_SOD_VIOLATION`, which attaches a violation to a review item so the reviewer sees the conflict at the moment of decision. It carries the policy id and name, the severity, the conflicting entitlement, both thresholds, and whether the violation is direct.

The effect on the reviewer is not advisory. Rows for a user with an open violation are blocked — *"This user's access cannot be approved or revoked until all SoD violations are resolved"* — and the reviewer must resolve or skip the policy before submitting. See [What your reviewers see](/administration-guide/governance/certification/the-reviewer-experience.md).

## Related

* [Access certification](/administration-guide/governance/certification.md) — the other governance subsystem
* [SoD rule and policy reference](/administration-guide/reference/sod-rules-and-rule-sets.md) — enums, the rule JSON schema, the shipped catalogues
* [Designing a segregation-of-duties programme](/solution-architecture/governance/sod-programme.md) — SoD as a design decision

*Applies to OpenIAM 2026.9.1. Last reviewed 14 September 2026.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/administration-guide/governance/sod.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.