Tamper-Evident Audit and Read Logging
Two related controls: making the audit trail tamper-evident, and recording reads as well as writes.
Where to find it
Architect Panel → Activity:
- Audit Chain — the chain state and its verification points
- Record Read Log — who opened which record, and when
- Activity Log — the general activity trail
Why an ordinary audit trail is not enough
A normal audit table records what changed. It does not prove that the record of what changed has not itself been altered — and anybody with database access could edit or remove a row.
For most purposes that is acceptable. For an investigation, a regulator or a court, "the audit trail says so" invites the question of whether the audit trail could have been edited.
The hash chain
Each audit entry is stamped with a hash of its content, chained to what came before. Altering or removing an entry breaks the chain from that point onward, and the break is detectable.
This does not make tampering impossible. It makes it evident — which is the achievable and useful property.
Gaps are declared, not silent
One legitimate operation does remove audit rows: retention disposal, which deletes the audit for a record it destroys.
Rather than leaving a break indistinguishable from tampering, disposal declares the gap. So a verification run can distinguish "records were lawfully destroyed here" from "something was altered here" — which is exactly the distinction that matters.
Read logging
Write auditing answers who changed this. Read logging answers who looked at it — frequently the more important question.
Inappropriate access to records is far more often reading than editing: a member of staff looking up a neighbour, an ex-partner, a celebrity. No write audit will ever show that. The read log will.
Read logging has a cost
Every record opened writes a row, so the log grows quickly on a busy system. Enable it where the sensitivity justifies it — casework, HR, health, anything classified — rather than everywhere by default, and set a retention period for the log itself.
Using it
The read log is only useful if somebody looks. Two practical uses:
- Investigation — after a concern is raised, showing who accessed a record and when.
- Proactive sampling — periodically checking access to high-profile records, which is how inappropriate access is usually found rather than reported.
Pair it with break-glass review; between them they cover both the access that was refused and escalated, and the access that was permitted but questionable.
Worked example
A council receives a complaint that a resident's records were accessed by a member of staff who knows them personally. The read log shows three accesses over two months, none associated with any case activity. The write audit showed nothing at all, because nothing was changed — which is precisely why read logging was enabled on that datastore.
Recommendations
- Enable read logging on sensitive datastores, not everywhere.
- Set a retention period for the log — it is personal data too.
- Verify the chain periodically rather than only after an incident.
- Sample proactively. Waiting for a complaint means most inappropriate access is never found.