, ,

Annotated Workpaper Examples: A Model Testing File From Cover to Conclusion

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

Workpaper refC-240.03EngagementLogical Access Management Audit — FY2026 (ENG-26-014)
Control refAC-07 (per RCM, WP C-100)Prepared byD. Reyes, Senior Auditor — 08/03/2026
Test period07/01/2025 – 06/30/2026Reviewed byM. 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/CtrTerm dateA1 ticketA2 AD (bus. days)A3 apps (bus. days)Result
1EMP07/14/2025✓ (1)✓ (1)Pass
2EMP08/02/2025✓ (0)✓ (2)Pass
19 further items: Pass
17CTR02/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

MarkMeaning (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-xxxCross-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 honestly — 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.

Comments

Leave a Reply

Discover more from internalauditguide.com

Subscribe now to keep reading and get access to the full archive.

Continue reading