Electronic Signatures in EDMS: Acceptance Checklist

Accept an EDMS signing workflow only when the evidence connects the authorized person, the intended signing action and the exact record signed. A signature image, successful login or green Approved label does not establish that complete relationship.

Use this checklist to evaluate a proposed configuration or a material change to an existing workflow. The US examples concern electronic signatures within the applicable scope of 21 CFR Part 11. The EU note concerns computerized systems in human-medicines GMP activities. Determine applicability before treating any row as a legal requirement. Sources were checked October 6, 2026; the fixture is illustrative, not an executed commercial-product test.

Set the scope and evidence record

Record the document family, underlying approval requirement, signature purpose, users, EDMS release/configuration, identity service and any external signing service. State where the authoritative signed record resides. Identify the workflow owner, technical owner and designated acceptance approver.

For each item retain criterion, applicability rationale, configuration, evidence reference, observed result, reviewer/date and unresolved-action owner. A Pass requires relevant evidence; Fail means observed contradiction; Unknown means evidence or applicability is unresolved. Not applicable requires an accepted scope reason. Required Fail or Unknown results hold acceptance of that scope.

The checklist combines regulatory control areas and proposed practical tests. It does not establish complete compliance, and the suggested fixture is not a regulator-issued test protocol.

If a row contains several independently testable outcomes, split it in the execution record. For example, an on-screen signature manifestation can pass while the exported readable copy fails. Keep both results; one must not conceal the other.

Apply the correct regulatory boundary

Part 11 applicability depends on the electronic records/signatures and underlying FDA requirements, not the EDMS brand. FDA's August 2003 scope and application guidance discusses its interpretation and specified enforcement discretion. That does not remove relevant predicate obligations or make a supplier's generic certificate sufficient evidence for your use.

For signed electronic records within scope, 21 CFR 11.50 addresses the signer's printed name, signing date/time and signature meaning, including their presence in human-readable forms. Evaluate the actual record display and output route; a separate signature tab may not travel with an exported file.

Section 11.70 addresses linking signatures to their records so ordinary manipulation cannot transfer them to falsify another record. A decorative stamp copied onto a PDF does not itself establish that control. Test the actual stored relationship and supported export operations.

Section 11.100 addresses unique individual signatures, identity verification and certification to FDA of intended handwritten-signature equivalence. Its current text permits the traditionally signed certification to be submitted electronically or on paper. Use the current FDA submission instructions when fulfilling that organizational requirement; do not assume buying software sends the certification.

For an EU human-medicines GMP workflow, Annex 11 section 14 addresses internal handwritten-signature effect, permanent linkage and signing date/time. These provisions should be evaluated in their own context rather than described as identical to every Part 11 detail. The current baseline checked here is revision 1, January 2011, as listed by the European Commission.

Separate login, signing and authorization

SSO authenticates a user session. The signing design still needs an intentional action, the applicable signature components, correct record linkage and task authority. Likewise, a user might be a valid employee with an active account but lack authority to approve this particular document.

21 CFR 11.200 distinguishes biometric and non-biometric signatures. For non-biometric signatures it requires at least two distinct identification components and distinguishes the first and subsequent signings during one continuous period of controlled access from signings outside such a period. Do not convert that wording into a universal requirement to type a username and password on every screen, or assume that any login satisfies every signing scenario.

Ask the supplier to describe the implemented components and controlled-access boundary. Then execute first signing, later signing in the defined continuous session, signing after the session ends, and signing after an identity or privilege change. Document why the expected behavior meets the applicable design. An unexplained session assumption remains Unknown.

Where identification codes and passwords are used, 21 CFR 11.300 addresses security controls including uniqueness, issuance review, compromise response, unauthorized-use safeguards and applicable device testing. The organization must translate those requirements into its actual account lifecycle and incident response; a password field alone does not do that work.

Challenge the exact-record relationship

Create a synthetic document with two clearly distinguishable revisions and a separate document with the same title. Give one test user the intended signing authority and another an active account without that authority. Record the approved role design so a successful action can be distinguished from an authorized one.

Review revision 2, then introduce revision 3 before the signing action. The accepted design must make clear what was actually signed and prevent an old review or signature from silently becoming approval of different content. A title match is insufficient because titles can repeat or change.

Next, retrieve the signed record through the normal interface and the required export route. Compare record identity, version, content and signature information. If a companion signature manifest is part of the approved record package, verify that the relationship and retrieval method preserve it. Do not assume a detached PDF remains complete without checking the defined package.

Test an allowed new revision after signing. The earlier signed record and its history must retain their meaning. The workflow may legitimately require a new review/signature for changed content; the point is to verify the approved lifecycle rather than demand one universal version-number scheme. See the document-control guide for the surrounding process.

Complete the example before accepting a demonstration

Fictional Alder's process authorizes Maya to approve SOP A-14 revision 2. Theo can read but cannot approve. Alder uses a non-biometric signing design, and its record package requires a readable copy containing signature information. The references below represent stipulated documentary evidence, not vendor test results.

The last case matters because a user-facing error does not prove the server rejected the action. Establish the authoritative result and record identity before repeating it. A retry that creates a second unexplained signing event or targets a later revision fails the intended workflow even if the interface ends green.

Required failures and unknowns cannot be averaged into a passing percentage. The designated approver closes an exception only after the correction and relevant retest are documented, or after an enforceable scope change is assessed and accepted. A scope exclusion cannot waive an applicable obligation.

Retain the evidence through change and staff departure

Keep the approved scope, applicable requirements, configuration, identity/authority setup, test records, deviations and acceptance decision together in the system validation record. Specify which changes trigger affected checks: identity-provider replacement, signing-service update, session-policy change, document conversion or export redesign.

When a signer leaves, disable future access through the appropriate process while preserving historical attribution. Do not rename the former employee's identity to their replacement. Confirm the older signature remains understandable without restoring the departed person's login.

Extend Alder's fixture by disabling Maya's access after her valid signing. Retrieve A-14 revision 2 as an authorized records reviewer and confirm that its signature still identifies Maya and the original signing date, time and meaning. Separately attempt a new signing through the disabled identity. Historical retrieval should remain interpretable while unauthorized future signing is prevented. If the old display now names Maya's replacement, the attribution check fails even if the underlying document bytes are unchanged.

Start a supplier evaluation with the two-revision fixture and an unauthorized signer. It exposes more than asking whether the product “has e-signatures.” Assyro publishes this checklist. For an Assyro discussion, bring the required signing workflow and evidence checklist. Establish the offered configuration and remaining responsibilities before treating a feature label as an accepted regulated process.