An Audit Trail You Can Prove Wasn’t Edited
Most audit logs are just a table someone with database access could quietly change. Fintra’s audit trail is hash-chained, so any edit breaks the chain - and an auditor can recompute it to confirm integrity.
Illustrative product view
Why most audit logs don’t hold up
A plain audit log records what happened, but it proves nothing about whether the record itself was altered afterward. Anyone with database or admin access can change a row, and the log has no way to show it. An auditor assessing a control has to take the log on faith. Fintra’s audit trail closes that gap by hash-chaining every entry so tampering becomes detectable rather than invisible.
How the trail stays tamper-evident
- Each entry’s hash includes the previous entry’s hash, forming a chain
- A per-org monotonic sequence means gaps or reorders are visible
- Hashes cover the decision content, so any field change is detectable
- verify_chain recomputes the whole chain and reports whether it is intact
| Property | Plain log | Fintra audit trail |
|---|---|---|
| Records the action | Yes | Yes |
| Detects a silent edit | No | Yes - breaks the chain |
| Independently verifiable | No | Yes - recompute the chain |
| Reproducible entry hash | No | Yes - same input, same hash |
What the trail captures
Every governed action becomes an entry: who acted, what they did, to what resource, the verdict, the risk and trust score, and the linked evidence. Because the same decision always hashes to the same value, the entry is a golden vector - replay the action and the hash must match, or the record was changed.
Audit-ready by construction
What an auditor gets
- A complete, sequenced record of governed actions
- A verification endpoint to confirm the chain is intact
- Reproducible hashes they can independently recompute
- Evidence links from each entry to the control it supports
Frequently asked questions
Does SOC 2 require an audit trail?
SOC 2’s Common Criteria expect logging and monitoring of system activity - CC7 in particular covers detecting and responding to events, and evidence that access and changes are recorded. A tamper-evident audit trail is strong evidence for those controls because it shows not only that activity was logged but that the log itself is trustworthy.
What makes an audit trail tamper-evident?
Tamper-evident means any change to a recorded entry is detectable. Fintra achieves this by hash-chaining: each entry’s hash incorporates the previous entry’s hash, so altering one entry breaks every link after it. Recomputing the chain reveals the break.
Can an auditor verify the trail independently?
Yes. Because entry hashes are reproducible and the verification recomputes the chain from stored fields, an auditor can confirm integrity without trusting the application. The verify endpoint reports whether the chain is intact.
Is this an immutable log?
It is tamper-evident rather than strictly immutable: entries can physically be changed, but any change is detectable because it breaks the hash chain. That gives you the audit property that matters - you can prove whether the record was altered - without the cost of an append-only distributed ledger.
Stay in the loop
One practical finance briefing a week - new guides, checklists, and benchmarks.
Prove your audit trail wasn’t edited
Give auditors a hash-chained record they can verify for themselves.
Talk to us