Electronic Signatures Are Not Just Digital Versions of Handwritten Ones
A signature is evidence of an approval event
A handwritten signature is often treated as a familiar shorthand for approval, authorship or acknowledgement. In a paper process, its meaning is supported by the surrounding record: the document pages, version, date, physical custody, witnessing arrangements and the procedures governing its use.
An electronic signature must carry an equivalent, and in many systems stronger, evidential burden. A typed name at the foot of an email, a tick box, an image of a handwritten mark and a cryptographic signature may all be electronic signatures in a broad sense. They do not, however, provide the same assurance. Whether any is suitable depends on the intended use, the consequences of an incorrect approval, the governing legal framework and the controls around the system.
The central engineering question is not whether a user can place a mark on screen. It is whether the organisation can later establish who acted, what they intended to approve, what information was presented at the time, and whether the associated record has changed.
Identity must be more than an account label
A signature event begins with attribution. The system needs a defensible basis for associating the action with a particular person or authorised role. A username alone is rarely sufficient evidence, particularly where shared accounts, weak password controls, unattended sessions or unmanaged devices are possible.
Appropriate identity assurance is risk-dependent. Controls may include individual accounts, credential lifecycle management, multifactor authentication, session controls, re-authentication at the point of signing and segregation of duties. The required combination depends on the process. Approving a low-risk internal document and releasing a batch record are not equivalent events.
Identity management also has an operational dimension. Systems must cope with leavers, role changes, contractor access, emergency access and credential recovery without creating untraceable paths around normal controls. A well-designed signature process records the identity used, the relevant role or authority, the authentication context and the time of the event. It should not rely on a later assertion that an account was probably used by its assigned owner.
Intent requires an explicit act
Authentication establishes that a user has access to an account. It does not necessarily establish that they intended to approve a specific item. This distinction matters where users can remain signed in for long periods, where workflows execute automatically, or where an approval control can be triggered accidentally.
A meaningful signature ceremony should make the action unambiguous. The user should be able to review the relevant information, select a clear approval meaning such as review, authorisation or acknowledgement, and perform a deliberate action. Where justified by risk, the system may require credentials to be re-entered or a second factor to be confirmed immediately before the signature is applied.
The displayed meaning matters. A generic button labelled “submit” does not reliably convey whether the user is approving content, releasing a record, accepting a deviation or merely advancing a workflow. The signature meaning must be defined by the process and retained with the event.
Context determines what the approval means
An approval has no useful meaning in isolation. A record that only states that a person signed at a given time cannot establish whether they approved a draft, a final revision, a selected subset of results or a record affected by an unresolved exception.
The signature evidence should therefore capture context sufficient to reconstruct the decision. Depending on the application, this may include:
- the record identifier and immutable revision or content version;
- the workflow state before and after signing;
- the reason or signature meaning;
- the signer’s role and applicable authority;
- timestamps with a defined time source and time zone treatment;
- relevant exceptions, comments and linked records; and
- the software configuration or rules governing the workflow.
Timestamps deserve particular care. A timestamp is not inherently trustworthy because it exists. Its value depends on clock synchronisation, access controls, handling of daylight-saving changes, storage precision and the ability to identify which system generated it. In distributed systems, event ordering may require more than comparing local server times.
The signature must be bound to the exact approved information
A principal failure mode is a signature that remains attached to a record after the underlying content changes. This can occur when systems treat the approval as a field on a mutable database row, rather than as evidence bound to a defined record state.
At minimum, the system should preserve an immutable representation of the approved content or a reliable version reference that can be retrieved later. Cryptographic hashes can strengthen this association by detecting changes to a defined content representation. They are useful engineering controls, but a hash by itself does not establish the signer’s identity, intent or authority. It must sit within a complete design.
Where a record is corrected or amended, the prior signed version should remain reconstructable, with the later change clearly identified and subject to the appropriate review or approval process. Overwriting values, replacing files in place or silently recalculating derived results can destroy the very evidence the signature was intended to protect.
Audit trails are necessary but not sufficient
An audit trail helps reconstruct events, but it is only one component of a trustworthy approval system. It must be protected from unauthorised alteration, retain meaningful before-and-after information where applicable, and be reviewable over the required retention period. Access privileges, backup and restoration processes, data migration, archival formats and periodic review all affect whether the evidence remains usable.
For regulated use, applicable requirements and guidance must be established from authoritative sources for the relevant jurisdiction and sector. An electronic signature feature cannot make a system compliant in isolation. Suitability depends on intended use, risk assessment, validation, operating procedures, user training, supplier controls and evidence that the system continues to operate as designed after change.
The dependable electronic signature is therefore not a decorative substitute for ink. It is a controlled record of a decision: attributable to an identified person, made deliberately, situated in its proper workflow context, and inseparably connected to the exact information that person approved.