What is an audit trail?

An audit trail is a traceable record of events within an electronic signing process. It is intended to show which document was sent, who participated, which actions occurred, and whether the document was changed after signing.

Depending on the platform, it may be called an audit report, certificate of completion, transaction log, or evidence record. It can be supplied as a separate PDF, as structured data, or together with the signed document.

An audit trail is not the same as a qualified certificate or the electronic signature itself. It supplements the technical signature data with information about the workflow. Its existence alone does not turn a signature into an advanced or qualified electronic signature.

Events typically recorded

The exact scope varies by provider, configuration, and signature method. An audit trail will commonly contain events such as:

• creation or upload of the document
• start of the signing transaction
• dispatch of an invitation by email or another channel
• successful or failed delivery
• opening of the signing link
• completion of an authentication step
• approval or refusal to sign
• completion or cancellation of the transaction
• download of the signed document
• expiry or revocation of an invitation

Each event may be accompanied by a time value, transaction identifier, and information about the user or system that initiated it. For automated steps, the record should make clear that an action was triggered by the system rather than by an individual.

For example, an audit report may state that an invitation was sent at 09:12, the link was opened at 09:18, a one-time PIN was confirmed, and the document was signed at 09:21. This sequence provides more context than an isolated entry stating only “signed.”

Identity and authentication evidence

The identity data retained depends on the required level of assurance. For a simple electronic signature, the record might contain a name, an email address, and confirmation that a checkbox was selected. These details document the process, but they do not automatically constitute reliable identification of the person.

Where additional authentication is used, the evidence may include:

• confirmation of a one-time code by SMS or app
• successful login to an existing user account
• the result of an electronic identification process
• a reference to identity verification by a trust service provider
• certificate information for certificate-based signatures

An audit trail should distinguish between a value that was merely entered and an attribute that was verified. A typed name is not equivalent to an identity confirmed through an identification procedure.

For advanced electronic signatures, the requirements in Article 26 of eIDAS are relevant. Among other things, the signature must be uniquely linked to the signatory, be capable of identifying the signatory, and be linked to the signed data so that subsequent changes are detectable. Whether these conditions are met depends on the complete technical process, not on the title or appearance of an audit report.

A qualified electronic signature involves, in particular, a qualified certificate and a qualified electronic signature creation device. The audit trail may record related certificate and validation information, but it does not replace these elements.

Time records, timestamps, and time zones

Almost every audit trail contains time records. Three questions are important when interpreting them:

1. Which system clock provided the time?
2. Which time zone is used for display?
3. Is the value an ordinary log entry or a cryptographic timestamp?

A platform server entry documents when the system registered an event. An electronic timestamp cryptographically binds data to a particular time. A qualified electronic timestamp under eIDAS is subject to additional defined requirements and legal presumptions.

For cross-border workflows, the time zone should be stated clearly, for example as UTC or with a specific offset. Without this information, records from different systems can appear to be in a contradictory order.

Document integrity

A key element of the evidence is the link between the audit trail and the signed document. Cryptographic hash values are frequently used for this purpose. A hash is a verification value calculated from a file’s contents. Even a small modification to the file will generally produce a different result.

A useful evidence export should show:

• the exact file to which the audit report relates,
• whether the hash was calculated before or after signing,
• the hash algorithm used,
• whether embedded signatures can be technically validated.

For PDF documents, electronic signatures can be embedded directly in the file. Post-signing modifications can then be detected during validation. Additional timestamps and certificate status or revocation information may be relevant for long-term validation, for example through appropriate PAdES profiles.

The fact that an audit report is supplied as a PDF does not automatically protect it against modification. What matters is whether the report itself is signed, sealed, or otherwise protected against undetected changes.

Interpreting technical metadata

Audit trails often contain IP addresses, browser details, device identifiers, or operating-system information. Such data can support the plausibility of a transaction, but it needs to be interpreted carefully.

An IP address will not normally prove a person’s identity or exact location. Corporate networks, mobile connections, VPN services, and shared devices all limit its evidential value. Likewise, opening a signing link does not necessarily prove that a person read the entire document.

Technical metadata is therefore one element of a broader chain of evidence. Its significance depends on how it interacts with authentication, document integrity, time records, and the organisation’s operational procedures.

Data protection and retention

Many audit-trail entries constitute personal data. Names, contact details, IP addresses, authentication events, and certificate information may all fall into this category. Their processing will therefore generally be subject to the GDPR where it applies.

Practical implementation should address at least the following points:

• the purpose and legal basis for processing
• collection of necessary rather than maximum data
• transparent information for affected individuals
• allocation of roles among the platform operator, customer, and other service providers
• access controls and protection against unauthorised changes
• retention and deletion periods
• processing locations and any third-country transfers

Not every value that can technically be collected needs to be stored permanently. Under the data-minimisation principle, processing should be limited to data necessary for the defined purpose. At the same time, statutory retention obligations or legitimate evidence requirements may prevent premature deletion. The appropriate period depends on the document, contractual relationship, and context of use.

The respective GDPR roles also need to be determined for the actual setup. A signing platform may process certain data on behalf of its customer, while separate services or purposes can lead to a different allocation of responsibilities.

Evidence for different signature types

The expected evidence package should reflect the selected signature level. A simple electronic signature may rely heavily on the process record, email address, confirmation steps, and document-integrity controls. Its evidential value depends strongly on the surrounding circumstances.

For an advanced electronic signature, the technical mechanism must satisfy the relevant eIDAS criteria. The audit trail should help explain the link to the signatory, the authentication or identification used, control over signature creation, and detection of later changes.

For a qualified electronic signature, validation focuses on the qualified status of the certificate, the certificate’s validity at the relevant time, the qualified signature creation device, and the integrity of the signed data. A readable transaction report remains useful, but the decisive technical evidence is not confined to that report.

This distinction matters when exporting records. A visual signature image, a completion certificate, and a cryptographically verifiable signature serve different purposes and should not be treated as interchangeable.

What organisations should check

Before selecting or configuring a signing service, organisations can run a test using a complete sample transaction. The review should cover not only the visible signature but the entire evidence package.

Useful questions include:

• Can the audit trail be exported independently of the user account?
• Are the document, report, and transaction ID unambiguously linked?
• Are all material events recorded with consistent time information?
• Is the authentication method described clearly?
• Can certificates, signatures, and timestamps be validated with commonly available tools?
• Will the evidence remain available after account closure or contract termination?
• Can retention periods and access permissions be configured?
• Are failed and cancelled transactions recorded as well?
• Is the exported report itself protected against unnoticed modification?

An audit trail is most useful when it does more than collect a large volume of data. It should provide an understandable and technically verifiable sequence of events tied to a specific document. The appropriate signature type and evidence for a transaction depend on its risks, applicable form requirements, and required evidential value. That assessment is specific to the circumstances and may require legal and technical review.