Control walkthrough documentation: what belongs in the file

Control walkthrough documentation has to establish three things, not just one: that the control exists as described, that the person performing it understands why they are doing it, and that it was actually performed on a specific transaction traced end to end. A file that only describes the control in the abstract, without tracing one real transaction through it, has documented a process description rather than a walkthrough.

What a walkthrough is for

A walkthrough is a design test performed once, early, before any sample-based operating effectiveness testing begins. Its job is narrow: confirm that if this control operated as the process owner describes it, it would actually address the risk it is meant to address, and confirm that the description matches what really happens rather than what the policy manual says should happen. Those two can diverge quietly over a year, and a walkthrough performed from the policy document alone, without talking to the person who does the work, will not catch the divergence.

The three things a walkthrough must establish

Narrative versus flowchart format

Neither format is inherently superior; the choice should follow the shape of the process being documented.

• Narrative works well for a process with few decision branches and a small number of control points — most payroll processing, for instance — where a paragraph of prose is faster to write and faster to review than a diagram.
• Flowchart earns its cost when the process has multiple decision points, parallel paths, or system-driven branching — a procurement process with different approval routes by value threshold is clearer as a flowchart than as prose trying to describe every branch.
• A hybrid is common and often best in practice: a flowchart for the overall process flow, with a narrative annotation at each control point describing what evidence was reviewed and what was found.
• Whichever format is used, it should be legible to someone who was not in the room when the walkthrough was performed. A flowchart only the preparer can interpret has the same defect as a narrative too terse to follow.

Building the walkthrough record

1. 01Identify the control point and the risk it addresses before scheduling the interviewWalking in without a clear sense of what the control is supposed to prevent leads to a conversation that describes the process generally rather than tests the specific control.
2. 02Select one real, identifiable transaction in advanceNot a hypothetical example the process owner constructs on the spot. A transaction selected before the meeting, so the walkthrough tests the actual system and actual documents rather than a rehearsed version.
3. 03Trace the transaction step by step with the person who actually performs the controlNot their manager, and not a process owner one level removed. The person doing the work day to day is who can show you what actually happens, including the shortcuts.
4. 04Capture the evidence at each control point, not just a description of itA screenshot of the approval workflow, the signed document, the system log showing who actioned what and when. The record should let a reviewer see the evidence, not take the preparer's word for its existence.
5. 05Note any divergence between the documented process and what was observedEven a minor one. A process description that is slightly wrong in a detail that does not matter this year may matter next year when something is tested against it.
6. 06Conclude explicitly on design effectivenessState, in writing, whether the control as observed would address the risk if performed consistently. This conclusion is what operating effectiveness testing later builds on; without it, the sample testing has no design basis to test against.

Shortfalls that show up most often on inspection

• Walkthrough performed once, years ago, and rolled forward every year without re-performance, while the underlying process has since changed.
• No specific transaction referenced — the documentation describes the control in the present tense and generically, with nothing to show a real instance was traced.
• Evidence referenced but not retained — the narrative says 'approval was reviewed' with no copy of the approval attached or referenced by identifiable document number.
• The walkthrough performed with the control owner's manager rather than the person who actually executes the control, producing a description of policy rather than practice.
• No explicit conclusion on design effectiveness, leaving a reviewer to infer whether the control passed design testing from the absence of any noted problem.
• Walkthroughs for IT-dependent controls performed without anyone from IT or anyone who understands the system configuration, missing that the 'control' is actually a system setting that could be changed by someone with access.