Two auditors test the same control and reach the same conclusion. One conclusion survives review, a regulator and a change of audit firm. The other falls apart the first time someone asks a hard question.
The difference is almost never the conclusion. It is the evidence behind it.
The three questions your evidence must answer
Every piece of evidence in a workpaper should answer these without anyone needing to ask:
Where did this come from? Not “the client provided it”, which system, extracted by whom, when, and did you watch it happen?
Is it complete? Could items be missing, and how would you know if they were?
Is it what it claims to be? Does this actually show the control operating, or something adjacent that resembles it?
Most evidence problems are failures of the second question.
The completeness trap
This is where inexperienced auditors get caught, and it is worth being blunt about it.
You ask a system administrator for a list of all privileged accounts. They send a spreadsheet. You sample from it, test each one, find everything appropriate, and conclude the control is effective.
The problem: your entire population came from the person whose access you are auditing. If an inappropriate account existed, the simplest way to pass your test is to not include it in the file. You would never detect that, because you have nothing to compare against.
There are three ways out, in order of strength:
- Observe the extraction. Sit with them, in person or on a call, and watch the query run against production.
- Reconcile to an independent source. Compare the total against a system-generated count, a licence report, or the identity platform.
- Test in the other direction. Take a sample from the system itself and confirm each item appears in the population you were given.
The third is the one people forget, and it is often the most revealing.
Screenshots and their limits
Screenshots are not worthless, but they are weaker than most people treat them.
A screenshot shows a setting existed, somewhere, at some point. It does not establish which environment, or whether it was changed shortly before or after. Anyone can screenshot a development system.
If a screenshot is your only option, strengthen it: capture the full window including the system identifier and any environment banner, note who took it and when, and record the navigation path you used to reach it. Better still, take it yourself during a screen share.
Exceptions are not negotiations
When you find an exception, you will usually be offered an explanation. That is normal and often given in good faith. But an explanation and a resolution are different things.
The test is simple: does the explanation change what the evidence shows?
If a change was deployed without approval and the emergency process was documented and followed, with retrospective approval on file, then it was not an exception. The evidence changed.
If the response is “that was urgent, we approved it verbally,” the evidence has not changed at all. The control requires documented approval. It did not happen. A reasonable business justification for a control failure is still a control failure.
Recording it does not make you difficult. It makes your conclusion defensible when someone reviews it two years from now with no memory of the conversation.