Auditors do not want your policy. They want an artefact.

Operations 4 min read

An auditor cannot test a policy document. What they can test is an artefact with a timestamp on it — and the difference decides how an access review goes.

Disclosure: I work on an access tool (Tessera), mentioned once at the end. Everything before that is about evidence, and applies whatever you use.

The most common surprise in a first SOC 2 or ISO 27001 audit is not that a control is missing. It is that a control exists, works, and cannot be evidenced — so it counts as absent.

The distinction is worth stating precisely, because it is not obvious until it has cost you something.

A control is a thing that is true about your system. Only authorised engineers can reach production.

Evidence is an artefact, produced by a system rather than by a person, that demonstrates the control was operating throughout the audit period — not on the day someone checked.

Most organisations have decent controls. Most cannot produce evidence, because their controls live in places that do not emit artefacts: a bastion’s authorized_keys file, a spreadsheet, a Slack thread where someone approved something, and the collective memory of three engineers.

What gets asked for

Reconstructed from what people have told me, this is the shape of the questions:

“Show me everyone who could access production on 14 March.” Not today. A specific date in the past, usually chosen by the auditor. This is the one that catches people, because most systems can tell you the current state and cannot tell you a historical one. authorized_keys has no history. A spreadsheet has whatever history git gives it, if it is in git, which it usually is not.

“Show me that this person’s access ended when their employment ended.” Both timestamps, from two systems, matched. HR has the first. The second is the problem.

“Show me the approval for this elevated access.” Not that a policy requires approval — the specific approval, for this specific grant, with who approved it and when.

“Show me what was done in this session.” Increasingly common where production access to customer data is involved. Not “we log commands”, but the actual record for a named session.

“Show me that these controls operated for the whole period.” The hardest one, and the reason point-in-time screenshots fail. A screenshot proves a moment. The auditor is asking about twelve months.

Why the usual sources fail

Spreadsheets are claims, not evidence. They record what someone believed, are edited without history, and cannot answer a question about a past date.

authorized_keys files hold current state only. You can see who has access now. You cannot see who had access in March, or when a key was added, or by whom.

Ticket systems record that a request happened, not that the access was actually granted, matched the request, or was removed afterwards. The gap between the ticket and the system is exactly where findings live.

Chat approvals are not retrievable at audit scale and not tamper-evident. “Someone said yes in a thread” is a story.

Shell history is user-writable, per-host, and rotates. It is not evidence of anything, and treating it as such is worse than admitting you have nothing.

What actually works

Three properties, and they are not features of any particular product — they are what makes an artefact count.

It is append-only. If the record can be edited by anyone, including an administrator, then it establishes nothing under adversarial assumptions, and audit is an adversarial exercise by design. Whatever your system, the log needs to be one that cannot be quietly rewritten.

It lives somewhere other than the system it describes. If the access system’s own log is the only copy, then compromising that system compromises the evidence of the compromise. Streaming to a SIEM or any external collector is not a nice-to-have here; it is what makes the record survive.

It is produced automatically. Evidence created by a human is a claim about the system. Evidence emitted by the system is a fact about it. This is the difference between “we review access quarterly” (a process, evidenced by a document someone wrote) and “here is the log of every grant and revocation with timestamps” (a fact, evidenced by itself).

Add a fourth, practical one: you can export it. Auditors work in spreadsheets and PDFs. A beautiful dashboard you cannot export is a demo, not evidence.

The thing nobody plans

Retention.

Your audit period is twelve months. Your evidence has to cover twelve months. If your log rotates at 90 days, you have three months of evidence and nine months of an explanation.

Set retention to your compliance window before you need it, and size the disk for that window deliberately. Both failure directions are real: too short and you cannot evidence the period; infinite and you are storing personal data forever, which is its own regulatory problem and will show up in a different part of the same audit.

The reframe worth taking away

Access control is usually budgeted as prevention — stopping bad things. That framing makes it compete with every other security spend and usually lose, because prevention is unfalsifiable until it fails.

The evidence framing is different and easier to defend. The artefacts are what unblocks enterprise deals and passes audits, which are revenue events with dates attached. A control you cannot evidence does not appear in either.

That is the argument that gets budget approved, and it happens to also be the true one.

Tessera writes an append-only audit log of every login, command and approval and streams it to your SIEM as events happen, so a copy exists outside the broker. https://tessera.company/docs/access/audit/siem/

Also posted on dev.to