"We have an audit trail" has become a checkbox phrase. Almost every document tool prints a list of events somewhere. The question that matters is different: when the log itself is challenged, can you show it has not been altered?
An ordinary activity log is just rows in a database
A typical activity log is a table that the application writes to — and can, in principle, rewrite. An administrator, a bug, or an attacker with database access can edit or delete rows, and nothing about the remaining rows reveals it. The log is evidence only as long as nobody questions the log.
What GingerDocs does differently
Every event in a document’s life — created, sent, viewed, signed, declined, voided — is appended to a log that works like a tamper-evident ledger:
- Append-only — events are added, never edited or removed.
- Hash-chained — each entry includes a SHA-256 hash of the previous entry, so every record is cryptographically bound to everything before it.
- Attributed — each event carries a timestamp and the IP address it came from.
Why chaining changes the game
Suppose someone alters one historical entry. Its hash no longer matches the value embedded in the next entry, which no longer matches the one after that — the chain visibly breaks at the point of tampering. Falsifying history quietly would require recomputing the entire chain forward, which is precisely what an append-only design refuses to allow.
The result is a log that does not ask to be trusted; it can be checked.
Verification closes the loop
A tamper-evident log is most useful when the other side can consult it. Anyone holding a completed GingerDocs PDF can confirm on the public verification page that the file matches what the audit log records as signed — without an account and without taking anyone’s word for it.
When you evaluate a signing tool, do not ask whether it has an audit trail. Ask what stops the audit trail from being edited. If the answer is "permissions," keep looking.