Segregation of duties (SoD) is a control principle that splits a sensitive task across two or more people so that no single individual can both commit and conceal an error or fraud. By dividing authorization, execution, custody and reconciliation, SoD removes the concentration of power that makes wrongdoing easy to hide.
Why segregation of duties matters
The logic is simple: when one person controls an entire sensitive process end to end, they can create a fraudulent transaction and then hide it in the same records they are trusted to maintain. Splitting the process forces collusion for fraud to succeed, which is far harder to arrange and far easier to detect. SoD also catches honest mistakes, because a second set of hands reviews work before it becomes final.
The ACFE 2024 Report to the Nations found that a lack of internal controls was a contributing weakness in nearly one third of occupational fraud cases, with a median loss of 145,000 US dollars per case and a median detection time of about twelve months (ACFE, Report to the Nations, 2024).
The classic conflicting-duty combinations
Most SoD frameworks separate four core functions that should never sit with one person: authorization, custody of assets, record-keeping, and reconciliation. When any two of these combine in one role, a control conflict exists. The examples below are the combinations auditors flag most often.
- Authorizing a transaction and recording it in the general ledger
- Receiving cash or checks and approving write-offs of receivables
- Reconciling bank statements and booking the entries being reconciled
- Authorizing payments to vendors and controlling the vendor master file
- Creating a new vendor and approving invoices for that same vendor
A useful test in cash handling is to split the process into receiving, depositing, recording and reconciling, and to check that different people own each stage. If one person spans two or more stages, you have a conflict to remediate or compensate for.
SoD in finance versus IT and access management
In finance, SoD conflicts are about money moving and being recorded. In IT and identity, the same principle applies to privileges. A developer who can also deploy to production, or an administrator who can grant themselves access and then clear the logs, holds the digital equivalent of authorizing and concealing a transaction. This is why SoD is central to identity and access management and to periodic access reviews, topics we cover in our guide to identity and access management.
Access reviews are where IT SoD conflicts surface. When reviewers certify who has access to what each quarter, they should be checking not just whether access is still needed, but whether any one person now holds a toxic combination of entitlements that together enable and hide a harmful action.
How to build an SoD matrix
An SoD matrix is the primary tool for making conflicts visible. It maps roles or individuals against sensitive processes and entitlements, then marks which combinations are incompatible. Building one follows a repeatable sequence.
- List the sensitive processes and privileged functions in scope
- Identify the incompatible pairs, the toxic combinations to prevent
- Map current roles and users against those functions in a grid
- Flag every cell where one person holds a conflicting pair
- Remediate by reassigning duties, or apply a documented compensating control
The matrix is not a one-time artifact. Roles drift as people change jobs and systems evolve, so the matrix should be re-run at each access review to catch conflicts that crept in since the last cycle. Our GRC implementation guide shows how to fold the SoD matrix into a wider governance, risk and compliance program rather than treating it as a standalone spreadsheet.
Compensating controls when SoD is not feasible
In small teams, full segregation is often impossible because there simply are not enough people to split every duty. Auditors accept this, provided you put compensating controls in place and document why. The goal is to reintroduce independent oversight even when you cannot fully separate the duties themselves.
- Owner or management review of bank activity and key transaction logs
- Dual approval for high-risk changes such as vendor master data
- Independent monthly reconciliations performed by someone outside the process
- Rotating duties periodically so no one owns a process indefinitely
- Automated workflow approvals that enforce digital separation despite low headcount
How SoD appears in ISO 27001, SOX and audits
SoD is a named requirement across major frameworks. In ISO 27001:2022, Annex A control 5.3 requires conflicting duties and areas of responsibility to be segregated to reduce the risk of fraud, error and bypassing of security controls. Under the Sarbanes-Oxley Act, Section 404 treats inadequate segregation of duties as a common driver of internal-control material weaknesses in financial reporting. SoD also appears in SOC 2 and in IT general controls testing.
Across all of these, the expectation is the same: identify conflicting duties, separate them where you can, and where you cannot, prove that documented compensating controls hold the residual risk to an acceptable level. Treated this way, segregation of duties becomes less a compliance checkbox and more a durable defense against both fraud and honest error.