Electronic signature audit trail: what each field proves and what the law asks

Someone says they never signed. The squiggle on page four settles nothing, since anyone can paste a picture of a name onto a PDF. What settles it is the electronic signature audit trail: the time-ordered record, kept by the signing service, of who received the document, how they opened it, how they proved who they were, when they signed and what the file looked like at that moment.

Services call it a certificate of completion, an audit report or an evidence file. The name matters less than what's in it.

So what is an audit trail in general? NIST's glossary defines it as a chronological record that reconstructs the sequence of activities behind an event. That's the audit trail meaning in one line. For a signed contract the record is mostly metadata: names, email addresses, timestamps, IP addresses, document hashes. None of it is the contract. All of it is what you'll lean on if the contract is disputed.

Below: what an audit trail for electronic signature records, what each field proves, what the law asks, and what one California court wanted to see and never got. To simply send something for signature, start with the signing workflow.

Most signing services log the same events. They differ in how much they record about identity, and in whether anything outside their own database can confirm the record later.

The table lists the usual fields of an electronic signature audit trail in the order they happen, with the honest limit of each. Read the last column twice. It's where disputes start.

Here's a short audit trail example for a two-party services agreement, written the way most reports print it. Names, addresses and hashes are invented.

1. 1.
   2026-10-02 09:14:05 UTC. Document "Services agreement v3" created by Priya Nair (priya@agency.example). Hash 9b1e…c07.
2. 2.
   09:15:40. Sent for signature to Tom Weller (tom@client.example).
3. 3.
   11:02:19. Tom Weller opened the link. IP 198.51.100.23, Safari on iOS.
4. 4.
   11:03:02. Tom Weller passed SMS verification to a number ending 4471.
5. 5.
   11:04:47. Tom Weller signed. IP 198.51.100.23.
6. 6.
   11:20:13. Priya Nair signed. IP 203.0.113.9.
7. 7.
   11:20:14. Completed. Final hash a41d…e52.

Read it the way the other side's lawyer would. Lines 3 to 5 tie Tom's signature to an inbox and a phone, from one network address, inside three minutes. That's a coherent story. Lines 1 and 7 give two hashes: the file that went out and the file that came back signed. If the PDF you hand a court hashes to a41d…e52, nobody changed it after completion.

What's missing? Nothing records which version Tom saw when he opened the link. A good trail either logs every edit made after sending or locks the draft once it goes out. Ask your vendor which, because "we don't log that" is a bad thing to learn in a deposition.

In the US, the question about a disputed electronic signature is narrow: was it the act of that person? Section 9 of the Uniform Electronic Transactions Act, which nearly every state has adopted, says the act "may be shown in any manner," including by showing how well a security procedure worked. The electronic signature audit trail is how you show it, though not on its own: it gives a witness (someone at your company, sometimes at the vendor) the facts to explain why the signature could only have come from that person.

The soft spots: identity and time

That's why the authentication line carries more weight than any other field. An email link proves the signer could open that inbox. An SMS code adds a phone. An ID check against a passport adds a face and a document. Each layer shrinks the group of people who could have signed, and none of them shrinks it to one. A shared mailbox, an assistant signing for a manager, a phone left lying on a desk: the trail records the credentials, and a court decides what they say about the person.

Time is the other soft spot. Most audit trails take their timestamps from the vendor's own servers. That's usually fine, since nobody has a reason to doubt them, but it's still the vendor's word. A qualified timestamp from a trust service provider, or a hash written to a public blockchain, puts a second party behind the time.

The EU frames the same idea differently. Under Article 25(1) of eIDAS, a court can't refuse an electronic signature as evidence just because it's electronic or isn't qualified, so for simple and advanced signatures the audit trail is how you argue its weight. A qualified signature gets the legal effect of a handwritten one under Article 25(2), and the trail matters less.

Honestly, most disputes never get this far. A coherent trail usually ends the argument before anyone files anything, because the other side's lawyer reads it too.

No US statute lists the fields an audit trail must contain, and eIDAS doesn't either. The law fixes the outcome instead: the record is accurate and retrievable, the signature is attributable to a person, and at the advanced level any change to the signed data is detectable. Those are the real audit trail requirements, and an electronic signature audit trail is how you meet them.

The US rules sit in the ESIGN Act, 15 U.S.C. § 7001, state UETA enactments and the Federal Rules of Evidence; the EU rules in the consolidated eIDAS Regulation. The table maps each rule to the field that answers it. For UK law and GDPR too, see what ESIGN, eIDAS and Part 11 ask of a signing process.

The same audit trail bar applies inside regulated production facilities, where maintenance and asset records fall under 21 CFR Part 11, GMP, and ISO regimes. MaintainX is a mobile-first maintenance and asset management platform that captures who performed each work order, when, against which asset and procedure version, with a timestamped record technicians create at the point of work rather than reconstruct after the fact.

That matters because audit preparation is usually where the gap between "we have logs" and "we have a defensible trail" shows up as real hours. PharmaNZ saves 3 to 4 hours per GMP audit using MaintainX. Ahlstrom standardized 170+ procedures across 38 plants in 13 countries within one month of implementation, giving auditors a consistent record shape to work from across every site. Enor Chile cut audit preparation time by 33% and improved field data quality and completeness by 30%.

For regulated operations still running maintenance on paper or across disconnected tools, the practical consequence is that the audit trail exists as a byproduct of daily work, not as a separate reconstruction project when an inspector arrives.

In Fabian v. Renovate America (California Court of Appeal, November 2019), a homeowner said she never signed a financing contract that carried her electronic signature. The company wanted arbitration under that contract, so it had to prove she'd signed. It couldn't. The contract had gone through DocuSign, but the court found that Renovate "offered no evidence about the process used to verify Fabian's electronic signature via DocuSign." The word DocuSign didn't even appear in its moving papers.

The opinion then lists what nobody had answered, and the list reads like the contents page of an audit trail. It also leans on an earlier case, Ruiz v. Moss Bros. Auto Group, where a business manager asserted that an employee had signed but never explained how the signature could only have come from someone using her unique login and password.

Notice what Fabian isn't: a story about a weak DocuSign audit trail. The record was never put in front of the court. An electronic signature audit trail helps only if you keep it, produce it, and have someone explain the process behind it. In federal court, Rule 902(13) lets a qualified person's written certification do that explaining.

An electronic signature audit trail the vendor's staff could quietly rewrite is still evidence, just evidence that depends on trusting them. Three techniques make a trail tamper-evident and take that trust out of the question:

• Hashing the document. A hash is a short fingerprint of a file; change one character and it changes. If the hash in the trail matches the file you hold, it's the file that was signed. The committee note to Federal Rule of Evidence 902(14) treats hash values as the usual way to show a copy matches its original.
• Chaining the log: each entry carries a hash of the one before it, so editing an old line breaks every line after it.
• Writing a hash somewhere the vendor doesn't control, such as a public blockchain, so even the vendor can't backdate it.

Chaindoc uses the last two in a specific, limited way. The app keeps a hash-chained event log of each signing. Two moments go on chain, on the SKALE network: when you publish a document for signing, its version hash is recorded, and when signing completes, each signer's proof is recorded. Identities, IP addresses and individual views stay in the app's log, not on the chain. More on why Chaindoc records on SKALE.

For the signed PDF itself, the PDF signature verification service reports whether the file's integrity holds and which certificate signed it. It asks for your email and a one-time code before the first check.

Every mainstream service produces an electronic signature audit trail; they differ in what it records and how easily you get it out.

Adobe's own explainer lists four things an electronic signature audit trail should include: the date and time of the signature, confirmation that the signer was verified, a record of changes made during or after signing, and each signer's IP address. That's a fair minimum to check in an Adobe Sign audit trail or anyone else's. As for a DocuSign audit trail, Fabian is the reminder that it works only once someone produces it and explains the process.

Chaindoc's looks like this. When the last party signs, you can download an audit trail PDF listing each signer, their timestamps and IP addresses, the document hash and the blockchain transaction ID. If you turned on the optional ID check (a paid-plan feature), its result goes into the trail too. Chaindoc's qualified signatures are PAdES-BES, which carry no qualified timestamp, so there the time evidence is the trail plus the block holding the completion record. Chaindoc isn't a trust service provider, either: the qualified certificate comes from a provider that keeps its own records. More on how qualified signatures work.

Five questions for any vendor

Choosing an electronic signature with audit trail features for legal compliance? Ask these:

1. 1.
   Which events do you record, and do you log edits made after a document is sent?
2. 2.
   Which authentication options can I require for a single document?
3. 3.
   Where do your timestamps come from?
4. 4.
   Can I export the trail with the signed file and keep it without an account?
5. 5.
   Can a third party check the record without your help?

Keep the electronic signature audit trail as long as you keep the contract, and store the two together. ESIGN's retention rule wants the record accurate and accessible for as long as another law requires the contract to be kept, so a trail you lose when the vendor account closes doesn't help. Part 11 ties the trail's life to the record's. The period for the contract itself comes from tax, employment or limitation rules; our guide to document retention periods lists the common US ones. Export both at completion. Don't rely on a login you might lose.

Pick a contract signed six months ago and rebuild its story from the record alone. It's the quickest way to find out whether your electronic signature audit trail would hold up.

1. 1.
   Find it. Can you download the trail today without asking support?
2. 2.
   Match the hash. Does the hash in the trail match the file in your records? No hash printed at all is a finding too.
3. 3.
   Read the authentication lines. Email link only, or something stronger?
4. 4.
   Look for gaps. Is there a view event before every signature, and are edits after sending logged?
5. 5.
   Check the clock. Do the times run in order, in one stated time zone?

If any answer is no, fix it for the next contract: change the default authentication, export the trail at completion, and file it with the signed PDF. On Chaindoc, how signing works in Chaindoc shows where the trail lives.