A practical, department-by-department (across finance, HR, procurement, IT, and sales) breakdown of Segregation of Duties examples, showing what a conflict looks like and how to write the policy for it.
Most people understand SoD in the abstract: don't let one person control an entire process end to end. Where it gets harder is spotting the conflict in your own systems.
It rarely looks like the textbook purchase-order example. It looks like a Zendesk admin role, a Workday approval chain, or a Salesforce permission set that quietly grants more than anyone intended.
This guide walks through concrete SoD examples across the departments where conflicts show up most often, what each one looks like in practice, and how it typically gets resolved. For the underlying definition and the four core functions these examples are built on, see our Segregation of Duties guide.
Finance and accounts payable
The conflict. An accounts payable specialist can create a new vendor record and also approve payments to that vendor. Nothing structurally prevents them from creating a fictitious vendor and approving payment to an account they control.
How it's typically resolved. Vendor creation and payment approval get assigned to different roles, usually AP staff create vendor records while a finance manager or controller approves both the vendor and any payment above a defined threshold. Smaller teams that can't fully separate these functions often add a compensating control instead, like requiring a second reviewer to spot-check new vendor records monthly against payments made.
Sample policy language. "No individual may both create or modify a vendor record and approve a payment to that same vendor. Payments to newly created vendors require secondary approval from a role outside the AP function for the first 90 days."
Procurement
The conflict. A procurement lead selects a vendor for a contract and also has authority to approve the final contract value. This combination has shown up repeatedly in real procurement fraud cases, where a buyer steers business toward a vendor they have an undisclosed relationship with, then approves the terms themselves.
How it's typically resolved. Vendor selection and contract approval sit with different people, often the procurement team recommends and a finance or legal stakeholder approves. For high-value contracts, some organizations require a documented competitive bid process specifically to create an additional check beyond simple approval separation.
Sample policy language. "The individual who selects or recommends a vendor for a contract may not also hold final approval authority over that contract's value. Contracts above [threshold] require a second approver outside the procurement function."
HR and payroll
The conflict. An HR generalist processes new hire paperwork and also has the ability to approve compensation changes, including their own. In a related pattern, someone managing timesheets also approves the payroll run those timesheets feed into.
How it's typically resolved. Compensation approval typically moves up to an HR director or a role with no direct processing responsibility for that same employee. Payroll runs generally require approval from someone outside the team that manages day-to-day timesheet entry, often the controller or a dedicated payroll manager.
Sample policy language. "No employee may approve their own compensation change under any circumstance. Payroll run approval must come from a role independent of timesheet processing for that pay period."
This example also touches a subtler risk: access to employee personal data (like direct deposit details) combined with the ability to modify it. Payroll diversion schemes, where a fraudster changes a direct deposit account and redirects a paycheck, often exploit exactly this combination when it isn't separated. For a fuller look at what this kind of risk actually costs an organization once discovered, see our guide to Segregation of Duties risks.
IT and system administration
The conflict. A database administrator who also holds application development access can push code changes and directly modify the production data those changes touch, with no independent review of either. In a related IT pattern, a system administrator can make a configuration change and also approve their own change request in the ticketing system.
How it's typically resolved. Change management processes require an approver distinct from the requester, enforced through the ticketing or CI/CD tooling itself rather than relying on informal team norms. DBA and developer access get provisioned as genuinely separate roles.
IT conflicts follow a fundamentally different shape than the finance examples above, since a single admin account often has reach across an entire system rather than one bounded transaction. We cover this category in full in our IT Segregation of Duties guide.
Sample policy language. "Production database administration rights and application development access may not be held by the same identity for more than [X] days without documented justification and time-bound expiration."
Sales and CRM administration
The conflict. A sales operations administrator can both create custom pricing or discount approvals in the CRM and also approve their own deals under those custom terms. This shows up most often in fast-growing sales teams where the same person who configures the CRM's approval workflow is also an active quota-carrying rep.
How it's typically resolved. CRM administrative rights (the ability to configure approval thresholds and discount rules) get separated from any role that also closes deals. Where a small team can't fully separate this, deals above a certain discount level require sign-off from someone with no personal stake in that specific deal.
Sample policy language. "Individuals with the ability to configure discount approval thresholds in the CRM may not also submit deals for approval under those same thresholds without independent sign-off from Sales Finance."
Customer support and data access
The conflict. A support agent with the ability to both view customer payment details and issue refunds can, in principle, issue unauthorized refunds to their own external accounts or manipulate a customer's data without a second party noticing. This conflict is easy to overlook because support tools rarely get the same SoD scrutiny finance systems do.
How it's typically resolved. Refund approval above a set dollar threshold routes to a supervisor role distinct from the agent handling the ticket. Access to full payment details is often restricted to a smaller subset of senior agents, with standard support staff seeing only masked or partial data sufficient to resolve most tickets.
Sample policy language. "Refunds above [threshold] require supervisor approval independent of the agent who initiated the request. Full, unmasked payment detail access is limited to designated senior support roles."
Engineering and DevOps
The conflict. A developer who can both merge code and deploy it to production without a required review step holds, functionally, the same unchecked authority as someone who can create and approve a financial transaction. As deployment pipelines have automated more of the release process, this conflict has become more common rather than less, since a single misconfigured pipeline permission can remove the human checkpoint entirely.
How it's typically resolved. CI/CD tooling enforces a required approval step before any production deployment, configured so it can't be bypassed by the same identity that submitted the change. Branch protection rules commonly require review from someone other than the code's author before a merge to a production branch is possible.
Sample policy language. "No individual may both author and approve a pull request merging to a production branch. Production deployment pipelines must enforce a mandatory review step that cannot be self-approved."
When a conflict is conditional, not absolute
Not every example above resolves the same way. It's worth being explicit about that in policy language rather than treating every conflict as identically severe.
Some conflicts are absolute. Creating and approving a vendor payment should never sit with the same person, regardless of dollar amount, because the potential for fraud exists at any size. Other conflicts are conditional, meaning they only become a real risk above a certain threshold. A support agent processing a $15 refund and also having general refund authority isn't the same risk as the same agent approving a $1,500 refund unsupervised.
Writing a policy that treats both identically either creates unnecessary friction on low-risk cases or, more commonly, gets quietly ignored because the threshold-free rule is impractical to enforce.
Good policy language names the threshold explicitly rather than leaving it to individual judgment. "Refunds under $50 may be processed and approved by the same agent; refunds above that amount require supervisor sign-off" is enforceable and specific. "Large refunds require appropriate oversight" is neither.
Writing your own policy example
Every example above follows the same underlying structure, worth naming explicitly if you're documenting conflicts specific to your own organization.
Start with the two functions in tension, phrased as concretely as possible. "Manages vendors" is too vague; "creates or edits vendor records" is specific enough to test against actual system access. Then state what happens if the same identity holds both, in a plain description of what that person could actually do. Finally, document how it gets resolved, either through full separation or a named, specific compensating control.
This same structure, applied consistently across every process in scope, is what a documented SoD policy actually is. It's also what makes SoD testable as a specific control activity within a broader internal controls framework rather than a general principle; see Separation of Duties and internal controls for how the two connect.
We walk through building that full policy, along with the operational procedure for identifying and remediating violations day to day, in Segregation of Duties policy and procedure. And if you're building the underlying conflict matrix these examples map to, our Segregation of Duties matrix template has a full working structure to start from.
Finding these conflicts in a real environment
Every example above assumes you already know who holds which combination of access. In practice, that's the hard part. Across a mid-size company running dozens of departments and dozens more SaaS applications, the CRM discount example, the support refund example, and the DevOps deployment example might all be true simultaneously, for different people, in different tools, none of it visible from any single admin console.
Zluri, an identity security platform, addresses this through its IGA product's Segregation of Duties capability, which detects when an identity holds conflicting entitlements anywhere across your SaaS stack, including combinations that span two entirely different applications, and routes violations for remediation automatically.
If you're evaluating tools that can surface these conflicts at scale rather than finding them one department at a time, our guide to SoD software compares the leading platforms against the buying criteria that matter most.
Want to see which of these conflicts already exist somewhere in your own SaaS stack? Book a demo with Zluri.
Frequently Asked Questions
What is a common example of a Segregation of Duties violation? The most cited example is an accounts payable employee who can both create a vendor record and approve payments to that vendor, allowing them to route payments to a fraudulent vendor with no independent check. Similar patterns show up in procurement, payroll, and IT change management.
Are Segregation of Duties conflicts only found in finance? No. Sales operations, customer support, engineering, and IT all have their own version of the same underlying conflict pattern: someone who can both take an action and approve or verify that same action without independent review.
How should a Segregation of Duties policy example be written? State the two conflicting functions concretely, describe specifically what the combination would allow someone to do, and document how the conflict is resolved, either through full role separation or a specific, named compensating control rather than vague oversight language.
What if a small team can't fully separate every conflicting duty? Compensating controls fill the gap, a second reviewer, a dollar threshold requiring extra approval, or periodic sampling review. The policy should document the compensating control explicitly rather than leaving the conflict unaddressed.
How do Segregation of Duties examples relate to a conflict matrix? Each example is essentially one row of a broader SoD matrix, written out in full narrative form. The matrix condenses many such examples into a structured, testable reference document covering an entire department or organization.
Can the same conflict pattern show up in multiple departments? Yes. The create-and-approve pattern behind the accounts payable example recurs almost identically in procurement, payroll, sales discounting, and engineering deployment approval. Recognizing the pattern once makes it much easier to spot in departments that haven't been reviewed yet.
.svg)
