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, recipient list, field configuration.
- Envelope sent: exact timestamp, delivery method per recipient.
- Recipient opened: first view, with IP address and device.
- Identity verified: email link clicked, SMS one-time code consumed (if required).
- Each field filled: which signer, which field, in what order.
- Signature applied: timestamp, IP, and device at the 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?” The field-fill log answers that. “Did they actually verify their identity?” The SMS OTP event answers that.
Tamper evidence: the document fingerprint
When an envelope completes, VG·Sign records the SHA-256 hash (a one-way fingerprint) of the final, flattened PDF on the certificate of completion. Anyone holding the signed document can recompute that hash and compare it to the certificate. Change a single byte of the PDF and the fingerprints no longer match. You don’t have to trust our word for the document’s integrity. You can verify it yourself, with nothing more than the signed PDF and any SHA-256 tool.
The event log behind the certificate is append-only. Updates and deletes are blocked at the database level by Row-Level Security, so entries can’t be quietly rewritten after the fact. The log only ever grows.
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.
- Device captured at each signing event.
The certificate travels inside the signed package and carries each document’s SHA-256 fingerprint, so its core claim, that this exact PDF is the one that was signed, can be checked by anyone, independently of our platform.
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 device captured 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 document fingerprint you can recompute yourself to confirm the file is unaltered.
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.