How to Run a Control Walkthrough That Actually Finds Problems

Most weak walkthroughs fail the same way. The auditor reads the process narrative, asks the control owner to confirm it, writes "no exceptions noted," and moves on. Nothing was learned, because nothing was tested against reality. A walkthrough is not a formality that precedes the real work. It is the first point at which you can see whether a control exists as designed, and it is where many of the most useful findings surface.

Know what a walkthrough is for

A walkthrough traces a single transaction through a process from start to finish so you can confirm two things: that you understand how the control is supposed to work, and that its design would prevent or detect the risk it targets. That is the whole purpose, and it is worth stating plainly because it draws a line you must not blur.

A walkthrough does not confirm operating effectiveness. Following one invoice through the approval workflow tells you the control is designed to catch unapproved spending. It does not tell you the control caught the other 4,000 invoices that month. Confirming that the control operated consistently over a period is testing, and testing comes later with a sample. Keep the two ideas separate in your head and in your workpapers. When you conflate them, you overstate your assurance and you skip the sampling that a design conclusion cannot substitute for.

Prepare before you sit down

Preparation is what separates a walkthrough that finds problems from one that rubber-stamps a narrative. Read the existing process documentation, the prior-year workpapers, and any known issues before the meeting. Identify the specific risk the control addresses and the assertion it supports, so you are testing a control against a purpose rather than admiring a procedure.

Pick your transaction deliberately. A live example that carries real dollars and real approvals is more revealing than a hypothetical the owner walks you through from memory. Ask to see the actual system records, the actual signatures or electronic approvals, and the actual supporting documents. If you can select the transaction yourself rather than accept the one offered, do so.

Ask questions that surface real gaps

The questions that expose gaps are rarely the ones that ask whether a control exists. They ask how it behaves under stress. A short set worth carrying into every walkthrough:

• "Show me where the system stopped this, or who caught it and how" — a control need not block a transaction, but a detective or advisory control must trigger a timely, defined response, or it is not really operating.
• "What happens when the approver is out, or the amount is unusual, or the file is incomplete?" — exceptions are where designs quietly break.
• "Who can override this, and where is the override recorded?" — an unlogged override is a hole in the design.
• "When did this last fail, and how did you find out?" — owners often describe a detective control that has never actually detected anything.

Ask the person who performs the control, not only the manager who owns it. The performer knows the workarounds. Watch for the difference between "the policy says" and "what I actually do," because that gap is often the finding.

See the difference between described and operated

The narrative describes an idealized control. The walkthrough shows you the real one. A description might say two people review each disbursement, while the walkthrough reveals that the second reviewer approves in bulk without opening the underlying files. Here the prescribed control is adequate but is not being performed as designed, which is an implementation or operating failure, not a design flaw.

The distinction matters, so keep it sharp. A design deficiency means the control as prescribed would not address the risk even if performed perfectly: a threshold set too high, a reconciliation that omits a key account, a review with no criteria. An operating failure means a sound control is not performed consistently. Look for both: controls that depend on judgment no one applies, thresholds that are never enforced, reconciliations prepared but never reviewed, and configurations that differ from the documented rule. Name which kind you found, because a design flaw needs a redesign while an operating failure needs enforcement, and testing a larger sample fixes neither on its own.

Document so someone else could follow it

Useful documentation lets a reviewer re-perform your walkthrough without asking you a single question. Record the specific transaction identifier, the dates, the people involved, and the evidence you inspected, not a restated narrative. Note what you saw with your own eyes versus what you were told. Capture screenshots or copies of the actual approval, and describe any deviation from the documented process even when you conclude it is not a deficiency.

State your conclusion in two parts: your understanding is confirmed, and the design is or is not adequate. Then flag what needs testing. A walkthrough that ends with a clear, evidenced design conclusion has done its job, and it sets up every test that follows.