This is a ready-to-use validation protocol for a configured eConsent system. Replace every <<FILL: ...>> placeholder, scale the test depth to your documented risk assessment, and route it through your normal validation review and approval. A filled specimen test case follows. Verify each cited regulation against the current source before you rely on it. This content is general educational reference, not legal or regulatory advice.
1. Approval page
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation) | <<FILL>> | ||
| Clinical / business SME | <<FILL>> | ||
| Clinical QA / GCP QA | <<FILL>> | ||
| System owner | <<FILL>> |
| Field | Entry |
|---|---|
| Protocol number | <<FILL: VAL-eCON-###>> |
| System name / version | <<FILL>> |
| Vendor | <<FILL>> |
| Protocol version / date | <<FILL>> |
2. Objective
Provide documented evidence that the configured eConsent system performs as intended for its GxP use: it serves the correct informed consent form (ICF) version to each participant, presents every required element of consent, captures a bound electronic signature, delivers a participant copy, and maintains a complete, reviewable audit trail, in line with 21 CFR Parts 11, 50, and 56 and the 2016 FDA/OHRP eConsent guidance.
3. Scope
In scope: the configured eConsent application as used for <<FILL: study / program>>, including consent presentation, comprehension aids, signature capture, participant-copy delivery, version control, and the audit trail. Out of scope: <<FILL: e.g. downstream EDC, covered by its own validation>>. Integrations to <<FILL>> are tested at the seam in section 7.
4. System description
<<FILL: hosting model (vendor SaaS), architecture, user roles (participant, site, sponsor), languages supported, device model (provisioned / BYOD), integrations>>
5. Prerequisites
- Approved URS and risk assessment on file (high-risk functions: version control, signature integrity, identity binding, audit trail).
- Supplier assessment complete; quality agreement in place.
- Test environment representative of production; test ICF versions and site/language variants loaded.
- IRB/IEC approval of the electronic consent materials for the test versions.
- Test accounts for participant, site, and sponsor roles.
6. Roles and acceptance
Each test case is executed by <<FILL: tester role>>, reviewed by <<FILL: QA>>. A case passes when actual result equals expected result with objective evidence attached. Any deviation is logged in section 8 and dispositioned before the summary.
7. Test cases
Record for each: actual result, pass/fail, tester, date, evidence reference.
| ID | Requirement | Test step | Expected result |
|---|---|---|---|
| TC-01 | Correct ICF version served | Enroll a participant at a given site and language; open consent | The site- and language-approved ICF version is served, no other |
| TC-02 | All 50.25 elements present | Inspect the served ICF against the 21 CFR 50.25 element list | Every required element is present and legible |
| TC-03 | Comprehension support | Trigger knowledge-check and glossary features | Aids function; a failed knowledge check routes per design |
| TC-04 | Signature capture and meaning | Complete participant signature | Record shows signer name, date/time, and the meaning of the signature (11.50) |
| TC-05 | Signature-to-version binding | Inspect the signed record | Signature is bound to the specific ICF version and cannot be reused or transferred (11.70) |
| TC-06 | Person-obtaining-consent / investigator signature | Complete the site signature where required | Captured with correct metadata and meaning |
| TC-07 | Participant copy delivered | Complete consent | A copy of the signed ICF is generated and delivered to the participant (50.27) |
| TC-08 | Audit trail completeness | Export the audit trail for the consent event | Open, time-on-form, knowledge-check results, signature, and any re-consent are captured, time-stamped, and independently reviewable |
| TC-09 | Amendment: serve new, block old | Approve and push a new ICF version; attempt to sign the superseded version | New version served to the right population; superseded version blocked; re-consent prompted where required |
| TC-10 | Re-consent record | Complete a re-consent after amendment | Record shows who re-consented under which version and when; not-yet-re-consented participants are flagged |
| TC-11 | Withdrawal | Execute a withdrawal | Workflow functions and is traceable |
| TC-12 | Multi-language fidelity | Serve a non-primary-language variant | Content and elements render faithfully in the tested language |
| TC-13 | Identity verification | Execute the remote identity-verification step | Identity is verified and recorded; signature binds to the identified participant |
| TC-14 | Connectivity loss | Interrupt connectivity mid-session | No partial or duplicate consent is created; behavior on reconnect is defined and correct |
| TC-15 | Integration seam | Confirm consent status transmits to <<FILL: downstream system>> | Data transmits completely and reconciles; counts in equal counts out |
8. Deviation handling
Log each deviation with description, impact, root cause, and resolution. A high-risk-function failure (version control, signature binding, audit trail, identity) must be resolved and re-tested before the summary is signed.
| Dev # | Test case | Description | Disposition |
|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
9. Acceptance criteria (protocol level)
- Every 50.25 element is demonstrably present in each served variant and language.
- The right ICF version is served to the right participant in 100 percent of version-control tests; superseded versions are blocked.
- Every signature record carries signer identity, date/time, and meaning, bound to a specific ICF version.
- A participant copy is generated and delivered for every completed consent.
- The audit trail captures open, comprehension, signature, and re-consent events and is independently reviewable and tamper-evident.
- Re-consent, withdrawal, and identity verification function and are traceable.
- Requirements trace cleanly from URS to test evidence with no orphans.
10. Summary and conclusion
<<FILL: statement that the system is validated for its intended use, or the conditions/restrictions on release; signed by Validation and QA>>
11. Attachments
- Requirements traceability matrix (URS to test case).
- Executed test evidence (screenshots, record and audit-trail exports).
- Deviation records and resolutions.
Filled specimen: TC-09 (amendment: serve new, block old)
The following shows one executed high-risk test case, so you can see the evidence level expected. Details are illustrative.
| Field | Entry |
|---|---|
| Test case | TC-09, ICF amendment version control |
| Precondition | v3.0-EN in production; v3.1-EN approved by IRB and loaded in test |
| Step 1 | Push v3.1-EN to the study; confirm effective |
| Step 2 | As an already-enrolled participant, attempt to open and sign v3.0-EN |
| Expected | v3.0-EN is blocked at signing; v3.1-EN is served; re-consent is prompted |
| Actual | v3.0-EN blocked with re-consent prompt; v3.1-EN served; audit log entry 2026-07-14 10:22 UTC recorded the version switch |
| Result | Pass |
| Evidence | Screen capture SC-09a/b; audit-trail export AT-09 |
| Tester / QA | J. Reyes / M. Osei, 14 July 2026 |
Because version control is the single most common eConsent finding, this case is executed with full scripted rigor and its evidence retained. A “we assume the vendor handles it” approach fails here; the sponsor must show the configured system was tested.
Common inspection findings this protocol prevents
- A participant consented under a superseded ICF because the amendment was not blocked.
- Reliance on a vendor’s “Part 11 compliant” claim with no sponsor testing of the configured system.
- An audit trail that exists but cannot be exported and read independently of the application.
- Missing signature metadata or a signature not bound to the specific ICF version.
- An integration validated only in isolation, so consent status drops or duplicates downstream.
How to adapt this protocol
- Scale test depth to your risk assessment; high-risk functions get scripted testing, lower-risk vendor-tested functions can lean on supplier evidence plus targeted unscripted checks.
- Add device-matrix test cases if consent is captured on BYOD.
- Point the integration seam test at your real downstream systems.
- Confirm the 50.25 element list and every cited regulation against the current source before execution.