What Is segregation of duties (SoD)? Definition and examples

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.

Key takeaways

SoD splits authorization, custody, and recordkeeping across different people so a single account can't complete a sensitive process alone.
It's distinct from least privilege and RBAC. Least privilege limits how much access one person has, RBAC is the mechanism, and SoD is the design rule that decides which combination of roles a single account may hold.
The median occupational fraud case cost $104,000 in 2026 and ran about 12 months before anyone caught it (ACFE).
NIST AC-5, ISO 27001 Annex A 5.3, and NIS2 Art. 21(2)(i) all expect documented SoD controls, though the legal weight varies by sector.
Teams without a dedicated identity governance and administration (IGA) or governance, risk, and compliance (GRC) platform can run SoD through compensating controls: non-removable admin roles, approval routing, audit logging, and periodic review.

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.

How Passwork enforces segregation of duties in the vault

Passwork builds segregation of duties into the vault through four mechanisms: non-removable admin roles, custom RBAC roles, AD/LDAP group sync, and an exportable audit trail. Together they separate who creates a vault from who permanently controls it, and they turn access review from a manual chase into a scheduled export.

Vault policies assign administrators at the vault-type level, not to whoever happens to create the vault. A vault policy defines which corporate administrators get automatic, non-removable access to every vault of that type, so the person who spins up a new department vault can't quietly strip out oversight later. That's a preventive control: the conflict between "creator" and "permanent admin" never gets the chance to form.

Role management in Passwork

Custom RBAC roles separate account and user administration from day-to-day vault access. Passwork ships three built-in roles, Owner, Administrator, and Member, and supports unlimited custom roles scoped across account settings, vault management, user management, authentication methods, and API access. See designing an enterprise RBAC policy for how to structure roles before rollout. A role built for a helpdesk technician doesn't need vault-policy authority, and it doesn't have to carry it.

AD/LDAP group sync enforces the preventive control at scale. Instead of an administrator manually rechecking who belongs in which Passwork group, directory group membership drives it. When HR moves someone to a different team in Active Directory, their Passwork access follows automatically, and revoking conflicting access when roles change stops depending on someone remembering to file a ticket.

Activity log in Passwork

The Activity log is the detective layer. It records vault, folder, password, and account-level events, filterable by date, user, and action type, and exportable to Syslog, Windows Event Viewer, or a SIEM. For an auditor asking to see evidence of access review, an exportable log is the difference between a real answer and a promise. Full detail on Passwork's access management capabilities covers how these pieces fit together.

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.

The bottom line

Segregation of duties runs as an ongoing design discipline: every time a role changes, a vault gets created, or a new pipeline goes into production, the question is the same. Can one account complete this alone? If yes, that's a conflict waiting for an incident to expose it.

The matrix and the compliance citations matter, but the daily work is operational: non-removable admins, synced groups, an audit trail someone actually reads. That's where SoD holds, or quietly stops mattering.

Start by pulling up your most sensitive vault and checking who can create, approve, and audit access there unchecked.

If one admin on that vault can create, approve, and audit access unchecked, fix that before an audit finds it for you. Start a free trial of Passwork and set up vault policies that separate those roles from day one.

Frequently asked questions about segregation of duties

Is segregation of duties the same as least privilege?

No. Least privilege limits how much access one person has. Segregation of duties ensures no single person can complete an entire sensitive process alone, even within their allowed access. A narrowly scoped account can still violate SoD if it's the only account involved in both authorizing and executing a transaction.

Does segregation of duties apply to machine and service accounts?

Yes. Automation scripts and service accounts can hold conflicting entitlements just like people do, for example a pipeline that both deploys code and approves its own deployment. SoD reviews should include service accounts and automation identities alongside human accounts, especially as CI/CD pipelines and AI agents take on more privileged actions unsupervised.

Is segregation of duties legally required?

It depends on the framework and sector. SOX Section 404 ties it to financial reporting controls for public companies. NIST, ISO 27001, and NIS2 treat it as an expected security control rather than a standalone legal mandate. Check which frameworks apply to your organization before treating any single citation as a blanket requirement.

How do small teams enforce SoD without a dedicated GRC platform?

Through compensating controls: separate roles wherever headcount allows, route unavoidable overlaps through a second approver, log every privileged action to an exportable audit trail, and review access on a fixed schedule. None of that requires identity governance software, though someone still has to own the schedule.

How often should a segregation of duties matrix be reviewed?

Review high-risk roles, such as vault or system administrators, monthly. Medium-risk roles can run on a quarterly cycle. Review immediately after any role change as well, since that's when new conflicts most often get created.