What an e-signature audit trail contains
An e-signature audit trail is the record of everything that happened to a document during the signing process — who received it, when they opened it, when they signed, and from where — chained together in a way that makes later tampering detectable. It's what turns "this document was signed electronically" into something you can actually prove if it's ever challenged.
Why an audit trail exists in the first place
A signature on its own — even a perfectly drawn one — doesn't prove much without context. What gives an electronic signature its evidentiary weight is the surrounding record: proof that a specific, identified person received the document, took a deliberate action to sign it, and that the document hasn't changed since. The audit trail is that record.
What events a typical audit trail logs
- Document sent: when the signing request was created and the signer's link generated.
- Document viewed: when the signer opened the link and accessed the document, if the platform tracks this event.
- Fields completed: when the signer filled in their assigned fields — signature, initials, date, text.
- Document signed: the moment the signer completed all required fields, along with the IP address and browser/device information recorded at that time.
- Request completed: when every required signer on the document has finished their part.
Each of these events is typically timestamped and stored alongside identifying details about the signer's session, so the full sequence can be reconstructed later.
Why the entries are chained with hashes
A plain log of events — even a detailed one — could theoretically be edited after the fact. A hash-chained audit trail solves this by having each new entry include a cryptographic hash of the previous entry, so the entries form a chain: altering any single entry would change its hash, which would no longer match what the next entry in the chain recorded, making the tampering detectable. This is the same basic principle used in other tamper-evident logging systems, applied specifically to the signing process.
Document hashing vs audit trail hashing
These are two related but distinct mechanisms, and it's easy to conflate them:
|
What it protects |
How it works |
| Document hash |
The signed file itself |
A cryptographic hash of the final signed document is computed; any later edit to the file would produce a different hash |
| Audit trail hash chain |
The sequence of signing events |
Each audit log entry includes the hash of the previous entry, so the order and content of events can't be silently altered |
Both matter: the document hash tells you whether the file was tampered with, and the audit trail hash chain tells you whether the record of what happened was tampered with.
RFC 3161 timestamps
Some platforms add an independent timestamp conforming to RFC 3161 to the signing record. This is a timestamping standard that lets a third party certify that a given piece of data (in this case, the signed document or a specific event) existed at a specific point in time, independent of the signing platform's own internal clock. It adds an extra layer of evidence about exactly when something happened, verifiable outside the system that generated it.
What a completion certificate usually includes
Once every signer has completed their part, most platforms generate a completion certificate — a summary document that typically includes the document's hash, each signer's identifying information (name, email, IP address, device), and the timestamp of each key event in the audit trail. This certificate is meant to be a self-contained, portable piece of evidence that doesn't require access to the original platform to understand what happened.
What an audit trail does not do
An audit trail proves what happened during the signing process on the platform — it doesn't verify the signer's real-world identity beyond what was used to access the link (typically, control over an email address), and it doesn't substitute for a notary or an identity-verification service if a document specifically requires one. For documents that need stronger identity assurance, this is one of the reasons higher-tier signatures — such as the qualified tier under eIDAS — require a certificate issued by an accredited provider rather than relying on an audit trail alone. See eIDAS: simple, advanced and qualified signatures for that distinction.
Why this matters if a signature is ever disputed
If the validity of a signed document is ever questioned, the audit trail — not just the visual signature — is typically what gets examined. A clear, hash-chained record showing exactly who was identified, what they did, and when, is far stronger evidence than a signature image alone. See E-signature evidence: what counts in a dispute for more on how this record gets used in practice.
How a multi-signer audit trail stays organized
On a document with several signers, the audit trail doesn't merge everyone's actions into one undifferentiated log — each signer's events (viewed, fields completed, signed) are tied specifically to that signer's identity and session, even when multiple people are acting on the same document around the same time. This matters most on documents with a signing order, where the trail needs to clearly show not just that each person signed, but that they did so only after the document had actually reached them in sequence.
You don't need to understand cryptographic hashing to get value from an audit trail in an everyday business context — the practical value for most people is the plain-language sequence: who received the document, when they opened it, when they completed it, and whether every required step happened in the expected order. The hashing and chaining work in the background to make that sequence trustworthy; you don't have to verify the hashes yourself to benefit from the fact that they exist and would reveal tampering if it occurred.
What happens if an event in the chain seems to be missing
If a specific expected event — say, a "document viewed" entry — doesn't appear in an audit trail, that's not automatically evidence of tampering; it may simply mean the platform didn't log that particular event type, or that the signer accessed the document in a way that didn't trigger it. It's worth distinguishing a genuinely broken hash chain (where an entry's hash no longer matches, indicating something was altered) from an audit trail that was simply never configured to capture a certain event category in the first place.
See it on a real document
Every signature completed through Esignapi's API is backed by a hash-chained audit trail and a completion certificate automatically — you don't need to build this logging yourself.
Frequently asked questions
Can an audit trail be edited after the fact?
Not without it being detectable. Because each entry includes the hash of the previous one, changing any entry breaks the chain, which makes tampering apparent when the trail is reviewed or verified.
Does the audit trail include the signer's exact location?
Typically it includes the IP address recorded at the time of key events, which can indicate an approximate geographic location, along with device and browser information — not a precise physical address.
Is a document hash the same as a digital signature?
They're related but not identical — a document hash is one building block used in cryptographic signing. See Electronic vs digital signature for the fuller distinction between the legal concept and the cryptographic technique.
How long should an audit trail and certificate be kept?
That depends on the type of document and any retention requirements that apply to it (contractual, regulatory, or otherwise) — the audit trail itself doesn't expire, but how long you need to retain a copy depends on your own recordkeeping obligations.
What happens to the audit trail if I cancel a signature request?
A cancelled request still retains whatever events were logged before cancellation; the cancellation itself is typically also logged as an event, so the record reflects that the document was withdrawn rather than completed.