Every guide to audit workpapers tells you the same things: state a purpose, document your population, support your conclusion. What almost nobody publishes is the thing juniors actually need — a complete, realistic testing workpaper you can read from cover to conclusion, with someone explaining why each element is there and what a reviewer is checking when they read it. Templates exist behind paywalls; real workpapers are confidential; so the craft gets transmitted by review notes, one bruise at a time.
This article is that missing artifact. Below is a fictionalized but structurally faithful control-testing workpaper — a terminated-user access revocation test, the kind performed in some form at nearly every company — presented section by section. The shaded excerpts are the workpaper; the commentary after each explains why the element exists, what good looks like, and the failure modes reviewers see constantly. Names, numbers, and systems are invented; the anatomy is the real thing.
The model file, section by section
- 1. The header block — identity, ownership, dates
- 2. Purpose and scope — one paragraph that governs everything
- 3. Control description and criteria
- 4. Population and completeness — the step that decides whether the test means anything
- 5. Sampling approach — parameters, seed, reperformability
- 6. Procedures and attributes tested
- 7. Results — the summary table and the exception
- 8. Exception analysis — the section that separates professionals
- 9. Conclusion — answering the purpose, exactly
- 10. Tick marks, cross-references, sign-offs
- 11. The same anatomy for a substantive test
- 12. The reviewer’s checklist
- 13. Review notes the draft drew
- 14. Software, retention and the regulator’s reading
- Frequently asked questions
1. The header block — identity, ownership, dates
| Workpaper ref | C-240.03 | Engagement | Logical Access Management Audit — FY2026 (ENG-26-014) |
| Control ref | AC-07 (per RCM, WP C-100) | Prepared by | D. Reyes, Senior Auditor — 08/03/2026 |
| Test period | 07/01/2025 – 06/30/2026 | Reviewed by | M. Okafor, Audit Manager — 08/11/2026 |
Why it exists. The header answers, at a glance: what file is this, which engagement and control does it belong to, who did the work, who challenged it, and when. The unglamorous fields carry real weight. The workpaper reference (C-240.03) places the document in the file’s architecture so every cross-reference elsewhere can land on it. The control reference ties the test back to the risk and control matrix — if you build RCMs in our free RCM Workbench, this is the row ID — which is what lets a reviewer trace risk → control → test → conclusion without asking you anything. And the two names with two dates are the review trail: under the Global Internal Audit Standards, engagement documentation and supervision are explicit requirements (Standards 14.6 and 12.3), and the prepare/review pairing is how a file evidences both.
Failure modes. Review dates that precede preparation dates (it happens, and external assessors screenshot it); “prepared by” fields naming someone who left the team; test periods that silently differ from the engagement’s stated scope period.
2. Purpose and scope — one paragraph that governs everything
Purpose: To determine whether control AC-07 — “Logical access of terminated employees and contractors is revoked in all in-scope systems within three business days of termination effective date” — operated effectively throughout the period 07/01/2025–06/30/2026. This test addresses risk R-12 (unauthorized access by separated personnel; see RCM at C-100) and supports engagement objective 2 per the planning memo at A-110.
Why it exists. One sentence of purpose disciplines the entire document: the procedures must serve it, the results must speak to it, and the conclusion must answer it — in its own words. Note the three anchors packed into the paragraph: the control’s verbatim definition (so nobody tests a paraphrase), the risk it mitigates (so the work is risk-based, not ritual), and the pointers to the RCM and planning memo (so scope decisions trace to their source). A workpaper whose conclusion answers a question its purpose never asked is the single most common structural defect in young files.
3. Control description and criteria
Control (per walkthrough at C-210): Upon a termination action in the HR system (Workday), an automated feed generates a deprovisioning ticket in ServiceNow within 1 hour. The IAM team disables the network account (Active Directory) and revokes access to in-scope applications (see systems list at C-215) per the ticket. Criteria: revocation completed within 3 business days of termination effective date, per Information Security Policy §6.4 (v4.2, effective 01/2025). Control owner: IAM Operations Manager. Frequency: each termination event (event-driven).
Why it exists. Two distinct things live here and must not blur: the control (what management does) and the criteria (the standard it is measured against, with its source and version). Citing “Policy §6.4 v4.2” rather than “company policy” matters because policies change mid-period — and when they do, the criteria section is where you documented which version governed which months. The walkthrough cross-reference (C-210) is deliberate separation of duties between documents: understanding lives in the walkthrough, testing lives here. Blending them produces the twelve-page workpaper nobody can review.
4. Population and completeness — the step that decides whether the test means anything
Population: All employee and contractor terminations with effective dates 07/01/2025–06/30/2026, obtained from Workday report “Terminations – All Types” run by the auditor on 07/08/2026 (parameters and extract at C-241): 214 records (168 employees, 46 contractors). Completeness and accuracy: (a) record count reconciled to Payroll’s final-pay register for the period (214 vs. 214, C-242); (b) period boundaries verified by inspecting the earliest/latest records; (c) report run by the auditor directly from the system of record — no management-prepared extract. One termination type (“conversion to employee”) reviewed and excluded with rationale at C-241.1 (identity continues; access transfer tested under AC-04).
Why it exists. Every conclusion you will write is a statement about this population, so the file must prove the population is real, complete, and correctly bounded. The reconciliation to an independent source (payroll) is the completeness anchor — terminations that HR forgot to process are precisely the ones most likely to still have live access, so a population drawn only from processed terminations would be blind exactly where the risk lives. Note also the quiet IPE discipline: the auditor ran the report, captured the parameters, and archived the extract. If a management-provided report had been used instead, this section would need testing of that report’s completeness and accuracy — information produced by the entity is never self-evidently reliable. The documented exclusion, with its rationale and a pointer to where the excluded risk IS covered, is what stops a reviewer’s “wait, what about…” before it starts.
5. Sampling approach — parameters, seed, reperformability
Method: Attribute sampling, zero-expected-deviation plan. Parameters: 90% confidence, 10% tolerable deviation rate → minimum n = 22 per department methodology §4.3; sample size used: 25. Selection: simple random selection of 25 of 214 records using mySampler (seed 20260708-C240, selection log and memo at C-243) — selection reperformable from seed. Evaluation rule (set at planning): control concluded effective only if zero deviations; any deviation to be investigated for cause and isolated-vs-systematic character before any conclusion.
Why it exists. This section makes the test reproducible — the difference between evidence and anecdote. The parameters state what the sample can and cannot prove (if the derivation is fuzzy, our guide to where 25, 40, and 60 come from is the companion read); the documented seed means any reviewer can regenerate the identical 25 records — our free mySampler stamps the seed on every export precisely for this line; and the evaluation rule written before selection is the integrity lock: it commits the team to what happens on an exception while nobody knows whether one exists. Deciding that rule after seeing results is how “one failure is probably fine” creeps into files.
6. Procedures and attributes tested
For each sampled termination, the auditor: (P1) agreed termination effective date to the Workday record; (P2) inspected the ServiceNow deprovisioning ticket for existence and creation timestamp; (P3) inspected the Active Directory account status and disablement timestamp from the AD change log (independently extracted, C-244); (P4) for the two highest-risk applications (Payments Portal, Data Warehouse), inspected application access logs for revocation date; (P5) computed business days from effective date to final revocation across all in-scope systems and compared to the 3-business-day criteria. Attributes: A1 — ticket generated; A2 — AD disabled within criteria; A3 — in-scope application access revoked within criteria.
Why it exists. Procedures are written as performed actions with named evidence sources — “inspected the AD change log,” not “verified access was removed.” Verbs matter: inspected, agreed, computed, observed describe what you did; verified, ensured, confirmed describe a conclusion and belong nowhere near a procedure line. Defining lettered attributes (A1–A3) before results keeps the results table honest — each item passes or fails per attribute, not on gestalt. And notice P5 does the arithmetic explicitly: “within 3 business days” is a computation, so the workpaper says who computed it and from what timestamps. The number of files that assert timeliness without ever showing the two dates is larger than the profession would like to admit.
7. Results — the summary table and the exception
| # | Emp/Ctr | Term date | A1 ticket | A2 AD (bus. days) | A3 apps (bus. days) | Result |
|---|---|---|---|---|---|---|
| 1 | EMP | 07/14/2025 | ✓ | ✓ (1) | ✓ (1) | Pass |
| 2 | EMP | 08/02/2025 | ✓ | ✓ (0) | ✓ (2) | Pass |
| … | … | … | … | … | … | 19 further items: Pass |
| 17 | CTR | 02/06/2026 | ✓ | ✓ (2) | ✗ (11) | Exception — see §8 |
| … | … | … | … | … | … | 3 further items: Pass |
| Totals: 25 tested — 24 pass, 1 exception (A3) | ||||||
Why it looks like this. One row per sampled item, one column per attribute, business-day counts shown rather than bare check marks — so the reviewer re-performs the judgment, not just the arithmetic. (The full 25-row detail sits in the file at C-245; a published article abridges, a workpaper never does.) The table states totals explicitly because summaries elsewhere — the findings sheet, the report — will quote this line, and every quoted number in an audit report must trace to a tabled total somewhere. One habit worth copying: the exception row points forward to the analysis section rather than resolving itself in a cramped cell comment. Exceptions deserve paragraphs, not margins.
8. Exception analysis — the section that separates professionals
Item 17. Contractor termination effective 02/06/2026. Ticket generated same day (A1 pass); AD disabled in 2 business days (A2 pass). Payments Portal access remained active until 02/23/2026 — 11 business days (A3 fail). Cause (per inspection of ticket history and inquiry with IAM Operations, memo at C-246): the portal is not integrated with the automated feed; revocation requires a manual task that was assigned to a queue with no coverage during a team transition. Inquiry and inspection of the queue backlog identified the same manual-task gap affected other portal revocations in Feb–Mar 2026. Character: not isolated — systematic for the non-integrated application. No compensating detection: the quarterly user access review (AC-09) would not run until 04/2026. Sample not expanded: cause is systematic to a definable sub-population (manual-revocation applications), so additional random sampling of the blended population would not sharpen the conclusion; instead, the full population of portal revocations for the period was obtained and analyzed (C-247): 9 of 31 exceeded criteria. Disposition: reported as Finding F-3 (High) — see findings summary at D-100; management action and validation approach per D-110.
Why it exists — and why this is the section that separates professionals. An exception is a fork: isolated error or systematic failure. This analysis shows the honest path: establish the facts, run cause to ground, test the isolated-vs-systematic question with evidence (not hope), and then choose the response that fits the answer. Because the cause was systematic to a definable slice, the right move was not “test 13 more” — mechanical sample expansion answers isolated-error questions, and this was not one. Pulling the entire affected sub-population converted a 1-in-25 anomaly into a defensible, quantified finding: 9 of 31. That is the judgment our sample-size guide’s exception rules point toward, applied in the wild. The disposition line then hands off cleanly to the findings architecture, and eventually to issue validation, which will one day need exactly this level of specificity to test whether the fix actually fixed.
9. Conclusion — answering the purpose, exactly
Conclusion: Control AC-07 operated effectively during the period for terminations whose in-scope access is revoked through the automated deprovisioning feed (24 of 25 sampled items; zero deviations among feed-integrated revocations). The control did not operate effectively for applications requiring manual revocation, where 9 of 31 portal revocations in the period exceeded the 3-business-day criteria (Finding F-3, High). Residual exposure for risk R-12 is elevated pending remediation; see D-110 for management’s action plan and planned validation.
Why it exists. Read the purpose from section 2, then this. Same control, same period, same terms — answered with a split verdict because the evidence demanded one. A conclusion is not a vibe (“control generally operating as intended”) and not a restatement of procedures (“testing was performed without exception, except as noted”); it is the purpose sentence, answered, with the population it actually covers and the boundary the exception drew. If you write one thing well in a workpaper, write this: reviewers read purpose, results totals, and conclusion first, and if those three do not lock together, nothing between them can save the file.
10. Tick marks, cross-references, sign-offs
| Mark | Meaning (this file) |
|---|---|
| ✓ | Attribute met per inspected evidence; source noted in item row |
| ✗ | Attribute not met; see exception analysis |
| ⊕ | Agreed to system of record (Workday) by auditor |
| Σ | Column footed / count reconciled by auditor |
| C-xxx | Cross-reference to supporting workpaper in this file |
Why it exists. Tick marks are compression, and compression only works with a shared dictionary — so the file defines its marks rather than assuming them. Keep the set small and boring; a workpaper with eleven exotic symbols is showing off, not communicating. Cross-references, meanwhile, are the file’s hyperlinks: purpose points to the RCM and planning memo, population points to extracts, the exception points to the cause memo and the findings sheet. A file wired this way answers reviewers’ questions before they form. For the fuller documentation doctrine — organization, retention, review evidence — our beginner’s guide to workpapers and documentation best practices go deep; this article is their missing worked example.
Final thoughts
Strip the fiction away and the model file teaches one lesson: a testing workpaper is an argument. Purpose states the claim to be tested; population and sampling establish what the evidence can support; procedures generate the evidence; results and exception analysis weigh it without flinching — including when it splits; the conclusion answers the claim in its own words; and the mechanics (references, marks, sign-offs) let a stranger audit the argument itself. That standard — a stranger can reperform the work and re-reach the conclusion from the file alone — is what the Global Internal Audit Standards’ documentation requirement (Standard 14.6) is really asking for, and it is the standard an external quality assessor, an examiner, or opposing counsel will apply without asking your permission. Build your next file against this anatomy and the review notes get shorter fast.
The same anatomy for a substantive test: a reconciliation workpaper
The model file above is a control test, and the anatomy transfers to substantive work with two changes: the purpose asks whether a balance or population is right rather than whether a control operated, and the results section reports differences in money rather than attributes in counts. Below is the abridged skeleton of a second workpaper from the same fictional engagement, a test of the bank reconciliation for the operating account, shown as a table so that the correspondence with the ten sections is visible.
| Section | Reconciliation workpaper (C-310.02) | What changed from the control test |
|---|---|---|
| Header | Ref C-310.02; account 1010 Operating Cash; period ended 06/30/2026; prepared D. Reyes 08/05, reviewed M. Okafor 08/12 | An account and a date replace a control reference and a period |
| Purpose | To determine whether the 06/30/2026 reconciliation of the operating account is complete, accurate and supported, and whether reconciling items are valid and timely cleared (risk R-04, misstatement of cash; engagement objective 1) | The question is about the balance and the reconciling items, not about operation over time |
| Criteria | Treasury Policy §3.2 v2.1: reconciliations prepared within 5 business days of month end, reviewed within 10, items over 30 days escalated | Policy still supplies the criteria; the test applies them to one period’s output |
| Population | All 47 reconciling items on the 06/30 reconciliation (total 1,284,300), obtained by the auditor from the treasury system; book balance agreed to the general ledger (C-311) and bank balance agreed to the bank statement obtained by the auditor (C-312) | Completeness is anchored by agreeing both sides to independent sources rather than by reconciling a count to payroll |
| Sampling | All items over 25,000 (11 items, 1,106,900, 86 per cent of value) tested; 10 of the remaining 36 selected at random (seed logged, C-313) | Value-weighted coverage plus a random layer replaces an attribute sample |
| Procedures | P1 agreed each item to source (cheque image, wire advice, deposit slip); P2 traced subsequent clearance on the July bank statement; P3 recomputed ageing; P4 inspected preparer and reviewer evidence and dates | Verbs unchanged: agreed, traced, recomputed, inspected |
| Results | 21 items tested, 20 agreed and cleared; one deposit in transit of 38,400 dated 06/29 not cleared by 07/31 | A money amount with an ageing, not a pass count |
| Exception analysis | Item traced to a customer cheque returned unpaid on 07/03 and not reversed; cause: returned-item notification routed to a shared inbox with no owner; population check found two further returned items unreversed (total 61,200, below materiality but systematic); Finding F-5 (Medium), D-100 | The isolated-versus-systematic fork is the same; the quantification is in money |
| Conclusion | The reconciliation is complete and accurate except for returned items, which are not detected or reversed timely; book cash at 06/30 is overstated by 61,200 (below materiality); reconciliation preparation and review met policy timing | Answers the purpose in its own terms, with the amount and the boundary |
| Mechanics | Same tick-mark legend; cross-references to C-311, C-312, C-313, D-100 | Unchanged |
The transfer shows what the anatomy is for. A reader who understands why the control-test file has a population section understands why the reconciliation file agrees both balances to independent sources: both are proving that the thing being tested is the whole thing. The evidence standards for issue closure guide applies the same logic to remediation evidence, which is where this reconciliation finding will eventually be tested again.
The reviewer’s checklist for this file
Reviewers do not read workpapers front to back. They read purpose, results totals and conclusion, check that the three lock together, then work through the file with a checklist that is nearly identical across functions. The one below is the checklist that produced the review notes in the next section; the receiving review comments guide covers what to do when they arrive.
| Area | Check | Where the model file answers it |
|---|---|---|
| Identity | Reference, engagement, control, period, preparer and reviewer with dates in the right order | Header, §1 |
| Purpose | Control quoted verbatim; risk and objective referenced; period stated | §2 |
| Criteria | Source document, section and version cited; any mid-period change addressed | §3 |
| Population | Source of record; auditor-run or IPE-tested; count reconciled to an independent source; period boundaries verified; exclusions documented | §4 |
| Sampling | Method, parameters, size derivation, seed, selection log; evaluation rule set before selection | §5 |
| Procedures | Written as performed actions with evidence sources; attributes defined before results | §6 |
| Results | One row per item; attribute-level outcome; totals stated; exception pointed forward | §7 |
| Exceptions | Facts, cause, isolated-versus-systematic determination with evidence, response chosen to fit, disposition to the findings sheet | §8 |
| Conclusion | Answers the purpose in its own words; covers the population actually tested; states the boundary any exception drew | §9 |
| Mechanics | Tick marks defined; cross-references resolve; sign-offs complete | §10 |
| Stand-alone test | Could a stranger reperform the work and reach the conclusion from the file alone? | The whole file |
| Report linkage | Does every number the report will quote trace to a tabled total here? | §7 and §8 |
Review notes the draft drew, and how they were cleared
The model file is the version after review. The draft that preceded it drew six notes, which are typical of what a first-year senior’s file collects and are worth seeing because they show the difference between the draft and the final. Each was cleared in the file itself, never in an email.
| Note (as written by the reviewer) | What was wrong in the draft | How it was cleared |
|---|---|---|
| “Purpose says ‘terminations’; population excludes conversions. Where is that decided?” | The exclusion existed in the extract but not in the narrative | Exclusion paragraph added to §4 with rationale and a pointer to AC-04 |
| “Who ran the Workday report?” | Report source stated, auditor-run not stated | Added the run date, the auditor, and the archived parameters at C-241 |
| “Evaluation rule?” | Sample size and seed documented; no statement of what a deviation would mean | Evaluation rule added to §5, dated before selection from the planning memo |
| “P2 says ‘verified ticket’. Verified how?” | A conclusion verb in a procedure line | Rewritten as “inspected the ServiceNow deprovisioning ticket for existence and creation timestamp” |
| “Item 17: one exception, sample not expanded, no reason given.” | The systematic determination was in the senior’s head | Exception analysis rewritten with the cause memo (C-246), the sub-population pull (C-247) and the reasoning for not expanding |
| “Conclusion reads ‘generally effective’. Effective for what?” | A blended verdict on a split result | Split conclusion written in the purpose’s terms, with the boundary and the finding reference |
Two features of the clearance deserve a note. Every clearance changed the file rather than answering the reviewer, because a review note answered in a message leaves the file as weak as it was. And the reviewer’s notes were questions rather than instructions, which is the style the first engagement as in-charge guide recommends for anyone reviewing a file for the first time: a question makes the preparer find the answer, and the file is better for it.
Workpaper software, retention and the regulator’s reading
Three practical points round out the model file. First, the anatomy is independent of tooling: a file in a dedicated audit management platform, a shared drive with a folder convention, or the software the function is evaluating all hold the same ten sections, and the platform’s value is in enforcing the cross-references and sign-offs rather than in the sections themselves. Second, retention follows policy and regulation rather than habit: the file must survive, unaltered after sign-off, for the retention period the methodology manual sets (commonly five to seven years, longer where regulators require), with any post-sign-off change logged as a new version rather than an edit. Third, regulators and external quality assessors read files the way the reviewer’s checklist does, with one addition: they look for the places where the file says something the report does not, or the report says something the file cannot support. The what regulators expect guide describes that reading in detail; the model file is built to survive it.
Frequently asked questions
What should an audit workpaper contain?
A header identifying the file, engagement, control or account, period, preparer and reviewer; a purpose stating the question in the control’s or account’s own terms; the criteria with source and version; the population with evidence of completeness; the sampling method, parameters and seed; procedures written as performed actions; results with totals; an exception analysis that resolves the isolated-versus-systematic question; a conclusion that answers the purpose; and defined tick marks, cross-references and sign-offs.
What is the stand-alone standard for workpapers?
That a competent stranger could reperform the work and reach the same conclusion from the file alone, without asking the preparer anything. It is the practical meaning of the documentation requirement in Standard 14.6 of the Global Internal Audit Standards and the standard an external quality assessor or regulator applies.
How should an exception be documented in a workpaper?
Establish the facts, run the cause to ground, determine with evidence whether the exception is isolated or systematic, choose the response that fits (sample expansion for an isolated question; pulling the affected sub-population for a systematic one), and record the disposition to the findings sheet. The exception row in the results table points forward to this analysis rather than resolving itself in a cell.
What verbs belong in audit procedures?
Inspected, agreed, traced, recomputed, observed, inquired: verbs that describe what the auditor did and against what evidence. Verified, ensured and confirmed describe conclusions and belong in the conclusion section, if anywhere.
How does a substantive workpaper differ from a control-test workpaper?
The purpose asks whether a balance or population is right rather than whether a control operated; completeness is anchored by agreeing the tested amounts to independent sources; coverage is often value-weighted with a random layer rather than an attribute sample; and results and exceptions are reported in money with ageing rather than as pass counts.
Who reviews workpapers and what do they check?
The engagement lead or manager, and at some functions a second-level reviewer for high-risk files. They check that purpose, results totals and conclusion lock together, then work through a checklist covering identity, criteria, population completeness, sampling, procedure wording, exception analysis and cross-references, and they write notes as questions that the preparer clears in the file.
Related guides
- Audit tick marks — symbols, meanings and a standard legend for the marks in section 10.
- Audit review notes — what a reviewer writes on a file like this one, and how to clear it.
- Handling audit test exceptions — the decisions behind the exception analysis in section 8.
- Documenting analytics as audit evidence — queries, scripts, completeness and the workpaper that lets a reviewer rely on the result.
- Receiving review comments — how to read, clear and learn from the notes on a file like this one.
- Your first engagement as in-charge — reviewing files like this one for the first time.
- Evidence standards for issue closure — what proof of remediation requires when Finding F-3 is validated.
- Issue validation in internal audit — the process that will one day retest this control.
- The internal audit methodology manual — where documentation and retention standards are set.
Leave a Reply