Evidence and audit

bb-sign records complete evidence for every envelope: who received what, who opened it, who signed, from where and when. That evidence, protected by an audit chain, supports each signer’s identity and the integrity of the process. This page explains what is recorded and how it is checked.

The audit chain

Every audit event carries its own hash and the hash of the previous event of the same envelope. The chain therefore lets you check that no event was inserted, modified or removed afterwards: any alteration breaks the link with the next event.

In an envelope’s detail, the Audit Trail section shows every event with its date, its actor (a person, a signer or System) and its hash. It is available to Auditors and Managers of the workspace, and to administrators in every workspace.

Recorded events

Event	When
SIGNER_ELIGIBLE	It becomes a signer’s turn (on send or, in sequential signing, when the previous group finishes).
SIGNING_LINK_CLICKED	The signer opens their link.
SIGNING_VIEW_OPENED	The signer opens the signing view.
SIGNING_VIEW_CLOSED	The signer closes or leaves the signing view.
SIGNER_SIGNED	The signer submits their signature.
ENVELOPE_COMPLETED	The last signer signs.
SIGNED_COPY_ACCESSED	A signer downloads their signed copy.
EMAIL_SENT, EMAIL_DELIVERED, EMAIL_OPENED, EMAIL_BOUNCED	An envelope email is sent, delivered, opened or bounces, as reported by the email provider.

The envelope also keeps its status and its creation, sent and cancelled dates, and webhooks notify your systems of sending, cancellation and expiry.

At organization level, bb-sign also records the creation and revocation of API credentials; the creation, deletion and secret rotation of webhooks; and the creation, renaming and deletion of workspaces, together with role grants and revocations. Administrators consult these events in Audit trail.

Data kept with each signature

When a signer submits their signature, bb-sign keeps the signature image, the exact time, the originating IP address and the browser (the user agent string). This data accompanies the SIGNER_SIGNED event and the signer’s record.

Opening tracking

Every time the signer opens the signing view, SIGNING_VIEW_OPENED is recorded. So that a reload or a retry does not count as separate openings, reports arriving within 30 seconds of the previous one are treated as the same opening. An opening after that interval is recorded as a new one.

The public verification

The QR code on every seal leads to a public bb-sign page with the envelope identifier and the first sixteen characters of the seal’s hash. Anyone who has the document can use it, without an account. See Verify a signed document.

bb-sign looks up the signer of that envelope whose hash starts with the received value and recomputes the hash with the formula SHA-256(name|email|date|documentId|certFingerprint), using the fingerprint of the organization’s active certificate. If the result matches the recorded hash, the page confirms the seal is valid and shows the signer’s name, their email and the signing date.

To verify the PDF, use the reader's signature panel

The public page confirms that the seal’s data matches what bb-sign has on record. To confirm that the PDF in your hands is intact, open it in Adobe Acrobat or another reader and review its signature panel. See Electronic signature and seal.

Because the hash includes the certificate’s fingerprint, if your organization changes its certificate, earlier seals stop validating on the public page, even though the documents are intact. In that case, verify earlier documents with the reader’s signature panel and let whoever will verify them know.

Consult and keep the evidence

Each envelope’s evidence is consulted in its Audit Trail, inside the application. To keep it beyond bb-sign’s retention period, see Scope and retention.