Resources
How Do I Tell Whether a Segregation of Duties Conflict Needs Action?
A segregation of duties review is also called an analysis or an assessment. This page uses the terms interchangeably.
A potential conflict is a question, not an answer. To answer it, check what the user can really do in the system, why they need that access, and what else is in place. Write down what you confirmed and what is still unknown. Then the Controller decides what happens next. This is the Examine Results step.
Why does this step matter? Start with a picture.
Picture a Controller with a list of 60 potential conflicts. That list came from the Highlight Conflicts step. Two potential conflicts look the same on paper. Each shows a user who can add vendors and release payments. For the first user, one of those rights was switched off months ago. For the second user, both rights are live, and nobody else ever sees the payments. The potential conflicts match. The situations do not.
Think of the smoke alarm again. In the last step, it beeped. Now you walk to the kitchen. Most of the time it is burnt toast. Sometimes it is not. You cannot tell from the hallway. This step is the walk to the kitchen.
Think of a key card. The label on the card says “Facilities.” The label does not tell you which doors the card opens. You need to ask what it really opens, whether it is switched on, and whether a guard stands at the door. A role name is like that label.
What should I check for each potential conflict?
Work through five questions. Ask the right person for each one.
| Question | Who can answer | Why it matters |
|---|---|---|
| What can this user really do? Count rights from every role, including custom roles. | System administrator | A role name does not show the real rights. |
| Are those rights active today? | System administrator | A potential conflict may rest on an old right that no longer works. |
| Does a limit apply, such as an amount limit? | System administrator or process owner | A limit may block some of the risky transactions. |
| Why does this user need this access? | Process owner | Daily work may need it. Need is not the same as acceptable risk. |
| How does the work flow, and who else sees it? | Process owner | It shows whether one user can start and finish the same transaction alone. |
If another person reviews the work, note it. Do not rely on it yet. The next step, Confirm Safeguards, checks whether that review really happens.
Which facts can change the answer?
Four facts often change how a potential conflict looks. A role may sound broad but hold narrow rights. A limit may block the larger transactions. A second person may see the work. Or the potential conflict may rest on access that is no longer active. Each fact needs support. A verbal answer is a starting point. If you cannot support a fact yet, mark the item open. Do not guess.
Who does what?
| Person | Their part |
|---|---|
| Controller | Chooses which potential conflicts to examine first. After the facts are in, decides what the risk means for the business, and writes down the reason. |
| System administrator | Confirms what each right really allows and whether it is active. Runs any extra reports. |
| System owner | Approves any later change to the system. |
| Process owner | Explains the work, who handles each step, and why the user has the access. |
IT reports the technical facts. IT does not decide the business risk. The Controller does not need to read permission codes. Ask the system administrator to explain each right in plain words.
What do I write down?
For each potential conflict, keep a short note. Include the user, the system, the rights you checked, where the proof came from, the business reason, any open questions, and who checked. Give each item a plain status, such as “Needs review,” “Evidence pending,” or “Ready for the Controller’s decision.” These are working labels for your own worksheet.
What if we still do not know?
Give each missing answer to one person. Ask for the data, the approval record, or the process explanation that would settle it. Write down the limits of what you know. If an item looks urgent, follow your company’s normal escalation steps. The Controller can then decide with those limits in plain view.
What does this step not do?
This step checks facts. It does not show that anyone misused their access. It does not change any access. It does not decide whether the risk is acceptable. It does not test the safeguards, which come next. This guide explains a review process. It is not an audit.
A worked example
This example is an illustration, not a real event. An accounts payable specialist named Priya can change vendor bank details and release payments. She was shown as a potential conflict in the last step. The system administrator confirms both rights are active, and no amount limit applies to her. The process owner says a second person approves bank detail changes. The company has a written policy that says so. Nobody has seen proof that the approval happened. The team writes the status as “Evidence pending,” names who will ask for the proof, and moves the item to the next step. The team does not conclude that the safeguard works. It also does not conclude that it fails.
Frequently asked questions
Is a potential conflict the same as a problem?
No. A potential conflict starts the review. The conclusion comes after the facts are checked.
Who checks what a user can really do?
The system administrator. They can see the real rights. The Controller does not need to pull the reports.
Do I need to examine every potential conflict at once?
No. Start with the potential conflicts that involve payments or payroll. Write down which potential conflicts you have not reached yet.
What if the user needs the access for daily work?
That is useful to know. It is not the end of the question. The Controller still decides whether the risk is acceptable, and may rely on a safeguard. The next step covers how to check one.
Can we skip to fixing access?
You can, but you may fix the wrong thing. Facts first helps you change what needs changing. Any change should go through the system owner’s approval.
Your next step
This week, take three potential conflicts from your payment process. For each one, answer the five questions in the table above. Then use the free How to Review Segregation of Duties Conflicts: Examine Results Worksheet to record the answers, the proof, and the status. You do not need to give an email address to get it.
Need the potential conflicts first? Read Find Conflicting Duties in User Access. New to the method? Start with How Do I Run a Segregation of Duties Review? Ready for the next step? Read the Confirm Safeguards guide.
Top internal controls and SOX education for growing companies.