Electronic Signature Validation: A Part 11 Checklist

Use this practical checklist to review electronic signatures, identity, intent, controls, audit trails, and evidence for regulated systems.

What does electronic signature validation prove?

Electronic signature validation should show that the signature process reliably identifies the signer, records their intent, binds the signature to the record, and protects the signed record from inappropriate change. The signature control must work in the actual configured workflow.

A signature image alone is not the control. Review identity, authentication, meaning, timing, association, audit trail, access, and record retention together.

Electronic signature checklist

How should identity and access be tested?

Test unique identities, role permissions, account lifecycle, authentication failure, session behaviour, and privileged access. Include joiner, mover, and leaver scenarios. A user who should not approve a record must be prevented from doing so, not merely warned.

Test the role that signs, the role that reviews, and the role that administers. Separation of duties may matter even when each role is technically valid.

How should intent be shown?

The signer should understand what action the signature represents. The screen, prompt, or controlled workflow should make the meaning clear, such as approval, review, authorship, or confirmation. Test that the correct meaning is shown for each signature type and record state.

What should audit-trail testing cover?

Create, modify, approve, reject, and attempt-to-change scenarios. Check that the audit trail captures the relevant user, date and time, action, record, and version. Verify that ordinary users cannot disable, rewrite, or delete the history.

Do not validate only the signature button. Validate the record, audit trail, permissions, and retrieval path around it.

How do you validate signed-record retention?

Confirm that the signed record can be retrieved with its signature metadata and audit history. Test export or archival when the record leaves the active system. If the record is migrated, confirm that the signature association and history remain understandable.

What should the working record contain?

Keep the decision, evidence, and ownership together. A reviewer should be able to see the current baseline, the reason for the activity, the people who approved it, and the records that support the conclusion. Use stable identifiers for requirements, risks, tests, actions, and versions so a later review does not depend on one person's memory.

Good lifecycle records explain both the decision and its limits. Record assumptions, exclusions, unresolved questions, and the date when the conclusion should be revisited. This makes the next change or review faster without turning the file into a wall of generic text.

• State the system and process boundary.
• Link the activity to intended use and risk.
• Preserve original results and approved corrections.
• Assign an owner to every open action.
• Record the final decision and residual risk.

How can teams keep the process practical?

Use short decision gates instead of one large end-of-project review. At each gate, ask what is known, what remains open, who owns the next action, and whether the current risk is acceptable. This keeps the work moving while preserving an auditable trail.

Make the record useful to the people who operate the system. Link procedures, training, access decisions, and evidence to the same controlled item. When a future reviewer can understand the context without opening several disconnected folders, the lifecycle is doing its job.

Review the process after the first release. Operational experience often reveals a missing requirement, an unclear role, or a control that looked adequate on paper but is difficult to use. Feed those findings into the next controlled decision.

FAQ

Is a typed name an electronic signature?

A typed name may be part of an electronic signature process, but acceptability depends on the system controls, intended use, identity, intent, and applicable requirements.

Can a vendor certificate replace testing?

Vendor evidence can support assurance, but the organisation still needs to test its configuration and use.

What if a signature is rejected?

Test the rejection path, the record state, the reason captured, notifications, and whether a later approval remains traceable.

Should signatures be tested during migration?

Yes, if signed records or their metadata are migrated. Confirm that identity, association, history, and retrieval remain intact.

Conclusion

Validate the complete signature process, not its visual mark. Test identity, intent, association, audit trails, access, and long-term retrieval.