No single person should be able to create, approve, and execute a transaction alone. Segregation of Duties is the control that makes sure they can't.
Segregation of Duties (SoD) sounds like paperwork. Until the year it prevents a six-figure fraud, or the year its absence causes one.
At its core, SoD is simple: split the tasks in any high-risk process across more than one person or system, so no single identity can complete the process end to end, unmonitored. In this guide, we'll cover what SoD is, why organizations enforce it, the different forms it takes, how it relates to other access control principles, the compliance frameworks that require it, and how to actually implement it in a modern, SaaS-heavy environment where "who has access to what" changes weekly.
What is Segregation of Duties?
Segregation of Duties, sometimes called Separation of Duties, is an internal control principle that divides the responsibilities within a critical business process across multiple people or systems, so no single individual has end-to-end control.
The classic formulation splits any sensitive process into four functions:
- Custody — who physically or digitally holds an asset (cash, inventory, credentials)
- Authorization — who approves a transaction or action
- Recording — who logs or documents the transaction
- Reconciliation — who verifies the transaction actually matches what was recorded
When one person holds two or more of these functions for the same process, you get a toxic combination, also called an SoD conflict.
The textbook example is an employee who can both create a purchase order and approve that same purchase order. Nothing stops them from creating a fake vendor, approving a payment to it, and pocketing the difference, because no second party is required to catch it.
SoD isn't about distrust. It's about removing the opportunity for error or fraud to go unnoticed, whether the person involved has bad intent or just fat-fingers a number nobody else checks. A well-designed SoD program assumes people are competent and well-meaning, and it builds a structure where mistakes and abuse both get caught by the process itself instead of relying on individual judgment every time.
Why Segregation of Duties matters
Without SoD, one compromised or careless identity can cause damage that a properly split process would have caught at the approval or reconciliation stage.
Undetected financial fraud. The purchase-order example isn't theoretical. Payroll fraud, fictitious vendor schemes, and expense manipulation almost always trace back to one person holding both the ability to initiate a transaction and the ability to approve it, with no independent check in between.
Failed audits and delayed certifications. SOX Section 404 requires documented internal controls over financial reporting, and SoD gaps are one of the most common findings auditors flag. A material weakness tied to access control can delay a SOX attestation, jeopardize a SOC 2 report, or trigger a qualified opinion, and none of that stays contained to the finding itself. It ripples into timelines, budgets, and board conversations.
Privilege creep. Access rarely gets revoked as fast as it gets granted. An employee promoted three times over five years often keeps every permission from every prior role, because deprovisioning isn't automatic and nobody audits the accumulation until something forces the question. Eventually that person becomes a single point of failure, and nobody decided that on purpose; it just happened. See our dedicated guide to privilege creep for how this specifically forms and what stops it.
Operational risk beyond fraud. SoD isn't only a fraud control. A system administrator who can both make configuration changes and approve their own change requests can introduce outages or security gaps with no independent review catching the mistake before it ships.
None of this is hypothetical or rare. It's the default outcome of how access accumulates in most companies unless someone actively manages it.
For a detailed look at what actually goes wrong when SoD isn't enforced, and what remediation costs in time and exposure, see our full breakdown of Segregation of Duties risks.
Types of Segregation of Duties conflicts
SoD conflicts fall into a few recurring patterns, regardless of industry.
Transactional conflicts. The same person can initiate and approve a transaction. This is the purchase-order example, and it's the most common conflict type in finance, procurement, and payroll.
Custodial conflicts. The same person has both custody of an asset and the ability to record its movement. A warehouse manager who can adjust inventory counts and also physically move stock is a custodial conflict, since they can move goods and then edit the record to hide the discrepancy.
System-level conflicts. The same identity holds both application-level access and the administrative rights to modify logs or audit trails for that application. This pattern is especially common in IT, where a single admin account often has far more reach than any one financial role would, because IT access tends to get provisioned broadly by default. We cover this pattern in detail, including the specific role splits that matter (DBA vs. sysadmin vs. network engineer), in our guide to IT Segregation of Duties.
Cross-application conflicts. Sometimes the conflict doesn't live inside one system at all. An identity might have "create vendor" rights in the ERP and "approve payment" rights in a separate finance tool, and neither system alone would flag it. The conflict only exists when you look at the person's total access across tools. This is exactly why manual, spreadsheet-based SoD reviews miss it most often, and it's the pattern that's grown fastest as companies moved from single monolithic ERPs to dozens of specialized SaaS tools.
Segregation of Duties vs. related access control principles
SoD gets confused with a few adjacent concepts that solve different problems and don't substitute for one another.
SoD vs. least privilege. Least privilege means giving each identity only the minimum access needed to do their job. SoD is about what happens when two specific pieces of access, each individually reasonable, get combined in the same identity. A person can be fully compliant with least privilege, every individual permission justified by their role, and still create an SoD violation, because the combination is what creates the risk, not either permission on its own.
SoD vs. RBAC. Role-Based Access Control (RBAC) is the mechanism for assigning permissions based on job function. SoD is a rule that constrains which roles, or combinations of roles, can be assigned to the same person. RBAC without SoD checks can still produce conflicts, since someone can be assigned two legitimate roles that individually make sense but together create a toxic combination. The same logic extends to attribute-based access control and policy-based access control. Whichever model assigns access, SoD is the separate check on which combinations of that access are allowed to coexist.
SoD vs. internal controls generally. SoD is one control inside a much broader internal controls framework that also includes preventive, detective, and corrective controls across an organization's financial and operational processes. We break down exactly where SoD sits relative to internal controls in Separation of Duties and internal controls.
Compliance frameworks that require Segregation of Duties
SoD shows up, explicitly or implicitly, in most major compliance and audit frameworks.
Meeting these requirements on paper is easy; a written policy takes an afternoon. Meeting them in practice, with provable, enforced separation and evidence an auditor can actually check, is where most programs fall short, and that gap is usually where audit findings come from.
How to structure Segregation of Duties in practice
Most SoD programs are built around a matrix: a mapping of roles or job functions against the tasks or entitlements that would conflict if held together. The matrix turns "we believe in SoD" into something you can actually audit and enforce.
Building and maintaining that matrix is its own discipline. What counts as a conflict, how granular to get, and how to keep it current as roles change all take real thought. We've laid out a full working template and the logic behind it in our Segregation of Duties matrix template.
Once the matrix exists, it needs to become an actual policy: a documented set of rules for what conflicts are prohibited, what happens when one is detected, who owns exceptions, and how often the whole thing gets reviewed. That policy also needs a procedure behind it, the concrete steps for identifying a violation, deciding how to remediate it, documenting the decision, and re-checking that the fix held.
A policy without a procedure tends to sit in a shared drive and never get followed. A procedure without a policy has no authority behind it when someone pushes back on an access change. You need both, read together, and we walk through exactly how in Segregation of Duties policy and procedure.
Real-world Segregation of Duties examples
Reading a definition of SoD and recognizing it in your own org's Slack, Jira, and finance stack are two different things.
It helps to see the same conflict pattern play out across departments: a finance team member who can both create and approve vendor payments, an HR generalist who can both process a new hire and approve their own timesheet, a DevOps engineer who can both write code and push it to production without review, a procurement lead who can both select a vendor and sign off on the contract value. Same pattern, different departments, different dollar amounts at risk.
For a full set of concrete, department-by-department examples, see Segregation of Duties policy examples.
Common challenges in implementing Segregation of Duties
Most organizations don't fail at SoD because they don't understand the concept. They fail at the mechanics.
Access lives across too many systems to track manually. A mid-sized company might run 100 to 300 SaaS applications. Cross-referencing entitlements across all of them by hand isn't realistic past a certain headcount, which is exactly why cross-application conflicts go undetected longest.
Roles change faster than policies get updated. An SoD matrix built once during an audit prep cycle goes stale the moment the org chart changes.
Small teams genuinely can't fully separate every duty. In a five-person finance team, there may not be enough people to split every function three ways. That doesn't mean SoD is impossible on a small scale. It means compensating controls fill the gap: a second reviewer checking transactions after the fact, tighter approval thresholds, more frequent reconciliation.
Exceptions become permanent without anyone deciding that on purpose. A temporary access grant to cover a vacancy or crunch period often just never gets revoked, because nobody owns the follow-up.
Ready to see how automated SoD detection works across your actual SaaS stack? Book a demo with Zluri.
Segregation of Duties in a SaaS-first environment
The classic SoD examples above come from ERP and finance systems, where the discipline originated. Most companies today run their operations across dozens or hundreds of SaaS applications instead, and SoD conflicts increasingly live in that layer: a marketing ops manager with both campaign-launch rights and budget-approval rights in two different tools, a finance analyst with vendor-creation rights in one tool and payment-approval rights in another.
Manually cross-referencing access across that many applications isn't realistic past a certain headcount. That's why identity platforms with dedicated SoD capabilities have become the practical answer for most mid-size and enterprise organizations, since they sit above your individual apps, pull entitlement data from each one, and flag conflicting combinations automatically.
Zluri, an identity security platform, includes Segregation of Duties as part of its Identity Governance and Administration (IGA) product. It detects when an identity holds conflicting entitlements across your SaaS stack, even when the two sides of the conflict live in entirely different applications, and remediates violations automatically through configurable Playbooks rather than just flagging the problem. If you're evaluating whether to build SoD enforcement manually or buy a platform that already does it, our guide to SoD software walks through the buying criteria and compares the leading tools, including Zluri.
Frequently Asked Questions
What is the difference between Segregation of Duties and Separation of Duties? They're the same concept. "Segregation of Duties" is more common in finance and audit contexts, while "Separation of Duties" shows up more often in IT security and government frameworks like NIST.
Is Segregation of Duties required by law? SoD itself isn't a standalone law, but it's a required control under several major compliance frameworks, including SOX (Section 404 internal controls), and it's a recommended or required practice under HIPAA, PCI DSS, and ISO 27001, depending on the process in question.
What is an SoD conflict matrix? An SoD conflict matrix is a mapping of roles or access rights against each other, showing which combinations are considered a violation if held by the same identity.
Can small companies skip Segregation of Duties? Small teams often can't fully separate every duty because there simply aren't enough people to split the work across. Compensating controls, like a second reviewer checking transactions after the fact, typically fill the gap instead.
How is Segregation of Duties enforced in IT systems specifically? In IT environments, SoD is enforced by mapping conflicting entitlements across applications and using policy-based detection to flag any identity holding both sides of a defined conflict. See our IT Segregation of Duties guide for the full breakdown.
Does Segregation of Duties apply only to finance teams? No. SoD originated in finance and audit contexts, but the same logic applies anywhere a process has a create-and-approve pattern: IT admin access, HR record changes, procurement, and engineering deployments all carry the same underlying risk.
How do I get started with Segregation of Duties if we have nothing in place today? Start with a risk assessment of your highest-exposure processes, usually finance, procurement, and IT admin access. Build a conflict matrix for those first, then formalize it into a documented policy. Our policy and procedure guide walks through this sequencing in more detail.
.svg)
