A single employee who can create a vendor record and then approve that vendor's invoice doesn't need anyone else's help to push an improper payment through. No collusion is required, and nothing has to be forged: one login with too much reach is enough on its own. Segregation of duties (SoD) is the control that closes that gap. It splits a sensitive process into steps that different people must complete, so no one person can execute a transaction from start to finish unchecked.
The principle sits underneath most internal-control frameworks in finance, IT, and security operations. Auditors ask about it by name. Regulators cite it in specific clauses. And the cost of skipping it keeps climbing: the median case of occupational fraud cost $104,000 in 2026, and the average case ran for about 12 months before anyone caught it, according to the ACFE's Occupational Fraud 2026: A Report to the Nations.
What is segregation of duties (SoD)?
Segregation of duties (SoD) is an internal control that divides a sensitive process into stages, typically authorization, custody or execution, and recordkeeping or reconciliation, and assigns each stage to a different person. No single individual initiates and approves the same transaction, or handles an asset and records its own movement. The goal is to make fraud or error require collusion instead of opportunity.
SoD is not the same as an org chart. A reporting line shows who manages whom, but it says nothing about who can create a vendor, approve its payment, and reconcile the ledger without a second person ever reviewing the transaction. Two people can report to the same manager and still satisfy SoD, as long as neither can complete the full process alone. The four-eyes principle, requiring at least two people to sign off on a sensitive action, is the simplest expression of the idea.
Segregation of duties vs. least privilege vs. RBAC
SoD is not least privilege, and least privilege is not RBAC. Least privilege limits how much access one person has. SoD limits whether one person can complete an entire sensitive process alone, even within their allowed access. RBAC (role-based access control) is the mechanism that usually enforces both, by attaching permissions to roles instead of individuals.
The three ideas fail differently when applied alone. Least privilege without SoD still lets one narrowly scoped account both create and approve the same type of record, because narrow doesn't mean isolated. RBAC without SoD can quietly hand one person two roles that were never meant to overlap, like an accounts-payable clerk covering for an approver during a vacation week. The role definitions look clean, the combination defeats the control.
None of this makes RBAC unnecessary. It's the tool that makes SoD enforceable at scale. See how RBAC assigns access by role for the underlying model: instead of tracking individual permissions, an administrator defines roles, and SoD rules decide which roles a single account can hold at once.
| Principle | What it controls | Fails without it |
|---|---|---|
| Least privilege | How much access one account has | Accounts accumulate unused, high-risk permissions over time |
| RBAC | How access maps to job function | Permissions get assigned ad hoc, inconsistently, per person |
| Segregation of duties | Whether one account can finish a sensitive process alone | A single compromised or careless account can complete fraud or cause damage with no second party involved |
Common segregation of duties conflicts (with examples)
A segregation of duties conflict exists whenever one account or one person holds two roles that, combined, let them complete a sensitive process without a second party involved. The clearest examples sit in finance and procurement, but the same failure pattern shows up in DevOps pipelines, HR systems, and credential vaults.
Formalized SoD requirements trace back to the accounting scandals at Enron and WorldCom in the early 2000s, which led directly to the Sarbanes-Oxley Act and its Section 404 internal-controls mandate. That history still shapes how auditors approach the control today: SoD exists because informal trust stops scaling once a company passes a certain size.
When one person can both create a vendor and approve its payment, fraud requires no collusion at all.
| Domain | Conflicting duties | What it enables if combined |
|---|---|---|
| Finance | Create a vendor + approve its invoice | Fictitious vendor payments with no second reviewer |
| Procurement | Request a purchase + approve the purchase order | Unauthorized spending routed around budget controls |
| IT / DevOps | Deploy code + approve the deployment | Unreviewed code reaches production, including backdoors |
| HR | Set an employee's pay rate + process payroll | Unauthorized pay changes that no one else verifies |
| Credential management | Create a vault + grant its own admin rights | One account that stores secrets and controls who can see them, with no independent oversight |
| IT administration | Provision user accounts + approve access requests | Accounts created and approved by the same person, bypassing review |
If one row in that table describes how your vault works today, that gap is fixable. Try Passwork free and see how vault policies close it.
How to build a segregation of duties matrix
A segregation of duties matrix maps roles against the actions those roles can take, so conflicts become visible before they cause a problem. Building one takes five steps.
- Identify the critical processes. Start with anything that moves money, changes access, or touches production: vendor payments, payroll changes, code deployment, credential and vault administration.
- List every role involved. Include job-title roles (accounts-payable clerk, DevOps engineer) and system roles (vault administrator, approver) side by side.
- Map roles against actions. Build a grid with roles on one axis and actions, such as create, approve, execute, and record, on the other. Mark every action each role can currently perform.
- Flag the overlaps. Any role that can both initiate and approve the same process, or both execute and record it, is a conflict.
- Resolve each conflict. Reassign the role, split the process across two roles, or, where reassignment isn't practical, document a compensating control.
A small worked example, three roles against three actions in an accounts-payable process:
| Role | Create vendor | Approve payment | Reconcile ledger |
|---|---|---|---|
| AP clerk | Yes | No | No |
| Finance manager | No | Yes | No |
| Auditor | No | No | Yes |
No single row can check every column. That's the matrix working as intended.
Preventive vs. detective SoD controls (and compensating controls for lean teams)
Preventive SoD controls stop a conflicting assignment before it happens, usually by blocking a role combination in the access system itself. Detective controls catch conflicts after the fact, through audit trails and periodic access review. Compensating controls substitute for either when a team is too small to fully separate a process.
Preventive controls are the strongest, because they remove the opportunity entirely. A role system that refuses to let one account hold both "approver" and "requester" for the same workflow never lets the conflict form in the first place.
Detective controls accept that some overlap is unavoidable and catch it instead. An audit trail that logs who created a record, who approved it, and who accessed it afterward lets a reviewer spot a conflict during an access certification, even if the system allowed it to happen.
Most SoD guidance assumes a dedicated identity governance and administration (IGA) or GRC platform running continuous conflict checks. Small IT teams rarely have that budget, and most guidance skips what to do instead.
Four compensating controls cover most of the gap. Call it the four-control SoD baseline:
- Separate roles wherever headcount allows
- Route anything that can't be separated through a second approver
- Log every privileged action to an exportable audit trail
- Review access on a fixed schedule instead of never
None of the four requires a GRC platform. All four require someone to own the schedule.
Segregation of duties and compliance frameworks
Segregation of duties shows up by name or by requirement in most major compliance frameworks, though the legal weight varies by sector and jurisdiction. SOX ties it to financial reporting controls, NIST and ISO frame it as a general security control, and NIS2 folds it into access control policy requirements for essential and important entities in the EU.
None of these frameworks hand over a ready-made SoD matrix. They require that the organization has one and can show how conflicts get resolved.
| Framework | What it requires | Citation |
|---|---|---|
| SOX | Documented internal controls over financial reporting, including access controls that keep one person from completing certain transactions alone | SOX Section 404, SEC small-business guide |
| NIST SP 800-53 Rev. 5 | Organizations define and document individual duties, then configure system access so no combination of duties lets one account complete a sensitive process alone | NIST AC-5, control AC-5 |
| ISO/IEC 27001:2022 | Segregation of duties as a named control area, covering how conflicting duties and responsibilities are separated | ISO/IEC 27001:2022, Annex A control 5.3 |
| NIS2 Directive | Essential and important entities implement measures covering human resources security, access control policies, and asset management | NIS2 Directive, Article 21, Art. 21(2)(i) |
SOX's Section 404 mandate is the one most compliance-driven SoD programs cite by reflex, though it applies specifically to public companies' financial reporting controls, not to every framework in this table. Whether SoD is legally required for a given organization depends on sector, jurisdiction, and which frameworks apply. A compliance or legal team is the right source for that determination. This table is a map, not a legal opinion.
Segregation of duties checklist
Use this checklist to move from an ad hoc access setup to a documented segregation of duties program, with or without a dedicated GRC platform.
- Map every critical process that moves money, changes access, or touches production.
- Build a segregation of duties matrix and flag every role that can both initiate and approve the same action.
- Assign non-removable administrators per vault or policy type, so oversight doesn't depend on who created the resource.
- Enable AD/LDAP group sync so access changes follow directory updates instead of manual tickets.
- Turn on exportable audit logging for every privileged action.
- Schedule periodic access review, more often for high-risk roles than for standard ones.
- Document compensating controls wherever strict separation isn't feasible, and record who owns each one.
Top comments (0)