Protocol: Technology Transfer to a CDMO

This is a ready-to-use technology transfer protocol for moving a manufacturing process from a sponsor (the sending unit) to a contract development and manufacturing organization (the receiving unit). Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval on both sides. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it. This template is an educational reference for you to adapt to your own quality system, products, and regulatory context; it is not legal, regulatory, or professional advice.

Document control header

1. Purpose

This protocol defines the approach, deliverables, batches, and acceptance criteria to demonstrate that <<FILL: receiving unit / CDMO name>> can reproduce the process for <<FILL: product name>>, transferred from <<FILL: sending unit name>>, at scale, on its own equipment, with its own operators, and consistently meet the same critical quality attributes. The objective is to prove the process is understood and controlled at the receiving site before any commercial batch is distributed from it, not to prove that a batch was made.

2. Scope

This protocol applies to the manufacturing process, unit operations, and equipment train described in section 6 and section 7, transferred from the sending unit to the receiving unit named in the header. It covers the knowledge transfer package, the engineering and confirmation batches, and the comparability acceptance testing against the sending unit’s proven acceptable ranges. It does not cover analytical method transfer, which runs on its own protocol per <<FILL: analytical method transfer protocol number>>; the two workstreams are linked but distinct, because a method can transfer cleanly while the process it tests does not, and the reverse. It does not cover the commercial or quality agreement negotiation, which must already be in force before this protocol executes.

3. Responsibilities

4. Definitions

• Sending unit: the site delivering the process knowledge, here the sponsor or an existing internal manufacturing site.
• Receiving unit: the site that will manufacture the process going forward, here the CDMO.
• Critical process parameter (CPP): a process parameter whose variability affects a critical quality attribute and must therefore be monitored or controlled to ensure the process produces the intended quality.
• Critical quality attribute (CQA): a physical, chemical, biological, or microbiological property or characteristic that must fall within an approved range to ensure product quality.
• Proven acceptable range (PAR): the range of a CPP, established from development or historical manufacturing at the sending unit, within which the process is demonstrated to produce material meeting its CQAs.
• Engineering / demonstration batch: a non-commercial batch run at the receiving unit to work through the process on its own equipment; deviations are expected and are documented, not hidden or absorbed into “the process now works.”
• Comparability / confirmation batch: a batch run against acceptance criteria set before testing began, used to confirm the receiving unit’s process performs within the sending unit’s proven acceptable ranges.
• Knowledge transfer package (KTP): the defined set of documents in section 6 that the sending unit delivers before any batch is planned.

5. Prerequisites before execution

This protocol may not begin execution (section 7, stage 4 onward) until all of the following are complete and documented. Executing before these are closed is itself a protocol deviation.

6. Knowledge transfer package

The sending unit delivers the following before any batch is planned. The receiving unit’s technical team reviews each element and raises questions before proceeding; a package accepted without a documented technical review is not a completed step, it is a file transfer.

Outstanding questions from the receiving unit’s technical review: <<FILL: list, or "none">>

7. Stage-gated transfer flow

8. Batches to be executed

State the number of confirmation batches and the rationale for it (commonly three) in <<FILL: rationale, e.g. risk assessment reference>>. If fewer than three are used, record the risk-based justification here rather than silently running fewer.

9. CPP/CQA comparability acceptance testing

Every criterion in this table is set before any confirmation batch runs. A criterion added or adjusted after testing has begun invalidates the comparability claim for that parameter.

If any confirmation batch result falls outside the proven acceptable range, the criterion fails and section 11 (deviations) applies; a documented, risk-assessed rationale for a widened range is a change to this protocol, not a note in the results table.

10. Acceptance criteria

The transfer is accepted only when all of the following are true. Meeting some but not all is a partial transfer, not a completed one, and must be stated as such in the transfer report.

• Every criterion in section 9 was set before testing began and is a number, not an aspiration.
• Every CPP and CQA at the receiving unit falls within the sending unit’s proven acceptable range, or a documented, risk-assessed rationale exists for any adjustment, approved by both quality units before the confirmation batches are accepted.
• Engineering batch deviations were documented, assessed, and either closed or carried forward as defined process risk, not silently absorbed into a passing confirmation result.
• The regulatory filing impact (section 10a below, tracked via section 12) was assessed and, where a variation or supplement is required, it is approved before commercial batches from the receiving unit are distributed.
• The master batch record executed at the receiving unit was reviewed against the sending unit’s process description line by line, with every adaptation documented and justified.
• Both quality units signed this protocol before execution and the transfer report before routine supply began.

10a. Regulatory impact assessment

No commercial batch from the receiving unit is distributed before the entry above shows the filing approved, unless the assessment concluded no filing is required and both quality units concurred in writing.

11. Deviations and handling

Any deviation from this protocol, any engineering or confirmation batch event, and any out-of-range result is documented as a deviation per <<FILL: deviation SOP-ID>> and assessed for impact on the acceptance decision before the transfer is accepted. Engineering batch deviations are expected and are not grounds alone for rejecting the transfer; each is either closed with a defined root cause or carried forward as a documented process risk that both quality units accept. A confirmation batch deviation that affects a CPP or CQA in section 9 holds that criterion at “Fail” until resolved; it is not averaged against a passing batch.

12. Report and disposition

On completion, the technology transfer leads jointly issue transfer report <<FILL: report number>>, summarizing the stage outcomes, the CPP/CQA comparability results against section 9, all deviations and their resolution, the regulatory filing status, and the conclusion on the transfer, including any conditions attached to routine supply. The report is approved by both quality units before the receiving unit is approved for routine supply.

13. Attachments

14. References

WHO Technical Report Series 1044, Annex 4 (2022), guidelines on technology transfer in pharmaceutical manufacturing, superseding the 2011 edition in TRS 961. ICH Q10, Pharmaceutical Quality System, technology transfer as a product lifecycle stage. ICH Q7, Good Manufacturing Practice for Active Pharmaceutical Ingredients, section 16 (contract manufacturers, including transfer expectations). ICH Q2(R2), Validation of Analytical Procedures (basis for the parallel analytical method transfer). EU GMP Chapter 7, Outsourced Activities. 21 CFR Parts 210 and 211. ICH Q9(R1), Quality Risk Management (basis for the risk assessment in section 5).

Confirm the current version and clause numbers of each reference before issue.

15. Revision history

16. Approvals

Filled specimen

The following shows the protocol’s comparability table and disposition completed for an example oral solid dose product, so you can see the level of detail an inspector expects. The company, product, and numbers are illustrative; replace them with your own.

CPP/CQA comparability table

Deviations: One engineering batch deviation, DEV-26-0311, an out-of-specification blend uniformity result on a single location at the start of the run, traced to an unqualified sampling thief technique; corrected before confirmation batches, closed 15 February 2026, no impact on confirmation batch acceptance.

Regulatory impact assessment: Assessed as a Type IB variation (EU) / CBE-30 (US), submitted 20 February 2026, approved 22 April 2026. Commercial distribution from Penhallow held until approval; first commercial batch dated 29 April 2026.

Conclusion: All three confirmation batches met every predefined CPP range and the CQA release specification. The single engineering batch deviation was closed with an assignable cause unrelated to the process itself. The regulatory variation was approved before commercial distribution. Transfer accepted, no conditions. Both quality units signed the transfer report, TTR-26-011, on 25 April 2026, four days before the first commercial batch.

In this example the team set every acceptance number before any confirmation batch ran, treated the engineering batch deviation as expected and investigated it to an assignable cause rather than absorbing it into a passing result, and held commercial distribution until the regulatory approval actually landed rather than at submission. That sequence is exactly what a reviewer is expected to demonstrate.

Common inspection findings this protocol prevents

• Engineering batches quietly treated as the confirmation or comparability batches, with no predefined acceptance criteria set before they ran.
• A raw material substitution made at the receiving unit with no documented comparability assessment, discovered only when a CQA drifts.
• The regulatory filing impact assessed, or approved, after commercial batches from the receiving unit were already distributed.
• No development risk assessment or known-deviation history included in the knowledge transfer package, so the receiving unit rediscovers a failure mode the sending unit already knew about.
• This protocol approved by only one site’s quality unit, or approved after batch execution had already started.
• Confirmation batch results averaged, or a single out-of-range CPP dropped from the table, to present a clean pass.
• No traceable link between this protocol and the parallel analytical method transfer protocol, so a method that has not itself transferred is used to accept the process.

How to adapt this protocol

1. Set your document number, both quality units’ names, and the effective date in the header.
2. Replace the CPP/CQA rows in section 9 with your own process’s parameters and the sending unit’s actual proven acceptable ranges.
3. Point the cross-references in sections 2, 11, and 14 to your real analytical method transfer protocol, deviation SOP, and quality agreement.
4. Set the number of confirmation batches and the rationale in section 8 to match your risk assessment; do not default to three without recording why.
5. Confirm every regulation in section 14 against the current published version before issue.
6. Track the outcome into Report: CDMO Periodic Performance Review for the relationship-level view, and if the relationship later needs to be escalated or wound down, use Log: CDMO Dispute, Escalation, and Transition-Out Tracking, which references a successor-site technology retransfer run on this same protocol structure in reverse.