Resources
What Should I Record After a Segregation of Duties Review?
A segregation of duties review is also called an analysis or an assessment. This page uses the terms interchangeably.
After a segregation of duties review, write down what was checked, what the Controller decided, and why. Link the proof to each item. Name who owns the next step and set a due date. A good record lets someone who missed the meeting understand the decision. This is the Keep a Record of Decisions step.
Why does this step matter? Start with a picture.
Picture a car with no service record. A new mechanic asks what was done last year. Nobody remembers. Some work gets done twice. Some work never gets done. A record fixes that. It tells the next person what happened and why.
Now picture a Controller who moves to a new role. The successor opens the review file and finds one line: “Reviewed, OK.” The successor cannot tell what was checked, who decided, or what proof exists. So the review starts again from zero. A clear record saves that work.
What belongs in the record?
Keep one entry for each item. These parts are a good start.
| Part | What to write | Example (illustration) |
|---|---|---|
| Item number | A short ID | SOD-014 |
| System and process | Where the item sits | Payments system, payment process |
| Potential conflict | The pair of tasks | Create a vendor and approve a payment |
| What was checked | The rights and the proof reviewed | IT confirmed both rights. Approval records requested |
| Decision and reason | What the Controller decided, and why | Keep the item open until proof of a second review arrives |
| Owner and due date | One person and one date | Accounts payable owner, by the 15th |
| Status | A plain label | Evidence pending |
| Proof of completion | What shows the work was done, and the date closed | Review record saved, closed on the date written here |
Do not put sensitive access details in a public or shared template. Keep real records in approved, secure storage, for as long as your company’s policy says.
What kinds of decisions might appear?
An item may need more review. A safeguard may need more proof. The Controller may ask for an access change, which IT carries out after the system owner approves it. Or the Controller may keep the access and rely on a safeguard, if the facts support that choice. These are possible outcomes. They are not results about any real company.
How do I write a clear reason?
Avoid a note like “Reviewed, OK.” Say what the team checked and why the decision makes sense. Here is an illustration: “IT confirmed the access. The process owner described the payment approval step. The Controller asked for proof of a second review before closing the item.” That note shows the steps and the next action. It does not claim that the safeguard worked.
Who signs off, and who does the work?
| Person | Their part |
|---|---|
| Controller | Decides the business risk and writes down the reason. |
| System administrator | Carries out an approved access change, or confirms that it was made. |
| System owner | Approves any change to the system. |
| Process owner | Gathers proof or adjusts a business step. |
Give each action to the person who can do it. Do not ask IT to approve the risk for management.
How do I track items that stay open?
Use simple working statuses: “More review needed,” “Evidence pending,” “Change approved,” and “Closed with support.” For every open item, name an owner and a due date. At follow-up, check that the work was done and save the proof. If the plan changes, update the reason and the new date. Do not close an item just because someone sent an email.
What should the next reviewer be able to see?
Someone who was not in the meeting should be able to answer five questions.
1. What the potential conflict was?
2. What did the team check?
3. What did the Controller decide?
4. Why?
5. What happened next?
If the record cannot answer all five, add detail.
What does this step not do?
A record does not fix an access problem. It does not replace the Controller’s decision. It does not prove that a safeguard works. It shows what was decided and what was done about it. This guide explains a review process. It is not an audit.
A worked example
This example is an illustration, not a real event. A user can add vendors and approve payments. IT confirms both rights. The Controller asks for proof of a separate payment review. The log shows “Evidence pending,” names the accounts payable owner, and gives a due date. The proof arrives. The Controller reads it, writes the decision and the reason, and sets the status to “Closed with support.” The log keeps the proof and the date. A year later, a new team member reads the entry and understands the story in a minute.
Frequently asked questions
Should I save the source reports?
Keep records as your company’s policy requires and as the agreed scope allows. Use approved, secure storage.
Does a decision log replace fixing the access?
No. It records decisions and follow-up. It does not make the change.
Who can close an item?
Follow your company’s sign-off rules. Keep proof of completion with the entry.
How much detail is enough?
Enough for someone who was not there to answer the five questions above.
Do I need a special tool?
No. A shared log that your team can find, update and protect is a good start.
Your next step
This week, take one item from your latest review and write its entry using the table above. Then use the free How to Record Segregation of Duties Decisions: Keep a Record of Decisions Worksheet to keep the rest in one place. You do not need to give an email address to get it.
Need the safeguard step first? Read How Do I Know Whether a Control Reduces a Segregation of Duties Risk? Want the full process? Read How Do I Run a Segregation of Duties Review?
Top internal controls and SOX education for growing companies.