Designing audit logs you can actually trust
How tamper-evident hash chains change incident response and what we learned implementing them in production.
Why audit logs matter more than you think
When a security incident happens, the first thing investigators reach for is the audit log. But here’s the uncomfortable truth: most audit logs can be silently modified by anyone with database access.
If your audit log is just rows in a SQL table, it’s not an audit log — it’s a suggestion.
Our approach: hash chains
Every event in EntryBit’s audit log includes a cryptographic hash of the previous event. This creates an immutable chain — if anyone modifies or deletes a single entry, the chain breaks and the tampering is immediately detectable.
The implementation details matter:
- SHA-256 hashing with the previous event’s hash as input
- Periodic checkpoints signed with a hardware security module
- Export verification — any exported log bundle can be independently verified without our system
What this means for compliance
For any security audit, tamper-evident logging isn’t just nice to have — it fundamentally changes your audit story. Instead of “we believe our logs are accurate,” you can say “our logs are cryptographically verified.”
That’s a conversation compliance teams want to have.
