How We Audit Signatures

Every signed PDF is hashed with SHA-256 at the moment its last signer signs. The hash is the document’s unique fingerprint; changing a single byte — adding a watermark, swapping a signature image, even an invisible edit — produces a completely different digest.

That hash is the row’s primary key in the signed-documents registry. Verification is therefore a literal equivalence check, not an inference: either the 64-character SHA-256 matches a row in the registry, or it does not.

When a match is found, the verify page exposes the following public-tier facts only — and nothing more (per the E-B10 2026-06-30 privacy decision):

• Document title (as supplied by the sender at the time of dispatch)
• Sender’s display name (the workspace owner — no email, no user id)
• For each signer: their display name, whether they are the owner or a counterparty, and a timestamp
• The full SHA-256 hash
• Page count and file size of the signed PDF
• Wall-clock completion timestamp

The verify page deliberately does not expose emails, IP addresses, user agents, or the signer’s individual IP-captured audit trail. Those rows live in the sender’s account on a higher privilege tier (workspace admin or owner) and are exported only via the GDPR data-export endpoint per a data-subject access request.

The verdict answers byte identity and signer-bound continuity. It does not on its own:

• Confirm the signer’s real-world identity (SignFile does not perform KYC; signer identity is self-asserted at the email layer)
• Prove the signer’s device was uncompromised at the moment of signing
• Prove the document’s contents reflected the parties’ intent outside the system (signers are responsible for reviewing what they sign)

Where a higher evidentiary standard is required (financial, healthcare, regulated-industry contracts), parties should pair the SHA-256 with their existing notarization or identity-verification process. SignFile produces the audit-grade artifact; legal interpretation of that artifact is the parties’ responsibility.

Every event that affects the document’s lifecycle is timestamped and recorded in the sender’s account:

• Created — when the sender finished placing fields, setters, and recipients.
• Sent — when the dispatch email(s) queued.
• Opened — when a signer first loaded the signing page (no value here; this is engagement signal, not consent).
• Consent given — when the signer ticked the ESIGN/UECA consent checkbox before applying their signature.
• Signed / declined — the actual binding event, captured with timestamp + (subject to privacy hardening) IP + user agent.
• Stamped — when the PDF was rewritten to embed the signature image.
• Certificate downloaded / email delivered / void requested / void executed — operational events around the document’s post-signing handling.

These rows never leak to the public verify view; they are the sender’s evidentiary record. A printed Cert of Completion is delivered alongside the completion email and to the owner’s account, and includes a SHA-256 anchor that the sender can re-verify against this same registry at any time.

If a signer claims they did not sign, or a recipient claims the document was altered after signing, the third party’s standing position is:

1. Re-pull the SHA-256 from the saved/printed signed PDF and paste it into the verify page — equivalence confirms the document has not been altered.
2. Compare the public signer list (name + signed_at) to the contractually-named recipients — continuity confirms the right parties signed.
3. Request the sender’s audit log via the sender (it is theirs to release; third parties do not have access to the IP-level audit trail).

Adversaries must break SHA-256 (cryptographically infeasible at the date of this page), or convince a sender to release the document from a workspace that has not been compromised by an IP-class attacker. SignFile does not promise either is impossible; the system is built to make both detectable.

SignFile is a SaaS tool, not a court. The legal force of a SignFile signature is whatever the jurisdiction’s electronic signature law (ESIGN, UECA, eIDAS, ITA 2000, etc.) gives it. SignFile’s job is to make the artifact the law asks for — a tamper-evident, signer-bound, time-stamped document with a one-way cryptographic hash — and to keep the public registry open to anyone with the document.

If anything on this page reads like an over-claim, that’s a bug. Email support@signfile.io and we’ll fix it.