Surviving the Transfer Audit Walkthrough

The calendar invite reads "Walkthrough — file transfer controls, sixty minutes," and you are listed as the presenter. The notes field says "please have logs available," and does not say which. Unlike the document requests you have been answering by email, this one happens live. Auditors watch your screen while you operate the system, asking questions as you go, taking notes you cannot see. For most administrators it is the single most stressful hour of the audit, because it feels like an exam with unknown questions and no retakes.

It is not an exam. A walkthrough is a structured observation with learnable rules. Teams that know the rules routinely come out of the hour having strengthened their audit position. A control demonstrated smoothly, live, by the person who runs it is among the most convincing evidence an auditor ever collects. I have sat on the presenter's side of that table often enough to know that the hour is won or lost the day before. This article covers the whole arc: what a walkthrough actually tests, how to prepare the environment without staging it, and who belongs in the room. It covers the dialogue itself — with realistic exchanges done badly and done well. It explains how to handle the finding you already know is coming, and how to turn the aftermath into commitments you can meet.

This is the fifth article in our Audit-Ready Reporting series, and it leans on two earlier ones. It uses the question themes from what auditors actually ask. It uses the evidence standards from transfer evidence auditors accept and reject.

What a Walkthrough Is — and Is Not

A walkthrough is a session where the auditor traces a process end to end by watching the people who actually perform it. For a transfer system, that usually means following one real flow — a partner upload, a nightly batch, an employee sending a file. The auditor follows it from initiation through authentication, transfer, logging, and monitoring, with you demonstrating each step in the live system.

Its purpose is corroboration. Before the walkthrough, the auditor has read your documented process and your answers to the question list. The walkthrough tests whether reality matches the description. Does the approval step actually happen, or is it a checkbox in a document? Does the log entry the policy promises actually appear? Is the person operating the control the person the org chart says operates it? In audit terms it primarily establishes that controls exist and are designed sensibly. The deeper "did it operate all year" testing continues afterward on documents and samples. But a walkthrough that goes badly reliably triggers more of that deeper testing, and one that goes well can visibly shrink it.

The hour follows a predictable arc, and knowing it means nothing about its rhythm surprises you. It opens with context questions — what the system is, which flows run through it, who operates what. Then comes the trace: one flow followed step by step through the live system, which consumes most of the time. Around the trace, the auditor drops in control questions from the standard themes — access, authentication, encryption, logging, review. It closes with a recap of follow-ups: what they want sent, and by when. Four movements, sixty minutes, and every one of them improves with the preparation below.

What a walkthrough is not matters just as much. It is not an interrogation — the auditor is not trying to trick you. It is not a product demo — polish is worth nothing; correspondence between claim and reality is worth everything. And it is not the place to win arguments about scope or requirements. Those conversations belong to your management and compliance team, who own the relationship with the audit. The same division of labor runs through this whole series: they define and negotiate what must be true, you demonstrate what is true.

Before: Prepare the Environment, Not a Performance

Good preparation is the opposite of staging. Staging means arranging the system to look better than it is. It is the cardinal sin, because a discovered pretense poisons every other answer you have given. Preparation means removing friction and surprise from an honest demonstration:

• Choose and rehearse the flow you will walk through. Pick your bread-and-butter transfer, not your prettiest one. Trace it yourself the day before: trigger it, watch it authenticate, find its log entries, show where a failure would surface. If the auditor picks a different flow, the rehearsal still pays — the muscle memory of navigating settings and logs transfers.
• Pre-run every lookup you expect to perform. Pulling the account list, filtering the log for one session, opening the permission view: do each once that morning so you know the path and the response time.
• Clean the screen honestly. Close unrelated windows, silence notification popups, shut the browser tabs from your other work. This is courtesy and privacy, not concealment — you are removing noise, never state. Do not "tidy" data, disable a failing job, or hide a backlog.
• Have the evidence folder within reach. Half the follow-up requests a walkthrough generates can be closed on the spot by opening the right file from your evidence tree.
• Do a dry run with a skeptical colleague. Have someone play the auditor for twenty minutes and ask the obvious questions. The gaps you find rehearsing cost nothing; the same gaps found live cost credibility.
• Settle logistics early. Screen sharing or conference room, who attends, whether recording is happening, how long. Ambiguity here wastes the hour's calmest minutes.

Who Belongs in the Room

The non-negotiable attendee is the operator — the person who actually performs the work being walked through. Auditors specifically want the doer, not a manager describing the doing. A manager who intercepts every question creates the impression, fair or not, that the documented process and the practiced process are different things. The second seat that earns its place is a scribe: someone who records every question asked, every item promised, and every document requested. This produces the request log that becomes your tracker afterward. The operator cannot take these notes while driving the demo, however firmly they believe otherwise.

Keep the room small beyond those two. A manager or compliance liaison who can speak to policy questions is useful; a crowd is not. Six observers radiating nervous energy make ordinary questions feel like cross-examination. Every extra person is another chance someone volunteers a tangent the session did not need.

During: The Dialogue, Done Badly and Done Well

The heart of the walkthrough is conversational, so the best way to prepare is to see the moves. Four exchanges occur in almost every transfer walkthrough.

Exchange one — the monitoring question. Auditor: "How do you know when a transfer fails?"

Done badly: "Well, usually the partner calls us, ha — no, seriously, we have alerts, though honestly since the migration some of them are a bit noisy, we've been meaning to tune them, and Dave used to watch the mailbox but he moved teams..." Every clause of that answer is a thread the auditor is now obliged to pull.

Done well: "Failed jobs email the team the moment they fail — here is yesterday's notification. The weekly exception report rolls up everything with a disposition; here is last week's." Two sentences, two artifacts, stop. If your scheduled jobs run in Sysax FTP Automation, the failure notification email it sends is exactly the artifact to show. In that case, show it alongside the exception reports described in the transfer reports worth automating.

Exchange two — the access question. Auditor: "Show me who can reach the payroll drop folder."

Done well: narrate while you navigate — "This is the server's account view; I am filtering to the payroll folder; these four accounts have rights, and this column shows the level." Then corroborate with operation: "and this is the activity log for that folder for the last month, from the log database." On a server like Sysax Multi Server, accounts may be built-in, come from Active Directory, or authenticate by public key. The strong move is to show that your list covers all the sources — completeness demonstrated before it is questioned. Narration matters: silent clicking forces the auditor to guess what they are seeing, and guesses become follow-ups.

Exchange three — the design-plus-operation answer. Auditor: "What happens after repeated failed sign-ins?"

Done well: show the lockout setting (design), then filter the log to a real lockout event from last month (operation). That is one question, both halves answered, no return visit needed. If the follow-up comes — "and how would a locked-out partner get back in?" — the reset-and-verify path from handling auth failures and lockouts is the answer to have ready. This pairing — the setting, then a real instance from the record — is the single most useful walkthrough habit you can build. It is why comfort navigating your own logs (see reading transfer logs) pays off so visibly here.

Exchange four — the question you cannot answer. Auditor: "What is the retention on the archived logs?"

Done badly: "Uh, I think it's a year? Probably a year." A guess recorded as fact becomes a contradiction later, and contradictions are how credibility dies.

Done well: "I don't want to guess — the scribe has it noted, and I will confirm by Thursday." Auditors hear this answer constantly and respect it. Delivering Thursday's answer on Wednesday is how you turn it into a point in your favor.

Threaded through all four exchanges are the standing rules: answer, then stop. Auditors deploy silence deliberately, and the silence is not yours to fill. Show rather than describe wherever the system can speak for itself. Avoid casual absolutes — "we always," "that never happens" — because absolutes are testable, and the record only has to disagree once. And never argue mid-session. If a question seems out of scope or a conclusion seems wrong, note it and flag it politely. Let the follow-up conversation happen through the channel that owns it. The silence rule is the hardest; I once filled an auditor's pause with a sentence it took me a week to retract.

When the Demo Breaks Live

Sometimes the transfer you trigger fails in front of everyone. This is not the disaster it feels like — it may be the best minute of your walkthrough, if your handling is real. Say what you see ("that job failed — let's look"), open the log, and find the cause. Let the auditor watch your actual failure process operate: the notification arriving, the retry, the ticket. An auditor who watches a failure get detected, diagnosed, and dispositioned has just seen your monitoring control operate with zero possibility of staging. What sinks teams is not the failure; it is bluffing past it, or revealing that failures have no path at all.

The same logic covers the surprise that is not a failure. Bluewater Bank's operator filtered the payroll folder's account list live and saw five names where she expected four. The fifth belonged to a contractor whose engagement had ended two months earlier. She said so, disabled the account while the auditor watched, and had the scribe log a ticket and a note for the next access review. The account's existence became a finding, as it should have, and the response became part of the same paragraph. The version of that hour where she recognized the name, said nothing, and hoped would have ended a great deal worse.

The Finding You Know Is Coming

Almost every team walks in knowing their weak spot: the shared service account nobody has split, the quarter where access reviews slipped, the one legacy endpoint still speaking cleartext. Handle it in three stages.

Before the audit, fix what is quick. Some known issues are an afternoon's work wearing a year of procrastination. Clearing them beforehand is worth more than any amount of session polish.

For what remains, prepare the disclosure. Write down, in advance: the fact, the actual risk impact, the compensating controls around it, and the remediation plan with an owner and a date. Then brief your manager and compliance team. Whether to raise a material issue proactively — versus answering fully when asked — is a judgment they own. What is never acceptable is concealment when a question lands on it: asked directly, you answer truthfully, every time.

In the session, deliver it flat. "Correct — that endpoint still accepts cleartext from one legacy device. Access is restricted to that device's address, and the migration is scheduled with the vendor; here is the plan." No excuses, no drama. A self-identified issue with compensating controls and a dated plan typically becomes a managed finding. The same issue excavated by the auditor from behind a confident "no" becomes a credibility problem attached to every other answer.

After: The Request Log and the Commitments

The walkthrough ends; the scribe's request log begins its second life as your tracker. Deliver the promised follow-ups fast — speed on small items builds the credibility that cushions larger discussions. Route each delivery through the evidence standards you already use: system-generated, dated, filed.

Then come the findings, and with them management responses: the written commitments about what will be fixed and by when. Resist the reflex to promise everything immediately. Next year's audit opens by testing last year's commitments, and a missed commitment is a finding with compound interest. Commit to what you can verifiably meet: a named owner, a realistic date, and a defined check that will show the fix operating. "Quarterly access reviews resume next quarter, owned by the IT manager, evidenced in the review folder" is a commitment that closes cleanly. The promise "we will completely overhaul access management" is a commitment that comes back to bite. Next year's auditor will open with it.

One more habit compounds year over year: keep the request log and your session notes with the audit's evidence. Walkthroughs repeat — next year's session will revisit most of the same ground, plus your commitments. So this year's question list is next year's rehearsal script. Teams that keep those notes walk into their second audit measurably calmer than their first, for one hour of filing effort. The sustainable version of this — controls running on a calendar so audits stop producing surprises at all — is where this series concludes, in from annual audit panic to continuous compliance.

The Day-Before Checklist

WALKTHROUGH PREP  --  run this the day before

[ ] Flow chosen; traced end to end today; log entries located
[ ] Every expected lookup rehearsed (accounts, permissions, logs)
[ ] Evidence folder current and one click away
[ ] Screen cleaned: unrelated windows closed, popups silenced
    (nothing disabled, nothing hidden, no data "tidied")
[ ] Dry run done; gaps found are fixed or on the disclosure list
[ ] Known-issue disclosures written: fact, impact, compensating
    controls, owner, date -- and management briefed
[ ] Operator and scribe confirmed; roles clear; room small
[ ] Logistics settled: sharing method, attendees, duration
[ ] Request log template ready (question, asker, owner, due)
[ ] Yesterday's failure notification and latest reports at hand

The Hour Is Winnable

A walkthrough rewards exactly the things this series has been building. Know the questions in advance and keep evidence that answers them. Run controls steadily enough that demonstrating one is just doing your job with an audience. Prepare the environment honestly, and put the operator and a scribe in the room. Answer-then-stop, and pair every setting with a real event from the record. Disclose the known issue flat, and commit only to what you can meet. Do that, and the hour that reads as the audit's most dangerous becomes the hour your controls look their best. They are being watched doing what they actually do. The logs will be available. All of them, one click away, which is more than the invite asked for.

Frequently Asked Questions