Skip to main content

Signed PDF, proof page or audit log: what to store for the auditor

· 4 min read
Julien Jenoudet
Julien Jenoudet
CEO of IgniSign

An auditor, or a customer's compliance team, sends your product a question about a signature from last spring. Your backend can answer it, but only with what it fetched at the time. IgniSign produces several proof outputs for each signed document, and they do not answer the same question. So the integrating developer has a decision to make for each flow: which output does the backend fetch and keep? This post is about that choice, not about where you store it.

The outputs, and the question each one answers​

For each signed document, IgniSign can give your backend three kinds of proof:

  • The signed PDF. The document with the signatures applied and a signature page that summarises who signed. For data documents (JSON or XML), the matching output is the signed data file. It answers: show me what was signed.
  • The proof page. A web page reached through the proof link and the QR code on the signature page. It answers: let me check this myself, without asking you for files.
  • The signature files and the audit log. Depending on your application's configuration, IgniSign also produces a kit: a ZIP with the signature files and the audit log. It answers: show me how it was signed: the steps, the times, the authentication used.

All three are retrievable through the API per document once the proof exists. The SIGNATURE_PROOF webhook tells you when: GENERATED for the signed PDF and the proof link, ADV_GENERATED for the kit.

Start from the question, not the file​

Most teams fetch the signed PDF for every flow and stop there. That is a sensible default, and for many flows it is enough. The trouble starts when the question is not "what was signed" but "how". A signed PDF with a signature page shows the result. It is not the place to look for the sequence of events behind it.

So, for each flow that ends in a signature, write down the question you expect to be asked, then map it to an output:

  1. "Send us the signed document." Store the signed PDF. This covers contracts users download, consents, terms acceptance.
  2. "We want to verify it on our side." Store the proof link next to the record, and keep the signed PDF too. The outside party opens the page; you do not have to explain your storage.
  3. "Walk us through how this person signed." Store the kit with the signature files and the audit log, alongside the signed PDF. This is where flows with a second factor or an identity check belong, because the question will be about the steps, not only the outcome.

A flow can sit in more than one row. What matters is that the mapping is a decision you made, not whatever the first handler happened to download.

What it changes in the backend​

One handler per output keeps this simple:

  • On GENERATED, download the signed PDF for each document in the event and save the proof link on your record.
  • On ADV_GENERATED, and only for the flows in row 3, download the kit.

Add one field per output to your record, for example pdfStoredAt, proofLinkStoredAt and kitStoredAt. When the question arrives, a single query tells you whether you hold the output that answers it. If a field is empty because your endpoint was down when the event was sent, find the event in the webhook event log and resend it manually; key the handlers on the document id so a second delivery does nothing.

Do not fetch the kit for every flow by default. It is more data to store and back up, and for a terms-acceptance checkbox nobody will ask how the signer authenticated.

Check the mapping before production​

Run each flow once in your development environment and open what you stored as if you were the auditor. Can you answer the question you wrote down using only those files and that link? If not, change the mapping before you switch to production keys. It is cheaper than trying to rebuild an answer for a signature that completed months ago.

The decision​

Signed PDF for every flow. Proof link wherever an outside party may want to check. Signature files and the audit log for the flows where the question will be "how". Write the list down per flow; it is the first thing you show when the auditor asks how your product keeps proof.