An e-signature audit trail is a tamper-evident record of every event in a document's signing lifecycle. It is the primary evidence chain that makes an electronic signature legally defensible. Here is what it should contain, how PKCS#7 sealing works, and what to look for in a service.
SHA-256 hash of the original PDF recorded at envelope creation — any later alteration is detectable.
Timestamp, IP address, user agent, and geolocation captured the moment a signer opens the signing page.
Explicit e-sign consent (ESIGN Act § 101(c)) captured with intent-to-sign disclosure acceptance.
Each signature event logged with timestamp, IP, user agent, and the signer's OTP-verified identity.
Fields flattened into the PDF; a service-level PKCS#7 digital signature applied; document hash recorded.
A human-readable summary page appended to the sealed PDF listing every event, hash, and timestamp.
Each audit event row carries a cryptographic hash of the previous row. Removing or altering any row breaks the chain — detectable by anyone who re-verifies the sequence, even if they have direct database access.
Email or SMS one-time password (OTP) verification ties each signature event to the signer's verified contact method. The OTP delivery event is itself logged, providing a chain from identity to signature.
Every event records the signer's IP address, browser user agent string, and resolved geographic location. This is the forensic metadata that proves a specific device, in a specific location, performed the action.
After all signers complete, the document is sealed with a PKCS#7 (CMS) digital signature using a CA-issued certificate held by the service. Any single-byte modification to the sealed PDF invalidates the signature — verifiable by any PDF reader that supports digital signatures.
A human-readable summary page is appended to the sealed PDF: every event, every timestamp, every hash, and every IP address. Courts and counterparties can read the certificate without any external tool.
The audit log table is append-only at the database grant level — UPDATE and DELETE permissions are revoked from the application role. Even a compromised application cannot alter past events.
SHA-256 hash of the original PDF stored at envelope creation.
Each signing event — view, consent, OTP verification, signature — appended to the hash-chained audit log with IP, user agent, timestamp, and geolocation.
Fields flattened into the PDF; the sealed document hashed; hash stored as document_hash_final.
A PKCS#7 digital signature applied over the entire sealed PDF using a CA-issued X.509 certificate.
Audit certificate page appended to the PDF: every event, hash, IP, and timestamp — readable without any external tool.
Audit log table is append-only at the database grant level — UPDATE and DELETE revoked from the application role.
This is the integrity layer. It exists entirely to hold up in court, not just to demo well.
An e-signature audit trail is a tamper-evident record of every event in a document's signing lifecycle: when the document was created (and its hash), when each signer viewed it, when consent was recorded, when each signature was applied, and when the document was sealed. A legally defensible audit trail includes IP addresses, timestamps, user agents, and geolocation for each event, plus a cryptographic seal over the final document.
In the US (ESIGN Act and UETA), the law does not mandate a specific audit trail format, but it does require that e-signature systems be capable of producing records that demonstrate the intent to sign and the integrity of the signed document. A comprehensive audit trail is the standard way to satisfy this requirement and to defend a signature in court. Canada's PIPEDA and provincial electronic commerce acts have similar evidence standards.
A PKCS#7 (also called CMS — Cryptographic Message Syntax) seal is a digital signature applied over the entire sealed PDF file using an X.509 certificate issued by a certificate authority. Any modification to any byte of the file after signing invalidates the signature. PDF readers that support digital signatures (Adobe Acrobat, Preview on macOS, and others) will report the signature as valid or broken. GetSigned applies one service-level PKCS#7 seal after all signers have completed.
Hash-chaining means each audit event row stores a cryptographic hash of the previous row's hash. The result is a chain: altering or removing any event changes its hash, which breaks the next row's expected hash, and so on through the entire chain. This makes tampering detectable even by someone with direct database access — you cannot silently remove an event without the chain breaking.
Yes. GetSigned produces a hash-chained event log (append-only at the database grant level), a PKCS#7-sealed PDF, and an audit certificate page appended to the signed document. Every event — view, consent, OTP verification, signature, seal — is logged with IP, user agent, timestamp, and geolocation. The sealed PDF carries the full evidence chain within the document itself.
This page is for informational purposes only and does not constitute legal advice. Consult a qualified attorney for advice specific to your use case and jurisdiction.
Related: Are electronic signatures legally binding? · What is an e-signature API? · Developer integration guide
Every GetSigned envelope ships with a PKCS#7 seal, hash-chained audit log, and an audit certificate page — on the free tier.
Get free API keys →