A walkthrough is the auditor following one real transaction through your process, step by step, from the event that starts it to the record that ends it, at the screens of the people who perform each step. They are not testing whether your controls worked all year; that comes later, with samples. They are building a documented picture of how the process actually runs, where it could go wrong and which controls stand at those points, so they can decide what to test and what to write up as a design gap.
Good preparation takes about two hours: a one-page flow of what actually happens, the systems and who can show them, the control points and the evidence each leaves, the exceptions path, and the people who do each step. In the room, show the live system on a real recent transaction, describe what happens rather than what the procedure says, and name the workarounds before the auditor finds them. A gap you name is a finding about a control. A gap the auditor uncovers after you described the control as working is a finding about the control and a question mark over everything else you said.
This guide is written from the auditee’s chair. The auditor’s version already exists on this site: the walkthrough question bank and script auditors work from, the walkthrough documentation template they fill in afterwards, and the explanation of why a walkthrough is not a test of controls. This one follows your day instead: what the auditor is building, the preparation, the live session, the questions that feel like traps, the gaps between procedure and practice, the corrections, the requests that follow, and a full worked walkthrough at a hypothetical distributor where a gap surfaces mid-session. It sits in the Being Audited? collection next to the guide to what internal auditors ask in interviews.
In this guide
- What the auditor is building
- The two-hour preparation plan
- The one-page process flow
- Running the live walkthrough
- The questions that feel like traps
- When the procedure says one thing and you do another
- What to do when you do not know
- Correcting a misunderstanding before it becomes a finding
- After the walkthrough: the requests and the document to review
- Mistakes that create findings
- Worked example: MidState Beverage vendor onboarding
- Questions readers ask
- Related guides
What the auditor is building
The output of a walkthrough is a file, not an impression. By the end of the session the auditor needs to write a narrative of the process as performed, the points where it could go wrong, a control (or an explicit “no control”) at each point with the evidence it produces, the handoffs between people and systems, and the differences between the written procedure and what they saw. From that they write a design conclusion and a test plan.
| Component | What it looks like in the audit file | What the auditor needs from you | Where it goes next |
|---|---|---|---|
| Boundaries and the flow as performed | A numbered narrative, typically six to ten steps for a standard process and more for a complex one, each with role, action, system, input, output and timing | Agreement on where the process starts and ends, then the performer showing each step on the live system | The narrative and flowchart that every later question rests on |
| Systems, interfaces and handoffs | A handoff register: what passes from whom to whom, how, and what could go wrong in transit | The systems list and the points where data is re-keyed, exported, emailed or uploaded | Interface and report testing |
| Risk points (“what could go wrong”) | Specific errors or abuses at specific steps: duplicate, unauthorized, wrong amount, late, missing, fictitious | Your answers to “what happens if” and “has this ever gone wrong,” plus the exception paths | The engagement risk assessment (Standard 13.2) and the control map |
| Controls at each risk point | Who performs it, what they check, how often, what evidence it leaves, which risk it addresses; preventive or detective, manual or automated | The control shown operating on the walked transaction and the evidence it left, not a description of it | The design conclusion; the key controls selected for testing (Standard 13.6) |
| Documented-versus-actual gaps | A gap log: procedure says, actually observed, performer’s explanation, control implication | Candor about undocumented, unperformed and reassigned steps and workarounds, in your words | Design findings, procedure updates, or a note that practice beats the document |
| Design conclusion and test plan | Designed effectively (test it), effective except as noted, or not designed effectively (report it, usually untested) | Nothing further; this is the auditor’s judgment, resting entirely on the facts above | The work program, the preliminary findings, the report |
Two things follow. The controls that count are the ones that would prevent or catch a specific error at a specific point; “procurement reviews everything” lands nowhere on the map. And the gaps between the procedure and what you showed are the most useful thing the session produces, because they say where the written control list is fiction, which is a problem you want solved before an external auditor or a regulator finds it.
If the walkthrough belongs to a SOX program, its shape comes from PCAOB AS 2201, the standard external auditors follow for audits of internal control over financial reporting and the model SOX programs typically copy. Paragraph .37 describes a walkthrough as following a transaction from origination through the company’s processes and information systems until it reaches the financial records, using the same documents and information technology that company personnel use, through a combination of inquiry, observation, inspection of documentation and re-performance. Paragraph .38 has the auditor question personnel at the important processing points about what the prescribed procedures and controls require, to find where a necessary control is missing or badly designed. Paragraph .43 says walkthroughs that include these procedures are ordinarily sufficient to evaluate design effectiveness, and the note to paragraph .50 says inquiry alone does not provide sufficient evidence of a control’s effectiveness. Translated: your words are the weakest evidence in the room; the screen, the document and the re-performed check are the stronger kinds. The SOX guide for control owners covers what follows in that world.
Internal audit’s own requirements point the same way: an engagement risk assessment (Standard 13.2), a work program that sets out the procedures (Standard 13.6), and information that is sufficient, reliable and relevant (Standard 14.1). The walkthrough is where the engagement risk assessment meets reality and the work program gets written. Hold onto one distinction, explained in the test of design versus operating effectiveness guide: a walkthrough supports a conclusion about design, not about operation over a period. If the auditor leaves believing a control is well designed, the next step is a sample. If they leave believing it is missing or badly designed, the next step is a finding, usually without any testing. The design conversation in the room therefore deserves more of your attention than any later argument about sample results.
The two-hour preparation plan
Two hours is enough for a process you run. It is not enough to learn a process you only supervise, which is the reason the performer belongs in the room. Do the preparation before you open the procedure document, because reading the procedure first makes everyone describe the procedure. The plan assumes a 60–90 minute walkthrough of one process with two or three performers.
| Minutes | Task | Output | Why it matters to the auditor |
|---|---|---|---|
| 0–15 | Reread the notification. Confirm the boundaries: the trigger that starts the process and the record that ends it. Note the objective and any named risks. | Scope in one line, in your words, plus any boundary question | The auditor opens by agreeing boundaries; a mismatch wastes the first twenty minutes |
| 15–45 | Write the flow from memory: role, action, system, input, output per step. Then compare with the procedure and mark every difference. | Draft one-page flow with differences flagged | The differences are the gap log in advance; you decide how each is introduced |
| 45–60 | List every system, spreadsheet, mailbox and folder the process touches. Confirm who present can open each, and which screens show personal or restricted data to mask. | Systems list with a presenter for each | Walkthroughs stall on access more than anything; a system nobody can open means a second session |
| 60–75 | Mark the control points: where an error would be prevented or caught. For each, write who, what is checked, when, and the evidence left. Mark the ones with no evidence. | Control points on the flow | A control is recorded with its evidence; one without is recorded as a gap or “inquiry only” |
| 75–90 | Write the exceptions path and the workarounds: rush items, rejects, reversals, overrides, manual entries. For each, who authorizes it and roughly how often. | The exceptions and workarounds page | Undocumented steps live in exception paths; “what happens when it fails” is followed by “show me the last one” |
| 90–105 | Pull two real recent transactions: one plain, one that took an exception path. Note identifiers and where the records sit. | Transaction identifiers | A real item answers hypotheticals; the auditor will still pick their own from a listing |
| 105–120 | Brief each performer for five minutes. Sort the room or call, a shareable screen, the procedure version in force, the one-pager. | Performers briefed; logistics set | Performers who know what the hour is for answer plainly; the rest guess, hedge, or defer to you |
Expect the auditor to select the transaction from a population listing rather than accept yours; the auditor’s walkthrough guide tells them never to take the item the owner offers. Have your two ready anyway. If their pick is a one-off (a reversal, a vendor created during a migration, an item from before a process change), say so at once and offer a typical one beside it. Do not argue that their item is unrepresentative; show both and let the contrast make the point.
Briefing the performers
The brief should contain rules, not answers; rehearsed answers are easy to hear, and they move the auditor from understanding mode into verification mode, which is slower for everyone. Here it is as you would say it to the two or three people who will be at the screens. The longer version, for a whole team facing a whole engagement, with the three-minute talk and the rules on one page, is in briefing your team before an audit.
- What the hour is for. The auditor wants to see how the process runs, on screen, on a real item. It is not a test of you.
- Show, then explain. Open the record first and talk while it is on screen.
- Say what you do. If it differs from the procedure, say what you do. I will handle the procedure question.
- Answer what was asked, then stop. If they want more they will ask.
- “I don’t know” is a complete answer. Add who would know, or that you will find out.
- Do not guess about other teams. Describe what you receive from them and what you send.
- I will not answer for you. If I add something, it is context, not a correction.
The one-page process flow
The auditor’s narrative for a standard process runs to somewhere between six and ten steps, and a complex multi-system process to more (those are the tiers the auditor-side guide works in). Your one-pager should be written at the same resolution: finer and you are documenting keystrokes, coarser and whole controls disappear inside a step called “processing.” Write each step as a role, a verb and an object, in the present tense, in the order it happens. Use roles, never names; a name in place of a role is a signal auditors are trained to notice, because it usually means the step depends on one person. The one-pager is not a procedure. It is the map you hand over at minute two so that everything the auditor sees afterwards has somewhere to go. If the process has no usable documentation at all and you have weeks rather than hours, the one-pager grows into the three-document kit described in documenting your process before an audit: a one-page narrative, a control list and an evidence map saying where the proof of each control lives.
| Column | What to write | Example entry (hypothetical expense-claim process) |
|---|---|---|
| Step | One numbered line per step: role, verb, object. Keep only steps that move the item forward or check it. | 3. Line manager approves the claim in the expense system |
| System and record | Where the step happens and the record it creates or changes | Expense system; status changes to Approved with approver ID and timestamp |
| Input and output | What arrives at the step and what leaves it | In: submitted claim with receipts. Out: approved claim queued to payables |
| Control point | Whether anything here would prevent or catch an error, and what is checked: amount, limit, duplicate, authority, coding | Yes: approver checks receipts against lines and policy limits; system blocks self-approval |
| Evidence left behind | The artifact a stranger could pull later: approval log, reconciliation, signed form, report, ticket | Approval record with approver, date and time; policy-breach flag if triggered |
| Variants and exceptions | The other routes an item can take here and who authorizes each | Approver absent over five days: delegate approves. Over the manager’s limit: next level. Rejected: returns to submitter |
A control point is a place where a specific error would be prevented or caught. For each candidate, answer four questions: who performs it, what exactly they compare or check, when, and what it leaves behind. If you can answer the first three but not the fourth, you have found what the auditor will find, and the choice is yours to make before the session rather than during it: start producing evidence now (an annotation, a sign-off field, a saved report) or be ready to say plainly that the control leaves no trace. The control description examples show the who-what-when-evidence standard auditors write to, and the guide to preventive, detective and corrective controls explains why they ask whether each one stops the error or only finds it later. Where another team performs a control, point to them; neither claim it nor disown it.
Running the live walkthrough
The first two minutes are yours. State the boundaries as you understand them and check they match the auditor’s. Hand over the one-pager and say what it is: the process as performed, with the places you already know it differs from the procedure marked. Introduce the performers by role, then offer to step out: many auditors prefer to see the performer alone, because managers tend to answer for their staff, and the offer costs you nothing. If you stay, the session belongs to the auditor and the performer; your job is to keep it moving, add context when asked, handle the procedure questions, and watch for misunderstandings forming. If you leave, ask to come back for the gap discussion at the end, which is where the owner’s account matters.
Everything else is a version of one rule: show the thing. Open the auditor’s transaction in the system it lives in, not in a slide and not in the procedure. At each step let the record speak first and explain second. At each control, open the evidence it left (the approval stamp, the match result, the reconciliation) and then describe what the performer checked. At each branch point, say which route this item took and name the others: “This one went the standard path. Rush requests arrive by email and skip the portal; that path differs from step two.” Answer hypotheticals with the last real instance and offer to open it. Introduce workarounds yourself, in one breath: “Here the procedure says X. What we do is Y, because the system cannot do Z. Here is the spreadsheet, who can edit it, and what we check it against.” The Dekker field guide makes the point that procedural adaptation is normal work rather than deviance, and that the gap between the walkthrough and the policy usually says something about the system the people are working in; an auditor who hears the reason with the workaround writes a different finding from one who finds the spreadsheet in the data three weeks later.
Pace matters more than people expect. The auditor is writing in a fixed grammar of role, action, system, input and output, and marking control points as they go. Let the typing catch up before the next step; when they stop you over something small (the exact field, the exact report name, who else has that menu), that is the narrative being built accurately.
- Say “here is what happens,” not “the process is.” The second phrase invites a description of the design; the first keeps you in the room.
- Let silence sit. After “what could go wrong here,” auditors wait for the second answer. Give it if there is one; do not fill the pause with reassurance.
- Do not oversell a compensating control. Name it, show it, state its frequency, and let the auditor weigh it; the compensating controls guide shows how.
- Do not vouch for other teams’ controls. “Finance checks that” is a claim you cannot show; “we send it to finance and receive a confirmation, here is one” is a fact.
- Keep conclusions out of your mouth. “That’s a material weakness” and “that’s immaterial” are the auditor’s words, and either one in yours makes the later conversation harder.
- Manage the screen. Mask personal or restricted data the step does not need. Auditors must protect what they gather (Standard 5.2), and senior management is expected to support their unrestricted access to the records they need (Standard 6.3), so refusing to show a record is rarely right; limiting the screen to what the step requires usually is.
Remote sessions obey the same rule with more friction: one performer shares at a time, from the live system, notifications off, access tested beforehand, transaction identifiers in the chat. Recording is unusual; if anyone proposes it, the rule is ask first, since most organizations prohibit recording internal meetings without permission, and ask what it is for and how long it is kept. If you want a record, ask the auditor to confirm the key points and requests in writing afterwards instead. The interview guide covers recording, who attends and the other remote questions.
The questions that feel like traps
None of these are traps. Each maps to something the auditor must establish: a risk point, a control, an override path, a means of detection, a dependency on one person, a piece of evidence. The answers that cause trouble claim more than you can show. The right-hand column is what we hear, and what we do next, when the answer goes that way. These fourteen are the ones that arrive at the screen during a walkthrough; the wider set asked across interviews and fieldwork, grouped by area, is in 60 questions internal auditors ask process owners.
| Question | What the auditor is establishing | A good answer | The answer that creates work or a finding |
|---|---|---|---|
| “Walk me through what happened with this one, from the start.” | The flow as performed | The performer, step by step, on screen, naming the system at each step | A manager’s summary from memory; a tour of the procedure |
| “What happens if this is wrong, missing or late?” | Whether the risk point has a control, and whether it prevents or detects | What actually happens, with the last instance: “The match fails and it sits in the exceptions queue; here is one from last week” | “That can’t happen,” or “the system wouldn’t allow it,” without showing the setting |
| “Who can override this?” | The override path, who holds it, whether overrides are visible afterwards | The roles with the authority, where overrides are recorded, who reviews them, roughly how often it happens | “Nobody,” when the access list says otherwise; “only me,” as reassurance |
| “How would you know if this had gone wrong?” | Detection: the report, reconciliation or review that would surface it, and how soon | The specific report, who looks at it, when, and the last time it caught something | “We would notice”; “the vendor would call”; “it has never happened” |
| “Can you show me the last one?” | Turning a described exception path into an observed one | Open it. If it takes a minute to find, say so and find it | “I’d have to dig for that,” then silence; describing it instead of opening it |
| “Who covers when you are out?” | Key-person dependency; whether the backup has access and knows the steps | The backup role, when they last did it, whether their access matches yours | “It waits for me”; “my manager has my password” |
| “Who else can do this step?” | Access versus responsibility; segregation of duties | The roles with access, and whether any of them also performs an incompatible step | Who should be able to, rather than who can |
| “Is that written down anywhere?” | Whether the step is in the procedure and, if not, which of the two is right | “No. The procedure predates the system change; the practice is right and the document needs updating,” or the reverse | Claiming it is documented; blaming the document’s owner |
| “How often do you do this?” | The real frequency, which drives how the control is tested | The real frequency, including slips: “Weekly, though in month-end weeks sometimes the following Monday” | The procedure’s frequency, if that is not what happens |
| “Where is the approval kept?” | Whether approval evidence exists somewhere inspectable | The location, shown: workflow, signed form, email folder, with who and when | “They would have approved it”; approvals that live only in a chat tool |
| “How was this report produced?” | Information produced by the entity: source, parameters, completeness, editing before use | The source system, who runs it, the parameters, whether it is touched in a spreadsheet afterwards | “It comes from the system,” when it is a spreadsheet someone maintains by hand |
| “Who set this tolerance or rule, and when did it last change?” | Configuration ownership and change control over automated controls | The owner, the current value, where the change history lives, the last change you know of | A guess at the value; “IT handles that” |
| “Has this ever gone wrong? What happened?” | Loss history and whether the control improved afterwards | The instance, what was found, how, and what changed | “Not that I know of,” from someone who would know; a story that stops before the fix |
| “What would stop someone from doing X?” | Fraud and misuse points: payments, master data, custody of assets | The preventive control if one exists, or “nothing at that step; it would be caught at Y, which happens on Z” | Indignation; “our people wouldn’t do that” |
The fourteen questions fall into three families, each with one answering rule. Hypotheticals (“what happens if”) are answered with the last real instance, opened on screen, because a real item ends the hypothetical. Authority questions (“who can”) are answered from the access list and the configuration, not from policy, because the auditor will reconcile your answer to the system’s within the week; the segregation of duties guide shows what they do with the difference. Detection questions (“how would you know”) are answered by naming the report or reconciliation, its timing, and the last time it caught something. If it never has, say so: a detective control with no catches in years is either watching a very clean process or not operating, and the auditor would rather hear you raise that than discover it.
When the procedure says one thing and you do another
Every mature process has drifted from its document. Systems change, people leave, a step written for a paper form makes no sense in a workflow tool. The auditor expects this; the documentation template they use has a gap log with columns for “procedure says,” “actually observed” and “performer’s explanation.” What they do not expect, and do not forgive easily, is being told the procedure’s version while the transaction on screen shows the practice.
The reason goes to how findings are built. Under Standard 14.2 a potential finding is the difference between criteria (what should be) and condition (what is). When your procedure is the criteria and your practice is the condition, every drift is a candidate finding. But the criteria are not fixed. If the practice is better than the document, the right outcome is a procedure update, and you can say so in the room. If the document is right and the practice has slipped, say that, and say what you will do. What you cannot do is leave the auditor to work out which one you believe.
| Situation | Say | Do not say | What the auditor does with it |
|---|---|---|---|
| Undocumented step (you do something the procedure omits) | “The procedure skips this. Here is what we do and why it is needed.” | Nothing, hoping it passes | Logs a gap; usually a procedure update, sometimes a control worth crediting |
| Unperformed step (the procedure has a step nobody does) | “Nobody has done this since the system started doing the match. Here is the setting that replaced it.” | “We do that,” hoping the sample agrees | Checks the replacement. If it works, a documentation point; if nothing replaced it, a design gap |
| Reassigned step (a different role does it) | “The procedure says the supervisor; the senior analyst does it because of X. The supervisor still reviews Y.” | The procedure’s version | Tests whether the actual performer is independent of what they check; segregation matters more than the title |
| Workaround (spreadsheet, email approval, manual entry around a system limit) | “The system cannot do X, so we keep it here. This is who can edit it and how we check it.” | “It’s temporary”; hiding the file | Treats the workaround as part of the process; checks access, version control and the check over it |
| Threshold or tolerance differs from the procedure | “The procedure says 5%; the system has been 10% since the change two years ago. Here is the setting and the ticket.” | The procedure’s number | Compares the current value with the risk; asks who approved the change |
| Timing differs (monthly review done quarterly) | “Documented as monthly; done quarterly because X, and we accept the longer window,” or “it slipped and I will fix it” | “Monthly” | Asks whether the real frequency still addresses the risk; a knowing deviation reads very differently from a concealed one |
| Backup or coverage differs | “When I am out, the team lead does it with their own access. The procedure names a role that no longer exists.” | “Someone covers” | Checks the backup’s access and competence |
| Procedure made obsolete by a system change | “The document describes the old system. Here is a marked-up version with the current steps.” | “It’s basically the same” | Uses your marked-up version as the criteria and logs the stale document |
The aspirational answer is the single most expensive mistake in this guide. When a performer describes the control as the procedure writes it and the walked transaction shows otherwise, the auditor does not just record a gap. They re-weigh everything else they were told, extend the follow-up requests, and often expand the sample for anything resting on that person’s account. The what-not-to-say guide lists the phrases that trigger this. The principle: a candid gap is written up on its merits; a concealed one is written up on its merits, with the concealment in the cause statement and in every judgment the auditor makes about your area afterwards.
What to do when you do not know
You will be asked things you do not know: a configuration value, who else holds a role, what another team does with your output, when a rule last changed. There are three good answers and one bad one. The bad one is a confident guess, because the auditor writes it down as fact under your name and finds out a week later that it was wrong, which costs more than the gap in knowledge ever would.
- “I don’t know; that is the system owner’s step. Let’s get them.” When the person who knows is reachable in the hour. A two-minute call beats an entry on the follow-up list.
- “I don’t know. I will find out and send it by tomorrow.” For anything that needs a lookup. Say the date, keep it, and send evidence rather than a sentence.
- “I believe it is X, but check it before you rely on it.” When you have a working belief. The qualifier tells the auditor to record a belief, not a fact.
Keep your own parking lot during the session (question, who will answer, by when) and read it back at the end so both sides hold the same list. Then make sure “I don’t know” is not written down as “no control”; they are different facts. If a performer cannot say whether a report is reviewed, the accurate record is “performer unaware; review to be confirmed with the manager,” not “no review performed,” and it is fair to ask in the room, “how are you noting that?”
Correcting a misunderstanding before it becomes a finding
A walkthrough misunderstanding travels along a fixed pipeline: notes become the narrative and gap log, the gap log feeds the design conclusion and test plan, the tests produce exceptions, the exceptions become preliminary findings, and those become the draft report. The life of a finding guide follows that path. Every stage adds a reviewer, a document and a position someone must retreat from, so the cost of a correction climbs with time. Standard 13.1 expects communication with management throughout the engagement, and a function that follows it gives you the chances in the table; your part is to use the earliest one.
Misunderstandings come in three kinds. A factual one (wrong role, missed step, misheard frequency) is fixed with the fact and the evidence. An interpretive one (the auditor believes no control exists where one exists elsewhere, or in another form) is fixed by showing the other control and letting them judge whether it covers the risk. A judgment one (facts agreed, adequacy of the design disputed) is not fixed in the walkthrough at all; it is argued at the validation meeting with evidence, as the guide to disputing a finding properly sets out. Spending the walkthrough on the third kind while the first two go uncorrected is the common failure. Agree the facts first; the condition sentence the auditor eventually writes rests on them, and the condition-writing guide shows how precisely it will be stated.
| Moment | What to do | What it can still fix | What it can no longer fix |
|---|---|---|---|
| In the room | “I think that may have gone down as X; what actually happens is Y,” and show it | Almost anything: a wrong step, a missed control, a misheard frequency, a role recorded as a person | Nothing; the file is not yet written |
| Same day, by email | One message to the lead auditor: the fact, the evidence attached, the wording you suggest | Facts misheard or misstated; a control the performer forgot to mention | A gap observed on the real transaction; that happened, and the file will say so |
| Walkthrough documentation review (in most functions, within a week) | Mark factual corrections in the narrative, control list and gap log, with evidence; leave the conclusions alone | The description of process and controls; the performer’s-explanation wording; anything recorded from inquiry alone that you can now evidence | The auditor’s design judgment, which is argued later with evidence |
| Preliminary finding or validation meeting | Bring evidence of facts, compensating controls and anything already fixed | The accuracy of the condition; the cause; credit for a compensating control; acknowledgment of remediation under way | The existence of a documented gap supported by evidence |
| Draft report | Written management comments through the formal process | Wording, factual precision, the rating within the methodology’s definitions, your response | The scope, and findings supported by tested evidence |
| After the final report | Request a correction under the function’s errors-and-omissions process | A factual error in the issued report (Standard 11.4: correct and recommunicate) | A difference of judgment rather than fact |
The method is the same at every stage: one message, the fact in a sentence, the evidence attached, the wording you propose. “Step 6 records the callback as performed by the analyst who keyed the bank details. It is performed by the second analyst; the callback form (attached) carries her initials and the system log (attached) shows a different approver ID. Suggested wording: ‘A second vendor master analyst performs the callback and activates the record.’” Ten minutes to write; it removes a segregation finding that would take a month to unwind. Correct facts, not conclusions, since an email that argues the rating before the facts are agreed gets filed under “management pushback,” and correct once, completely, rather than in a drip.
After the walkthrough: the requests and the document to review
Expect a request list within a day or two. In most engagements it runs to between six and a dozen items (practitioner judgment, not a statistic), nearly all predictable from what was shown. The PBC survival guide covers running requests through one coordinator without losing your week; this table is narrower: the requests that come specifically out of a walkthrough, and how to make the list shorter before it arrives.
| Typical request | Why the auditor asks | What to send | How to shorten it |
|---|---|---|---|
| Copies of the items observed on screen | Observed items must become retained evidence; the file cannot rest on “we saw it” | Exports or screenshots with system name, user, date and record identifier visible | Capture them during the session and send them the same day |
| Population listing (every item in the period) | The test sample is selected from a complete population, not from items you choose | A system extract with parameters, run date and row count | Ask which fields and exactly which period before running it |
| Configuration evidence (tolerances, match settings, duplicate checks, workflow rules) | Automated controls are evidenced by settings and change history, not inquiry | Configuration screens with system and date visible, plus the change log for those settings | Pull the settings you named on the one-pager before the session |
| Access list for the system or role | “Who can do this” is answered by the system, not the org chart | The current access report by role and user, with run date | Request it from the system owner the day the walkthrough is scheduled; it is always asked for |
| The last several instances of a review or reconciliation | To see what evidence of review looks like before deciding how to test it | The reviewed items as they exist: signed, annotated or workflow-approved; never re-created | Decide now what evidence each review leaves; if none, say so rather than manufacture it |
| The procedure in force, with version and approval | The criteria the walkthrough is compared against | The document with version, owner, approval date and marked-up changes | Have it ready before the session |
| Exception or override log for the period | Exception paths are where risk concentrates; the auditor needs to size them | The log, with how it is produced and whether it can be edited | Know how many exceptions the period held before you are asked |
| Report production details for any report used as a control | Information produced by the entity must be shown complete and accurate before anyone relies on it | The report, the query or parameters, who runs it, whether it is modified before use | Name source and parameters the first time you show the report |
Three of these deserve a sentence more. Copies of observed items are requested because the auditor’s evidence inventory marks each item “copy” (retained) or “observed” (seen on screen, not retained), and observed is acceptable for a walkthrough but never for a test; the guide to what counts as audit evidence shows what a screenshot needs to carry (system name, logged-in user, date and record identifier) to be accepted first time. Populations are requested because the sample has to come from everything; the sample size guide explains where the usual 25, 40 and 60 items come from, and a filtered list means the test is repeated. Report production details are requested because of the IPE problem: a report used as a control is only as good as the query behind it, and a spreadsheet someone edits before review is not a system report. For the rest, the rule from the audit evidence guide holds: inspection beats inquiry, and the file beats the description of the file.
The walkthrough documentation you should ask to review
Most functions will share the narrative and control list for factual confirmation; the auditor-side guidance on this site tells them to clear facts, not conclusions, with the performers and the owner. If it is not offered, ask: “Could I see the narrative and the gap log to confirm the facts before you rely on them?” You are checking facts and wording, not arguing judgments, and you should return it in two or three business days (a practitioner norm). Check six things.
- The steps and their order. A missing step is usually a missing control.
- Roles, not names. A person’s name in a step records a dependency on that person.
- Each control description against what was shown. Who, what is checked, when, and the evidence; a control described more generously than it operates is a liability for you at testing.
- The performer’s explanation. It should be in words the performer would recognize as their own.
- Anything recorded from inquiry alone. If a control was only described in the room, send the evidence now so the entry can rest on something inspectable, and send copies of items that were only observed on screen.
- Every “no control” entry. Where a control exists elsewhere in the process or in another team, attach it and say where it sits.
Do not rewrite the narrative into the procedure’s language, soften an accurately recorded gap, or add conclusions of your own. The owner who returns two factual corrections with evidence and confirms the rest as accurate has set the tone for everything the fieldwork guide describes next.
Mistakes that create findings
Some findings are about controls. These are about walkthroughs: they would not exist, or would be smaller, if the session had gone differently. The middle column is the conclusion the auditor draws, which is rarely the one the owner meant to create.
| Mistake | What the auditor concludes | Do this instead |
|---|---|---|
| Presenting from slides or the procedure instead of the system | The owner describes the design; practice is unverified; a second session is needed | Open the system on a real item in the first five minutes |
| The manager answers every question for the performers | Only one account is captured; the inconsistencies surface in testing | Introduce, frame the boundaries, then let the performer talk |
| Showing one specially chosen clean transaction | Representativeness is doubted; the auditor picks their own and the clean one is ignored | Offer two, including one that took an exception path, and accept the auditor’s pick |
| Hiding a workaround that is visible in the data | It is found in testing, and the finding says “not disclosed during the walkthrough” | Name it, show it, explain why it exists and what checks it |
| Describing the control you wish you had | The sample contradicts the description; the control and the owner’s account are both questioned | Describe the control as performed, including when it slips |
| “The system won’t let you,” without showing the setting | Inquiry only; if nobody can find the setting the control is treated as unverified | Show the configuration, or say “I believe it blocks that; I will get the setting” |
| Guessing about another team’s step | A wrong fact enters the narrative under your name; the other team contradicts it | “That step is finance’s; from our side we receive X and send Y” |
| Agreeing to a control you do not perform (“yes, we review that”) to end a line of questioning | The review is tested, the evidence is absent, and the finding gains “control not performed” as its cause | “We receive that report; nobody reviews it formally” |
| Arguing the design conclusion in the room | The facts are left half-established; the auditor concludes on what they have | Agree the facts in the room; take the design argument to the validation meeting with evidence |
| Letting a misunderstanding stand because correcting it felt rude | It becomes a draft finding and costs far more to unwind | “I’d like to fix one thing before we move on” |
The pattern: the auditor rates what they can verify and treats what they cannot verify as absent. Almost every mistake above converts something verifiable into something that must be taken on trust, and trust is not among the qualities Standard 14.1 asks of information: sufficient, reliable, relevant. It is also the argument for clear control ownership before the audit arrives: a control with a named owner who knows what evidence it leaves needs very little explaining.
Worked example: MidState Beverage vendor onboarding
Everything here is hypothetical: the company, the people, the systems, the numbers. MidState Beverage is a regional beverage distributor. Internal audit’s purchase-to-pay engagement includes vendor onboarding, and the notification asks for a 75-minute walkthrough of “new vendor request to payment-ready record, including subsequent changes to bank details.” The process owner is Renata Okafor, procurement operations manager. The performers are Tom Brandt and Ana Reyes, the two vendor master analysts. The auditor is Priya Natarajan, a senior auditor in her second week of fieldwork.
Monday afternoon: the two hours
Renata wrote the flow from memory before opening the procedure, which was last revised two years ago and still describes a paper form. Comparing the two, she found three differences and wrote them on a separate page in the order she wanted to raise them. First, the procedure requires a callback to the vendor at an independently sourced phone number before any bank details go live. For original setups, that happens. For changes to an existing vendor’s bank details flagged urgent, meaning accounts payable is holding a payment, the analysts have been confirming by email to the contact named on the change request and releasing the change the same day. Second, the weekly vendor master change report reaches her by email every Monday; she reads it, but nothing records that she did. Third, the system blocks a second vendor with the same tax ID, a control the procedure never mentions because it postdates the document. Her one-pager, condensed:
| Step | System and record | Control point | Evidence left behind | Variants and exceptions |
|---|---|---|---|---|
| 1. Buyer submits new-vendor request with tax form and bank letter | Procurement portal; request VR-nnnn | Portal will not submit without the tax form (automated) | Request record with attachments and timestamp | Depot managers may submit for local services; a few urgent requests arrive by email |
| 2. Procurement manager approves the request | Portal; approval stamp | Approval authority; checks justification and whether an existing vendor covers the need | Stamp with user ID and time | Delegate approves when the manager is out, set in the portal |
| 3. Analyst checks for duplicates | ERP vendor master | Automated block on duplicate tax ID; analyst also searches by name | System message only if the block fires; none for the name search | None |
| 4. Analyst creates the record in Pending status | ERP; vendor number; change log | Field validation only | Change log: creator, date, fields | None |
| 5. Analyst enters bank details from the bank letter | ERP; change log | None here; verification follows | Change log | None |
| 6. Second analyst calls the vendor at an independently sourced number, completes the callback form, activates the record | ERP activation; callback form in the onboarding folder | Independent callback; a different person activates | Form with date, number source and initials; ERP log shows a different approver ID | Urgent bank changes to existing vendors: email confirmation to the contact on the change request, same day |
| 7. Weekly change report sent to the procurement operations manager | ERP report by email | Review of all creations and bank changes (detective) | None | None |
| 8. Portal notifies the buyer; first purchase order can be raised | Portal and ERP status Active | None here; downstream three-way match in accounts payable | Status change logs | None |
She confirmed that Tom and Ana could open the portal, the ERP and the onboarding folder from the meeting room, asked the ERP administrator for the vendor master access list (knowing it would be requested), pulled two recent vendors, one plain setup and one with a bank change, and briefed each analyst for five minutes. She told them she would raise the urgent-change practice herself if it did not come up, and that if it did, they should describe it exactly as it happens. She also emailed Priya to say she would frame the boundaries and then step out if Priya preferred to work with the analysts alone; Priya asked her to stay for the procedure questions and let the analysts answer the rest.
Tuesday, ten o’clock: the session
| Moment | What was asked | What was said and shown | What went into the auditor’s notes |
|---|---|---|---|
| Opening | “Let’s start with the listing of vendors created since July. I’ll pick one.” | Priya chose vendor 70311, a pallet supplier set up three weeks earlier. Renata: “Fine. I also have 70288, a plain setup, and 70102, which had a bank change two weeks ago, if you want the change path.” | Boundaries agreed. Owner offered an exception-path item unprompted. |
| Step 1 | “Can a request be submitted without the tax form?” | Tom opened VR-2291, showed the attachments, then a blank form rejecting submission without one. | CP1 automated, observed. Configuration evidence to request. |
| Step 2 | “Who approved this one, and who can approve when she is out?” | The stamp showed the category lead as delegate during the manager’s leave. Tom: “The delegate is set in the portal; I can’t change it.” | CP2 observed. Request delegation settings and approval history. |
| Step 3 | “How do you check it’s not already a vendor?” | Tom: “I search the name.” Priya: “Only the name?” Tom: “Yes.” Renata: “There is also a system block on duplicate tax IDs. Tom would only see it if it fired. I’ll send you the setting.” | CP3: name search (no evidence) plus automated tax-ID block, described by owner; configuration needed before crediting. |
| Steps 4–5 | “Who else can create vendors or change bank details?” | Tom: “Me and Ana. And the ERP administrator, technically.” Renata: “The access list reaches you this afternoon.” | Access list requested; administrator access to check against the change log. |
| Step 6, setup | “Show me the callback for this vendor. Where did the number come from?” | Tom opened the onboarding folder: callback form dated, initialed by Ana, number taken from the vendor’s own website, not the bank letter. The ERP log showed Ana’s ID on the activation. | CP4 observed; designed well for original setups. |
| Step 6, change path | “Now a bank change. The change listing shows 70102 two weeks ago; show me that change and the callback.” | Tom opened the change of 24 October. The confirmation was an email reply from the contact named on the change request. Tom: “For urgent ones, when AP is holding a payment, we confirm by email to the contact on the request and release it. There isn’t time to source a number.” Renata, when he finished: “That is accurate. The procedure says callback to an independently sourced number. For urgent changes, which run at about one a month, we have been confirming by email to a contact the requester supplied, which proves nothing if the request itself is fraudulent. I’d rather you heard that from us. I’ll give you the exact count from the change log.” | G1: urgent bank changes verified by email to a requester-supplied contact; procedure requires independent callback. Performer’s explanation recorded verbatim. Population of bank changes requested. |
| Step 7 | “Show me last week’s change report and how you review it.” | Renata: “It arrives Monday. I read it, usually on my phone. There is no sign-off and no annotation, so treat it as not evidenced. I am going to start annotating it this week, and I understand that does not change what you have seen.” | CP5: inquiry only; not relied on. Owner’s remediation intent noted. |
| Risk probe | “What would stop someone submitting a fake bank change for an existing vendor?” | Renata: “At setup, the callback. For an urgent change, nothing before payment except the AP supervisor’s payment run review, which checks amounts and approvals, not bank details. That is the gap.” | Risk point with no effective preventive control on the urgent path. |
| Close | Priya read back the follow-ups: access list; bank change log for the year to date; portal configuration for the mandatory attachment and the delegation; the duplicate tax-ID setting; the last eight change reports; the procedure version in force. | Renata: “Access list and change log this afternoon. Configuration by Thursday; the administrator is out tomorrow. Reports and procedure today.” | Parking lot recorded with dates. |
The next 48 hours, and what came of it
That afternoon she sent the access list, the bank change log (27 bank detail changes in the year to date, 8 flagged urgent), the last eight change reports and the procedure, each with system, run date and parameters in the covering email, plus screenshots of the items seen on screen so that the evidence inventory could mark them “copy” rather than “observed.” On Thursday the administrator sent the three configuration screens with their change history, and the duplicate tax-ID block was credited at CP3 as an evidenced automated control rather than left as an owner’s description.
When the narrative and gap log arrived on Friday, one entry was wrong: for original setups it read “callback performed by the analyst who keyed the bank details; no segregation.” Priya had conflated the two analysts while writing up. Renata sent one email with the fact, the callback form carrying Ana’s initials, the ERP log with Ana’s approver ID, and a suggested sentence; the entry was removed the same day. She confirmed everything else as accurate, including the two gaps she had raised herself, and said so rather than leaving it implied. Note what her candor was not: a self-identified issue, which would have needed an issue statement, an owner and dated actions logged before the audit began. Disclosing a gap in the room earns credibility; logging it a quarter earlier, with an owner and dated actions, would have had it reported as management-identified and, in many functions, kept out of the engagement rating.
She also started the fix before anyone asked. Urgent bank changes now require a callback to a number taken from the original onboarding file or independently located, performed by the analyst who did not key the change, with the form filed before activation; accounts payable was told a held payment is not a reason to skip it. The weekly report gained a review field with initials, date and items queried. Both were running within two weeks, which mattered for the report: Standard 15.1 requires the final communication to acknowledge actions management has already started or completed, so the action plan she wrote described something in operation rather than something promised.
The auditors tested all eight urgent changes and a sample of the rest. The draft report carried one finding on the urgent-change path, rated High on MidState’s four-level scale: the exposure is a diverted payment, and nothing on the urgent path would have stopped a fraudulent change before the payment run. The condition used the words Renata had said in the room and the remediation was acknowledged. The duplicate tax-ID block was credited as a key control and tested; the delegation question closed on the configuration; the weekly review appeared inside the finding as an unevidenced detective control rather than as a separate finding. Renata did not contest the rating. The severity matrix on this site shows how impact and likelihood combine for an unverified vendor bank change, and the ratings decoder for auditees explains what a single High does to the report rating and who reads it.
Now the other version. Suppose Tom had answered the change-path question with the procedure’s words, “we call the vendor back,” and Renata had let it stand. Priya would have asked for the last five callback forms for bank changes, found none for the urgent ones, and written the gap anyway. But she would also have written “the practice described during the walkthrough was not supported by the records,” extended the bank-change request from the year to date to two full years, re-examined the setup callback that was in fact working, and carried a reasonable doubt about the rest of Renata’s account into the depot and accounts payable walkthroughs still to come. The gap would have cost the same. The credibility would have cost more, for longer. The difference between the two versions was one sentence, prepared on Monday afternoon and said on Tuesday at about twenty past ten.
Questions readers ask
What is an audit walkthrough and how long does it take?
A walkthrough is the auditor following one real transaction through your process from start to finish, at the screens of the people who perform each step, to document how the process actually runs and where the controls are. Most take 60–90 minutes for a single process; a multi-system process with several exception paths can take longer or be split across sessions. It is not a test of whether the controls worked all year; that follows, with a sample.
Who should attend a process walkthrough with internal audit?
The people who perform the steps, at their own screens, plus the process owner to frame the boundaries and handle procedure questions. Auditors usually prefer to see the performer without the manager present, because managers tend to answer for their staff, so offer to step out after the framing and return for the gap discussion at the end. Keep the system administrator or any other team that owns a configuration reachable rather than in the room. If you do stay, the thing to avoid is answering for the performers: the auditor then has one account and will go looking for the others in testing.
Can I choose the transaction for the audit walkthrough?
Usually not, and you should not want to. Auditors select from a population listing so the walkthrough reflects a normal item rather than a prepared one. Have two of your own ready anyway, one plain and one that took an exception path, and if the auditor’s pick is unusual, say so and show a typical one beside it.
What happens if the auditor finds a control gap during the walkthrough?
They record the facts in a gap log with your explanation and decide whether it is a design gap, a documentation gap, or a gap covered by another control. A design gap usually becomes a finding without further testing, sized by the population of affected items. Confirm the facts accurately, name and show any compensating control, ask what population they need, and start the fix now; the final report must acknowledge remediation already under way (Standard 15.1).
Should I tell the auditor about our workarounds?
Yes, and introduce them yourself. A workaround is part of the process as performed, which is what the walkthrough documents, and most are visible in the data anyway. A workaround you explain, with its reason and the check over it, is assessed as a design question. One the auditor finds in testing after you described the procedure is assessed as a design question and a disclosure problem.
Is a walkthrough the same as testing the control?
No. A walkthrough examines one or a few transactions closely and supports conclusions about whether a control exists and is designed to address the risk. A test of controls examines a sample across the period and supports a conclusion about consistent operation. PCAOB AS 2201 says walkthroughs that include inquiry, observation and inspection of documentation are ordinarily sufficient to evaluate design effectiveness, and that testing controls over a greater period of time provides more evidence of their effectiveness. Expect sample requests to follow for the controls the auditor decides to rely on.
Can I ask to see the auditor’s walkthrough notes?
You can ask to review the narrative, control list and gap log for factual accuracy, and most functions will share them, because clearing facts with the people who performed the steps makes the file more reliable. You are confirming facts and wording, not the design judgment, which is discussed later with evidence. Return it within two or three business days with corrections supported by evidence, and say which entries you confirm.
Do SOX walkthroughs happen every year?
In practice, for in-scope processes, yes: external auditors and SOX teams typically re-walk each significant process each year to confirm their understanding is current, and again whenever a system or process changes (a practitioner observation, not a rule in the standard). Repeat sessions are shorter when last year’s narrative was accurate and you can point to what changed, so keep a marked-up copy of the narrative through the year; the year-round guide covers that habit.
This guide is general and educational; it is not legal or employment advice.
Related guides
- Being Audited? The hub for people on the receiving end — every stage from notification to follow-up, with the guide for each.
- Audit Walkthrough Guide: Question Bank, Script and Example — the auditor’s side: the 36-prompt question bank and the script they follow.
- The Walkthrough Documentation Template — the eight-part document the auditor writes afterwards, so you know what you are reviewing.
- Walkthrough vs Test of Controls — why the walkthrough supports design conclusions only, and what the sample afterwards is for.
- When Internal Audit Interviews You — the planning interviews, follow-ups and closing meeting around the walkthrough.
- The PBC Survival Guide — running the request list that follows without losing your week.
- What Not to Say to Your Internal Auditor — the phrases that move an auditor from understanding into verification.
- SOX for Control Owners — what testers ask for after the walkthrough and what each phase means for you.
- 60 Questions Internal Auditors Ask Process Owners — the by-area bank behind the fourteen walkthrough questions, with what a good answer contains.
- What Counts as Audit Evidence — what to send after the walkthrough, what gets rejected and why a spreadsheet is not enough.
- Control Ownership: Making Someone Actually Accountable — controls with a named owner and known evidence need less explaining.
- When You Disagree With an Internal Audit Finding — the proper route for judgment disagreements that do not belong in the walkthrough room.
- Audit Fieldwork: What Happens, Week by Week — where the walkthrough sits in the engagement and what follows.
- The Auditee’s Playbook — the paid PDF ($249) for people being audited.
Leave a Reply