This is a ready-to-use sign-off form for a Trial Master File transfer, whether the trigger is a CRO change, bringing a study in-house, or migrating between eTMF systems. It turns the transfer from an informal file copy into a controlled, evidenced, dual-signed reconciliation. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows the template. This is general guidance to adapt, not legal or regulatory advice.
Document control header
| Field | Entry |
|---|---|
| Transfer record ID | <<FILL: e.g. TMF-XFER-2026-004>> |
| Study / protocol(s) in scope | <<FILL>> |
| Sending organization and owner | <<FILL>> |
| Receiving organization and owner | <<FILL>> |
| Reason for transfer | <<FILL: CRO change / in-housing / system migration>> |
| Cut-off date (source frozen) | <<FILL>> |
| Transfer plan reference | <<FILL: document ID>> |
1. Scope and freeze confirmation
| Field | Entry |
|---|---|
| Sites / countries in scope | <<FILL>> |
| Sponsor TMF, ISF copies, or both in scope | <<FILL>> |
| Source system placed in read-only / controlled state | Yes / No, confirmed by <<FILL: name, date>> |
| Sending owner named | <<FILL>> |
| Receiving owner named | <<FILL>> |
2. Reference-model index mapping
| Field | Entry |
|---|---|
| Sending system reference-model version | <<FILL>> |
| Receiving system reference-model version | <<FILL>> |
| Artifact-to-artifact mapping completed | Yes / No |
| Unmapped or renumbered artifacts identified | <<FILL: count>> |
| All unmapped artifacts resolved before export | Yes / No, if No do not proceed to section 3 |
| Mapping document reference | <<FILL>> |
3. Export verification
| Field | Entry |
|---|---|
| Exchange mechanism / format used | <<FILL: e.g. reference-model exchange format, or vendor-native export>> |
| Document content exported | Yes / No |
| Metadata exported (artifact type, document date, version, site, status) | Yes / No |
| Audit trail exported and reviewable in the receiving system | Yes / No |
| Export performed by / date | <<FILL>> |
| Export verified as a complete pull of the scoped studies/sites | Yes / No |
A bulk document dump that loses metadata or audit trail does not satisfy this section; do not proceed to sign-off until Yes is true across this table.
4. Count and content verification
Reconcile the imported record count against the source for each artifact type in scope, and record the QC result. High-risk artifacts require 100% verification; medium and low-risk artifacts may use a risk-based sample per the receiving organization’s QC procedure.
| Artifact type | Source count | Imported count | Variance | Verification basis (100% / sample) | QC result |
|---|---|---|---|---|---|
| Blank ICF, all versions | <<FILL>> | <<FILL>> | <<FILL>> | 100% | <<FILL>> |
| IRB/IEC approvals | <<FILL>> | <<FILL>> | <<FILL>> | 100% | <<FILL>> |
| Delegation of Authority Logs | <<FILL>> | <<FILL>> | <<FILL>> | 100% | <<FILL>> |
| Safety reports (SAE/SUSAR/DSUR) | <<FILL>> | <<FILL>> | <<FILL>> | 100% | <<FILL>> |
| Monitoring visit reports | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: sample size and basis>> | <<FILL>> |
| IP accountability records | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: additional artifact type>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
5. Expected-document list reconfiguration
| Field | Entry |
|---|---|
| Receiving eTMF expected-document list reloaded to the study TMF Index | Yes / No |
| Completeness metric restart date | <<FILL>> |
| Confirmation the expected list matches the sending organization’s tailored index, not an out-of-box default | Yes / No |
A transfer that reconciles system-to-system but leaves the receiving eTMF on a default expected list will misstate completeness from day one; this step exists to prevent that.
6. Exception log
Every missing, duplicated, or mis-mapped document identified during verification is tracked here to closure. Do not proceed to sign-off with an open row.
| Exception ID | Description | Type (missing / duplicate / mismapped) | Resolution | Closed by / date |
|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
7. Acceptance criteria for this transfer
- Artifact and site counts reconcile to the source, or every variance is an explained, closed exception.
- High-risk artifacts (consent versions, IRB/IEC and regulatory approvals, delegation logs, safety reports) are 100% verified.
- Metadata and audit trails are intact and reviewable in the receiving system.
- The expected-document list is reconfigured to the study TMF Index and completeness metrics restart on that basis.
- Every exception in section 6 is closed, not just logged.
8. Dual sign-off
Signing this section states that the transfer is complete, the verification in sections 3 through 6 was performed as recorded, and the receiving organization accepts the TMF, including any documented, closed exceptions, as of the cut-off date.
| Role | Name | Signature | Date |
|---|---|---|---|
| Sending owner | <<FILL>> | ||
| Receiving owner | <<FILL>> | ||
| Quality Assurance (receiving) | <<FILL>> |
9. Records generated and retention
This form, the mapping document, and the exception log are retained as part of the TMF per the study’s retention schedule, since they are the evidence that the receiving organization’s TMF is complete from the transfer date forward. Retain for the same period as the TMF itself.
10. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Filled specimen
The following shows an illustrative completed transfer for a single study changing CRO. Organization names, numbers, and studies are illustrative; replace with your own.
Transfer record ID: TMF-XFER-2026-004. Study: Protocol XYZ-201. Reason: CRO change. Cut-off date: 15 August 2026.
| Field | Entry |
|---|---|
| Sending reference-model version | 3.2.1 |
| Receiving reference-model version | 3.3 |
| Mapping completed | Yes |
| Unmapped artifacts identified | 4 (all in the Third Parties zone, renumbered between versions) |
| All unmapped artifacts resolved | Yes, mapped 20 July 2026 |
| Artifact type | Source count | Imported count | Variance | Verification basis | QC result |
|---|---|---|---|---|---|
| Blank ICF, all versions | 18 | 18 | 0 | 100% | Pass |
| IRB/IEC approvals | 42 | 41 | 1 | 100% | Fail, 1 missing, see exception TX-002 |
| Delegation of Authority Logs | 12 | 12 | 0 | 100% | Pass |
| Safety reports | 96 | 96 | 0 | 100% | Pass |
| Monitoring visit reports | 210 | 208 | 2 | Sample of 40, acceptance limit 1 error | Fail on sample, 100% review triggered, both located |
Exception log (specimen): TX-002, one IRB approval (site 07, Amendment 4) missing from the export, cause traced to a filing error in the source system before cut-off, resolved by obtaining the original from the site and filing it in the receiving system with the correct document date, closed 25 July 2026 by the TMF Lead.
Dual sign-off (specimen): Sending owner (CRO) signed 28 July 2026; receiving owner (sponsor TMF Lead) signed 29 July 2026; QA signed 30 July 2026, noting the one closed exception in the sign-off comment.
Common inspection findings this form prevents
- A transfer treated as an IT file copy with no reconciliation evidence, so the receiving organization cannot demonstrate the TMF is complete.
- Reference-model version mismatch causing artifacts to be mis-filed or lost, discovered only much later.
- Metadata and audit trail lost in export, so filing history is no longer reviewable.
- The receiving eTMF left on a default expected-document list, distorting completeness from the start.
- Exceptions identified during a transfer but never tracked to closure.
How to adapt this form
- Set the transfer ID, studies, and organizations in the header.
- Add or remove artifact-type rows in section 4 to match your study TMF Index; keep 100% verification for every artifact your risk assessment treats as high-risk.
- Point this form’s retention to your TMF Management Plan and records retention schedule.
- If your organization uses a validated transfer-verification tool, reference its validation record in section 3 rather than duplicating its output here.