Segregation of duties is the oldest control in the book: no one person should be able to both initiate and conceal the same wrongdoing. SOX leans on it for financial reporting (it’s the heart of the PCAOB’s ITGC expectations and COSO’s control environment), ISO 27001:2022 names it directly in A.5.3 (Segregation of duties), NIST SP 800-53 codifies it as AC-5 (Separation of Duties), and COBIT, PCI DSS, and GDPR all assume it. The principle is easy to state and miserable to enforce: as people change roles, accumulate group memberships, and cover for each other, someone quietly ends up able to both approve a payment and pay it.
Most teams audit for this once a year by exporting group memberships into a spreadsheet and eyeballing the overlaps. Talarity treats it as a standing control: you declare the conflicting pairs once, and the platform continuously flags every user who holds both.
Who’s involved
- Compliance / SOX lead — defines which pairs of duties are toxic and reviews the violations each cycle.
- IT / identity admin — maps each conflict rule to the two real groups in the org, and remediates by removing a membership.
- Risk owner — decides when a conflict is an accepted exception (with a compensating control) versus a must-fix.
- Auditor — pulls the violation list and the acknowledgement reasons as evidence the control operates.
Step 1 — Start from ten framework-mapped starter rules
Open Segregation of Duties under Governance & Policy. You don’t start from a blank page — Talarity ships ten starter conflict rules drawn straight from the frameworks: authorize and execute the same transaction (SOX), approve and disburse the same payment (SOX), manage user provisioning and approve access requests (NIST CSF / ISO 27001), accept a risk and own the control mitigating it (COBIT), manage MFA enrollment and approve MFA resets (NIST / Identity), and more.
Each starter ships disabled and unmapped, because the conflict is universal but your groups are not. The rule says “these two duties shouldn’t live in one person” — you tell Talarity which two of your groups represent those duties. You can also add your own custom rules for conflicts specific to your business.
Step 2 — Map a rule to two of your groups
Click Map groups on a starter. Pick the two groups in your org that must never be held by the same user. For the SOX “approve and disburse the same payment” rule, that’s your payment-approver group and your disbursement group.
This is the step that turns a framework citation into an enforceable control. The conflict definition is portable; the group mapping is what makes it true for your organization. A rule stays disabled until both groups are mapped — there’s nothing to scan for otherwise.
Step 3 — Enable the rule
Once both groups are mapped, Enable lights up. Turn it on and the rule joins the active set.
Severity is your triage order, not decoration. A user who can both approve and disburse payments (critical/high) is a different conversation than one who can both classify and share data (medium). When you have a dozen active rules and a backlog of violations, severity is how you decide what to fix this week versus this quarter.
Step 4 — Scan, and see who holds both
Switch to the Violations tab and click Run scan now (a scheduled scan also runs daily). Talarity checks every active rule against every user’s group memberships in a single pass and flags anyone who holds both conflicting groups.
Each violation names the user, the rule they tripped, and the exact pair of groups that conflict — so the fix is obvious. Filter by status and severity to work the list down. The detection is membership-based and evaluated together, so it scales to a large directory without turning into a per-user crawl.
Step 5 — Remediate, or accept with a reason
The real fix for a violation is to remove the user from one of the two groups, then re-scan — the conflict clears itself. Sometimes that isn’t possible yet (a small team, a temporary cover), and you accept the risk with a compensating control. Acknowledge records that decision.
Acknowledging is honest by design: it records an accepted exception with your reason and an optional expiry, but the violation stays flagged until the underlying membership is removed. An auditor sees both the conflict and your documented rationale — which is exactly what “the control operates, and exceptions are governed” looks like.
What you walk away with
- Ten framework-mapped starter rules (SOX, NIST, ISO 27001, COBIT, GDPR, TPRM) you map to your groups in minutes — no blank page.
- A standing control, not an annual spreadsheet: a daily scan plus on-demand re-scan flags conflicts as memberships drift.
- Specific, actionable violations — the user, the rule, and the exact two groups in conflict, ordered by severity.
- An honest acknowledgement trail: accepted exceptions with reasons and expiries that never hide the underlying conflict.
Set yours up this afternoon. Open Segregation of Duties, map two or three of the starter rules to your real groups, and run a scan. The first conflict you find is usually one you didn’t know you had.