Separation of Duties Fundamentals: Toxic Combinations and the Conflict Matrix

A payment nobody recognized

David had been the financial controller at a mid-sized food distributor for three years when the bank called about a payment. It was routine, a confirmation on a transfer of $48,000 to a packaging supplier, except that nobody in purchasing had heard of the supplier. The invoice was in the ERP. So was the purchase order, and a goods receipt for eleven pallets of shrink film that nobody in the warehouse could find.

It took two days to work out what had happened. An accounts payable clerk who had been with the company for eleven years had created the supplier in the vendor master, entered an invoice against it and released it in the weekly payment run. Each of those steps had been done with access the clerk legitimately held. Vendor master rights had come two years earlier, during a backlog project when the master data team was short-staffed. Payment release had been added during a colleague’s parental leave and never taken away. Both grants had been approved by the clerk’s manager, and both had survived four quarterly access reviews, because a reviewer looking at either one alone saw nothing wrong.

What had gone wrong was the combination. No single permission was excessive, but together they let one person carry a payment from invention to bank transfer without anybody else touching it. That’s the problem separation of duties exists to solve, and it’s the reason the next four articles are about it.

What separation of duties means

Separation of duties (SoD), also called segregation of duties, is the principle that no single person should be able to complete a sensitive transaction from start to finish on their own. The steps are divided between people so that a mistake or a fraud needs at least two of them, either acting together or one failing to notice, before it gets through.

The idea is much older than computers. It comes from accounting and internal control, where it was the main defense against fraud long before anyone talked about access rights. A bookkeeper who records cash receipts shouldn’t also be the one who deposits the cash, and the person who signs cheques shouldn’t also reconcile the bank statement. The COSO internal control framework, which most auditors in the United States and many elsewhere use as their reference, lists segregation of duties as one of the basic control activities an organization is expected to have.

In a paper office, duties were separated by desks, ledgers and signatures. The person in purchasing physically couldn’t release a payment, because the cheque book was in a different room. Once those processes moved into ERPs and SaaS applications, the separation stopped being physical. It now exists only in the permissions each person holds, which means it’s an identity problem. That is why SoD lives in IGA, and why an IGA program that can’t answer “who can do both of these things” will eventually fail an audit, or, like David’s company, find out the hard way.

The duties that get separated

Accountants usually describe four kinds of duty that shouldn’t sit with the same person. The vocabulary differs between textbooks, but the idea is stable.

Authorization is the decision that something should happen: approving a purchase order, approving a new vendor, approving a payment. Recording is entering the transaction into the books or the system: creating the purchase order, posting the invoice, booking the journal entry. Custody is control over the asset itself: access to the bank account, the warehouse, the inventory, or in IT the production server and its data. Verification, sometimes called reconciliation or review, is checking afterward that what was recorded matches reality: reconciling the bank statement, counting stock, reviewing the payment run.

A sound process puts at least two of those duties in different hands, and the most sensitive ones keep all four apart. The four-duty model also gives you a quick test for any new access request. If someone who records transactions is asking for the ability to approve them, or someone with custody of an asset wants to reconcile it, you’re probably looking at a conflict, even before anyone has written a formal rule for it.

Toxic combinations

The term identity teams use for a forbidden pairing is a toxic combination: two or more access rights that are each harmless, often necessary, but that together let one person commit an error or a fraud and hide it. The vendor master and payment release combination from David’s company is the textbook case, because it’s so direct. With both, a person can invent a vendor or quietly change a real vendor’s bank account, and then pay it.

It’s tempting to think of SoD as a finance topic, and finance is certainly where the rules are most mature. But toxic combinations show up in every function that moves value or changes control. In HR, the ability to create employee records combined with the ability to run payroll lets someone pay an employee who doesn’t exist. In IT, creating user accounts combined with assigning privileged groups lets an administrator build themselves an untraceable admin account. In software delivery, writing code and deploying it to production without review lets one engineer change what the business runs. In a hospital, prescribing a controlled drug and dispensing it lets one person divert it. And inside an IGA platform itself, being able to request access and approve that same request makes every other control in the program decorative.

What makes toxic combinations hard to see is exactly what David found: each piece of access looks reasonable on its own. Access reviews that show a reviewer one entitlement at a time can’t catch them. Neither can a request process that checks whether this particular grant is justified without looking at what the person already holds. Catching them requires a rule that names the combination, and a platform that evaluates that rule against everything a person can do, across everything they’re assigned.

Static and dynamic separation

The RBAC standard, ANSI/INCITS 359, distinguishes two ways to enforce separation, and the distinction matters for deciding where a control should live.

Static separation of duties is a constraint on assignment. If two roles conflict, nobody can be assigned both, full stop. This is what most people mean by SoD in an IGA context, and it’s what an IGA platform is good at: it knows every assignment, so it can refuse a combination when access is requested and report one when it already exists.

Dynamic separation of duties is a constraint on use. A person may hold both roles, but can’t activate them in the same session, or, in the form most applications implement, can’t act on both sides of the same transaction. A purchasing manager may both create and approve purchase orders, but the system won’t let them approve one they created themselves. Banking portals that require a second user to authorize a payment someone else set up are doing the same thing.

The two complement each other. Static separation is cleaner and easier to audit, but it’s sometimes too blunt; a small team may need people who can both create and approve, just never on their own work. Dynamic separation is more flexible, but it lives inside each business application, configured by the application team, and the IGA platform usually can’t see whether it’s switched on. A mature program uses static SoD rules for the combinations that should never exist and records, as part of the ruleset, which risks are handled dynamically by the application, so that someone checks that the application setting is still there. A dynamic control that was quietly disabled during an upgrade is one of the more common audit findings in this area.

From a risk down to a permission

A rule that says “vendor maintenance conflicts with payment release” is perfectly clear to the head of finance. It’s useless to a platform that only knows about SAP authorization objects, Entra ID groups and roles in a banking portal. Every working SoD ruleset therefore has layers, and getting those layers right is most of the work.

At the top is the risk, written in business terms: “a fictitious or altered vendor is paid.” Below it are the functions whose combination creates the risk: “maintain vendor master data” and “release payments.” Below each function are the entitlements and transactions that perform it in each system: a set of ERP transactions and apps for the first, the payment run plus an approval role in the bank portal for the second. At the bottom are the technical permissions that actually grant the ability, such as authorization objects with specific field values, API scopes or database grants. SAP’s access control product uses almost exactly this structure, with risks made of functions and functions made of actions and permissions, and most IGA platforms model something similar.

flowchart TD
  accTitle: Layers of an SoD rule from risk to permission
  accDescr: At the top is a business risk, a fictitious or altered vendor being paid. It is created by combining two functions, maintaining vendor master data and releasing payments. The vendor function is granted by ERP vendor transactions and apps. The payment function is granted by the ERP payment run and by an approver role in the bank portal. Each of those entitlements is in turn granted by technical permissions such as authorization objects and their field values.
  R[Risk<br/>a fictitious or altered<br/>vendor is paid] --> F1[Function<br/>maintain vendor master]
  R --> F2[Function<br/>release payments]
  F1 --> E1[ERP vendor<br/>transactions and apps]
  F2 --> E2[ERP payment run]
  F2 --> E3[Bank portal<br/>approver role]
  E1 --> P[Technical permissions<br/>objects and field values]
  E2 --> P
  E3 --> P

The layers exist because different people own different parts of the problem. The business process owner can decide whether a risk matters and how severe it is, and can explain it to an auditor, but has no idea which authorization object governs vendor bank details. The ERP security team knows that, but shouldn’t be deciding which risks the business accepts. Keeping the layers separate lets each group maintain its own part. It also means a single risk can span systems: when the payment approval moves from the ERP to a new treasury platform, the risk and its functions stay the same and only the mapping underneath changes.

Building the conflict matrix

The conflict matrix is the business-readable view of the ruleset. Functions go along both axes, and each cell where two functions meet records whether holding both is a problem, how serious it is, and which rule covers it. It’s the document a process owner signs off, the one auditors ask for, and the one people consult when someone asks “can I give this person both?”

A good matrix starts from a process, not from a list of permissions. Pick one process, such as purchase to pay, and walk through it with the people who run it: who sets up vendors, who raises purchase orders, who approves them, who receives the goods, who enters invoices, who pays. Each of those steps is a candidate function. Most processes come out at somewhere between six and fifteen functions; much more than that usually means the functions are really permissions in disguise and should be grouped.

Then go cell by cell and ask what one person could do with both. For each pair that creates a real risk, write the risk in a sentence a non-specialist would understand, give it a severity and name an owner. Severity is usually set from a few questions: can the combination move money or assets directly, is there a downstream control that would catch misuse (a bank’s own dual authorization, a monthly reconciliation done by someone else), and how large could the loss be before anyone noticed. The answers should be written down with the rule, because the next person to review it will want to know why “create purchase order plus approve purchase order” is critical and “approve purchase order plus post invoices” is low.

A matrix like this one is symmetric, because holding A and B is the same as holding B and A, and the diagonal is empty, because a function can’t conflict with itself. That leaves fifteen pairs for six functions. Not every pair needs a rule. Medium and low cells are often accepted without a formal rule, or monitored rather than blocked, and that decision should be explicit too: a blank cell should mean someone looked and decided there’s no meaningful risk, not that nobody got around to it.

Each rule then gets a record of its own, with the functions it covers, the risk description, the severity, the owner, which systems it applies to and what exceptions are allowed. The policies article described that record as a policy object and showed how SoD rules sit next to assignment and lifecycle rules. The matrix is how those objects are presented to the people who have to agree with them.

Critical access: risk without a combination

Some access is dangerous on its own, without needing a second function. Changing the parameters of the payment run, opening and closing accounting periods, maintaining users and roles inside the ERP, editing data directly in production tables, or switching off the change log on a sensitive table all fall into this group. A single person with any of them can do serious damage without needing anything else.

Most SoD tools handle this as a special case of the same machinery, usually called critical access or sensitive access: a risk with a single function rather than two. The process is identical. Name the risk in business terms, map it to the entitlements and permissions that grant it, give it a severity and an owner, and decide who’s allowed to hold it and under what conditions. It belongs in the same ruleset as the conflicts, because the people looking at a user’s risk profile need to see both kinds at once, and because the same mitigation and acceptance process applies to each.

At what level to evaluate

Once the rules are defined, the platform needs to evaluate them against what people actually hold, and the level at which it does that decides whether the results are useful or just noisy.

Evaluating only at the role level is the easiest and the least reliable. It tells you that someone holds the role “AP clerk” and the role “treasury analyst,” and if a rule says those two roles conflict, you have a finding. But roles change, roles are often named for what they used to contain, and a role called “AP clerk” that quietly picked up payment release three years ago will never trigger a rule written against role names.

Evaluating at the transaction or entitlement level is better, and it’s where most programs operate. The rule maps each function to the transactions, apps or groups that grant it, and the platform checks whether a person’s combined access includes something from each side. The weakness is false positives. In SAP, for example, having a transaction in your menu doesn’t mean you can do anything with it; the authorization objects behind it decide whether you can create, change or only display. A rule that fires on the transaction alone will flag hundreds of people who can only look at vendors, and the real conflicts get lost in the noise.

The most accurate level is the effective permission: the transaction plus the authorization values that let a person actually perform the function. It’s more work to model and requires good connectors, but it’s the only level at which the numbers mean what they say. In practice, the rule should be defined at the function level, evaluated against effective permissions where the system exposes them, and reported both per user and per role, so that people see whether a conflict comes from one person’s unusual combination or from a role that hands it to everyone.

Conflicts inside roles and between them

A role that contains both sides of a conflict is the worst case, because every member inherits the conflict on the day they’re assigned it. These roles are surprisingly common. They’re usually built by copying the access of an experienced person who did several jobs, or they grow one request at a time as the role owner adds “just one more transaction” for a team that needs it. The role engineering article recommended running SoD analysis on every role’s content before it’s published and whenever it changes; this is why. Fixing one conflicting role can remove hundreds of user-level findings at once.

The more common case is a conflict between roles: two roles that are each clean but that combine into a conflict when one person holds both. These are harder to prevent at design time, because the role owner of each one has done nothing wrong. They’re caught by checking the combination at assignment time, which is where the preventive controls described below come in.

Conflicts across systems

David’s clerk worked entirely inside the ERP. Many real conflicts don’t. A company might maintain vendors in the ERP but approve payments in the bank’s own portal, or create employees in the HR system and run payroll through an outsourced provider. A rule that only looks inside one system will report both sides as clean.

Cross-system rules depend on something earlier articles spent a lot of time on: knowing that the ERP account JSMITH01 and the bank portal user j.smith@company.com belong to the same person. Without that correlation, described in the identity data model article, the platform sees two separate people and can’t evaluate the combination at all. Accounts that fail to correlate, or that were created by hand in a system without a connector, are exactly where cross-system conflicts hide. A useful test of any SoD tool is to set up one toxic combination split across two applications and check whether the tool reports it as a single violation. If someone has to cross-reference two reports by hand to see it, the tool doesn’t really cover cross-system SoD.

Non-human identities belong in scope

Most SoD analyses quietly leave out service accounts, integration users and API tokens. They aren’t people, they don’t fit into the role model, and they often hold broad access because an interface needed it years ago. Yet they’re frequently the identities with the most dangerous combinations. A batch interface that loads supplier invoices from a scanning service may well have rights to create vendors and post invoices, because that was the easiest way to make the integration work.

The risk is real even though no human logs in as that account. Whoever controls the integration, whether by holding its credentials, editing its configuration or feeding it a crafted input file, effectively holds its functions. Non-human identities should go through the same analysis as people, with an accountable human owner for each, and their access should be narrowed to the specific transactions the interface uses. Where an integration genuinely needs both sides of a conflict, it should be treated like any other exception, which is the subject of the next article.

SoD for the people who run IAM

There’s one set of conflicts that every program should check before any other: the ones inside its own administration. The people who run the IGA platform can usually change rules, approve requests on behalf of others, edit role content and sometimes write directly to target systems through connectors. If the same person can grant themselves access and approve it, or change an SoD rule and then hold the combination it used to block, the program has a hole at its center.

The usual separation is between administering the platform, approving access, owning rules and roles, and reviewing the logs of all of the above. Platform administrators shouldn’t approve requests for themselves or for systems they administer; rule changes should be approved by the rule’s business owner rather than by whoever edits the configuration; and administrative actions should be logged somewhere the administrators can’t alter and reviewed by someone outside the team, as the audit and reporting article argued. The same thinking applies to administrators of directories and identity providers, who can often do far more than the IGA platform knows about.

Preventing a conflict or detecting it

There are two broad ways to enforce SoD, and a working program needs both.

Preventive controls stop a conflict before it’s granted. When someone requests access, the platform simulates the result, compares the person’s future access with the ruleset and shows any conflicts to the approver before they decide, as the access request article described. When an assignment rule is about to grant a role automatically, the same check runs, and a conflicting grant is held rather than applied. When someone moves jobs, the combined old and new access is checked before anything is added. And when a role owner changes a role’s content, the change is checked against the ruleset before it’s published. Preventive controls are cheaper, because nobody has to clean up afterward, and safer, because the risky window never opens.

Detective controls find conflicts that already exist. The platform scans all current access against the ruleset on a schedule, usually daily or weekly, and reports what it finds. Certification campaigns show reviewers the conflicts a person holds alongside their access, so the reviewer is asked to decide about the combination rather than about each piece in isolation, as the certification article recommended. Detective controls are needed even with excellent preventive ones, because access arrives through paths the platform doesn’t control: an administrator who grants a role directly in an application, emergency access during an outage, a system that was connected after people had already accumulated rights in it.

The two kinds should also report to each other. A conflict found by detection that should have been stopped by prevention means a gap: a system without a connector, a request path that skips the check, a rule that isn’t evaluated at assignment. Each one of those is worth investigating, because it’ll keep producing conflicts until it’s closed.

Having access versus using it

A conflict in the report means a person could do both things. It doesn’t mean they did. That distinction, between access risk and what some vendors call exercised or transaction risk, is useful in two ways.

First, it helps prioritize. A program that finds 2,000 conflicts on its first run can’t fix them all at once, and starting with the people who’ve actually used both sides recently is a reasonable way to triage. Second, it’s often the fastest route to remediation. If a person has held vendor maintenance and payment release for a year but has only ever used payment release, removing vendor maintenance is unlikely to cause any trouble, and the person’s manager will agree to it more easily than to an argument about principle. Most ERPs and many SaaS applications record enough about who did what to support this kind of analysis, even if extracting it takes some effort.

Usage analysis also produces evidence for the cases that matter most. If someone held a critical combination and used both sides on the same transaction, that’s no longer an access question; it’s a transaction to be reviewed by someone outside the process, and possibly an incident. David’s investigation would have taken two hours instead of two days if anyone had been running that query.

The ruleset is never finished

An SoD ruleset describes processes and systems, and both change. A finance team reorganizes, a new treasury platform replaces the bank portal, an ERP is migrated to a newer version whose screens and authorization model are different. Every one of those changes can make rules obsolete, or leave new conflicts uncovered, without anyone noticing.

Rules therefore need the same discipline as any other controlled object. Each rule has an owner who reviews it at least once a year and whenever the process it covers changes. Changes to rules go through change control, with the old and new versions kept, so that the program can answer an auditor’s question about what the rule said last March. And any project that changes a business process or replaces a system should include, as a deliverable, an update of the affected rules and a test that they still detect what they’re supposed to. The finance case study later in this module looks at what happens when an ERP migration skips that step.

Worked example: a distributor’s first matrix

Back at David’s company, the audit committee asked for an SoD program within six months. The ERP vendor offered a generic ruleset with a little over 200 risks, and the first instinct was to load it and run it. The IGA team did that, as an experiment. The result was 9,400 conflicts across 380 users, which nobody could act on.

They started again from the processes. Over three weeks, the IGA analyst ran workshops with the owners of purchase to pay, order to cash, payroll, and record to report, and with the ERP security lead. For each process they mapped the steps, agreed on the functions and went through the matrix cell by cell. Many of the generic risks didn’t apply: the company didn’t use consignment stock, didn’t run its own payroll engine and didn’t manage fixed assets in the ERP. A few risks the generic set didn’t have were added, most importantly the combination of vendor bank data in the ERP and payment approval in the bank’s portal. They ended with 40 rules, which they then narrowed to 12 critical and high-severity rules to start with, and a list of the medium ones to monitor.

The first real run produced 2,300 conflicts. Analysis showed that about 70 percent of them came from three roles: an “AP super user” role that combined invoice posting and payment release, a “purchasing lead” role that could create and approve purchase orders, and a “finance support” role that had been used as a catch-all for years. Redesigning those three roles with their owners cut the findings to about 400. Usage analysis over the previous twelve months showed that most of the remaining people had used only one side of their conflict, and their managers agreed to remove the unused access, which brought the number down to 35.

Those 35 were the hard cases: a treasury team of three where people covered for each other, a regional warehouse with a single administrator, two integration users that genuinely needed to create and post. They couldn’t be fixed by removing access, and the company needed a way to live with them that an auditor would accept. That’s the subject of the next article. The preventive check was switched on in the request process and in role publishing at the same time, and over the following quarter the number of new conflicts dropped to a handful a month, each one reviewed before it was granted.

A shorter example: a fifteen-person startup

At the other end of the scale, a fifteen-person startup can’t separate everything, and shouldn’t try. The founder approves expenses, the single finance person both records and reconciles, and three engineers share the production on-call rotation.

What it can do is pick the handful of risks that would actually hurt and handle each one. The bank’s own dual-authorization feature can ensure that a second person approves every payment over a threshold, which covers the most dangerous combination without reorganizing anyone. Changes to vendor bank details can require a call back to a known number before they take effect. Payroll can be run through a provider whose changes the founder reviews each month. And production deployments can require a second engineer’s review in the code repository. None of this needs an SoD tool; it needs someone to have thought about the four or five combinations that matter and written down how each one is covered. As the company grows, those notes become the first version of its ruleset.

Common mistakes

The most frequent mistake is importing a generic ruleset and treating its output as the program. Generic rulesets are a useful checklist, but they reflect someone else’s processes, and running one unedited produces thousands of findings that nobody owns. The result is usually a program that’s switched off after its first report.

The opposite mistake is a matrix nobody maintains: hundreds of rules written by a consulting team during an implementation, with no owners, describing processes that have since changed. Rules without owners can’t be tuned, can’t be defended to an auditor and can’t approve exceptions, so every finding they produce ends up stuck.

Other common mistakes are evaluating only roles, which misses conflicts that sit inside role content or come from direct grants; ignoring systems without connectors, which is where cross-system conflicts hide; leaving out service accounts and integration users; and running only detective controls, so that the same conflicts are found and fixed every quarter because nothing stops them from being granted again.

What to measure

A few numbers show whether the program is working. The count of open conflicts, split by severity and by process, shows the size of the problem and should trend down. The share of open conflicts that have an approved mitigation or acceptance shows whether the remaining risk is managed or simply sitting there. The number of conflicts blocked or flagged at request time, compared with the number found by detection, shows whether prevention is doing its job; a rising share found by detection points to a path that skips the preventive check. The time from detection to resolution shows whether findings are being acted on. And the number of rules without a current owner, or not reviewed in the last twelve months, shows whether the ruleset itself is healthy.

Where this maps to standards

NIST SP 800-53 Rev. 5 has a dedicated control, AC-5 Separation of Duties, which requires organizations to identify the duties that need separating and to define access authorizations that support the separation; it works together with AC-6, least privilege. ISO/IEC 27001:2022 requires conflicting duties and areas of responsibility to be segregated in Annex A control 5.3. The COSO 2013 framework places segregation of duties among the control activities under principle 10, and that’s the framework most external auditors use when they test internal control over financial reporting for SOX section 404 under PCAOB AS 2201. SOC 2 addresses segregation of duties as a point of focus within its control activity criteria. And the formal definitions of static and dynamic separation come from the RBAC standard, ANSI/INCITS 359, maintained with NIST.

Recap

Separation of duties means no single person can carry a sensitive transaction from start to finish on their own, which in practice means keeping authorization, recording, custody and verification in different hands. Since those duties now exist only as permissions, SoD is an identity problem, and the thing to look for is the toxic combination: access that’s harmless piece by piece and dangerous together. Static SoD forbids holding both sides; dynamic SoD forbids using both on the same transaction, and usually lives in the application, so the ruleset should record which risks rely on it. A working ruleset is built in layers, from a business risk to functions to the entitlements and permissions that grant them, and it’s presented to the business as a conflict matrix built from real processes, with a severity, an owner and a reason for every rule. It covers critical access as well as combinations, it’s evaluated at the level of effective permissions, it looks across systems and at service accounts, and it applies first of all to the people who run IAM. Preventive checks at request, assignment, move and role design stop most conflicts; detective scans and certification catch the rest, and every conflict detection finds is a hint about a gap in prevention. Had the distributor’s clerk been checked against even one rule, vendor maintenance with payment release, the shrink film would never have been ordered, because the second grant would have stopped at the approver’s screen with a warning on it.

Three questions to test yourself

1. A person holds the role “AP clerk” and the role “treasury analyst,” neither of which conflicts with the other on paper. Under what circumstances could they still hold a toxic combination, and how would you find out?
2. Your purchasing application already stops users from approving purchase orders they created. Does that remove the need for a static SoD rule between creating and approving purchase orders? What would you record in the ruleset either way?
3. An integration user that loads invoices from a scanning service can create vendors and post invoices. Who should own that risk, and what would you change first?

Hands-on exercise

Pick a process you know well, from finance, HR, IT or software delivery.

1. List its steps and group them into five functions.
2. Draw a 5×5 conflict matrix and, for each of the ten pairs, decide whether holding both creates a real risk. For each pair that does, write the risk in one sentence and give it a severity.
3. For the most severe rule, list the entitlements or permissions that grant each function in the systems you know, and note whether any of them are held by service accounts.
4. Decide whether that rule should be enforced statically, dynamically inside the application, or both, and explain why.