This is a ready-to-use investigation report for a disputed electronic signature: a reviewer denying they signed something that carries their name, or a discrepancy found between a signed printout and the live record. It walks the fixed sequence that separates a genuine binding failure from an account-security problem, so the conclusion rests on evidence rather than on which explanation sounds more likely. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. Verify each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Investigation / deviation reference | <<FILL: DEV-ID>> |
| System / record affected | <<FILL>> |
| Signature(s) in question | <<FILL: signer name, meaning, date/time>> |
| Reported by / date reported | <<FILL>> |
| Investigation lead | <<FILL>> |
| Investigation opened / closed | <<FILL>> |
1. Description of the concern
<<FILL: state exactly what was disputed or found, in the reporter's own words where possible, and how it came to light (audit, complaint, routine review).>>
2. Binding check
| Question | Finding |
|---|---|
| Version or hash referenced by the signature row | <<FILL>> |
| Current version or hash of the record | <<FILL>> |
| Do they match? | Yes / No |
If Yes: the binding held; proceed to section 4 (identity and account path). If No: the record changed after signing without invalidating the signature; proceed to section 3 (binding failure trace).
3. Binding failure trace (if binding did not hold)
| Step | Finding |
|---|---|
| Every edit to the record since the signature was applied (from the audit trail) | <<FILL>> |
| Was each edit made through the application, or at the database level? | <<FILL>> |
| If application-level: which function permitted an edit to a signed record without forcing re-signature? | <<FILL>> |
| If database-level: who had that access, and was it logged? | <<FILL>> |
| Was the change authorized under change control, or unauthorized? | <<FILL>> |
4. Identity and account path (if binding held)
| Question | Finding |
|---|---|
| Login history for the account around the signing time | <<FILL>> |
| Any evidence of shared credentials or an implausible login (location, time, concurrent session)? | <<FILL>> |
| Password reset or account activity around the disputed period | <<FILL>> |
| Conclusion: account compromise, shared credential, or genuine misunderstanding of what was signed | <<FILL>> |
5. Root cause
<<FILL: state the root cause plainly: a software defect in the invalidation logic, a privileged database-access gap, a credential-sharing practice, or a documented misunderstanding with no system fault.>>
6. Product / record impact assessment
| Question | Finding |
|---|---|
| Was the affected record used for a release, disposition, or other GxP decision before the issue was found? | <<FILL>> |
| If yes, what is the impact on that decision? | <<FILL>> |
| Any other records potentially affected by the same root cause? | <<FILL>> |
7. Corrective and preventive action
| Action | Owner | Due date | Status |
|---|---|---|---|
<<FILL: e.g. patch the invalidation logic>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: e.g. restrict/monitor privileged database access>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: e.g. retrain on credential sharing>> | <<FILL>> | <<FILL>> | <<FILL>> |
8. Conclusion
<<FILL: state the finding plainly: confirmed binding failure with corrective action in place, confirmed account-security issue with corrective action in place, or no defect found, misunderstanding resolved.>>
9. References
21 CFR 11.70 (signature/record linking) and 11.100 (identity, uniqueness). EU GMP Annex 11, section 14(b) (permanent link) and section 9 (audit trails). Applicable deviation / CAPA procedure
<<FILL: SOP-ID>>.
10. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Investigation lead | <<FILL>> | ||
| System owner | <<FILL>> | ||
| QA | <<FILL>> |
Filled specimen
A QA reviewer disputes signing a deviation closure that carries her name.
| Item | Finding |
|---|---|
| Signature row version reference | Deviation record, version 2, hash a3f... |
| Current record version/hash | Version 3, hash 9c1... (mismatch) |
| Conclusion | Binding failure: the record was edited after signing |
| Audit trail trace | One edit logged 2 minutes after the signature, made through the application’s “add supporting attachment” function, which the system did not treat as content requiring re-signature |
| Root cause | Software defect: the attachment function was scoped as non-signable content in the original configuration, but attachments are visible on the printed record and a reviewer reasonably expects the signed version to include them |
| Product impact | The deviation’s conclusion text was unchanged; only an attachment was added after signing. No release decision was made on the affected version in the interim. |
| Corrective action | Reconfigure the attachment function to require re-signature when applied to a signed record; retrospective review of other signed deviations for the same pattern |
| Conclusion | Confirmed binding failure, software defect, corrective action implemented and verified; no product impact identified |
This specimen shows why the sequence matters: the investigation ruled the binding in or out first, using the version/hash comparison, before it ever asked whether the reviewer’s account had been compromised. Starting from “she must be mistaken” would have missed a real, fixable defect.
Common inspection findings this report prevents
- A signature dispute closed as “user error” or “reviewer forgot” with no binding check ever performed.
- An audit trail reviewed only for the disputed entry itself, missing other edits in the same window that show the actual mechanism.
- No distinction drawn between an application-level defect and a privileged database-level edit, which require entirely different corrective actions.
- A confirmed binding failure not followed by a check of other records for the same pattern.
How to adapt this report
- Always perform the binding check in section 2 before investigating identity or account history; it determines which branch of the investigation is relevant.
- Pull the complete audit trail for the record, not just the entry closest to the disputed time.
- State the root cause as one of the four named categories (software defect, privileged access, credential issue, misunderstanding), not a vague description.
- Extend the corrective action to check for the same pattern elsewhere before closing.
- Route the completed report through your deviation/CAPA system, referencing this template’s structure as the investigation method.