This is a ready-to-use operational qualification (OQ) protocol for the electronic signature controls of a GxP computerized system. It exercises the three mechanics an inspector probes: signature-to-record binding, signature manifestation, and continuous-session re-authentication, plus the identification-code and password controls under 21 CFR Part 11 section 11.300. Replace every <<FILL: ...>> placeholder with your own specifics, execute each test case in sequence, and record actual results and pass or fail as you go. A filled specimen of two executed test cases follows so you can see the expected level of detail. Verify each cited regulation against the current source before you rely on it, and design against the direction of the draft Annex 11 revision where you can.
Approval page
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation / CSV) | <<FILL>> | ||
| Reviewer (System Owner) | <<FILL>> | ||
| Reviewer (QA) | <<FILL>> | ||
| Approver (Quality Head) | <<FILL>> |
Protocol executed by: <<FILL: name>> Execution start date: <<FILL>> Execution end date: <<FILL>>
1. Document control header
| Field | Entry |
|---|---|
| Document title | OQ Protocol, Electronic Signature Controls |
| Document number | <<FILL: PROT-ID, e.g. OQ-ESIG-021>> |
| Version | <<FILL: version, e.g. 1.0>> |
| System name and ID | <<FILL: SYSTEM NAME / ID>> |
| System version / build | <<FILL: application version under test>> |
| Environment | <<FILL: qualified test / validation environment>> |
| Related URS / FS references | <<FILL: requirement IDs for signatures>> |
2. Objective
Confirm, by documented test, that the electronic signature functionality of <<FILL: SYSTEM NAME>> performs as specified and satisfies the signature requirements of 21 CFR Part 11 (sections 11.50, 11.70, 11.100, 11.200, 11.300) and EU GMP Annex 11 (electronic signatures, section 14 of the in-force 2011 version). The protocol demonstrates that signatures are bound to the record signed, manifested completely on screen and on any human-readable output, and executed with the correct components for first and subsequent signings within and across sessions.
3. Scope
This protocol covers the configured electronic signature behavior of the system: the signing dialog, the two-component logic, the session and timeout behavior that governs re-authentication, the signature manifestation on screen and on printout or export, the binding of the signature to the record version, and the identification-code and password controls. It does not cover the underlying installation qualification, network infrastructure, or the business-process procedures, which are qualified and controlled separately under <<FILL: IQ protocol ID>> and <<FILL: SOP for e-signature management>>.
4. System description
<<FILL: two to four sentences describing the system, its GxP use, the records it signs (for example batch records, analytical results, deviations), the signature points in the workflow, and the authentication method (password two-component or biometric).>>
5. Prerequisites
Confirm each item before execution. Record N/A with a reason where a prerequisite does not apply.
| # | Prerequisite | Confirmed (initials/date) |
|---|---|---|
| P1 | System installed and IQ complete and approved (<<FILL: IQ ref>>) | |
| P2 | Test environment is representative of production configuration | |
| P3 | Test user accounts provisioned with unique, identity-verified IDs: at least two distinct signers and one administrator | |
| P4 | Signature meaning list configured (for example Authored, Reviewed, Approved) | |
| P5 | Inactivity timeout configured to the risk-justified value: <<FILL: minutes>> | |
| P6 | System clock synchronized to the qualified time source; time zone configured | |
| P7 | Password policy configured per <<FILL: policy ref>> (length, aging, lockout threshold) | |
| P8 | A printer or PDF export path available to test manifestation on human-readable output | |
| P9 | Blank test records available to sign (<<FILL: how test records are created>>) |
6. Roles for execution
| Role | Responsibility during execution |
|---|---|
| Tester | Executes each step, records the actual result, marks pass or fail, signs each executed case. |
| Reviewer (QA) | Reviews executed cases, adjudicates any failure and deviation, approves the summary. |
| System administrator | Provisions test accounts, resets passwords, and configures timeout and policy for test conditions; does not execute signing test cases on records they will later administer in production. |
7. Acceptance criteria (protocol level)
The protocol passes when every test case below meets its expected result, or when any deviation is documented, assessed, and resolved with QA approval and shown not to affect the signature controls. Any unresolved failure of a binding, manifestation, or two-component test case fails the protocol.
8. Test cases
Record for each: actual result, pass or fail, tester initials, date. Attach screenshots and printouts as evidence with an attachment ID.
8.1 Binding (11.70, Annex 11 permanent link)
| ID | Step | Expected result | Actual | P/F | Tester/Date |
|---|---|---|---|---|---|
| TB-01 | Sign a test record, then attempt to modify the underlying signed content through the application UI | The system blocks the edit and forces re-signature, or accepts the edit, increments the version, and marks the prior signature as applying to the prior version only | |||
| TB-02 | After TB-01, view the signed record and compare signed version against current version | The system clearly shows which version was signed and which is current | |||
| TB-03 | Attempt to copy or move a signature from one record to another record using ordinary application functions | Not possible by ordinary means; no function allows transferring a signature | |||
| TB-04 | As administrator, alter the record content at the database or back-end level, then re-open the record | The change is captured in the audit trail and the signature is flagged as broken or the stored hash no longer matches (detective control demonstrated) | |||
| TB-05 | Generate a printout or PDF of the signed record | The output reflects the signed snapshot, not a re-render from current live data |
8.2 Manifestation (11.50)
| ID | Step | Expected result | Actual | P/F | Tester/Date |
|---|---|---|---|---|---|
| TM-01 | Sign a test record and view the on-screen signature block | The block shows the printed name of the signer, the date and time of signing, and the meaning of the signature | |||
| TM-02 | Confirm the printed name resolves to a real, identity-verified individual, not a user ID or a shared account | Full printed name shown, mapped to the enrolled individual | |||
| TM-03 | Confirm the signing date and time include an unambiguous time zone or UTC offset | Time zone or offset present; no bare local time | |||
| TM-04 | Attempt to select a blank or free-text meaning at signing | Meaning is a controlled, configured selection and cannot be left blank | |||
| TM-05 | Print or export the signed record and inspect the human-readable output | All three mandatory elements (printed name, date and time, meaning) appear on the output, not only on screen |
8.3 Re-authentication and continuous session (11.200(a)(1))
| ID | Step | Expected result | Actual | P/F | Tester/Date |
|---|---|---|---|---|---|
| TR-01 | Log in as a signer and apply the first signature of the session | Both components prompted (ID and password); signature applied only when both are correct | |||
| TR-02 | Apply a second signature in the same session with no timeout elapsed | At least one individual-executable component prompted (password); signature applied | |||
| TR-03 | Attempt the second in-session signing with no component at all (confirm button only) | Not possible; the system requires the password (or a second-factor prompt) | |||
| TR-04 | Attempt to use the user ID alone as the single subsequent component | Rejected; the ID alone is not accepted as the individual-executable component | |||
| TR-05 | Leave the session idle until the inactivity timeout fires, then attempt to sign | Session is locked or ended; full two-component signing (ID and password) required again | |||
| TR-06 | Log out and back in, then sign | Treated as a first signing; both components required | |||
| TR-07 | Enter a wrong password at a signing event | Signature rejected; no signature applied; attempt recorded in the audit trail |
8.4 Identification code and password controls (11.300)
| ID | Step | Expected result | Actual | P/F | Tester/Date |
|---|---|---|---|---|---|
| TP-01 | Attempt to create a second account with an ID/password combination identical to an existing one | Prevented; each combination is unique (11.300(a)) | |||
| TP-02 | Confirm password aging or periodic revision is enforced per policy | Password expiry behaves per <<FILL: policy>> (11.300(b)) | |||
| TP-03 | Enter wrong passwords up to and beyond the lockout threshold | Account locks at the configured threshold; security event raised (11.300(d)) | |||
| TP-04 | Confirm a failed signing attempt and a lockout are visible to system security or management | Event is logged and retrievable for unauthorized-use detection (11.300(d)) | |||
| TP-05 | If tokens or devices bear or generate codes, confirm the device test procedure exists and passes | Device tested initially and periodically (11.300(e)); N/A if no such devices |
9. Deviation handling
Record any test case that does not meet its expected result as a deviation on the log below. For each, describe the observed behavior, assess the impact on the signature control and on data integrity, and route to QA for disposition. Do not mark the protocol complete until every deviation is resolved and approved.
| Dev # | Test case | Description | Impact assessment | Resolution | QA approval (name/date) |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
10. Summary and conclusion
| Field | Entry |
|---|---|
| Test cases executed | <<FILL: count>> |
| Passed | <<FILL: count>> |
| Failed / deviations raised | <<FILL: count>> |
| Deviations resolved | <<FILL: count>> |
| Overall result | Pass / Fail |
| Conclusion statement | <<FILL: e.g. The electronic signature controls of SYSTEM meet the tested requirements of Part 11 and Annex 11; the system is qualified for GxP signing use.>> |
11. References
21 CFR Part 11, sections 11.50, 11.70, 11.100, 11.200, 11.300 (electronic records and signatures). EU GMP Annex 11 (Computerised Systems), electronic signatures, in-force 2011 version. Track the draft revision published 7 July 2025, which renumbers electronic signatures to section 13 and points toward multi-factor authentication and time-zone-aware timestamps; do not qualify against draft text. ICH Q9(R1), Quality Risk Management (for the risk basis of timeout and password settings).
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows two executed test cases for an example manufacturing execution system, so you can see the level of detail an executed protocol should carry. The system and results are illustrative; replace them with your own.
| ID | Step | Expected result | Actual | P/F | Tester/Date |
|---|---|---|---|---|---|
| TB-01 | Signed batch record step BR-STEP-14, then attempted to edit the recorded weight through the application | System blocked the edit and displayed “signed content, re-signature required to change” | System blocked the edit; on override the version incremented to v2 and the v1 approval signature was marked “applies to version 1 only.” Screenshot ATT-03. | Pass | A. Patel, 08-Jul-2026 |
| TR-05 | Left the session idle 16 minutes (timeout set to 15), then attempted the next signing | Session locked; ID and password both required again | At 15 minutes the workstation locked; re-entry required user ID and password; the next signature prompted for both components. Screenshot ATT-11. | Pass | A. Patel, 08-Jul-2026 |
In the TB-01 example the tester demonstrated the binding control two ways in one case: the system first blocked the edit, and when the edit was forced through the controlled path, the prior signature was correctly re-scoped to the version it had actually approved. That is exactly the behavior 11.70 and Annex 11 require, and capturing the screenshot as attachment evidence is what makes the executed case defensible.
Common inspection findings this protocol prevents
- Signatures configured but never tested for binding, so a record could be edited after signing with the old signature silently attached.
- Manifestation verified on screen but never on the printout, leaving an 11.50(b) failure undiscovered.
- The continuous-session logic assumed to work from the vendor claim, with no test that a timeout actually forces full re-authentication.
- Failed signing attempts not captured, so the unauthorized-use detection required by 11.300(d) has nothing to detect on.
- Timeout and password settings taken as vendor defaults with no risk justification and no test evidence.
How to adapt this protocol
- Set your document numbers, system identity, and the requirement IDs your test cases trace to.
- Delete test blocks that do not apply (for example the device-code cases in 8.4 if you use no tokens) and record them N/A with a reason rather than leaving them blank.
- Set the timeout and password values to your risk-justified configuration and reference the risk assessment.
- If you use biometric signatures, add cases that show the biometric cannot be used by anyone other than its owner and that the fallback path is itself compliant.
- Attach screenshots and printouts with attachment IDs so each executed case carries its own evidence.
- Confirm every regulation in section 11 against the current published version before issue.