Every e-signature platform claims to produce an audit trail. The differences between them are huge — and almost entirely invisible until something goes wrong. This is what should actually be in there, why each piece matters, and what makes the difference between “here’s a log” and “here’s proof.”
The events that get logged
A complete trail records every meaningful interaction with the envelope, not just the final signature:
- Envelope created — sender, document hash, recipient list, field configuration.
- Envelope sent — exact timestamp, delivery method per recipient.
- Recipient opened — first view, with IP and city-level geo.
- Identity verified — email link clicked, SMS one-time code consumed (if required).
- Each field filled — which signer, which field ID, what content type, in what order.
- Signature applied — captured signature image hash, timestamp, IP at moment of signing.
- Envelope completed, declined, or voided — terminal event with summary.
Anything less leaves gaps a counterparty can exploit. “Yes the document was signed, but how do we know they understood what they were signing?” — answered by the field-fill log. “Did they actually verify their identity?” — answered by the SMS OTP event.
Hash chaining: the tamper-evidence primitive
Every entry in a high-quality audit log is hashed with SHA-256 — a one-way fingerprint — and that fingerprint includes the previous entry’s hash. This is the same primitive that powers transparency logs and blockchains. The effect: changing any past entry invalidates every subsequent fingerprint, and the chain root embedded in the certificate of completion would no longer match.
You don’t need to trust the e-signature platform’s claims about integrity — you can verify the chain yourself, after the fact, with nothing more than the signed PDF and a script.
The certificate of completion
When the envelope reaches its terminal state, the audit trail is sealed and a certificate PDF is generated and appended to the signed package. The certificate condenses the trail into something a human (and a court) can read at a glance:
- Envelope ID and document fingerprints (SHA-256 of the final flattened PDF).
- Each recipient’s name, email, IP, and verification method.
- Full chronological audit trail with UTC timestamps.
- Chain root hash and instructions for verifying the chain.
The certificate itself is signed (PAdES-compatible), so its provenance is verifiable independently of the original platform. If VG·Sign disappeared tomorrow, your certificate would still verify.
What a weak audit trail looks like
You’ll know it when you see it. Common warning signs:
- Single “signed at” timestamp with no view, fill, or verification events.
- No IP address or geographic data on the signing event.
- No hash of the document — just “the user signed this PDF.”
- The audit log lives only in the platform’s dashboard, not embedded in the signed PDF.
- No way to verify the integrity of the log without trusting the platform’s API.
Any one of these is a problem. All of them is a platform that produces signed PDFs but not evidence.
Why this matters before anything goes wrong
Almost every signed agreement is never disputed. The trail just sits in storage, occasionally consulted for compliance audits. But the few that aredisputed — boundary disputes, employment terminations, contested closings — are the agreements you most need to defend with evidence. The audit trail you ship by default determines whether you have that evidence ready, or whether you’re scrambling.
Treat the audit trail as the product, not a feature. That’s the bar.