When a signed contract gets challenged, the first question is rarely about the signature image. It is about the audit trail behind it: who did what, when, and from where. A weak audit trail is a line or two of metadata. A real one is a detailed, chronological record that can stand on its own in a dispute.
What counts as an audit trail for an electronic signature
An audit trail is a timestamped log of every meaningful event in the life of a document: creation, sending, viewing, each field being filled, each signature being applied, and final completion. It exists separately from the PDF itself, though a summary of it is usually attached to or referenced by the final file.
The goal is simple: if someone later says
"I never saw that document" or "someone else signed for me," the audit trail should answer the question with specific, verifiable facts rather than assumptions.
The events a real audit trail should record
- Document creation: who built the envelope, from what template, and when
- Sending: the exact timestamp each recipient was notified, and by what channel (email or SMS)
- Access: when each recipient opened the document, and from what IP address
- Field-level actions: each signature, initial, checkbox and date field, tied to a specific recipient and timestamp
- Consent: confirmation that the signer agreed to sign electronically rather than on paper
- Completion: the moment all parties finished, with the final document hash recorded
Notice that this is a log of actions, not a log of intentions. A good audit trail does not try to prove what someone was thinking. It proves what happened, in what order, and leaves the legal interpretation to the people reading it.
Why timestamps and IP addresses matter more than people think
Timestamps establish sequence. If a dispute hinges on whether a document was signed before or after a deadline, a precise timestamp down to the second matters far more than a signature image. IP addresses add a second layer: they show the general location and device context of each action, which helps rule out scenarios like someone signing a document they never actually received.
Neither of these is foolproof on its own. Together with the full sequence of events, though, they build a record that is hard to argue with.
Where the hash comes in
Once a document is fully signed, VG·Sign generates a SHA-256 hash of the final PDF. That hash is a fixed-length fingerprint of the exact file content. If even one character inside the PDF changes afterward, the hash changes completely.
This means anyone can later verify that the PDF they are holding is the exact file that was signed, not a modified copy. The hash is recorded in the audit log, which is append-only: entries can be added as events happen, but nothing already logged can be edited or deleted. That combination, a cryptographic fingerprint plus a tamper-evident log, is what gives the audit trail its weight. It is worth being precise here: this is a hash plus an append-only log, not a blockchain-style hash chain linking every record to the next.
For a plain-language look at what is included at each plan level, our See how this fits into the full signing workflow page breaks down the features without the jargon.
Where the data actually sits
For Canadian businesses, a common question is where all of this is stored. With VG·Sign, envelope content, meaning the documents, fields and audit log, is stored and processed in the Montreal region: the database and file storage run on Supabase infrastructure in AWS ca-central-1, and the application itself runs on Vercel's yul1 region.
That said, it would be inaccurate to claim the data never leaves Canada. Email and SMS delivery, along with payment processing, run through US-based providers. The completion email that notifies everyone a document is fully signed also attaches the signed PDF, so that specific message is a cross-border hop. If your organization has strict data residency requirements, it is worth understanding this distinction rather than assuming a blanket guarantee that does not exist.
How this compares to a basic
"signed" stamp
Some tools only show a static "signed on [date]" line with no further detail. That is not an audit trail, it is a label. It cannot show you the sequence of views, the IP addresses involved, or whether the final document matches what was actually agreed to.
If you are comparing providers on this specific point, it is worth checking what level of detail each one actually exposes, not just whether they use the phrase "audit trail" in their marketing.
If you're evaluating alternatives, our compare the full feature set page walks through how VG·Sign stacks up on audit trails, pricing and Canadian data handling.
What to check before you trust a provider's audit trail
- Ask whether the log is append-only or editable after the fact
- Ask whether a document hash is generated and where it is stored
- Ask which specific events are logged (viewing, not just signing)
- Ask where the underlying infrastructure is physically located
- Ask which parts of the process touch US-based services, if any
A signature proves someone clicked. An audit trail proves what they saw, when, and from where.
Canadian legislation like the Electronic Signature Act context under ESA 2000, PIPEDA and UECA generally supports electronic signatures as valid, provided there is adequate evidence of consent and intent. None of this is legal advice, and specific contracts or regulated industries may have their own requirements, but a detailed audit trail is generally what makes an electronic signature defensible in the first place.
Frequently asked questions
- Is an audit trail the same thing as the signature itself?
- No. The signature is the mark or click a person makes on the document. The audit trail is the separate record of every event around that signature: when the document was sent, viewed, filled in and completed, plus the hash of the final file.
- Can an audit trail be edited after a document is signed?
- In a properly built system, no. VG·Sign uses an append-only log, meaning new events can be added as they happen, but existing entries cannot be changed or removed after the fact.
- Does VG·Sign store audit trail data outside Canada?
- The audit log and document storage run in the Montreal region (Supabase on AWS ca-central-1, app servers on Vercel yul1). Email and SMS notifications, including the completion email with the signed PDF attached, go through US-based providers, so that step is cross-border.
- What is the SHA-256 hash used for in the audit trail?
- It is a fingerprint of the final signed PDF. If the file is altered afterward in any way, the hash no longer matches, which lets anyone verify the document they have is the exact one that was signed.
This article is for general information only and is not legal advice. For advice on your specific situation, consult a qualified professional.