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 lives somewhere other than the system it describes. This is the one that does the real work, and it is worth being blunt about why.
Most audit logs, including ours, are rows in a database. There is no hash chain, no write-once storage, no cryptographic seal. Anyone with database access can edit a row, and nothing in the log itself would show it. That is the normal state of affairs for this class of product, and any vendor telling you their log is tamper-proof should be asked exactly how, because the honest answer is usually "it is not, it is a table".
Which means the property you actually need is not that the log cannot be altered. It is that altering it is not enough, because a copy already left the building. If the access system's own database is the only copy, then compromising that system compromises the evidence of the compromise — and the person best placed to do that is the administrator whose actions the log exists to record.
Streaming to a SIEM or any external collector as events happen is what closes this. The copy in the collector is written by a different system, under different credentials, usually with different administrators. Editing the source row after the fact does not retract it. That is where your tamper-evidence comes from — not from the broker, from the separation.
If you are evaluating tools in this category, this is the question to ask: not "is the log immutable" but "how fast does a copy leave the box, and who controls the destination".
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 logs every login, command and approval, and streams the log to your SIEM as events happen so a copy exists outside the broker. The log itself is database rows, not a hash chain — the copy in your collector is what makes it hold up. https://tessera.company/docs/access/audit/siem/
Top comments (0)