The Definitive Guide to Segregation of Duties (SoD): From Policy to Entitlement-Level Enforcement

Most SoD programs fail not because the policy is wrong, but because the enforcement stops at the wrong layer. Teams define roles, map them to a conflict matrix, and call it done - while the actual toxic combinations quietly accumulate inside those roles, invisible to any quarterly spreadsheet review.

This guide covers everything: what SoD is, why it exists, the classic toxic combinations auditors look for, how it maps to the frameworks you're being assessed against, and - critically - why role-level SoD is a necessary but insufficient starting point.

---

What Is Segregation of Duties?

Segregation of duties (also called separation of duties) is the principle that no single person should have end-to-end control over a critical process. It involves the systematic division of responsibilities so that a single person is not allowed to perform and control the same activity.

The logic is simple: if completing a harmful action requires two people to cooperate, the bar for fraud or error rises dramatically. One person can make a mistake or act maliciously; two people conspiring is harder to sustain and easier to detect.

SoD operates across three dimensions:

• Authorization - who can approve an action
• Execution - who can carry it out
• Review/Audit - who can verify it happened correctly

When the same identity holds two or more of these roles over the same process, you have a conflict.

---

Why SoD Exists: Fraud, Error, and the Numbers Behind It

The ACFE's 2024 Occupational Fraud Report analyzed 1,921 cases across 138 countries, with total losses exceeding $3.1 billion. CFEs estimate that organizations lose around 5% of revenue to fraud each year.

These aren't abstract risks. Nearly 29% of businesses impacted by fraud had no internal controls over accounts payable. SoD is the foundational control that closes that gap - not by making fraud impossible, but by ensuring that no single identity can both commit and conceal it.

SoD also catches unintentional errors. A developer who deploys their own code to production has no independent check on their work. An admin who both provisions access and certifies it has no external reviewer. The absence of a second set of eyes is a risk even when intent is entirely benign.

---

Classic Toxic Combinations

Toxic combinations in SoD refer to conflicting access permissions that allow a user to perform incompatible actions within a business process, creating opportunities for fraud, unauthorized transactions, or data manipulation.

Here are the combinations that appear most frequently in audit findings:

Finance SoD

Conflicting Entitlements	Risk
Create vendor record + Approve payment to vendor	Fraudulent vendor creation and self-payment
Initiate wire transfer + Authorize wire transfer	Unauthorized fund movement
Enter payroll data + Disburse payroll	Ghost employee schemes
Record journal entry + Approve journal entry	Financial statement manipulation

One of the most common SoD conflicts occurs when a user can both create vendor records and approve outgoing payments - a direct fraud risk because fraudulent vendors can be added and paid without independent validation.

IT SoD

Conflicting Entitlements	Risk
Write application code + Deploy to production	Unauthorized code changes bypassing QA
Request access + Approve own access request	Privilege escalation without oversight
Manage user accounts + Certify user access	Self-certifying excessive permissions
Configure security policies + Audit compliance with those policies	Concealing control failures

The developer who writes the code should not be the one deploying it to production; the person requesting access should not be the one approving it; the admin managing access rights should not also be the one auditing them.

The IT list is where most SaaS-heavy companies have the deepest exposure. When a single engineer has both repo:write on a production codebase and deployment pipeline access, the entire change management control collapses - regardless of what the role policy document says.

---

Preventive vs. Detective SoD

SoD controls fall into two categories, and you need both:

Preventive SoD is built into the provisioning workflow. When a user requests access, the system checks whether granting it would create a conflict with their existing entitlements - and blocks or escalates the request before the conflict is created. SoD is primarily a preventive control built into the role architecture and provisioning workflow to prevent conflicting entitlements from coexisting.

Detective SoD identifies violations that already exist. Detective controls such as access certification campaigns, audit log reviews, and entitlement monitoring identify violations that have accumulated over time.

Most organizations rely almost entirely on detective controls - periodic access reviews, quarterly certifications, annual audits. The problem: by the time a violation is detected, it may have existed for months. Preventive controls stop the conflict from being created in the first place.

The gold standard is request-time conflict detection: every access request is evaluated against the full entitlement picture before it is granted, not six months later during a certification campaign.

---

The SoD Conflict Matrix

An SoD conflict matrix is the structured grid that maps entitlements (or roles) against each other to surface incompatible pairings. The matrix becomes both a design reference for role configuration and an audit reference demonstrating that an SoD policy is formally defined.

A minimal matrix looks like this:

The matrix is a living document. Many organizations develop individual matrices by business process area and end up with 40, 50, 60, or even more than 100 SoD matrices that must all be constantly reviewed and updated when business processes or risk levels change. That's the spreadsheet problem in a nutshell.

---

SoD Across the Compliance Frameworks

Every major framework auditors use has an SoD requirement. Here's how they map:

A few framework-specific notes worth knowing:

SOC 2 CC6.3 expects that logical access is restricted to authorized users and that incompatible functions are separated. Auditors will pull samples and trace them end to end - a policy document alone is not sufficient evidence.

ISO 27001:2022 A.5.3 (updated from A.6.1.2 in the 2013 version) requires that conflicting duties and areas of responsibility are segregated. Auditors assessing ISO 27001 control 5.3 expect both policy-level documentation and operational evidence that segregation is actively enforced - not just described. A.8.2 adds the requirement to manage privileged access rights specifically.

SOX Section 404 treats SoD as a primary IT General Control category. Under Section 404 of the Sarbanes-Oxley Act, public companies must document, assess, and test internal controls that support reliable financial reporting, and SoD is one of the most heavily scrutinized ITGC control categories. SOX Section 404 treats inadequate segregation of duties as a common driver of internal-control material weaknesses.

PCI DSS v4.0 (fully mandatory as of March 31, 2025) requires least-privilege access to cardholder data environments, unique user IDs, and strict role-based access controls. PCI DSS v4.0 introduced 64 new requirements and moved from a prescriptive checklist model to a more flexible, risk-based approach.

---

The Core Problem: Role-Level SoD Misses Entitlement-Level Conflicts

Here's the uncomfortable truth that most SoD programs avoid: defining conflicts at the role level is not the same as enforcing them at the entitlement level.

Consider a common scenario. Your SoD policy says "Developer" and "Production Deployer" are conflicting roles. You enforce that no one holds both roles simultaneously. Clean, right?

Except your "Developer" role in GitHub includes environment:production write access inherited from a legacy permission group. Your "Release Engineer" role in your CI/CD tool includes the ability to trigger production deploys. A user who is technically assigned only the "Developer" role has, through entitlement inheritance, both sides of the conflict - and your role-level matrix never surfaces it.

Toxic combinations in IAM and IGA occur due to outdated systems, fragmented role structures, and human error during role assignments - a lack of structured entitlement policies and insufficient governance further exacerbates the issue.

The accumulation problem makes this worse. When a user joins, they are provisioned with role-appropriate access; when they move to a new team or function, new access is added, but old entitlements are rarely removed in the same action. Over time, a single identity can hold the residual permissions of every role they have ever occupied, creating toxic combinations that no single provisioning event ever intentionally created.

Manual SoD processes can't close this gap. Manual SoD processes depend on a static snapshot - usually a spreadsheet cross-checked against exported access reports - and that model breaks when the conflicting entitlements live in different systems, because each admin console only sees its own application. Once access changes faster than the review cadence, the conflict matrix is stale before it's used.

---

Building and Maintaining an SoD Policy

A functional SoD program has five components:

---

SoD for Small Teams: Compensating Controls Are Not a Loophole

The most common objection to SoD from lean IT teams is: "We don't have enough people to separate every duty." That's a real constraint, not an excuse - and the frameworks acknowledge it.

Where headcount is limited, compensating controls like detailed activity logging and independent management reviews can fill the gap - but the key is documenting where segregation is not possible and showing your auditor that you have thought it through.

Practical compensating controls for small teams:

• Tamper-evident logging reviewed by someone outside the process (even a manager, not a dedicated auditor)
• Time-boxed exception access that expires automatically and triggers a review
• Mandatory peer review for code changes before deployment, even if the same person can technically deploy
• Out-of-band approval for high-value transactions (e.g., a Slack confirmation from a second person before a wire is sent)
• Automated anomaly detection that flags when a single identity completes both sides of a sensitive process

The key is that compensating controls must be documented and tested. A verbal agreement that "the manager always checks" is not a compensating control - it's an unverifiable claim.

---

Why Continuous, Automated Detection Beats Periodic Reviews

The spreadsheet access review is the most common SoD enforcement mechanism and the least effective one. Here's why:

• It's a point-in-time snapshot. Access granted the day after the review won't be caught until the next cycle - potentially six or twelve months later.
• It's application-siloed. Each admin console exports its own data. Cross-application conflicts - where one side of the toxic combination lives in GitHub and the other in your ERP - require manual correlation that almost never happens.
• It scales inversely with complexity. The more apps you run, the more entitlements exist, the more combinations to check, and the less realistic manual review becomes.

Automated, entitlement-level SoD detection solves all three problems. It ingests entitlement data from every connected application, evaluates every identity against defined conflict rules continuously, and surfaces violations as they occur - not months later. It also catches cross-application conflicts that no single-app admin console can see.

For a deeper look at why spreadsheet-based access reviews fail the evidence test, see our post on moving from spreadsheets to continuous access certification.

And if you're preparing for a SOC 2 or ISO 27001 audit, the Identity Evidence Playbook covers exactly what auditors ask for - including the SoD evidence artifacts they expect to see.

---

How Iden Approaches SoD

Iden's agentic IGA platform enforces SoD at the entitlement level, across your full app stack - including apps without SCIM or APIs. That means:

• Request-time conflict detection: every access request is evaluated against the requester's full entitlement picture before it's granted, across all 175+ connected apps
• Cross-application conflict visibility: conflicts where one side lives in GitHub and the other in your ERP are surfaced as a single violation, not two disconnected findings
• Continuous monitoring: entitlement changes trigger immediate re-evaluation against your conflict ruleset - no waiting for the next quarterly review
• Fine-grained control: conflicts are detected at the permission level (channel, repo, project, environment), not just the role level - closing the gap that role-only SoD leaves open

---

SoD Readiness Checklist

Use this as a starting point for your own SoD program review:

Finance SoD - key questions:

• Is your conflict matrix defined at the entitlement level, not just the role level?
• Are vendor creation and payment approval separated for every user?
• Are payroll entry and payroll disbursement held by different identities?
• Are journal entry and journal approval separated?
• Are exceptions documented with compensating controls and time-boxed?
• Is there an independent reviewer for financial access certifications?

IT SoD - key questions:

• Are code commit and production deploy rights separated at the permission level?
• Is access request approval routed to someone other than the requester?
• Are account provisioning and access certification held by different identities?
• Are security policy configuration and security audit roles separated?
• Is cross-application conflict detection in place (not just per-app)?
• Are entitlement changes monitored continuously, not just at quarterly review?
• Are emergency access grants automatically time-boxed and logged?
• Is your SoD conflict matrix updated when roles or apps change?

---

The Takeaway

SoD is not a policy exercise - it's an enforcement problem. The policy is the easy part. The hard part is detecting conflicts at the entitlement level, across every app in your stack, before they're created rather than months after the fact.

Role-level SoD gives auditors something to point to. Entitlement-level SoD actually prevents fraud and errors. The gap between the two is where most violations live - and where most programs stop looking.

Start with your highest-risk toxic combinations, build your conflict matrix at the permission level, enforce at request time, and monitor continuously. For everything your spreadsheet can't see, that's where automated IGA earns its place.