An audit trail and a verification record answer two different questions. The audit trail tells the issuer what happened to a document and when. The verification record lets a recipient confirm that nothing happened to it since — that the file in their hands matches the one the issuer stands behind.
This guide breaks down the exact fields a credible audit trail should capture, what a recipient-facing verification record must show, and how the two fit together so a document stays provable years after it is issued.
What is a document audit trail?
A document audit trail is a chronological, append-only log of every meaningful event in a document's lifecycle, from creation to signing, issuance, access, and verification. Each entry records who did what, when, and from where, and binds that event to the document through a cryptographic hash so the log cannot be quietly rewritten. The purpose is non-repudiation: no party can later deny an action the trail recorded. Regulators expect this. HIPAA's Security Rule requires audit controls that preserve integrity, authentication, and non-repudiation for health documents, and the US ESIGN Act and UETA make e-signatures enforceable only when intent, consent, association with the record, and retention are all demonstrable. A trail that is editable, undated, or detached from the document content fails that test. For the bigger picture, see our pillar guide on how to verify document authenticity.
What fields should a good audit trail capture?
A credible audit trail captures the actor, the action, a precise UTC timestamp, the source context, and a content hash for each event — not just a list of names. Vague logs ("Document signed") are weak evidence; specific, hashed entries are strong evidence. The table below lists the fields a defensible trail should record for every event.
| Field | What it records | Why it matters |
|---|
| Event type | Created, signed, issued, viewed, verified, revoked | Reconstructs the full lifecycle |
|---|
| Actor identity | Name, email, role, or system ID | Establishes who acted (non-repudiation) |
|---|
| Timestamp (UTC) | Exact date/time, ideally to the second | Orders events and proves sequence |
|---|
| Source context | IP address, device, or user agent | Corroborates the actor and location |
|---|
| Document hash | Cryptographic fingerprint of the file | Binds the event to exact content |
|---|
| Outcome/status | Success, failure, or pending | Flags tampering or failed checks |
|---|
What should the recipient-facing verification record show?
The verification record is the public, recipient-facing view of authenticity, and it should show the issuer, the document's status, its cryptographic hash, and enough history to confirm the file is genuine without revealing private content. Unlike the internal audit trail, it lives on the issuer's own domain — with VerifyDoc.ai this is a hosted proof page reached by scanning a QR code or visiting a link. A recipient should see the issuing organisation, an authentic/altered status, the issuance date, and a hash they can compare. Critically, this requires no login and no app, which is what makes it usable by a landlord, an employer, or a bank clerk checking a document at speed. See our step-by-step recipient's guide to verifying a QR-coded document for the scan-side experience.
Why does a tamper-evident record matter in 2026?
It matters because forging a convincing document is now cheap and fast, so an unverifiable PDF is no longer trustworthy on sight. Digital document forgeries rose 244% year over year in 2024 and, for the first time, overtook physical counterfeits to make up 57% of all document fraud (Entrust 2025 Identity Fraud Report). A flat PDF with a signature image proves nothing about whether the content was altered after signing. A tamper-evident record solves this by storing the authentic document's hash on the issuer's infrastructure: if a recipient holds an altered copy, the hash will not match and the verification record exposes the change at the moment of the check rather than weeks later in a dispute.
How do audit trails and verification records work together?
They are two views of the same source of truth: the audit trail is the issuer's private, detailed history, and the verification record is the recipient's filtered, public proof. The audit trail feeds the verification record — when a document is issued, its hash and key events become the basis for what a recipient can later confirm. With VerifyDoc.ai, the same issuance event that writes an audit entry also publishes a hosted proof page and a certificate of authenticity, so the internal log and the external check never drift apart. This pairing is what keeps a document provable over time; for issuers formalising it, our guide on how to issue a certificate of authenticity covers the recipient-facing artefact in detail.
