Access reviews and separation of duties

What changed

Every content update is versioned. Select a version to compare it with the one before.

Version 5 → 6

Update

Rewritten against the product documentation. These features belong to Monosign, so the course moved there. Automatic revocation, framework reports and the old enforcement names were removed, and manual remediation and the known gaps in separation of duties are taught instead.

1 lesson updated

Content update. Enrolled learners were notified.

**Separation of duties (SoD)** stops one person from holding a combination of rights that lets them commit and hide a mistake or fraud, such as creating a vendor and approving its payment. ### Where rules live Rules are **triggers**, built at **Workflows → Triggers → Add New** in Monosign. Set **Category** to **Segregation of Duties**, then describe the toxic combination in **Rules** with conditions such as `User.Permission`, `User.Role` or `User.Group`, and limit when it applies under **Scope**. The older **Security → Segregation of D.** screen can no longer be reached. ::diagram sar-sod-enforce-detect ### Enforcement and detection are separate The **Decision** enforces the rule at the moment a change is made: - **Allow** runs the actions. - **Block (Veto)** rejects the event. - **Require approval** routes it to an approver, whose queue is the **Approvals** tab of **Triggers**. - **Allow & notify** allows it but notifies and requires a justification. When more than one rule matches, the most restrictive outcome wins. If evaluation throws an error, the result is deny. **Category** selects the rule for the **detective scan**, which looks for people who already hold the combination. Results appear in **Identity → Visibility** as the **SoD violations** KPI and the SoD chip. Setting one does not set the other, so configure both. > Tip: Access package approvals do not pass through SoD triggers, so a Block (Veto) rule does not stop a combination granted by an access package. Cover access packages in your SoD design too: review what each package grants, and use the detective scan to check holders. The scan covers at most 3,000 holders per trigger. ### What to do about it - The scan runs each time the Identity Visibility graph is rebuilt. Check its results regularly, and split the trigger scope when a rule has thousands of holders. - Review access package definitions by hand for toxic combinations. - When a conflict must stay for business reasons, document a compensating control, such as a supervisor reviewing the activity. > Tip: Start with a handful of combinations your auditors already ask about, not a large matrix nobody maintains.