E-signature audit trail: what it records and what it proves

What an audit trail is

A handwritten signature carries some evidence in itself, because handwriting can be compared. A signature drawn on a screen carries almost none: anyone can copy an image. What gives an electronic signature weight is the record around it: where the link was sent, when it was opened, when the signer agreed to sign electronically, which file they saw and when they signed.

That record is the audit trail, also called an event log. It is only useful if it is detailed enough to reconstruct what happened and hard to change afterwards. The sections below show how SignClearly's audit trail handles both.

What SignClearly records

SignClearly logs these events for each document:

• document created and file uploaded;
• sent, or self-signing started when you sign it yourself;
• opened;
• access code entered;
• consent given;
• signed and completed;
• signed copy downloaded;
• declined, link revoked or link expired.

When the sender requires an ID check, the log records the check as well.

When the signer signs with a key created in their browser, the log also records when SignClearly's certificate authority issued the signing certificate.

Each event stores the time in UTC, who acted and the IP address. The certificate page adds the SHA-256 of the original file, which the server computes when the PDF is uploaded, before anything else happens.

A SHA-256 hash is a 64-character fingerprint of a file. Change one byte and the fingerprint changes completely. Keep the PDF you uploaded: anyone can compute its hash and compare it with the one on the certificate page. On a Mac, in Terminal:

On Windows, in Command Prompt:

The hash chain, explained simply

Each event stores the SHA-256 of the event before it. Picture a stack of numbered pages where every page carries the fingerprint of the page before it. If someone edits page 3, its fingerprint changes, page 4 no longer matches, and the break shows. To hide the edit, they would have to rewrite every page after it.

Someone with full access to the database could try exactly that, so SignClearly adds a second protection. Each event also gets an HMAC: a fingerprint computed with a secret key kept outside the database. Without that key, rewritten events cannot get valid HMACs.

A daily timestamp from an outside authority

Once a day, the chain gets a timestamp from an independent RFC 3161 time-stamping authority. SignClearly sends a fingerprint of the chain as it stands, and the authority returns a signed token with the time. That token pins the chain to that day. If an earlier event were changed later, the chain would no longer match the timestamped fingerprint, and SignClearly could not obtain a new token with an earlier date.

What an audit trail can and cannot prove

What it can show

• The signing link went to a specific email address, and whoever used it had access to that mailbox at the time.
• If an access code was set, the person who signed also knew the code.
• The signer agreed to sign electronically, reviewed the final PDF and confirmed the intent to sign, each at a recorded UTC time from a recorded IP address.
• Which file was signed: the SHA-256 of the original, and a final PDF whose content does not change after signing.

What it cannot show on its own

• Who the person was. Without an ID check, SignClearly confirms control of the email link, not identity. Someone else with access to the recipient's email could have signed.
• Where the person was. An IP address points to a network, and a VPN or a mobile network can place it far from the person.
• That the signer read every page. The log shows the final PDF was put in front of them, not how closely they read it.
• That the agreement is enforceable. That depends on the law and the type of document.

An ID check changes the first point. The recipient shows an ID document and takes a selfie with Didit, a third-party identity service, and the name on the ID must match the name the sender entered. The log then shows that the signer passed that check, which is stronger evidence of identity than access to a mailbox. SignClearly keeps the result and the name on the ID, not images of the ID.

For how this maps onto the legal levels of signature, see SES vs AES vs QES.

How to read the certificate page

The certificate page is the last page of the signed PDF. Read it in this order:

1. 1Check the sender and the signer. The signer should be the person you meant to send the document to.
2. 2Compare the SHA-256 of the original file with the hash of the PDF you uploaded. If they match, the signed document started from that exact file.
3. 3Read the event log from top to bottom. Times are in UTC, so convert them to your time zone before you compare them with emails or calls.
4. 4Check the order. The document should be sent before it is opened, and consent should come before the final review.
5. 5Note where the log stops. It runs up to the final review, because the signer sees this exact file before signing and its content does not change afterwards. Later events, such as signed and completed, are in the document's event log in the sender's account.