Electronic signature audit trails: what to record and how to read them

What an audit trail is

In electronic signing, an audit trail is a chronological record of selected workflow events. It may cover creation, sending, consent, field completion, signature submission, reminders and overall completion. It is normally supporting evidence beside the executed document, not a magical certificate that settles every possible dispute.

First identify provenance. Some events are produced by the signing application; others may be callbacks from an email or SMS provider; some browser or network values may be reported by a client. Labels such as “opened” or “delivered” need definitions. Provider delivery can mean acceptance by downstream infrastructure, while an open signal may be generated by privacy software and does not prove careful reading.

Questions to ask of every event

• Source: Which application, server, provider or browser supplied it?
• Subject: Is it linked to a document, recipient, invitation, field or completed file?
• Time: Which clock and time zone produced the timestamp?
• Meaning: What exact condition creates the event, and can it occur more than once?
• Integrity: Can later changes be detected, and what bytes or record does any hash cover?
• Limits: What does the event not establish—for example, identity, authority or comprehension?

Reading Orbis Sign records carefully

Orbis Sign can expose selected workflow, consent, signing and provider-reported events. Coverage varies and should not be described as every interaction. Recorded browser or network information does not independently prove who used the device. Document states and reminders help teams manage work but are not legal conclusions.

At completion, the application records a SHA-256 value over completed PDF bytes when those bytes are available. A separately labelled fallback is a completion-event hash, not a PDF hash. The distinction matters: never state that a value verifies the final document unless it was actually calculated over that document’s bytes and the verification process is defined.

Retention and access

Decide who owns the completed PDF and supporting record, where they are filed, who may retrieve them and how legal holds work. Retention should reflect purpose, limitation periods, regulatory duties and data minimisation. A platform’s availability is not a customer retention policy, and indefinite storage should not be assumed.

Audit records contain personal data and potentially sensitive transaction context. Apply role-based access, review exports and deletion, and evaluate supplier and hosting arrangements. The ICO provides official UK GDPR security guidance; it does not prescribe one universal electronic-signature record.

A review checklist

1. Download the completed file and its separate supporting record.
2. Check document title, parties, recipients and completion status.
3. Distinguish application events from provider-reported signals.
4. Verify what any checksum covers before relying on it.
5. Record exceptions, corrections or manual verification undertaken.
6. File evidence under an approved retention and access policy.

For the wider workflow context, see how electronic signatures work and the Orbis Sign security overview.