Audit trail

What does Audit trail mean?

An audit trail is the time-stamped, chronological log of everything that happened to a document during the signing process: who it was sent to, when each person opened it, when they signed, and from where. In e-signature tools it is often called an electronic signature audit trail or signing history, and it is the main evidence you rely on if anyone later asks whether a signature is genuine.

In practice, the platform writes an entry every time something meaningful happens. A typical trail records the sender, each recipient's email address, when the invitation went out, when the link was opened, when the signer agreed to use electronic records, when they applied their signature, and when the finished file was sealed. Each event usually carries a timestamp, an IP address and some device or browser information.

Picture a landlord renting out a flat. The tenant signs the lease on a phone at 11 p.m. and, three months later, claims they never agreed to the pet clause. The landlord pulls the audit trail and shows that the full lease was opened from the tenant's email link, viewed for several minutes, and signed from a particular IP address. That does not win every dispute on its own, but it turns a vague disagreement into a factual record.

A common misconception is that the drawn signature image is what makes an e-signature enforceable. Under the ESIGN Act and UETA in the US, what matters is intent to sign, consent to do business electronically, and the ability to attribute the signature to a person. The squiggle proves very little; the surrounding record proves much more. Another myth is that an audit trail is tamper-proof by default. It is only as trustworthy as the way it is stored and linked to the final file.

That link is usually made through a document hash. The audit trail references the fingerprint of the finished PDF, and the certificate of completion presents the trail in a readable summary that you can file alongside the contract. Together they give you three things a dispute needs: a sequence of events, a readable summary, and proof that the file in front of you is the one that was actually signed.

Our take: the audit trail matters far more than signature fonts, colours or animated signing experiences. If a tool cannot show you a clear, exportable history of who did what and when, it is not doing the important part of its job.

eSignSimple records each step with timestamps, IP address and device details, attaches the history to a certificate of completion, and stores a SHA-256 hash of the final file that anyone can check on our public /verify page. Signers do not need an account to sign, and the trail is created for every document you send. For a step-by-step look at reading one, see our guide on what an audit trail is.

What is an example of audit trail?

A landlord sends a lease to two co-tenants. Months later one tenant claims she never agreed to the pet clause. The landlord downloads the audit trail from eSignSimple: it shows when the lease was sent to her email, when she opened it, the IP address and device she used, and the exact time she signed, all tied to the SHA-256 hash of the final PDF.

How do you read an audit trail line by line?

Take the history on an eSignSimple certificate of completion as an example. Each line has a UTC timestamp, an event and, where relevant, the signer's email and IP address. A typical sequence runs: document uploaded; document finalized for signing; signing request emailed to the first signer; document opened; document signed; then the same for the next signer; then document completed. If reminders went out, you will see reminder emailed lines between them, and if anything stopped the process, a declined or voided by sender entry with the time.

Read it the way a sceptical lawyer would. Do the times make sense, for example was the document opened before it was signed and was there enough time to read it? Does the IP address on the open match the one on the signature, or did the signer open it on a phone and sign later on a laptop? Neither pattern is suspicious on its own, but knowing your trail before anyone challenges it lets you explain it calmly. Our guide on what an audit trail is shows a fuller example.

What can an audit trail not prove?

An audit trail proves that events happened through a particular email link, from a particular network and device, at particular times. It does not prove who was holding the device. If a signer's partner or assistant had access to their inbox, the trail will look exactly the same. IP addresses are also imprecise: mobile networks, VPNs and corporate gateways can place someone in a different city, and one office can share a single address across dozens of people. Device descriptions come from the browser and are not a hardware fingerprint.

That is why the trail is strongest when combined with other evidence: correspondence before and after signing, payment that followed the contract, or a quick call confirming receipt. When identity really matters, add a signer authentication step suited to the risk rather than expecting the log to do a job it was never designed for.

Audit trail red flags to fix before you send

Most weak audit trails are created at the sending stage. Common examples: sending to a shared address such as info@ or accounts@, so the trail cannot point to one person; signing on someone's behalf from your own computer because they were in a hurry; sending to a personal email address you guessed rather than one they gave you; or entering a signer name that does not match the party in the contract.

Each has an easy fix: ask for the signer's own address, let them sign themselves even if it takes a day longer, and copy names from the contract into the signer list. If something went wrong after sending, such as the wrong email, void the document and send a corrected one rather than forwarding the link. A forwarded link produces a trail showing activity from someone other than the named recipient, which is exactly what you do not want to explain later.

Which terms are related?

• Electronic signature: An electronic signature is any electronic sound, symbol or process attached to a record and adopted by a person with the intent to sign it.
• Certificate of completion: A certificate of completion is a summary document issued when all parties have signed, listing signers, timestamps and document integrity data.
• Document hash: A document hash is a fixed-length fingerprint computed from a file's contents; any change to the file produces a different hash.
• Tamper-evident seal: A tamper-evident seal is a cryptographic seal on a PDF that shows whether the document has been changed in any way after it was signed.
• Signer authentication: Signer authentication is how an e-signature platform confirms that the person signing a document is the person it was sent to.