# SoD configuration

**Segregation of Duties (SoD)** is a security and compliance concept that ensures **no single user has conflicting access rights that could lead to fraud, errors, or abuse**. It separates critical tasks between different people so one person cannot fully control a sensitive process from start to finish.

There are four areas of the SoD admin UI:

1. **SoD Policy** — define what combinations of entitlements are considered a conflict
2. **Mitigation Controls** — compensating controls that acknowledge an accepted risk
3. **Violations** — find and resolve users in violation
4. **Reports** — generate exportable violation reports

***

## Configure a policy

To create a new SoD policy, go to **Webconsole** → **Access Control** → **Segregation of Duties** → **Policies**. The page lists all policies with these columns.

| Column          | Description                                 |
| --------------- | ------------------------------------------- |
| **Name**        | Policy name (click to open)                 |
| **Description** | Truncated description (hover for full text) |
| **Severity**    | `SOFT` or `HARD`                            |
| **Status**      | Active / Inactive                           |

Use the search bar to filter policies by name. Click **+ New Policy** to create one.

### Create or edit a policy

The policy editor has two tabs: **General** and **Segments**.

#### General tab

| Field                   | Required    | Description                                                                                                                    |
| ----------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Name**                | Yes         | Unique, human-readable policy name                                                                                             |
| **Severity**            | Yes         | `HARD` — violation must be resolved; `SOFT` — violation can be exempted                                                        |
| **Policy Threshold**    | Yes (min 1) | Number of segments that must each be independently breached to constitute a violation. Typically `2` for a two-segment policy. |
| **Risk**                | No          | Metadata type tag categorizing the risk level (lookup from the risk catalog)                                                   |
| **Manager Group**       | No          | Group responsible for reviewing and handling this policy's violations                                                          |
| **Description**         | No          | Free-text description (up to 1024 characters)                                                                                  |
| **Mitigating Controls** | No          | One or more mitigation controls associated with this policy (multi-select)                                                     |
| **Active**              | No          | Uncheck to disable the policy without deleting it                                                                              |

{% hint style="info" %}
**Policy Threshold tip:** For a standard two-segment "separation" rule set the threshold to `2`. Setting it to `1` means that holding entitlements from any single segment alone triggers a violation.
{% endhint %}

#### Segments tab

Each segment represents one "bucket" of conflicting entitlements. A policy needs at least two segments to be meaningful.

Click **+ Add Segment** to add a new segment card. Each card contains:

**Segment fields**

| Field             | Required    | Description                                                                                                              |
| ----------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Name**          | Yes         | Segment label (e.g., `Create PO`, `Approve PO`)                                                                          |
| **Threshold**     | Yes (min 1) | Minimum number of entitlements from this segment the user must hold for the segment to count as breached. Typically `1`. |
| **Description**   | No          | Free-text description                                                                                                    |
| **Manager Group** | No          | Override the policy-level manager group for this specific segment                                                        |
| **Active**        | No          | Disable this segment independently of the policy                                                                         |

**Segment entitlements**

Each segment can include entitlements from any combination of these four categories. Click **Manage** in each section to open the selection dialog.

| Category          | What it adds                        |
| ----------------- | ----------------------------------- |
| **Roles**         | IAM roles                           |
| **Groups**        | User groups                         |
| **Resources**     | Application resources / permissions |
| **Organizations** | Organizational units                |

{% hint style="info" %}
A warning icon appears on a segment card if the segment threshold is set higher than the number of entitlements assigned to it — meaning the segment can never be breached.
{% endhint %}

### Save

Click **Save** on the top-level policy editor. Segments are saved together with the policy in a single operation.

On successful save, the system:

{% stepper %}
{% step %}

### Persist policy and segments

Persists the policy and its segments to the database (`SOD_POLICY`, `SOD_POLICY_SEGMENT` and related junction tables).
{% endstep %}

{% step %}

### Refresh cache

Refreshes the Redis policy cache.
{% endstep %}

{% step %}

### Re-evaluate users

Triggers a background job to re-evaluate all users against the updated policy.
{% endstep %}
{% endstepper %}

This action generates `CREATE_SOD_POLICY` or `UPDATE_SOD_POLICY` audit events.


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs-beta.openiam.com/segregation-of-duties/sod-configuration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.