Walkthroughs are live, usually over a screen-share during audit fieldwork. The auditor picks a real instance — last week’s production deploy, the most recent termination — and asks the control owner to show each step in the actual systems while they compare what they see against the policies and system description. It is corroboration, not conversation: the point is to catch the gap between the process on paper and the process in practice, because that gap is where control failures hide. What surfaces in a walkthrough shapes what the auditor samples next.
Walkthroughs go sideways in predictable ways: the owner narrates the ideal process instead of the real one, improvises answers to questions they should defer, or reveals an undocumented workaround mid-demo. Preparation is mostly honesty plus rehearsal — owners should demo the process once beforehand, know which steps are theirs, and be comfortable saying “let me confirm and follow up” rather than guessing on the record.
Walkthroughs run alongside the evidence requests that dominate fieldwork; how the two fit together — and who should own each — is covered in our auditor PBC list guide.
The two procedures answer different halves of design vs operating effectiveness. A walkthrough corroborates design — the auditor watches one instance to confirm the control works the way it is described. Sample testing then proves operation, pulling many instances from across the period to check the control ran every time. Doing well in the walkthrough matters beyond the session itself: a process that demos cleanly earns lighter sampling than one held together with visible duct tape.
