Laboratory electronic signatures: approvals and record linkage

A name at the bottom of a report does not, by itself, explain who approved the result, with what authority or for which version. An electronic signature that serves the process must verifiably connect identity, act and content, even when the record is corrected or the system changes.

The starting point is not selecting a signature icon. It is defining the decision required in the laboratory and its supporting evidence. The controls below concern GMP workflows assessed within their regulatory scope, not universal certification of signature technologies.

1. Identify the act before the mechanism

Distinguish analysis execution, technical review, result approval and other decisions required by the quality system. Not every save requires a signature, and not every signature constitutes batch release. For each step, identify the requirement, responsible person, affected record and prerequisites.

Authentication verifies the identity accessing the system. An electronic signature records an act by the signer with its intended meaning. A typed name or signature image may be visible elements, but alone they do not demonstrate controlled identity, intent and record linkage. Cryptographic mechanisms can protect authenticity and integrity; they do not replace the signer’s authority or the completeness of the assessed data.

Start with Annex 11 and Part 11 applicability assessment. In the EU, eIDAS also governs signature categories and legal effects; it does not automatically replace GMP workflow controls. Do not infer that every internal approval requires a qualified signature, or that a cryptographic certificate alone demonstrates GMP compliance.

2. Design the approval chain

The original matrix below describes one possible laboratory workflow. Adapt the steps to actual responsibilities; “review” and “approval” are not interchangeable labels. The signed version must also identify attachments or linked objects that fall within the decision’s scope.

3. Control identity, authority and signature display

The signer must be identified, trained and authorised for the act. Keep digital laboratory roles and privileges consistent with the workflow. An administrator configuring the system does not thereby acquire the right to approve analytical data.

Where Part 11 applies, §11.50 requires the signed record to show the signer’s name, signature date and time, and meaning of the act, including in human-readable forms. Section 11.70 addresses linkage preventing signatures from being removed or transferred to falsify a record by ordinary means. Annex 11 §14 calls for permanent linkage, date/time and electronic signatures with the same impact as handwritten signatures within the company’s boundaries.

For nonbiometric signatures, §11.200 requires at least two distinct identification components, such as an identification code and password. This does not automatically mean two-factor authentication using different factor categories. The rule distinguishes the first signing within a continuous period of controlled access from subsequent signings; outside that period, every signing requires all components. Assess and test the actual session management. Section 11.100 includes uniqueness, identity verification and the certification to FDA required for electronic-signature users within the relevant scope.

4. Verify the workflow with positive and negative tests

Before testing, define what content the signer sees, which meanings are selectable and which conditions permit signing. An incomplete report or missing attachment does not become complete because the system accepts authentication.

In an authorised test environment, check permitted signing, an unauthorised role, an unready record, an ended session and cancellation. Confirm that a failed attempt does not leave an apparent approval. If content changes while the reviewer is reading it, the control must prevent unknowingly approving a different version: define the expected response and verify its effectiveness.

Also check display and export: name, timing, meaning and signed objects must remain interpretable. The audit trail documents events and changes; it does not automatically replace a signature or review decision. Retain observed outcomes and deviations, not merely a screenshot with a “signed” icon.

5. Simulated case: correction after approval

Result R7, version 1, has been approved. An incorrect unit is then found in the report. The assessment distinguishes a presentation error from a possible calculation error and considers how the result has already been used. Simply changing the unit while leaving an unchanged appearance of approval is insufficient.

The workflow authorises reopening, preserves version 1, the original signature and correction reason, then creates version 2 with relevant links. The new version undergoes review and approval as required by the impact. The old signature remains evidence of the decision on the old content: it is not transferred to the new content. Users can distinguish current status, superseded content and decision history.

6. Keep the link verifiable over time

Retention must include the record, necessary components, signatures and relationships. When format, application or archive changes, verify that who signed what, when and with which meaning remains reconstructable. Where cryptographic mechanisms are used, consider the dependencies needed for future verification; a signature image does not replace them.

Define responsibilities and controls before retiring the system. Revoking a former employee’s access must not anonymise their historical signatures. A retrieval check with representative records reveals problems that an archived-document list alone cannot demonstrate.

Sources and status — checked: 2 October 2026. EU GMP Annex 11, January 2011 revision, §§7, 12, 14, 17; 21 CFR Part 11, eCFR updated through 30 September 2026, §§11.50, 11.70, 11.100, 11.200; FDA Data Integrity, final nonbinding guidance, December 2018, Q11; Regulation (EU) 910/2014, eIDAS, consolidated text of 18 October 2024, definitions and Articles 25–26, for the distinction between categories and legal effects. The matrix and case are examples to adapt to applicable requirements.