How Do I Find Conflicting Duties in User Access?

By SOD Check practitioners, the SOX and internal controls team at SOD Check · Last updated 3 November 2026

A segregation of duties review is also called an analysis or an assessment. This page uses the terms interchangeably.

A potential conflict is a pair of access rights that lets one person do two jobs that should be split, such as adding a vendor and approving payments to that vendor. To find them, compare the access you captured against a short list of rules written for your own processes. Treat each match as a question to check, not proof that anything went wrong. This is the Highlight Conflicts step.

Why does this step matter? Start with a picture.

Picture a Controller holding the files from the first step. There are hundreds of users and dozens of roles. Every role name sounds sensible, like “Vendor Maintenance” and “Payment Approver.” Nothing looks wrong. But one person holds both roles. That person can add a vendor and approve payments to it. No single file shows this. It only shows when someone looks across the files.

Now picture one role called “Accounts Payable Lead.” The name is fine. Inside the role, the rights include creating a vendor and releasing a payment. The conflict sits inside one role, so it is easy to miss.

Think of a smoke alarm. It beeps when it senses smoke. It does not tell you the house is on fire. You walk to the kitchen and look. A potential conflict is the beep. This step finds the beeps. The later steps are the walk to the kitchen.

What does a potential conflict look like?

These are examples. Not every system allows each pair, and not every pair carries the same risk.

Which duties should be split?

Start with the process, not the role names. For each key process, ask four questions. Who can create or change? Who can approve? Who can release or pay? Who reviews?

Then write down the combinations one person should not hold alone. Each one is a rule, written as a short sentence: “The same person should not be able to create a vendor and approve a payment.” Start with payments, payroll and journal entries.

The Controller knows the business risk, so the Controller leads on the rules. IT helps match each sentence to the real rights in the system.

How are the rules applied?

Take the files from the Capture Data step. For each user, look at every right they hold. Count rights that come from roles and rights that were granted directly. If a user holds both sides of a rule, mark that user as a potential conflict. Look in two places.

Include every system in scope: core, custom and connected systems. Rights that cross from one system to another may need extra data or a mapping from IT before you can compare them. Write down any system you leave out, so the result is not overstated.

What do I do with a long list of potential conflicts?

A long list is normal. Do not read it top to bottom. Work it in four moves.

1. Group the potential conflicts by process, such as payments or journal entries.

2. Sort each group by how much harm a mistake could cause. A simple High or Medium is enough to start. This is only a way to decide what to look at first. It is not a final risk assessment. The Controller decides the risk in the later steps.

3. Name one person to check each item.

4. Keep the source of each potential conflict and write down what you do not know yet.

Do not use the number of potential conflicts as a score for fraud or weak controls. A long list of small potential conflicts can matter less than one large one.

Who does what?

The Controller does not need to read raw permission codes. Ask the system administrator to explain each right in plain words.

What does this step not do?

This step finds possible conflicts. It does not show that anyone misused their access. It does not say whether another control already covers the risk. The next step, Examine Results, looks at what each person with a potential conflict can really do. This guide explains a review process. It is not an audit.

A worked example

This example is an illustration, not a real event. A customer service specialist named Taylor can maintain customer records and approve refunds. The rule says one person should not do both, so Taylor has a potential conflict. The Controller does not conclude anything yet. Taylor’s potential conflict is a question, not an answer. The team writes down the potential conflict, the process it affects and who will check it. Then the item moves to the next step, Examine Results, where IT confirms what Taylor’s access really allows. Whether a second person reviews large refunds is a question for the Confirm Safeguards step.

Frequently asked questions

Does a potential conflict mean someone did something wrong?

No. A potential conflict means the access allows both jobs. It does not show that either job was done wrongly.

Does a long list mean high risk?

Not by itself. Look at what the access allows and what safeguards exist.

Can one person appear more than once?

Yes. A person can hold several potential conflict pairs. Review them together.

Can we remove every conflict?

Not always. A small team may not be able to split every job. In that case, the team needs another control and a written management decision. The Confirm Safeguards step covers this.

Do I need to check every system at once?

No. Start with the system that handles payments or payroll. Write down which systems are left out.

Your next step

This week, pick one process, such as payments, and write down the pairs of tasks one person should not do alone. Then use the free How to Find Conflicting Duties: Highlight Conflicts Worksheet to list each potential conflict, the process it affects, and who will check it. You do not need to give an email address to get it.

Need the files first? Read What Reports Do I Need for a Segregation of Duties Review? New to the method? Start with How Do I Run a Segregation of Duties Review? Ready for the next step? Read the Examine Results guide.

Top internal controls and SOX education for growing companies.