Auditor Walkthroughs: What They Ask, and How to Prepare Your Team

A walkthrough is the auditor following one real transaction or one real control occurrence end to end, through your actual systems, using your actual documents. PCAOB AS 2201 paragraph .37 describes the procedure precisely: the auditor "follows a transaction from origination through the company's processes, including information systems, until it is reflected in the company's financial records, using the same documents and information technology that company personnel use", and the procedures "usually include a combination of inquiry, observation, inspection of relevant documentation, and re-performance of controls". Paragraph .43 adds that inquiry, observation and inspection together are ordinarily sufficient to evaluate whether a control is designed effectively. Service auditors run substantially the same play against your Trust Services controls.

Teams do not lose walkthroughs because their controls are weak. They lose them because the person in the room does not perform the control and starts filling silence with guesses. Everything below follows from that one sentence.

Key takeaways

• A walkthrough tests design, not just existence. The auditor is confirming that the control as described would actually catch the thing it claims to catch.
• Inquiry is only one of four procedures. The auditor will also watch, read the artifact, and ask you to do it again in front of them, so a rehearsed verbal answer is not enough.
• Send the person who performs the control, not their manager. The manager knows the policy; only the operator knows what actually happens on a Tuesday.
• The most expensive answer in any walkthrough is a guess. "I do not know, I will find out today" costs nothing; a wrong answer becomes a documented inconsistency the auditor has to resolve.
• Rehearse by having someone internal walk the control with the operator a week early. Almost every problem this surfaces is fixable before fieldwork.

What a walkthrough is, in the standard's own words

The definition above is worth reading twice, because two phrases in it do most of the work.

"Using the same documents and information technology that company personnel use" means the auditor is not evaluating your control narrative. They are evaluating your system, with the narrative as a map. If your documented offboarding process says the ticket triggers directory removal and in reality someone does it by hand and closes the ticket afterwards, the walkthrough is where those two facts meet.

"A combination of inquiry, observation, inspection of relevant documentation, and re-performance" means four different things are happening, and only the first is a conversation. The auditor asks how it works. Then they watch you do it, or watch the system do it. Then they read the artifact it produced. Then, for some controls, they ask you to run it again while they watch. A team that prepares only for the interview has prepared for one quarter of the procedure.

The purpose is design evaluation. Paragraph .43 makes the point that inquiry, observation and inspection are ordinarily sufficient to evaluate design effectiveness, and design is a different question from operation. Design asks: if this control ran as described, would it prevent or detect the thing it is meant to? Operation asks: did it in fact run, every time, across the period? The walkthrough is mostly the first question. Sampling, which we cover in our piece on how audit sampling works, is mostly the second.

Send the operator, not the executive

This is the single highest-leverage decision you make about walkthroughs, and companies get it wrong for understandable reasons.

The instinct is to send a senior person, because the meeting feels important and senior people are good in meetings. But the auditor's questions are about mechanics, and the executive answers them from the policy document because the policy document is what they know. The operator answers them from Tuesday, because Tuesday is what they know. When the two answers differ, the auditor has found a design gap, and it is usually a real one.

So the rule is: whoever actually performs the control attends, every time. For access reviews that is the person who opens the report and clicks approve, not the department head whose name is on the sign-off. For change management it is an engineer who merges pull requests, not the VP of Engineering. For vendor reviews it is whoever fills in the questionnaire.

Bring a second person as a note-taker and escalation path, and let them stay quiet. Their job is to write down every follow-up item and every question that produced an "I will confirm", so that nothing gets lost between the meeting and the evidence submission.

One more thing about seniority: an executive in the room changes what the operator says. People do not contradict their manager in front of an auditor, so if the manager describes the process and the operator knows it works differently, you will very often get silence rather than the correction. If a senior person must attend, brief them to answer nothing.

The four questions underneath every question they ask

Auditors phrase questions many ways. Underneath, they are almost always asking one of four things, and preparing against the four is far more effective than preparing against a list of expected questions.

Does this control exist as described? The map-versus-territory question. Answer with the mechanism, not the intent: which system, which trigger, which person, in what order.

Who performs it, and what stops someone else doing it instead? This is the segregation and authorisation question. The auditor wants to know whether the control depends on a specific role or on a specific individual's diligence, because the second one breaks when that individual is on holiday.

How would you know it happened? The evidence question, and the one that most often exposes a real problem. A control that leaves no dated artifact is a control nobody can test. If your answer is "we would just know", you have found a gap before the auditor did. Our guide to the evidence request list covers what the artifact usually needs to look like.

What happens when it fails, or when someone needs an exception? Every real control has exceptions. The auditor is not surprised by that; they are checking whether the exception path is defined and evidenced, or improvised. An honest, documented exception process is a strong answer. A claim that exceptions never happen is a weak one, and it is usually not true.

What to bring, and what not to volunteer

Bring the artifact, not a description of the artifact. Have the actual ticket open, the actual log query ready, the actual approval email findable in under a minute. Fumbling to locate evidence during a walkthrough turns a five-minute item into a follow-up request, and follow-up requests accumulate into the delay that makes reports late.

Bring your own copy of the control description you are about to walk through, and read it that morning. If you disagree with how it is written, say so at the start of the session rather than after the auditor has noticed the mismatch. Auditors respond well to "that description is out of date, here is what we actually do", and badly to discovering the same fact themselves.

Answer the question asked. This is not evasiveness, it is precision. Volunteering adjacent detail expands the scope of the conversation into areas the auditor was not examining, and some of that detail will raise questions that then have to be resolved. There is a difference between hiding something, which is misconduct, and answering a question about access reviews without also narrating your unrelated concerns about the logging pipeline.

And when you do not know, say so. "I do not know, I will confirm and send it today" is a normal sentence in a walkthrough and it costs you nothing. A guess that turns out wrong becomes a documented inconsistency the auditor is obliged to chase, and chasing it costs everyone more than the original answer would have.

The rehearsal that actually works

An internal dry run one week before fieldwork catches most of what would otherwise become a follow-up item, and it does not need to be elaborate.

Pick someone who does not perform the control. Give them the control description and the four questions above. Have them sit with the operator and walk it: show me the trigger, show me the system, show me the artifact, show me what happens when it does not run. Time-box it to twenty minutes per control and write down every place the operator hesitated.

Hesitations are the output. They tell you three things: where the description no longer matches reality, where the evidence is hard to retrieve, and where the operator is uncertain enough to improvise under pressure. All three are fixable in a week. None is fixable during fieldwork.

Prioritise the rehearsal on the controls that are new, that changed during the period, that depend on a single person, or that had an exception last year. Controls that ran unchanged for two years and produced clean evidence do not need the practice.

The five ways walkthroughs go wrong

• Guessing. Covered above, and it is the most common by a wide margin.
• Contradicting the policy. The operator describes what really happens and it differs from the written control. This is a genuine finding, but discovering it in a walkthrough is the expensive version. A rehearsal finds it while there is still time to correct the description or the process.
• The person who left. The control was performed by someone who is no longer at the company and nobody else has done it. There is no good answer available in the room; the only fix is knowing before fieldwork and reassigning early enough to produce evidence.
• Screen sharing that stalls. The auditor asks to see the system, and the account has no access, the query has not been written, or the tool needs an admin who is in another timezone. Test the access the day before.
• Too many people in the room. Six attendees, three of whom answer, produces contradictions in the transcript. Two people, one talking.

When you do not need help with this

We sit in walkthroughs for clients, so it is fair to say when that is not worth buying.

If this is your second or third examination at the same scope, your control owners have done it before, and last year produced no exceptions in the areas being walked, run it yourself. The rehearsal described above is a half-day of internal time and it is most of the value. Bringing in an outside party to watch experienced operators explain controls they have explained twice already is buying comfort, not risk reduction.

The case for help is the mirror image: a first examination, a control set nobody has been questioned on before, a new scope area, or an operator population that turned over during the period. There, the value is not the meeting itself but the week before it, and specifically the person who has heard thirty of these and knows which of your descriptions will not survive contact.

Where Top Floor fits

Our audit and assurance work includes preparing control owners for interviews and sitting in through fieldwork: scheduling the walkthroughs, running the rehearsals, catching the description-versus-reality mismatches while they are still cheap, and handling the follow-up requests that come out the other side. We do not perform the examination and do not issue opinions, so nothing in the room is us assessing our own work.

If the underlying problem is that the controls are described but not really running, the purchase is compliance as a service rather than fieldwork support, because no amount of walkthrough preparation fixes a control that does not operate. And if you are earlier than that, deciding scope and criteria before an examination exists, start with SOC 2 readiness.

How to decide this week

List your controls and mark three categories: new this period, changed this period, and performed by exactly one person. That list is your rehearsal scope, and for most companies it is a third of the control set rather than all of it.

For each control on the list, name the operator who will attend. If any name is a manager rather than a doer, fix it now. If any name belongs to someone who has left, that is your most urgent item this week and it will not improve by waiting.

Then book twenty minutes per control with someone internal who does not perform it, and run the four questions. Anything that produces a hesitation goes on the remediation list before fieldwork opens, not after.

Frequently asked questions

What is an audit walkthrough?

It is the procedure where an auditor follows one real transaction or control occurrence end to end through your actual systems and documents, rather than reading your description of it. PCAOB AS 2201 paragraph .37 defines it as following a transaction from origination through the company's processes using the same documents and information technology that company personnel use, combining inquiry, observation, inspection of relevant documentation, and re-performance of controls. Service auditors apply the same approach to controls in a SOC 2 examination. Its main purpose is evaluating whether a control is designed effectively, which is a separate question from whether it operated consistently across the period.

Who should attend a walkthrough?

The person who actually performs the control, plus one quiet note-taker. Not the manager, and not an executive. Managers answer from the policy document because that is what they know, operators answer from what really happens on a normal working day, and it is the second answer the auditor is testing. A senior person in the room also suppresses corrections, because people do not contradict their manager in front of an auditor. If a senior attendee is unavoidable, brief them to answer nothing and let the operator speak.

How long does a walkthrough take?

It depends entirely on how many controls are in scope and how quickly your evidence can be retrieved, so ask your auditor for their session agenda rather than budgeting a fixed number. Auditors schedule walkthroughs by control area, and the variable you control is retrieval speed: a session where every artifact is open and findable runs at a completely different pace from one where each item becomes a follow-up request. Preparing the evidence in advance is the single biggest lever you have on the calendar.

What happens if we answer a walkthrough question wrong?

A wrong answer becomes an inconsistency the auditor is obliged to resolve, which usually means additional requests, additional evidence, and additional time for everyone. That is why the correct response to uncertainty is "I do not know, I will confirm and send it today", which costs nothing and is completely normal. If you realise afterwards that an answer was wrong, correct it immediately and in writing rather than hoping it passes; a prompt correction is a non-event, while a contradiction the auditor finds themselves in your evidence is a much larger conversation.