Log: ICF Version Control and Re-Consent Tracking

This is a ready-to-use log. Its single job is to answer, on demand, the question an inspector asks first about consent: for every participant, which ICF version did they sign, when, and if an amendment required re-consent, was it completed. Consenting a participant under a superseded ICF, or being unable to show which version each participant signed, is the most common eConsent finding, and this log is the control that prevents it. In a validated eConsent system the platform maintains this mapping; this log is the human-readable record and the paper-or-hybrid backstop. Replace every <<FILL: ...>> placeholder. A filled specimen follows. This content is general educational reference, not legal or regulatory advice.

Part A: ICF version register

Every ICF version, variant, and language, with its IRB approval and effective dates.

Part B: Participant-to-version mapping

One row per participant, updated on each consent and re-consent event.

Part C: Amendment re-consent tracking

When an amendment requires re-consent, track completion across the affected population.

Control rules

1. No trial activity under a superseded ICF. A participant flagged “re-consent pending” for an amendment that gates continued participation does not proceed until re-consent is complete, per the protocol and IRB determination.
2. IRB approval precedes effective date. A version cannot be “effective from” a date earlier than its IRB/IEC approval.
3. The mapping is retrievable for the full retention period, including after any eConsent vendor change; that retrieval is a validated capability, not an assumption.
4. Every re-consent is a consent event with its own signature, date/time, and audit-trail entry.

Acceptance criteria

The log is in good order when: every participant maps to exactly one current ICF version; every amendment that requires re-consent has its affected population identified and tracked to completion; no participant is proceeding under a superseded version where the amendment gates participation; and the whole mapping can be produced for inspection at any point in the retention period.

Filled specimen

The following shows the log after one amendment, with re-consent partly complete. Details are illustrative.

Part A (version register):

Part B (participant mapping, excerpt):

Part C (amendment tracking):

Participant 04-014 is flagged “re-consent pending,” so no gated trial activity proceeds for them until re-consent is captured. That single visible flag is what turns “the system served the old version” from a finding into a controlled, tracked task.

Common inspection findings this log prevents

• A participant consented under a superseded ICF, with no record showing which version they signed.
• An amendment requiring re-consent where no one tracked who still needed it.
• An “effective from” date earlier than the IRB approval date.
• Inability to produce the participant-to-version mapping years later from a vendor-hosted system.

How to adapt this log

1. Where a validated eConsent platform maintains this mapping automatically, use this log as the periodic human-readable extract and the reconciliation reference.
2. Set the “re-consent required” determination per amendment with the IRB, and record it in Part A.
3. Point the retention rule to your real retention obligation and the validated retrieval capability.
4. Reconcile Part B against the platform’s records at defined intervals and before any inspection.