A walkthrough is the part of an audit that feels most like an exam. Someone on your team shares a screen, an auditor asks how a process works, and the answer happens live. It is also the part teams prepare for least, because it looks like a conversation.
It is not only a conversation. A walkthrough produces evidence, shapes how the rest of the audit is tested, and sets the auditor's first impression of whether your controls work the way your documents say. This article covers what happens in one, what the auditor is looking for, and how to run it well.
What a walkthrough is for
The term comes from financial audit practice. The auditor follows one instance of a process from start to finish, through the people and systems that touch it, to confirm they understand how it actually works.
In a SOC 2 engagement, walkthroughs do three jobs.
They test design and implementation. The auditor checks that the control as described would address the risk, and that it exists in practice. For a Type I report, which covers a point in time, the walkthrough and related inspection carry much of the testing.
They plan the sampling. For a Type II, the auditor learns where the population lives, what each instance's evidence looks like, and which system reports they will need. What they learn decides the population requests that follow.
They surface gaps between the documents and reality. If the control description says a manager approves access and the walkthrough shows the IT lead approving it, that gap gets resolved here, or it becomes a finding later.
In an ISO 27001 Stage 2 audit, the same activity tends to happen as process audits. The auditor asks a process owner to explain and demonstrate how the process runs, samples records, and checks them against the ISMS documentation and the standard. The format varies by certification body and by auditor.
What happens in the session
Most walkthroughs follow a similar shape, though firms run them differently.
The auditor states the control. Usually they read your own control description back to you, or ask you to describe it.
The control owner explains the process. Who triggers it, what happens, who approves, where the record lands. The auditor is listening for the steps the description leaves out.
The owner demonstrates a real instance. A recent access request, a change that went through review, an onboarding ticket. The auditor wants to see the actual system, not a slide about it.
The auditor probes the edges. What happens when the approver is on leave? What if the request is urgent? Who can bypass this? How would you know if someone did? These questions are where design weaknesses appear.
The auditor asks for evidence. They may ask for screenshots of what they saw, an export of a setting, or the population for later sampling. Some firms capture screenshots themselves during the session. Some record sessions, with your agreement.
Walkthrough evidence combines inquiry and observation. As the types of audit evidence explains, neither is enough alone to show a control operated across a period. For a Type II, the walkthrough is followed by inspection of a sample, covered in how auditors sample controls.
How to prepare a walkthrough
Preparation is mostly practical. Most of it takes less time than the walkthrough itself.
Choose the right person
The person who performs the control should run the walkthrough. A manager who oversees it will describe the process as designed. The person who does it will describe it as it runs, which is what the auditor needs. The manager can attend.
Choose a real, recent instance
Pick an instance from inside the period that followed the process cleanly. Have it open before the session starts. Searching for a good example live, while the auditor watches, wastes time and invites the question of why it is hard to find.
Know one awkward instance too, if one exists. If the auditor asks about an exception, it is better to say "yes, here is one, and here is how it was handled" than to be surprised by it in the sample.
Read your own control description first
The auditor will test against what you wrote. If the description says "within 24 hours" and the practice is "by the end of the next working day", you have a gap to resolve before the session, not during it. Raise it with your coordinator, who can discuss it with the auditor.
Check access and screen sharing
Log into every system you will show, before the call. Confirm your account can see what you need to demonstrate. Close unrelated tabs, notifications and chat windows, which can expose customer data or internal discussion you did not intend to share.
Remote and on-site walkthroughs
Most SOC 2 walkthroughs now happen over video calls with screen sharing. ISO 27001 audits may be on-site, remote, or a mix, depending on the certification body and your arrangements. Accredited certification bodies follow accreditation rules for using remote techniques, so ask yours in advance which parts of the audit will be remote.
Remote sessions bring their own practical points.
Agree on recording first. Some firms record sessions to support their working papers. Others capture screenshots instead. Know which, and tell the people presenting.
Share one window, not the whole screen. It keeps notifications and other tabs out of the auditor's view, and out of any recording.
Plan for time zones. Book sessions inside the working hours of the person who performs the control, not the coordinator.
Have a backup presenter. If the control owner drops off the call, someone else should be able to continue.
Mistakes that lengthen a walkthrough
Describing the policy instead of the practice. The auditor can read the policy. They need to see what happens.
Answering beyond the question. Volunteered detail about adjacent processes generates more questions and sometimes more scope.
Guessing. "I think the approver is usually the team lead" is worse than "I don't know, I'll confirm and follow up." A wrong answer has to be corrected later, and the correction looks worse than an honest gap.
Showing a demo environment. Unless the control operates there, the auditor needs production, or at least the production configuration.
Arguing with the auditor's reading. If you think they misunderstood, explain the process again with evidence. Disputes about findings belong in a later conversation with your coordinator, not the walkthrough.
After the walkthrough
Expect follow-up requests within days: the screenshots or exports discussed, the population for sampling, and sometimes clarification of an answer. Keep a short note of each session, recording what was shown, what was promised, and by whom, so nothing promised in the room is lost.
If the walkthrough exposed a real design gap, tell your coordinator the same day. Depending on timing and the firm, the gap may be fixable before it becomes a finding, or it may be better described honestly in the report. The SOC 2 framework page covers how controls map to the criteria the auditor is testing against.
How TrustLynce helps
The auditor portal keeps each walkthrough's follow-up requests, the evidence supplied, and any findings against the control they relate to. The commitments made in the session are tracked in the same place as the work they create.