There is a sentence that appears in more ITGC workpapers than it should: “Evidence obtained; no exceptions noted.” It is not wrong, exactly. It is just not an answer to the question the workpaper was opened to settle.
Obtaining evidence and establishing control effectiveness are different achievements. The first means somebody sent you a file. The second means you know what the population was, that the evidence covers the period, that the attributes you defined were met, and that the deviations you found were investigated to the point where you understand them. Most ITGC findings that surface late in an engagement — or worse, in an inspection — are not caused by a missing control. They are caused by a conclusion that ran ahead of its evidence.
This playbook is about closing that distance. It covers the mistakes that produce weak ITGC conclusions, an interactive challenge built from five scenarios you have probably met, a fieldwork sequence you can follow, and a downloadable toolkit of the templates underneath it. Everything here is educational: the examples are synthetic, and none of it is a substitute for your own methodology.
These recur across organisations, auditors and ERP platforms, and every one of them is a reasoning error rather than a technical one.
1. Treating inquiry as evidence. “The control owner confirmed the review is performed quarterly” records what someone said. It is a starting point for testing, not a result of it. Inquiry tells you where to look; inspection and reperformance tell you what is there.
2. Accepting a population you cannot defend. If you cannot explain how a listing was generated, who generated it, when, and with what parameters, you cannot say it is complete — and every sample drawn from it inherits that uncertainty. An incomplete population does not produce a slightly weaker conclusion. It produces no conclusion.
3. Testing a point and concluding on a period. A user listing extracted in July describes July. A control that is supposed to operate throughout the year needs evidence that spans the year. This is the single most common reason an ITGC conclusion does not survive review.
4. Reading “no exception found” as “the control operated effectively”. In a sample of 25 from a population of 4,000, finding nothing tells you something useful about the rate of deviation. It does not tell you the rate is zero, and the workpaper should not say so.
5. Recording missing evidence as a pass. This is the one that matters most, and it is the thread running through the whole of this article. If the evidence does not permit you to test, the honest result is inconclusive — a scope limitation. It is not a pass, and it is not a control failure either. Collapsing those three outcomes into two is how a conclusion becomes a fiction.
Five scenarios, one per control area. Each has a defensible answer and three plausible alternatives — plausible because they are what practitioners actually do under time pressure, not obvious filler. Choose an answer and you get the reasoning, the evidence to request, the procedures to run, and the conditions for concluding pass, fail or inconclusive.
Everything runs on this device. No answer, score or input is sent anywhere, no account is needed, and there is no AI call involved. You can disconnect your network and it still works.
Order matters here. Several of these steps are only meaningful if the one before has been done, which is why a checklist worked out of sequence produces the mistakes above.
Write down what the control is supposed to prevent or detect, in a sentence, before you look at any evidence. “Access is removed when employment ends” is an objective. “Review the leavers report” is a task. If you cannot state the objective, you cannot define an attribute, and you will end up testing whatever the evidence happens to show.
The population is the complete set of items the control should have operated on during the period. Establishing it means knowing the source system, the query or report definition, the parameters, the extraction date, and who ran it. Proving it means agreeing it to something independent — a leavers list to payroll, a change log to the deployment pipeline, an account listing to the directory.
Where no independent source exists, say so in the workpaper. A population that cannot be corroborated is still testable; it just carries a limitation that the conclusion has to carry too.
Ask one question of every piece of evidence: does this cover the whole period under review, or a moment in it? A quarterly control needs four quarters. An automated configuration needs evidence that it was in force throughout, not just on the day you looked. This is where point-in-time evidence quietly becomes a period conclusion.
Sampling approach follows the control's frequency and the population size. What matters for the workpaper is not which method you chose but that the rationale is recorded and the selection is reproducible. A reviewer should be able to see why 25 and not 10, and should be able to re-select the same items.
An attribute is a yes/no question you can answer from evidence. For leaver access: does a disablement record exist; is it within the control window; did any authentication occur after the termination date. Define them first. Deciding what “pass” means after seeing the evidence is how conclusions get written backwards, and it is almost impossible to spot in review.
“Please send the user listing” produces whatever is convenient. Name the system, the parameters, the extraction date, and ask who produced it. If you are testing ERP user access, the difference between a listing filtered to active users and a complete listing including disabled accounts is the difference between finding your exception and not.
Before you write anything in the conclusion field, work through the evidence: is it system-generated or manually prepared; if manual, is it corroborated independently; does it cover the period; is it enough to test every attribute you defined? Any “no” here is a reason to pause, not a footnote.
A deviation is a potential exception until you understand it. Investigation means establishing the cause, not collecting an explanation. “The extract must be stale” is an explanation. The account status history is a cause.
Not all evidence carries the same weight, and the hierarchy is worth being explicit about.
System-generated beats manually prepared. An extract produced by a query against the source system, with the parameters recorded, is stronger than a spreadsheet someone assembled. The spreadsheet may be perfectly accurate; the point is that you cannot tell from the spreadsheet.
Independent beats self-reported. Evidence from a party with no interest in the conclusion carries more weight than evidence from the control owner. This is where a common error hides: a screenshot and a confirming email from the same person are two artefacts from one source. They do not corroborate each other.
Complete beats illustrative. A screenshot shows one state of one screen at one moment, chosen by whoever took it. It is useful to corroborate an extract and poor as a substitute for one.
Evidence handling also has a confidentiality dimension that is easy to overlook when you are focused on sufficiency — user listings, access extracts and change logs are often the most sensitive files an engagement touches. We covered the handling side of that separately in AI, audit evidence and data confidentiality.
When testing produces a deviation, four things need to happen in order, and skipping any of them weakens everything downstream.
The test of a workpaper is whether an independent reviewer could reperform your work from it alone. That means recording the purpose, the population and how its completeness was established, the sample and its rationale, the attributes, the results item by item, the exceptions, the conclusion and the rationale for it, and — the field most often left empty — what was not covered.
Here is the same test written two ways. Both describe identical fieldwork.
The second version is longer because it says what the first one assumed. Note in particular that it reports an inconclusive item as inconclusive instead of rounding it to a pass, and that it names what the test did not cover. Teams moving toward structured, reusable workpapers often find the format itself does some of this work — we looked at that in audit workpaper automation.
Download the practical fieldwork checklist, evidence request templates, control testing worksheet, exception log, workpaper documentation template, evidence sufficiency checklist and reviewer challenge checklist.
Your playbook is ready.
Automation is good at the parts of ITGC testing that are mechanical: reconciling a leavers list against a user extract, normalising timestamps across systems, flagging accounts that appear in one population and not another, drafting the first version of a workpaper from structured results. These are real hours, and they are hours that add nothing to professional judgement.
What automation cannot do is own a conclusion. It does not know whether your population was complete, it cannot tell the difference between an absent control and absent evidence of a control unless you have already made that distinction for it, and it cannot be accountable for what the workpaper says. The useful principle is simple: AI can accelerate the work. It should not own the conclusion.
Two practical consequences. First, any automated output used in a workpaper should be traceable back to the underlying evidence, so a reviewer can check the chain rather than the summary. Second, the person signing the workpaper is accountable for it regardless of what produced the draft — which means reading it as critically as you would read a junior's work, not more trustingly because a machine was involved.
If you want to see what that looks like in practice, the GrcAI Assistant runs an audit workflow against synthetic evidence so you can watch where the automation stops and judgement starts.