What a court-admissible audit trail actually contains

"Court-admissible audit trail" appears on the marketing page of every e-signature product, ours included. It is a phrase that sounds authoritative and explains nothing. So here is the actual contents of the certificate we attach to every completed document, field by field, and why each one is there.

What the certificate is trying to prove

When an electronic signature is disputed, the argument is almost never "electronic signatures are not valid". That question is settled by ESIGN, UETA, and eIDAS. The argument is one of four specific claims:

1. 1That was not me — an identity attribution dispute
2. 2I never agreed to that version — a document integrity dispute
3. 3I did not know I was signing — an intent and disclosure dispute
4. 4That is not when it happened — a timing dispute

Every field in the certificate exists to answer one of those four. If a field does not help with any of them, we do not collect it.

Identity attribution

We record the email address the document was sent to, the email address that opened it, and the authentication method used. If access-code or SMS verification was enabled, we record that the challenge was issued and passed, though never the code itself.

We also record the IP address at each interaction, along with a coarse geolocation derived from it. IP is weak evidence on its own — it can be shared, proxied, or mobile — but it is useful in aggregate. A signature from the recipient’s usual city on their usual network is unremarkable. The same account signing from three countries in an hour is worth a question.

Document integrity

This is the part that does real work. When signing completes, we compute a SHA-256 hash of the final document bytes and record it in the certificate. The certificate itself is then signed with our private key.

Anyone holding the signed PDF can recompute the hash and compare. If a single byte has changed — one digit in a payment amount, one word in a termination clause — the hash will not match. There is no partial match and no way to construct a different document with the same hash.

We also hash the document at the moment it was sent, before any signing. That gives you a before-and-after pair, which proves that what the signer saw is what ended up in the final file.

Intent and disclosure

ESIGN requires that a signer consent to doing business electronically and that they were able to review the document. So the certificate records that the electronic-records consent notice was displayed and accepted, with a timestamp.

We log every page view event with duration. This sounds intrusive and is in fact the most commonly cited evidence in disputes. A claim of "I never saw clause 12" is considerably harder to sustain when the record shows the signer had page four open for ninety seconds.

Each individual field completion is logged separately, in order, with its own timestamp. The certificate reconstructs the session as a sequence rather than a single moment.

Timing

All timestamps are recorded in UTC from a synchronised time source, and rendered in the certificate in both UTC and the signer’s local timezone. Local time matters because "signed at 3am" reads very differently once you know the signer was in Singapore.

For documents where timing is legally significant, an RFC 3161 trusted timestamp from an independent authority can be attached. That converts "our server says this was 14:02" into an assertion backed by a third party with no interest in the outcome.

The full field list

• Envelope ID and document title
• SHA-256 hash at send and at completion
• Sender identity, organisation, and IP
• Each recipient: name, email, role, signing order position, authentication method
• Per-recipient events: sent, delivered, opened, viewed (per page, with duration), field completed, signed, declined
• IP address and coarse geolocation per event
• Browser and operating system per session
• Electronic-records consent acceptance and timestamp
• Signature image or typed representation, and the adoption method
• Any conditional logic evaluated, with inputs and outcome
• Certificate issuance timestamp and our cryptographic signature

What we deliberately do not collect

We do not fingerprint devices beyond browser and OS strings. We do not track signers across other sites. We do not record precise GPS location, even where a browser would offer it. We do not retain the contents of verification codes.

Every additional field is data that has to be secured, disclosed under privacy law, and eventually deleted. Collecting less is both better privacy practice and less risk for the sender.

How to actually use one in a dispute

A certificate sitting in a folder proves nothing by itself. If a signature is challenged, the sequence that works is roughly this.

1. 1Produce the signed document and the certificate together — neither is much use alone
2. 2Recompute the SHA-256 hash of the document and demonstrate it matches the certificate
3. 3Walk through the event timeline, particularly the view durations for the disputed section
4. 4Show the consent record establishing the signer agreed to transact electronically
5. 5Where identity is contested, produce the authentication method and any verification challenge passed

The hash comparison is the step people skip, and it is the strongest single item. It converts "we believe this is the document" into a demonstrable fact that does not depend on trusting us or the other party.

Retention and the long tail

Disputes about agreements often arise years after signing. An audit trail available for ninety days is of limited value on a seven-year lease.

Certificates are retained for the life of the document under your account retention policy, and because the certificate is embedded in the signed PDF itself, a copy you downloaded and stored independently remains verifiable even if you later leave the platform. That is deliberate — an audit trail you can only access by maintaining a subscription is a weaker guarantee than it appears.

The limits, stated plainly

An audit trail proves what happened at our system boundary. It proves a particular email account accessed a document from a particular network and completed specific actions at specific times. It cannot prove who was physically holding the device.

Nothing can, short of in-person identity verification. A handwritten signature has exactly the same limitation and considerably less supporting evidence. The honest claim is that an electronic audit trail makes attribution substantially easier to establish than wet ink does, not that it makes it certain.

Getting hold of it

The certificate is attached as a final page to every completed document and is separately downloadable as a standalone PDF. It is generated once, at completion, and never regenerated — so the copy you download in three years is byte-identical to the one available on day one.