Segregation of duties (SoD), defined
Updated
Segregation of duties (SoD) is the control principle that no single person should be able to both commit and conceal an error or fraud. Conflicting duties — such as making a change and approving it, or granting access and reviewing it — are assigned to different people.
The classical formulation separates four functions: authorizing a transaction, recording it, holding custody of the related asset, and reconciling the result. In modern systems the same principle applies to roles and permissions — deploy rights, admin rights, approval workflows — which is why SoD today is largely an access-design problem, enforced and evidenced in software.
What segregation of duties means
SoD is a preventive control built on a simple observation: most errors and nearly all concealment require the same person to hold two powers at once — the power to act and the power to sign off on the action. Splitting those powers between people forces collusion, and collusion is rarer, riskier, and easier to detect than a single actor working alone.
In an IT and SOX context, SoD stops being about org charts and becomes about entitlements. A person's real duties are whatever their accounts can do across every in-scope system — so a conflict can exist even when job titles look clean, and an org chart can look conflicted while permissions are actually separated. The system of record for SoD is the permission set, not the job description.
Classic conflicts
Auditors look for a recurring set of conflict patterns. Each row pairs a duty with the duty it must be separated from:
| Duty | Conflicting duty | Why the combination is risky |
|---|---|---|
| Making a change | Approving or deploying that change | The author can move untested or unauthorized code into production with no independent review. |
| Granting access | Reviewing or certifying access | The grantor certifies their own decisions, so inappropriate access is unlikely to ever be flagged. |
| Initiating a payment | Approving that payment | One person can create and approve a fictitious or misdirected disbursement end to end. |
| Administering a system | Reviewing that system's logs | The administrator can act and then curate the record of their own actions. |
| Owning or operating a control | Testing that control | Tester independence fails: people testing their own work systematically under-report exceptions. |
Compensating controls when separation is impractical
Small teams often cannot fully separate duties — a five-person engineering organization may have one person who both writes and deploys code. The standard answer is a compensating control: an independent detective control that would catch what the missing separation can no longer prevent. Common patterns include management review of the complete change population by someone without deploy rights, immutable logging paired with independent log review, and dual approval required on the highest-risk paths even when broader separation is impossible.
A compensating control is only credible under specific conditions: the reviewer must be genuinely independent of the activity, the population reviewed must be demonstrably complete (which is an IPE question), the review must be evidenced at the time it happens, and exceptions must be dispositioned rather than noted. A review that is performed but never documented is, to an auditor, a review that did not happen.
How SoD is evidenced
SoD evidence has three layers: extracts showing who actually holds which entitlements across in-scope systems; the grant history showing who authorized each assignment and when; and the analysis layer — conflicts identified, evaluated, and either remediated or accepted with a compensating control. Periodic access reviews then confirm the picture stays true across the period. The recurring audit failure is not a missing policy but an evidence gap: the conflict rule exists on paper while nobody can produce the entitlement population or the grantor record that proves it operated.
What good looks like is duty assignments tracked with the granting admin on record, conflicts surfaced for disposition rather than discovered at audit, periodic access-review campaigns run on a schedule, and enforced tester independence so nobody evaluates their own control. When evaluating any tool for this, look for entitlement data pulled read-only from the source systems, a complete and traceable population rather than a sample, and a model where a conflict is only closed when a named human accepts the evidence or a documented compensating control. The aim is simple: make the auditor's SoD questions answerable from standing records instead of a quarter-end scramble.
Frequently asked questions
Why is segregation of duties important?
Because it is the structural defense against both error and fraud: a mistake made by one person gets caught by the second, and deliberate concealment requires collusion. Auditors treat SoD as foundational — when it is missing, they assume errors can persist undetected and expand their testing accordingly.
What is a common example of an SoD conflict?
A developer who can approve and deploy their own change to a production financial system. Other classics: an admin who grants access and also certifies the access review, and one person who can both create and approve payments.
What is a compensating control for segregation of duties?
An independent detective control that substitutes for a separation you cannot achieve — for example, someone without deploy rights reviewing the complete list of production changes each period. To hold up in audit, the reviewer must be independent, the population complete, and the review documented at the time.
How do small teams handle segregation of duties?
They separate the highest-risk pairs first (change vs. approval, payment creation vs. release), and cover the rest with compensating controls: independent review of complete activity populations, immutable logs, and dual approval on critical paths. Auditors generally accept well-evidenced compensating controls; what they do not accept is an unmitigated conflict nobody noticed.
How do auditors test segregation of duties?
They pull entitlement populations from in-scope systems and look for the classic conflict pairs, then trace exceptions: who granted the access, was the conflict identified by management first, and is there a documented compensating control. Finding a conflict the company had already found and mitigated is a very different outcome from finding one it did not know about.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.