Part IV · Chapter 7 · The Audit · lesson 2
Talk somebody through one control, start to finish
13 min
Builds on Who notices when this stops happening?
Part IV · Chapter 7 · The Audit · lesson 2
13 min
Builds on Who notices when this stops happening?
The first session is usually a conversation, and it is usually about one control at a time. Somebody asks you to talk them through it. Not to show them the policy — to describe what happens, in order, as though narrating a short film.
Almost everybody can do the first four steps. The fifth is where people slow down.
A walkthrough is five questions, asked in sequence about one control.
Who performs it. A named person or a named role, not a team.
When. On a clock, on an event, or continuously — and if on a clock, the same cadence your description claims.
What they look at. The actual screen, list or export. "They review access" is not an answer; "they open the group membership export and compare it against the current team list" is.
What they produce. The artefact that exists afterwards and would not exist otherwise.
What happens when they find something. The exception path: who they tell, what gets changed, where that is recorded, and how long it takes.
Four of these are description. The fifth is the one that decides whether this is a control or a routine.
Nobody is testing your eloquence. The reason the walkthrough comes first is mechanical: the sample request that follows is drawn from the population your answers imply, so a vague fourth answer produces a vague request and a precise one produces a short list of named artefacts. You are, in effect, writing the next week's homework out loud.
The fifth question is where the gaps live, and the reason is ordinary rather than sinister. Most controls have never found anything. The reviewer has opened the list eleven times, everything was fine eleven times, and no exception path has ever been walked. When somebody asks what happens if the reviewer disagrees with an entry, the honest answer is often we have not had to do that yet — which is a true, usable answer, and a much better one than inventing a process nobody has used.
Below is one control from the registry: who may approve a change, and whether the approver is allowed to be the author. It is a useful one to walk through because every step has a visible artefact and the fifth step is genuinely contested at small headcounts.
Decide where it stands for you. The block asks whether it applies, why in your own sentence, how far it has actually got, and who finds out when it stops — which is the fifth walkthrough question with the names filled in.
Decide · change-approval-independence
The point of an approval is that a second brain looked. Self-approval is not forbidden by arithmetic in a small team — sometimes there is genuinely nobody else awake — but it has to be a decision somebody made and can defend, rather than a gap nobody noticed between the policy and the branch protection settings.
The decision
Whether independent approval is a rule, a default with named exceptions, or honestly impossible at this headcount. All three are defensible and only one of them is true for any given company. If it is impossible, the decision is what stands in for it: a post-hoc review of merges, a pairing norm, an automated gate that cannot be bypassed by the person who wrote the change.
Where this goes wrong
The policy and the repository settings are written by different people at different times and nobody compares them. The policy says two approvals; the settings allow an administrator to merge alone; both are true, and the only artefact that shows the gap is the merge history, which is also the one nobody exports until an auditor asks.
Does this apply to you?
Nothing above graded your answer, because there is no answer key available. What the engine can do is read the rest of what you have written and say where it disagrees with what you just recorded.
Three of its rules bite hardest on a walkthrough. If you marked this running and nothing is linked that could show it ran, it says so and asks what you would hand somebody. If everything linked to it is a policy or a settings export, it says the linked artefacts speak to design rather than operation — which is exactly the gap between step three and step four above. And if you marked it in place with nobody named, it asks the fifth question back at you: who notices when this stops happening.
What does not line up
Nothing yet, because there is nothing in here yet. An empty workspace has no contradictions and tells you nothing.
These are contradictions between things you wrote. Nothing here can tell you whether any of it is enough — that is a judgement, and it moves with the auditor, the boundary and the year.
Check
If the control runs inside a supplier — a managed platform approves and deploys your changes, say — the five questions do not disappear, they move. Your walkthrough becomes a walkthrough of your own verification: who reads the supplier's report, when, what they look at in it, what they produce, and what happens when the report says something they do not like.
That is a real control with real evidence and it is smaller than the one it replaces. The trap is describing the supplier's control as though it were yours, because then the artefacts somebody asks for are artefacts you do not have and cannot get.