What an electronic signature audit trail actually records
An audit trail is only worth having if it can answer a question somebody asks you two years later, under pressure, about a document you no longer remember.
Every e-signature product produces something it calls an audit trail. They are not the same thing, and the differences only matter on the day they matter — which is the day somebody says they never agreed to this.
What gets recorded
A useful trail records the whole life of the agreement, not the moment of signing:
| Event | Why it is in the record |
|---|
|---|---|
| The document was uploaded, and what its bytes hashed to | Establishes what was sent, not what was later claimed to have been sent |
|---|---|
| Each invitation and reminder that went out | A signer who says they never received it is making a checkable claim |
| Each time a recipient opened the document | Opening is not agreeing, but never having opened it is a defence |
| Each identity check, passed or failed | A refused passcode attempt is the one an auditor goes looking for |
| Each field value as it was set, and by whom | Distinguishes what the sender pre-filled from what the signer typed |
| Consent to do business electronically | Required by several regimes, and trivially omitted |
| Completion, and the hash of the finished document | Ties the record to one specific file |
| Anything the routing skipped, and the rule that skipped it | A reviewer who never acted is the fact people query most |
That last row is the one most products get wrong. If an approval step is skipped because an amount came in under a threshold, the record has to say the approver was not required and why — otherwise the document appears to be missing a signature it never needed.
Three properties that separate a record from a log
It is append-only. A trail you can edit is not evidence of anything. Corrections are new entries, never changes to old ones.
It is tamper-evident. Each entry should carry a hash that covers the entry before it, so removing or altering an entry anywhere breaks the chain from that point forward. Without this, "append-only" is a promise about the software rather than a property of the data.
What it claims and what it seals are the same set. A certificate that lists twenty-one facts under a seal covering fourteen of them is worse than no seal, because it invites reliance it cannot support. This is easy to get wrong quietly: add a field to the certificate, forget to add it to the seal, and nothing fails.
Pactlyra has one definition of what the seal covers, and the certificate is sealed by calling it. A test edits every leaf of a real certificate one at a time and asks verification whether it noticed — so a fact added and left out of the seal fails on the day it is added, rather than in a dispute.
Questions to ask your current provider
- Can I export the trail in a form I can read without your software?
- Does the trail record failed authentication attempts, or only successful ones?
- If a recipient was skipped by conditional routing, does the certificate say so?
- Can I verify a completed document offline, without calling your API?
- If you went out of business tomorrow, what would I still be able to prove?
Question five is the honest test. A record that only means something while a vendor is alive to vouch for it is not evidence, it is a subscription.
What "verifiable" should mean
The strong version is that the evidence package carries its own verifier: the hashes, the chain, the certificate, and a small program that checks them, all in one folder, with no network call and no account. Anyone you hand it to can run it. The weak version is a PDF with a logo on it.
Last reviewed 2026-09-18. Pactlyra produces a detailed evidence record for every completed document. Electronic signature validity depends on your jurisdiction, the document type, and how the transaction is carried out; nothing here is legal advice.