E-signature audit trail requirements: what must be logged

Nobody reads an audit trail on the day a contract is signed. It is read months or years later, usually by someone who was not there, when one party says they never agreed or the document they signed said something else. So the useful way to think about audit trail requirements is backwards: what will that reader need to be shown, and does the record answer it without anyone’s memory? This is general information, not legal advice.

What the law actually asks for

Signing laws seldom name events. They ask for outcomes, and the trail is how you prove them.

Australia’s Electronic Transactions Act 1999, for Commonwealth laws, sets out in section 10 that a signature requirement is met where a method identifies the person and indicates their intention, the method is as reliable as appropriate for the purpose or proven in fact to have done that job, and the other party consents to the method. Section 12 deals with keeping records. A retained electronic document must be kept by a method that reliably maintains its integrity, meaning it stays complete and unaltered. For a retained electronic communication, section 12(4) also asks for information identifying its origin, its destination, the time it was sent and the time it was received, readily accessible for later reference.

The United States ESIGN Act, in section 101(d), accepts an electronic record for retention if it accurately reflects the information and remains accessible, in a form that can be accurately reproduced, for the required period. The eIDAS Regulation, as retained in UK law, sets four requirements for an advanced electronic signature in article 26, the last of which is that it is linked to the signed data so that any later change is detectable.

Put together, a trail needs to evidence identity, intent, consent, timing, integrity of the document and integrity of the log itself. The table below maps each one to where it is asked for, what records it, and where the evidence runs out.

The events that carry the weight

What an audit trail is, and its full list of eighteen event types, is set out in what an audit trail is. The point here is which of them answer which question.

Identity rests on invited, auth_challenged and authenticated, plus the identity method printed per signer. On the employment contract signing example, the employee, Nadia Kouri, verified with an emailed six digit code while the employer’s signatory used the email link alone, and the certificate records each signer’s method separately.

Intent rests on the sequence: the signer viewed the document and then signed it. Nadia’s single drawing filled two initials spots and her signature, and her acceptance date was printed from the moment she submitted. That same moment appears in the certificate and in the chained event log, so the contract’s date is a recorded fact rather than something she typed.

Delivery rests on sent, invited, delivery_failed, opened and resent. The purchase order signing example shows why resent matters: the operations manager’s first invitation went missing, the sender resent it, the old link stopped working, and the certificate’s twelve event log includes the resend. Anyone reviewing the order later can see the second link was the one used.

Hosted signing gets its own event. On the liability waiver signing example, staff hand a tablet to a visitor at a front desk, and the trail records the in person start, with the host’s user id, before the signed event. The status page labels it Signed in person, hosted by the sender. One honest caveat: the certificate currently prints that event’s raw name rather than a friendly label.

Timestamps, IP addresses and consent

Every event carries a sequence number, a timestamp, the event type, the recipient, an IP address, a user agent and any details. The certificate prints times as YYYY-MM-DD HH:MM:SS UTC, which avoids arguments about time zones.

Two limits belong in any honest description. The IP address is taken from the header the network edge sets, or failing that the last forwarding hop, so it can be a shared or corporate address. And timestamps come from the signing service’s own clock: the code to attach an RFC 3161 token from an independent timestamp authority exists, but it is switched off in the deployed configuration, so no signed PDF carries one today.

Consent is recorded per signer as a timestamp and a version string. The version matters more than it looks, because it shows which consent wording a person accepted if that wording later changes.

A two party record shows how these pieces sit together. On the NDA signing example, the certificate carries two signer entries, each reading Email link + emailed one-time code, each with its own signing time, IP address, consent timestamp and version, and the hash of the document that signer was shown. Because the second company was only invited after the first had signed, the second entry’s document hash is of a copy already carrying the first company’s block, which is exactly the order the event log reports.

Hashes and the chain

A hash is a fixed length fingerprint of data. NIST’s Secure Hash Standard describes hash algorithms as producing message digests that are used to detect whether messages have changed since the digests were generated.

A signing record uses them twice. The first use protects the document: the certificate prints the hash of the PDF as it was sent, the hash of the working copy each signer saw, the hash of each signature image, and the completed file is certified so that any later edit invalidates its signature. The second use protects the log: each event’s hash covers its own contents plus the previous event’s hash, with keys sorted so a database reordering them cannot change the result, and the status page reports the chain as verified or names the event where it broke. How that works step by step is in what a hash chain is.

Rows in the event log cannot be updated. The database does allow deletion, because deleting a draft request removes its events, and only drafts can be deleted. NIST’s guide to computer security log management frames logging as a practice an organisation has to develop, implement and maintain, not a feature it switches on, and that applies here too: the chain can show tampering, but only your own filing keeps the record available for the years it may be needed.

Common mistakes

Treating the certificate hashes as file checksums. The two in its envelope section are the uploaded file and the stamped file before certification, so neither matches the checksum of the PDF you download. What a reader checks in the file itself is covered in how to check if a PDF is signed.

Assuming downloads are logged. They are not.

Relying on an IP address as identity. Use an access code or emailed code where identity matters.

Keeping the PDF and discarding the certificate. The PDF answers whether the file changed; the certificate answers who, when and how.

Assuming one country’s rules travel. The laws differ in what they require and exclude, as set out in electronic signature laws by country.

Build it

The audit trail page shows the log as it appears on the status page, event by event, with the chain check. Every request records eighteen event types, from created and sent through authenticated, viewed and signed to certified and completed, each with a sequence number, timestamp, IP address and user agent, hash chained to the event before. When the last signer finishes, the certified PDF is emailed to everyone and the certificate of completion is written as its own A4 PDF, with an option to append it to the signed document. The tutorial on sending a PDF for e-signature covers choosing identity checks and downloading both files.