Proof, not promises

An auditor is not evaluating whether your access design is a good one. That is your judgement to make and they have no basis to second-guess it. What they are testing is much narrower and much harder to fake: whether you can demonstrate that what you claim is what is deployed, and whether you would notice if it changed.

That reframing is worth sitting with, because it changes what you spend the week before an audit doing. Polishing the policy does not move the needle. Being able to regenerate the current state of the world from a command, next to a written statement of what it should be, does.

• Access design - the written statement of which jobs need which columns in which regions. It is the ground truth every other artifact is compared against, and without it there are no findings, only opinions.
• Grants dump - a generated text file listing the privileges that currently exist. Generated, not assembled, because the value is in being able to produce it again on any date.
• Exception register - one row per exception: the class, the role, the reason, the approver and the expiry. The output of session 4, and the thing an auditor reads first.
• Recertification - the recurring exercise where somebody confirms that current access is still correct. Also the most widely performed and least informative control in the discipline.
• Standing privilege - a column a role can read in clear that the design does not mark clear for that role. The number this whole session exists to make reportable.

Each test exists because of a specific way evidence has been wrong in the past, and knowing which failure each one is guarding against makes them easy to apply yourself.

• Reproducible. Can somebody else produce the same artifact from the system, today, without you in the room. This guards against evidence that describes a state that never quite existed, which is what hand-assembled evidence tends to do without anybody intending it.
• Timestamped against a change history. Not "does it have a date on it" but "can you place it in a sequence of changes". A dated file that sits alone tells you the state on one day and nothing about how it got there or what happened after.
• Comparable. Can it be put next to the same artifact from last quarter and produce a difference. This is the test that actually detects drift, and it is the one most evidence fails, because each round is produced in a slightly different shape by a slightly different person.

Notice that none of the three is about how thorough the artifact is. A short reproducible file beats a comprehensive one that exists only once, every single time.

The screenshot survives because it is the fastest thing to produce under pressure and because it looks like proof to the person sending it. It is a picture of the real system, after all. But it is a picture of one screen, at one moment, chosen by the person being audited, in a format nothing can compare.

• It cannot be re-run. If the state changed yesterday, the image is silently wrong and there is no way to detect that from the image.
• Its date is metadata, not history. A file creation date says when the picture was taken, not when the grant was made, by whom, or what it replaced.
• It cannot be diffed. Two screenshots from two quarters have to be compared by a human reading them side by side, so in practice nobody does it and drift is never found.
• The framing is chosen by the subject. Not dishonestly, usually. But a screen showing the roles you thought to check is a different thing from a dump of all of them.

Three files, produced together, cover the whole question. They are not impressive individually, and together they answer both halves of what is being tested: what you claim, what is deployed, and whether you would notice a change.

The pairing is what makes it evidence. The design alone is a promise. The dump alone is a state with no standard to judge it by. Put them side by side and the gap between them is your finding list, produced by a comparison rather than by an opinion, which is also exactly what the auditor was going to do with them.

The register is short and it is read first, so every column on it is doing work. A row that cannot answer these five questions will generate a follow-up, and follow-ups are how a two-day review becomes a two-week one.

• Which class or column the exception applies to, matching the names used in the design. Different names in the two documents reads as two different systems.
• Which role holds it, never which person. A person named on a register is a row that becomes wrong the day they change team, and nobody updates it.
• The reason, in one sentence a stranger can evaluate. Support has to reach the actual human. Not "operational requirement", which cannot be checked and therefore cannot expire.
• The approver, by name, being whoever owns the table rather than whoever had the ability to grant it.
• The expiry, as a date. An exception without one is a permanent grant that has been described as temporary, and a register full of those is evidence of the wrong thing.

Empty rows count. A class with no exception role belongs on the register too, written as none, because the strongest statement in the design is invisible if it is only recorded as an absence of rows.

What it is meant to do. Find the grant whose reason has expired. Somebody moved team, a project finished, an incident was resolved, and the access stayed. Nothing in a warehouse notices any of those events, so a recurring human check is genuinely the right control.

What it usually does. A quarterly export lands in a manager's inbox listing every role their reports hold. Two hundred rows of names like analyst_shared and etl_legacy_loader, with no dates, no usage and no indication of what changed since last time. The manager cannot evaluate a single row and is not being unreasonable about that: the packet contains no information to evaluate against. So they approve all, on time, and the control reports 100 percent completion.

The failure is in the packet, not the person. A control that requires somebody to know something the document does not tell them will be performed and will detect nothing, quarter after quarter, while showing green.

Replace the full inventory with two short lists and the same hour of a manager's attention starts producing findings.

• The diff. What changed since the last review: new grants, removed grants, changed roles, each with a date and whatever ticket or approval is on file. Usually a handful of rows. The question becomes should this new grant exist, which a manager can genuinely answer, because it is about a recent decision they may well have been part of.
• The unused-privilege list. Privileges the role holds and has not exercised in 90 days, read from query history. The question becomes why does this role still hold something nobody used, and the honest answer is often "no reason", which is exactly the finding recertification was invented to produce.

Both questions have answers. That is the whole design criterion. A packet of 200 role names asks an unanswerable question 200 times and gets one signature; a packet of seven rows asks two answerable ones and gets seven decisions.

Recertification completion percentage is the metric usually reported, and it is a measure of whether people clicked, not of whether access is correct. The reportable outcome is standing privileges: columns a role can read in clear that the design does not mark clear for that role.

The Saltbox ladder makes the case on its own. One shared analyst role carries 30 standing privileges. The finished design, with masking, a five-way role split, a row policy on region and a pseudonymised modelling view, carries 0, alongside 0 leaks and 0 over-blocks across the same 150 requests.

That third row is the one to keep in mind when you report a zero. Every policy is still defined and still deployed, and the estate is identical to where it started, because one grant sits above all of it. A number is only evidence if the thing that can silently invalidate it is also being reported.

Worth saying plainly, and worth saying to the person who signs, because a control oversold is a control that gets blamed later. A review compares deployed state against written design. It cannot see purpose.

A grant that is correctly approved, correctly recorded, within design, and issued to somebody who is going to misuse it passes every test in this session. So does a grant to the wrong person with the right job title. Those are detected by monitoring what was actually read, by separation of duties, and by the fact that somebody notices a colleague pulling records they have no reason to pull.

• What a review does prove. That the deployed state matches the written design on the date it ran, and that you can show what changed since last time.
• What it does not. That the design is correct, that the approvals were thought about, or that access is being used for the purpose it was granted for.
• Why saying so helps. It puts the residual risk somewhere it can be owned, rather than leaving it hidden inside a green control that everybody assumed covered more than it does.

Reviews vary, but the sequence rarely does, and knowing the order tells you which artifact to have open.

• What is the control. Answered by the written access design. If this takes more than one document to answer, everything after it gets slower.
• Show me it is deployed. Answered by the generated grants dump, produced live if possible. Producing it in the meeting is worth more than any amount of prepared material.
• Show me the departures. Answered by the exception register, which is why the reason column has to be readable by somebody who does not know your business.
• Show me last quarter. Answered by the commit history and the previous dump. This is the question the screenshot approach dies on.
• Who approved this one. Answered by the register and the commit that added it. A change with no approver named is a finding regardless of whether the change was correct.
• How would you know if it changed. Answered by whatever runs on a schedule and by who reads its output. "We would notice" is not an answer, and it is the most common one given.