What Is an E-Signature Audit Trail, Why It Matters, and How to Read One

The signature on an electronically signed contract is the least interesting part of the file. The audit trail is what turns a picture of a name into evidence that a specific person agreed to a specific document at a specific time. This guide explains what an audit trail is, what a good one records, why hashes and trusted timestamps matter, and how to read one when it counts.

What an audit trail is

An audit trail is the chronological, tamper-evident record of everything that happened to a document from creation to completion: who uploaded it, when it was sent and to whom, when each recipient opened it, how they were verified, when and from where they signed, and when the document was sealed. It is generated automatically by the e-signature platform and stored alongside the signed PDF. Most platforms also produce a certificate of completion, a one- or two-page summary of the trail that travels with the document.

Think of it as the electronic equivalent of a notary's journal, a witness, and a postmark combined, except more detailed and harder to fake.

Why it matters

US law (the ESIGN Act and UETA) makes electronic signatures valid, but validity is only half the problem. When a signature is disputed, the question is almost always attribution: was it really this person, and did they really agree to this version? UETA says an electronic signature is attributable to a person if it was that person's act, which may be shown in any manner, including the efficacy of the security procedure used. The audit trail is that showing. Without it, you have a PDF with a name on it and someone's word. With it, you have delivery records, access records, verification records, timestamps, IP addresses, device details and a cryptographic proof that the file has not changed. See our guide on whether e-signatures are legally binding for the legal framework.

It also matters outside the courtroom. Auditors, insurers, lenders, licensing boards and HIPAA compliance reviews all ask the same question: show me who did what, when. A good audit trail answers it in one download.

What a good audit trail records

Here is what ShockSign writes, which is a reasonable standard to hold any platform to.

Document events

• Created and uploaded, with the original file's SHA-256 hash computed at upload.
• Sent: each signature request, the signer's name and email, the signing order and any CC recipients.
• Email sent and, separately, link accessed and document viewed, so you can distinguish delivery from reading.
• Reminders sent, on the schedule you configured.
• Signature completed or declined, per signer, with a reason if declined.
• Document completed, downloaded, voided or expired.
• Certificate generated.

Per event

• A timestamp (UTC on the server, shown in local time on the certificate).
• The actor: the account user, the signer's email, or "system" for automated events.
• The IP address and the user agent (browser and device) of the request. ShockSign stores these encrypted at rest.

Per signature

• Signer name and email, the time of signing, the signature type (drawn, typed or uploaded), and a hash of the signature itself.
• The verification method: the unique email link, an emailed code if the sender required one, or an in-person session started by the sender.
• How intent was demonstrated: an explicit click-to-sign action after completing the fields.
• For public signing links, additional signer metadata such as time zone, language and the page the form was signed from.

Integrity proof

• The SHA-256 hash of the final sealed PDF, and a current hash recomputed at verification time so the certificate can say whether the file still matches.
• An RFC 3161 trusted timestamp from an independent time-stamping authority, which proves the sealed file existed at that moment on a clock the sender does not control.

Hashes and trusted timestamps, briefly

A cryptographic hash is a fixed-length fingerprint of a file. SHA-256 produces 64 hex characters. Change a single byte of the PDF and the fingerprint changes completely, and there is no practical way to craft a different document with the same fingerprint. Recording the hash at completion means anyone can later check whether the file they hold is the file that was signed.

A trusted timestamp solves a different problem: your own server's clock could be wrong or manipulated. Under RFC 3161, the platform sends the hash to a time-stamping authority, which signs it together with the current time and returns a token. The token proves that this exact hash existed at that time, and it can be verified independently of the platform. Together the hash and the timestamp mean a signed document is both tamper-evident and time-anchored.

How to read a certificate of completion

ShockSign's certificate and downloadable audit PDF follow a common layout. Reading one:

1. Header. Document title, document ID, certificate ID, status (Verified for a completed document), created and completed times. Check that the document ID matches the PDF you are looking at.
2. File hash. The SHA-256 recorded at completion. If you have the PDF, compute its hash yourself (any OS can do this from the command line) and compare. Or use the document's public verification page, which does the comparison for you and reports whether the file is authentic and unaltered.
3. Security summary. Encryption at rest and in transit, and the integrity method. This is context, not evidence about the signer.
4. Signatures. One block per signer: who, when, from what IP and device, how they were verified, and how intent was shown. This is the section a lawyer reads first. Look for a verification method stronger than the email link on high-value documents, and for timestamps that make sense in sequence (viewed before signed, signed before completed).
5. Audit trail. The full chronological event list with actor, IP and user agent. Use it to answer specific questions: Did the signer open it before the deadline? Was a reminder sent? Was the document voided and resent, and when?
6. Timestamp. The RFC 3161 token details. Verifiable with standard tools if anyone challenges the completion time.

Red flags when reviewing someone else's audit trail

• No hash of the final document, or a hash that does not match the file you were given.
• Timestamps only from the vendor's own server, with no independent time source.
• No record of when the signer viewed the document, only when they signed.
• Events attributed to a shared or generic account rather than a named user.
• A certificate that can be edited (a Word file, say) rather than generated and sealed.
• Gaps: a document that was "completed" without a corresponding signature event for every signer.

Keeping the audit trail with the document

The trail is only useful if you can find it in three years. Download the signed PDF and the certificate together and store them in your own system of record, whether that is a deal folder, an EHR, a dealer management system or a plain shared drive. Retention policies in ShockSign control how long the platform keeps records; your own copy should outlast that. If you integrate through the API, fetch and archive the completed document and its audit data when the document.completed webhook fires.

Every plan includes it

We do not sell the audit trail as an upgrade. The free plan (1 document, 7-day trial), Starter ($12/month), Professional ($29/month) and Business ($99/month) all record the full trail, seal completed documents with a SHA-256 hash and RFC 3161 timestamp, and produce a certificate of completion. See the pricing page and the security page.