FOUNDING ACCESS First 3 months free — use it in production and tell us what to fix. Claim it →
Back to Policies
Policies Important

Separation of Duties: policy examples and toxic pairs

0 views

title: Separation of Duties: policy examples and toxic pairs category: Policies tags: separation of duties, sod, toxic pairs, sox, policy priority: High

Separation of Duties: policy examples and toxic pairs

Separation of Duties (SoD) is the control that stops one person from holding two pieces of access that, combined, let them commit and conceal fraud or error. Certification Center ships an editable, SOX-oriented rule set that detects these toxic pairs across your connected directories and routes every conflict into the certification queue for a person to resolve. This article gives you concrete examples to model your own rules on.

What a toxic pair is

A toxic pair is two capabilities that are each fine on their own but dangerous together. The classic example: a person who can create a vendor and also approve a payment could invent a fake vendor and pay it. SoD rules name those pairs so the combination is flagged wherever it appears.

Each rule is defined as: if an identity holds access matching side A and access matching side B, raise a conflict.

Example toxic pairs

Use these as starting points, then adapt the group, role, or entitlement names to match your environment.

Toxic pair Side A Side B Why it matters
Create + pay a vendor Create or edit vendor master data Approve or release payments Enables fake-vendor fraud
Request + approve access Raise an access request Approve access requests Self-granted privilege
Create + approve a purchase order Create purchase orders Approve purchase orders Unchecked spending
Enter + reconcile transactions Post journal entries Reconcile the ledger Hides posting errors or fraud
Payroll edit + payroll approve Change pay rates or bank details Approve the payroll run Diverted or inflated pay
Develop + deploy to production Commit or change application code Release changes to production Unreviewed code reaches prod
User admin + audit log admin Manage user accounts and rights Manage or delete audit logs Actions can be taken and then erased
Grant privileged role + review privileged access Assign admin or privileged roles Certify who holds privileged access Reviewer approves their own grants

How the editable rule set works

The rule set is yours to shape. You are not locked into a fixed list.

You can How it helps
Edit the built-in SOX-oriented rules Start from a sensible baseline instead of a blank page
Add your own toxic pairs Encode rules specific to your ERP, finance, or engineering processes
Map each side to real access Point side A and side B at the actual groups, roles, or entitlements in your directories
Set severity Rank which conflicts demand attention first
Record exceptions with justification Accept a genuinely required combination without silencing the rule everywhere

Where conflicts go

When a rule matches, Certification Center raises a conflict and flows it into the certification queue. That means the same reviewers who run your access reviews see and act on SoD conflicts in one place, rather than in a separate silo. A reviewer resolves the conflict by revoking one side of the pair, or by recording a justified exception when both sides are legitimately needed (for example a small team where full separation is not possible and a compensating control applies).

For the step-by-step resolution flow, see Resolve a Separation of Duties conflict.

Designing good rules

Practice Why
Start from the SOX baseline The financial toxic pairs above cover the most common audit findings
Be specific on each side Precisely mapped access means fewer false positives
Set severity honestly Not every pair is critical; reserve top severity for financial and privileged-access conflicts
Require a justification for exceptions Auditors will ask why a conflict was accepted
Re-check after reorganizations Role changes create new conflicts; a fresh access review catches them

Next steps

Was this article helpful?

Related articles

Creating Policies
Policies Overview
Lifecycle Management