If your e-signature integration cannot reconstruct who signed what, when, and why they intended to, the signature is just a drawing on a screen. Courts and regulators do not care about your product's UX polish; they care about evidence. An e-signature audit trail is that evidence: a structured, tamper-evident log of every event in a signing ceremony, stored in a way that can be independently verified months or years later.
This guide gives product and engineering teams a canonical event taxonomy, a minimum evidence checklist, and a copy/paste JSON data model for building defensible electronic signature audit trails that satisfy ESIGN (US), UETA (US state-level), and eIDAS (EU/UK). For implementation context, see Anvil's E-Signature API docs. For legal background and jurisdiction-specific edge cases, read through this checklist.
1. The legal requirements the audit trail must support (in plain English)
Three regulatory frameworks govern most commercial e-signatures. Each translates "legally binding" into a slightly different set of evidence requirements, but they converge on five properties: intent, consent, attribution, integrity, and retention.
ESIGN (US): what must be provable
The ESIGN Act (15 U.S.C. § 7001) establishes that a signature or contract cannot be denied legal effect solely because it is electronic. The practical burden falls on proving that the signer consented to transact electronically and that the requisite disclosures were provided.
Section 7001(c)(1)(B) is the one that catches teams off guard. Before a consumer consents, you must present a clear statement covering: the right to receive paper records, the right to withdraw consent, whether consent applies to a single transaction or a category of records, procedures for withdrawal, and the hardware/software requirements for access and retention. Your audit trail must record that this disclosure was presented, which version was shown, and that the consumer affirmatively accepted it.
UETA (adopted in most US states) mirrors ESIGN's core validity rule but is state law. For audit trail purposes, the evidence requirements are functionally identical: capture intent, consent, attribution, and integrity.
eIDAS (EU/UK): what changes for AES and QES
eIDAS Article 26 defines an advanced electronic signature (AES) through four requirements: (1) uniquely linked to the signatory, (2) capable of identifying the signatory, (3) created using signature creation data under the signatory's sole control with high confidence, and (4) linked to the signed data so that any subsequent change is detectable.
A qualified electronic signature (QES) adds a qualified certificate issued by a trust service provider and creation via a qualified signature creation device. For your eIDAS audit trail, the jump from AES to QES means logging additional cryptographic artifacts: certificate chain references, qualified timestamp tokens, and long-term validation data.
UK execution edge cases (witnessing, deeds) {#uk-witnessing}
English law accepts electronic signatures for most documents, but deeds require witnessing. The UK Law Commission's project on electronic execution of documents confirmed the legal conclusions and notes that the Government responded to the report in March 2020. Witnessing is a workflow requirement, not just a signature type.
2. Canonical event taxonomy
Core envelope events
| Event type | Description |
|---|---|
envelope.created | Signing request initialized with document(s) and signer list |
envelope.sent | Invitation delivered to signer's channel (email, SMS, API) |
envelope.delivered | Delivery confirmation received (e.g., email open, webhook ACK) |
envelope.viewed | Signer opened the signing URL |
envelope.completed | All required signatures collected; envelope sealed |
envelope.voided | Sender or system canceled the envelope before completion |
envelope.expired | Signing deadline passed without completion |
Consent events (ESIGN-sensitive)
| Event type | Description |
|---|---|
consent.presented | Disclosure text shown to signer, version recorded |
consent.accepted | Signer affirmatively agreed to electronic delivery |
consent.withdrawn | Signer revoked prior consent |
consent.disclosure_version | Snapshot of disclosure text hash and version ID |
These events directly address § 7001(c)(1) requirements.
Signer identity and authentication events
| Event type | Description |
|---|---|
signer.identified | Signer identity resolved (email match, SSO, identity proofing) |
auth.challenge_issued | Authentication challenge sent (OTP, knowledge-based, etc.) |
auth.passed | Challenge verified successfully |
auth.failed | Challenge failed; log attempt count |
session.bound | Authenticated session tied to signer identity |
Signing and integrity events
| Event type | Description |
|---|---|
document.rendered | Document presented to signer in final form |
signature.applied | Signer executed signature action (click, draw, type) |
hash.computed | Document hash at signing calculated and stored |
artifact.sealed | Final signed artifact assembled with all signatures and hashes |
Optional: higher assurance (AES/QES)
| Event type | Description |
|---|---|
certificate.issued | Signing certificate issued or selected for this session |
timestamp.qualified | RFC 3161 timestamp token obtained from TSA |
ltv.artifact_stored | Long-term validation data (OCSP responses, CRLs) archived |
Optional: witnessing workflows (UK deeds)
| Event type | Description |
|---|---|
witness.present_attested | Witness confirmed presence during signing |
witness.identity_captured | Witness identity recorded (name, ID, method) |
witness.signature_applied | Witness executed attestation signature |
3. Minimum checklist: "court-ready" evidence fields
For every signature packet, these fields represent the smallest defensible evidence set.
Intent
Capture the explicit user action (button click, gesture) and the UI context visible at the moment of signing. A bare API call with no user interaction evidence is weak attribution in a dispute. Store the action type, the text of the call-to-action element, and the page/screen state.
Consent and disclosures (ESIGN)
Store the disclosure version identifier, a hash of the disclosure text, the channel through which it was presented, the timestamp of presentation, and the affirmative consent action with its own timestamp and input method. Also capture the hardware/software requirements statement shown to the signer, per § 7001(c)(1)(B).
Attribution (who signed)
Record a stable signer identifier (user ID, email, phone) and the method by which the identifier was bound to the session. If identity proofing occurred (government ID check, knowledge-based verification), log the proofing level and provider.
Authentication (sole control proxy)
Capture the authentication method, its strength or assurance level, the verification timestamp, and the factors used. For eIDAS AES, sole control evidence is a core requirement per Article 26(c).
Integrity (tamper evidence)
Store the pre-sign document hash, the post-sign document hash, the hash algorithm (SHA-256 minimum), and confirmation that the signature cryptographically covers the signed data.
Time evidence
Record an authoritative timestamp for every event. For higher assurance, attach an RFC 3161 timestamp token to prove that a given hash existed before a specific time.
Retention and reproducibility
Capture the storage location (bucket, region), export hash, and retrieval metadata.
4. JSON data model
This schema is designed to be copied into product code.
If the signing flow is implemented via an embedded provider, the same structure can be populated from provider webhooks and stored alongside the final signed PDF. For Anvil-specific implementation details, see /docs/api/e-signatures/.
Top-level objects
{
"signature_packet": {
"packet_id": "sp_abc123",
"version": "1.0.0",
"created_at": "2025-01-15T10:00:00Z",
"status": "completed",
"document": { },
"signer": { },
"consent": { },
"authentication": { },
"events": [ ],
"signature_artifact": { },
"timestamp_token": null,
"audit_report": { }
}
}signer object
{
"signer_id": "usr_xyz789",
"email": "signer@example.com",
"phone": "+15551234567",
"name": "Jane Doe",
"role": "signer",
"identity_proofing": {
"method": "government_id",
"provider": "id_verify_co",
"level": "IAL2",
"verified_at": "2025-01-15T09:55:00Z"
}
}consent object (ESIGN)
{
"disclosure_version": "esign_disclosure_v3.2",
"disclosure_text_hash": "sha256:a1b2c3d4...",
"presented_at": "2025-01-15T10:01:00Z",
"presented_via": "signing_page",
"hardware_software_requirements": "Modern browser with JavaScript enabled",
"paper_option_presented": true,
"consent_action": {
"type": "checkbox_checked",
"performed_at": "2025-01-15T10:01:30Z",
"ip": "203.0.113.42",
"user_agent": "Mozilla/5.0..."
}
}authentication object
{
"method": "email_otp",
"factors": ["possession"],
"aal": "AAL1",
"session_id": "sess_abc",
"challenge_issued_at": "2025-01-15T10:00:15Z",
"verified_at": "2025-01-15T10:00:45Z",
"attempts": 1
}document object
{
"document_id": "doc_def456",
"filename": "service_agreement_v2.pdf",
"version": "2",
"hash_before_sign": "sha256:e5f6a7b8...",
"hash_after_sign": "sha256:c9d0e1f2...",
"hash_algorithm": "SHA-256",
"page_count": 12,
"rendering_context": {
"viewer": "anvil_embedded_v4",
"rendered_at": "2025-01-15T10:02:00Z"
}
}event object
{
"event_id": "evt_001",
"event_type": "signature.applied",
"timestamp": "2025-01-15T10:03:00Z",
"actor": "usr_xyz789",
"actor_type": "signer",
"ip": "203.0.113.42",
"user_agent": "Mozilla/5.0...",
"correlation_id": "sp_abc123",
"metadata": {
"action": "click",
"cta_text": "Sign and Complete",
"field_id": "sig_field_1"
}
}signature_artifact object
{
"signature_type": "SES",
"algorithm": "ECDSA-P256-SHA256",
"signature_value": "base64:MEUCIQD...",
"certificate_chain": null,
"signing_time": "2025-01-15T10:03:00Z",
"covers_document_hash": true
}timestamp_token object (optional)
For higher assurance, attach an RFC 3161 timestamp token.
{
"tsa": "http://timestamp.example.com",
"tsa_name": "Example TSA",
"token_payload": "base64:MIIEpA...",
"token_hash": "sha256:f3g4h5i6...",
"issued_at": "2025-01-15T10:03:01Z",
"hashed_message": "sha256:c9d0e1f2..."
}audit_report export object
Major e-signature platforms treat the audit report as a first-class downloadable artifact (see, for example, Adobe Acrobat Sign's audit report configuration). Generate yours from the underlying event log.
{
"report_id": "rpt_ghi789",
"generated_at": "2025-01-15T10:05:00Z",
"report_version": "1.0",
"format": "pdf",
"export_hash": "sha256:j7k8l9m0...",
"included_sections": [
"events",
"signer_identity",
"consent",
"integrity",
"authentication"
]
}5. Example payloads
Minimal SES example (B2B)
A straightforward business-to-business contract where both parties have accounts. No consumer disclosure requirements apply.
{
"signature_packet": {
"packet_id": "sp_minimal_001",
"version": "1.0.0",
"created_at": "2025-01-15T10:00:00Z",
"status": "completed",
"document": {
"document_id": "doc_001",
"filename": "nda_counterparty.pdf",
"hash_before_sign": "sha256:aabbccdd...",
"hash_after_sign": "sha256:eeff0011...",
"hash_algorithm": "SHA-256"
},
"signer": {
"signer_id": "usr_b2b_01",
"email": "cto@counterparty.com",
"name": "Alex Kim",
"role": "signer"
},
"consent": null,
"authentication": {
"method": "email_link",
"factors": ["possession"],
"aal": "AAL1",
"session_id": "sess_m01",
"verified_at": "2025-01-15T10:01:00Z"
},
"events": [
{ "event_id": "evt_01", "event_type": "envelope.created", "timestamp": "2025-01-15T10:00:00Z", "actor": "system" },
{ "event_id": "evt_02", "event_type": "envelope.sent", "timestamp": "2025-01-15T10:00:05Z", "actor": "system" },
{ "event_id": "evt_03", "event_type": "envelope.viewed", "timestamp": "2025-01-15T10:01:10Z", "actor": "usr_b2b_01", "ip": "198.51.100.10" },
{ "event_id": "evt_04", "event_type": "document.rendered", "timestamp": "2025-01-15T10:01:12Z", "actor": "usr_b2b_01" },
{ "event_id": "evt_05", "event_type": "signature.applied", "timestamp": "2025-01-15T10:02:30Z", "actor": "usr_b2b_01", "ip": "198.51.100.10", "metadata": { "action": "click", "cta_text": "Sign" } },
{ "event_id": "evt_06", "event_type": "hash.computed", "timestamp": "2025-01-15T10:02:31Z", "actor": "system" },
{ "event_id": "evt_07", "event_type": "artifact.sealed", "timestamp": "2025-01-15T10:02:32Z", "actor": "system" }
],
"signature_artifact": {
"signature_type": "SES",
"algorithm": "ECDSA-P256-SHA256",
"signing_time": "2025-01-15T10:02:30Z",
"covers_document_hash": true
},
"timestamp_token": null
}
}AES/QES-leaning example (EU) {#aes-example}
Stronger identity binding, certificate artifacts, and a qualified timestamp token.
{
"signature_packet": {
"packet_id": "sp_aes_002",
"version": "1.0.0",
"created_at": "2025-02-10T14:00:00Z",
"status": "completed",
"document": {
"document_id": "doc_eu_002",
"filename": "consulting_agreement_de.pdf",
"hash_before_sign": "sha256:11223344...",
"hash_after_sign": "sha256:55667788...",
"hash_algorithm": "SHA-256"
},
"signer": {
"signer_id": "usr_eu_42",
"email": "m.weber@example.de",
"name": "Maria Weber",
"role": "signer",
"identity_proofing": {
"method": "video_ident",
"provider": "ident_provider_eu",
"level": "high",
"verified_at": "2025-02-10T13:50:00Z"
}
},
"consent": {
"disclosure_version": "eidas_disclosure_v1.0",
"disclosure_text_hash": "sha256:aabb1122...",
"presented_at": "2025-02-10T14:01:00Z",
"consent_action": {
"type": "checkbox_checked",
"performed_at": "2025-02-10T14:01:20Z"
}
},
"authentication": {
"method": "smart_id_pin",
"factors": ["possession", "knowledge"],
"aal": "AAL2",
"session_id": "sess_eu_42",
"verified_at": "2025-02-10T14:01:45Z"
},
"events": [
{ "event_id": "evt_a01", "event_type": "envelope.created", "timestamp": "2025-02-10T14:00:00Z", "actor": "system" },
{ "event_id": "evt_a02", "event_type": "signer.identified", "timestamp": "2025-02-10T13:50:00Z", "actor": "ident_provider_eu" },
{ "event_id": "evt_a03", "event_type": "auth.challenge_issued", "timestamp": "2025-02-10T14:01:40Z", "actor": "system" },
{ "event_id": "evt_a04", "event_type": "auth.passed", "timestamp": "2025-02-10T14:01:45Z", "actor": "usr_eu_42" },
{ "event_id": "evt_a05", "event_type": "certificate.issued", "timestamp": "2025-02-10T14:01:50Z", "actor": "trust_service_provider" },
{ "event_id": "evt_a06", "event_type": "signature.applied", "timestamp": "2025-02-10T14:02:10Z", "actor": "usr_eu_42", "ip": "93.184.216.34" },
{ "event_id": "evt_a07", "event_type": "timestamp.qualified", "timestamp": "2025-02-10T14:02:11Z", "actor": "qualified_tsa" },
{ "event_id": "evt_a08", "event_type": "artifact.sealed", "timestamp": "2025-02-10T14:02:12Z", "actor": "system" }
],
"signature_artifact": {
"signature_type": "AES",
"algorithm": "RSA-2048-SHA256",
"signature_value": "base64:MIIBvT...",
"certificate_chain": ["base64:MIIDxT...", "base64:MIIEkj..."],
"signing_time": "2025-02-10T14:02:10Z",
"covers_document_hash": true
},
"timestamp_token": {
"tsa": "http://qtsa.example.eu",
"tsa_name": "EU Qualified TSA",
"token_payload": "base64:MIIEpA...",
"token_hash": "sha256:99aabb...",
"issued_at": "2025-02-10T14:02:11Z",
"hashed_message": "sha256:55667788..."
}
}
}Witnessed deed example (UK)
Demonstrating witness attestation events for a deed executed under English law, following the framework examined by the UK Law Commission.
{
"signature_packet": {
"packet_id": "sp_deed_003",
"version": "1.0.0",
"created_at": "2025-03-01T09:00:00Z",
"status": "completed",
"document": {
"document_id": "doc_deed_003",
"filename": "property_deed.pdf",
"hash_before_sign": "sha256:deadbeef...",
"hash_after_sign": "sha256:cafebabe...",
"hash_algorithm": "SHA-256"
},
"signer": {
"signer_id": "usr_uk_07",
"email": "j.patel@example.co.uk",
"name": "Jai Patel",
"role": "signer"
},
"witness": {
"witness_id": "usr_uk_08",
"name": "Sarah Thompson",
"email": "s.thompson@example.co.uk",
"identity_method": "government_id_visual",
"relationship": "colleague"
},
"authentication": {
"method": "email_otp",
"factors": ["possession"],
"aal": "AAL1",
"session_id": "sess_uk_07",
"verified_at": "2025-03-01T09:05:00Z"
},
"events": [
{ "event_id": "evt_d01", "event_type": "envelope.created", "timestamp": "2025-03-01T09:00:00Z", "actor": "system" },
{ "event_id": "evt_d02", "event_type": "envelope.viewed", "timestamp": "2025-03-01T09:05:10Z", "actor": "usr_uk_07" },
{ "event_id": "evt_d03", "event_type": "signature.applied", "timestamp": "2025-03-01T09:06:00Z", "actor": "usr_uk_07", "ip": "51.15.0.1", "metadata": { "action": "draw", "cta_text": "Sign as Deed" } },
{ "event_id": "evt_d04", "event_type": "witness.present_attested", "timestamp": "2025-03-01T09:06:05Z", "actor": "usr_uk_08", "metadata": { "attestation_text": "I confirm I witnessed the signing in person." } },
{ "event_id": "evt_d05", "event_type": "witness.identity_captured", "timestamp": "2025-03-01T09:06:10Z", "actor": "system" },
{ "event_id": "evt_d06", "event_type": "witness.signature_applied", "timestamp": "2025-03-01T09:06:30Z", "actor": "usr_uk_08", "ip": "51.15.0.2" },
{ "event_id": "evt_d07", "event_type": "hash.computed", "timestamp": "2025-03-01T09:06:31Z", "actor": "system" },
{ "event_id": "evt_d08", "event_type": "artifact.sealed", "timestamp": "2025-03-01T09:06:32Z", "actor": "system" }
],
"signature_artifact": {
"signature_type": "SES",
"algorithm": "ECDSA-P256-SHA256",
"signing_time": "2025-03-01T09:06:00Z",
"covers_document_hash": true
}
}
}Witnessing requirements are legal formalities. The audit trail can capture evidence of presence and attestation, but logging alone does not make an invalid process valid. Consult solicitors on the specific formalities for the document type.
6. Implementation notes: what breaks in production
Idempotency and ordering
Distributed systems produce duplicate and out-of-order events. Assign a globally unique event_id at the point of creation, and use it as an idempotency key on write. Store a monotonic sequence number alongside the ISO 8601 timestamp so you can reconstruct order even when wall-clock times collide across services. If you use webhooks to feed your signature event log, implement deduplication at the consumer, not just the producer.
Tamper-evident logging patterns
An audit trail stored in a mutable database column is barely better than a text file. Use append-only storage with hash chaining: each event record includes a hash of the previous record, creating a verifiable chain. Restrict write access to a single service; no human should have direct INSERT or UPDATE permissions on audit tables. If your infrastructure supports it, consider write-once storage (S3 Object Lock, Azure immutable blobs) for the sealed artifact and its event log.
PII minimization vs. evidentiary needs
Enough PII is needed to prove attribution, but not so much that it becomes a liability under GDPR or CCPA. Store full name and email in the signer object because they are necessary for identification. For IP addresses and user agents, consider hashing them after a retention period (e.g., 12 months) while keeping the original hashes for integrity verification. Never store passwords, raw biometric templates, or government ID images in the audit trail itself; store a reference and proofing result instead.
Long-term validation considerations
Signing certificates expire. CAs get decommissioned. An RFC 3161 timestamp token proves the signature existed while the certificate was still valid, which prevents the entire signature from becoming unverifiable years later. For documents with long legal lifespans (leases, deeds, regulated agreements), embed OCSP responses and the relevant CRL snapshot alongside the timestamp token at the time of signing.
7. Quick mapping table: requirement to what to log
| Requirement | Source | Fields / Events to capture |
|---|---|---|
Signature not denied legal effect because electronic | ESIGN § 7001(a)* | signature_artifact, events[signature.applied], document.hash_* |
Consumer consent to electronic records | ESIGN § 7001(c)(1)(A) | consent.consent_action, events[consent.accepted] |
Disclosure of rights before consent | ESIGN § 7001(c)(1)(B) | consent.disclosure_version, consent.disclosure_text_hash, consent.paper_option_presented, consent.hardware_software_requirements |
Consumer demonstrates ability to access electronic form | ESIGN § 7001(c)(1)(C) | events[envelope.viewed], events[document.rendered], authentication.verified_at |
Uniquely linked to signatory | eIDAS Art. 26(a)** | signer.signer_id, signer.identity_proofing |
Capable of identifying the signatory | eIDAS Art. 26(b) | signer.name, signer.email, signer.identity_proofing.method |
Sole control of signature creation data | eIDAS Art. 26(c) | authentication.method, authentication.factors, authentication.aal |
Linked to data; change detectable | eIDAS Art. 26(d) | document.hash_before_sign, document.hash_after_sign, signature_artifact.covers_document_hash |
Proof-of-existence at a point in time | RFC 3161*** | timestamp_token.* |
Witnessing for deeds (UK) | UK Law Commission**** | witness., events[witness.] |
* www.law.cornell.edu/uscode/text/15/7001
**www.legislation.gov.uk/eur/2014/910/article/26
****lawcom.gov.uk/project/electronic-execution-of-documents/
8. Anvil's embedded e-signature API and audit trails
If you are building embedded signing flows, Anvil's E-Signature API handles document packaging, signer routing, and event capture.
A practical way to use this guide is to map webhook events into the schema above, then seal the packet when the envelope completes.
{
"event_id": "evt_2001",
"event_type": "envelope.sent",
"timestamp": "2026-02-27T18:20:00Z",
"actor": "system",
"actor_type": "system",
"correlation_id": "sp_abc123",
"metadata": {
"provider": "anvil",
"packet_id": "sp_abc123",
"delivery_channel": "email"
}
},
{
"event_id": "evt_2002",
"event_type": "envelope.viewed",
"timestamp": "2026-02-27T18:21:10Z",
"actor": "usr_xyz789",
"actor_type": "signer",
"correlation_id": "sp_abc123",
"ip": "203.0.113.42",
"user_agent": "Mozilla/5.0...",
"metadata": {
"provider": "anvil",
"packet_id": "sp_abc123"
}
},
{
"event_id": "evt_2003",
"event_type": "consent.accepted",
"timestamp": "2026-02-27T18:21:25Z",
"actor": "usr_xyz789",
"actor_type": "signer",
"correlation_id": "sp_abc123",
"ip": "203.0.113.42",
"user_agent": "Mozilla/5.0...",
"metadata": {
"provider": "anvil",
"packet_id": "sp_abc123",
"disclosure_version": "esign_disclosure_v3.2"
}
},
{
"event_id": "evt_2004",
"event_type": "envelope.completed",
"timestamp": "2026-02-27T18:22:10Z",
"actor": "system",
"actor_type": "system",
"correlation_id": "sp_abc123",
"metadata": {
"provider": "anvil",
"packet_id": "sp_abc123",
"document_id": "doc_def456"
}
}In most implementations, hash.computed and artifact.sealed are system events written immediately after envelope.completed, using the final rendered PDF bytes as input.
For implementation details, see Etch E-sign API documentation.
9. References and further reading
Primary legal and technical sources
- ESIGN Act, 15 U.S.C. § 7001: https://www.law.cornell.edu/uscode/text/15/7001
- eIDAS Regulation, Article 26 (AES requirements): https://www.legislation.gov.uk/eur/2014/910/article/26
- RFC 3161, Time-Stamp Protocol: https://www.ietf.org/rfc/rfc3161
- UK Law Commission, Electronic Execution of Documents: https://lawcom.gov.uk/project/electronic-execution-of-documents/
Implementation references
- Anvil E-Signature API documentation
- E-sign legality explainer (US, UK, EU)
- Adobe Acrobat Sign audit report configuration (example of audit report as artifact)
FAQ
What is an e-signature audit trail?
An e-signature audit trail is the evidence packet for a signing flow: who did what, when, and from where.
What should an e-signature audit trail include?
Start with intent, consent, attribution, authentication, timestamps, and document integrity (hashes).
What ESIGN consent evidence should be stored?
Store the disclosure version, disclosure text hash, presentation timestamp, and affirmative consent action metadata.
What fields support eIDAS Article 26(c) “sole control”?
Log the authentication method, factors used, session binding, and verification timestamps.
What is the difference between SES, AES, and QES?
SES is basic electronic signing, AES adds stronger identity and sole-control evidence, and QES adds qualified certificates.
Do B2B signatures need ESIGN consumer consent logs?
Usually not, but consumer-facing flows should log ESIGN disclosures and affirmative consent.
Why store a document hash at signing time?
Hashes make later tampering detectable and support integrity claims in disputes.
When is an RFC 3161 timestamp token useful?
When signatures must remain verifiable after certificates expire or are revoked.
How long should signed documents and audit trails be retained?
Retention depends on document type and jurisdiction, so default to the longest applicable requirement.