Design transfer under the MDR is the point where a verified and validated design stops being a development artefact and becomes something a production line can build repeatedly, to specification, without the original development team in the room. It is governed by clause 7.3.8 of EN ISO 13485:2016+A11:2021 and sits inside the QMS obligation of MDR Article 10(9) on product realisation. The clause requires that design and development outputs are verified as suitable for manufacturing before they become production specifications, and that the capability of manufacturing to meet product requirements is confirmed. The outputs of that confirmation live in the design and development file and feed the manufacturing information in Annex II Section 3 of Regulation (EU) 2017/745. Transfer is not a meeting. It is a controlled handover where process validation, training, and documentation all line up on the same day.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • Design transfer is governed by clause 7.3.8 of EN ISO 13485:2016+A11:2021 and traces legally to MDR Article 10 and Article 10(9) on QMS and product realisation.
  • The clause requires that design and development outputs are verified as suitable for manufacturing before they become production specifications, and that production capability is confirmed.
  • Transfer happens after design verification (clause 7.3.6) and design validation (clause 7.3.7) are complete, and before release for routine production.
  • Manufacturing process validation is the mechanism that confirms the production process can repeatedly produce devices meeting specifications, and it sits directly inside the transfer activity for processes whose output cannot be fully verified on the finished device.
  • Design transfer to a contract manufacturer (CMO) is the same clause 7.3.8 obligation with added interface management, written quality agreements, and on-site verification — the transfer does not become the CMO's problem.
  • Transfer records live in the design and development file under clause 7.3.10, and the manufacturing information they produce feeds Annex II Section 3 of Regulation (EU) 2017/745.

The Monday the line stopped

A team finished design validation on a Class IIa reusable device three weeks before planned release. Verification was clean, validation was clean, the clinical evaluation was aligned. The first production batch on the contract manufacturer's line was scheduled for the following Monday. On Friday the CMO called to ask which torque value applied to one of the assembly screws, because the drawing said one thing, the work instruction said another, and the pilot build from two weeks earlier had used a third. Nobody on the startup side could give a clean answer in under an hour. The line stood idle until Tuesday afternoon.

Nothing was wrong with the device. The verification and validation files were intact. What was missing was the discipline that sits between "the design works" and "the production line can build it." That discipline is clause 7.3.8 design transfer, and when it is skipped or improvised the cost shows up not in the audit room but on the first production Monday.

This post is about doing the transfer on purpose, so Monday is boring.

What clause 7.3.8 actually requires

Clause 7.3.8 (Design and development transfer) of EN ISO 13485:2016+A11:2021 is one of the shortest sub-clauses in the standard, and one of the most consequential. In the plain language of a startup running against it, the clause requires the organisation to document procedures for transfer of design and development outputs to manufacturing, and those procedures must ensure two things at once.

First, that design and development outputs are verified as suitable for manufacturing before they become production specifications. Drawings, bills of material, work instructions, inspection plans, software release packages, packaging specifications, labelling, and the associated acceptance criteria all have to be reviewed against the question: can the production process actually use this to build the device correctly, every time? An output that was adequate to guide a hand-built prototype may be inadequate to guide a repeatable production process, and the transfer step is where that gap is caught.

Second, that the capability of production to meet product requirements is confirmed. This is where process validation enters, where first-article inspection enters, and where the production-representative units used for design validation under clause 7.3.7 (post 295) prove their second role — showing that the process that built them is capable. The confirmation is documented and kept as part of the design and development records.

The clause also makes explicit that the results of the transfer and the conclusions are recorded. Transfer leaves a paper trail, not a handshake.

Clause 7.3.8 is short. The work it anchors is where the development team and the production team actually meet.

What design transfer is — and what it is not

Design transfer is the controlled conversion of development outputs into production specifications, combined with the confirmation that the production process can build to those specifications. That is the whole definition.

It is not a meeting. It is not a milestone review. It is not a slide deck called "Handover." A meeting can be part of transfer, but a meeting alone does not satisfy clause 7.3.8. What satisfies the clause is a set of activities that produce records: the review of every output for manufacturing suitability, the process validation work where applicable, the first-article or pilot-build verification, the training of the production team, the sign-off that the production process is capable, and the formal release of the design to production.

Transfer is also not the end of design controls. Clause 7.3.9 (changes) continues to apply to every change made after transfer, and the post-market feedback loops from PMS (MDR Articles 83 to 86) can and do trigger design changes that go back through the design control process and then back through transfer again. Transfer is a handover, not a goodbye.

One more thing transfer is not: a fiction. A startup that ships without running 7.3.8 properly and then back-writes a transfer document before audit repeats the Graz over-documentation pattern described in post 290. An auditor can read a transfer record for five minutes and tell whether it governed the handover or was written to describe it retrospectively.

The handoff documentation

The documentation that moves at transfer is not a single file. It is a package, and the package has to be complete before the production process owns it.

At a minimum the transfer package includes the production-ready design outputs: drawings and models at the correct revision, bills of material with approved suppliers, component and material specifications, assembly and work instructions, inspection and test procedures with acceptance criteria, packaging and labelling specifications at the correct revision, software release packages where applicable, and the device master record or equivalent that pulls these references together. It also includes the process documentation: the manufacturing process description, the process validation evidence or the plan to generate it, the equipment and tooling qualification records, and the in-process and final inspection plans.

The transfer package includes the traceability that ties all of this back to the design inputs, the risk file under EN ISO 14971:2019+A11:2021, and the GSPR items in MDR Annex I. An auditor reading Annex II Section 3 of Regulation (EU) 2017/745 — the manufacturing information — expects to trace from the production specification back to the design output that produced it, back to the design input that drove it, back to the user need or GSPR item that required it. Transfer is where that traceability is finalised.

The package is reviewed, approved, and released under document control. Approval is by named signatories defined in the quality system — typically the design owner, the quality manager or person responsible for regulatory compliance, and the production owner. The release date is the date the production specifications become the governing documents.

Manufacturing process validation inside transfer

For most medical devices, some part of the production process produces an output whose quality cannot be fully verified by inspection or test of the finished device. A sealing process, a sterilisation process, a moulding process, a software compilation and signing process, a cleaning step — any process where the only way to prove the output meets its requirements is to prove the process itself is capable and is kept in a qualified state. For these processes, clause 7.5.6 of EN ISO 13485:2016+A11:2021 (validation of processes for production and service provision) requires validation. And the natural place for that validation to happen is inside design transfer.

Process validation in the transfer step typically means the classical IQ/OQ/PQ chain: installation qualification of the equipment and environment, operational qualification of the process across its operating parameters, and performance qualification showing that the process produces the specified output repeatedly, within tolerance, on production-representative materials, operated by trained production staff. The validation runs on the same equipment, in the same facility, with the same staff who will run the routine production. Running IQ/OQ/PQ on a different machine and then transferring to production without re-qualification is a common mistake that surfaces at the first audit.

Process validation does not have to happen for every process. It is required where inspection cannot fully verify the output, and where 7.5.6 therefore applies. For processes that can be fully verified on the finished device, in-process and final inspection are enough. The transfer plan states, for each production process, whether validation is required and on what basis — and records the validation evidence where it is.

The linkage back to design validation under clause 7.3.7 is direct: the units used in design validation must be production-representative, which means they must have been built under the validated production process. If the process is not validated at the time design validation runs, the design validation is at risk of being nullified by a later change to the production process. In practice this forces process validation and design validation to be planned together — another reason transfer is set up in clause 7.3.2 design planning (post 290), not improvised at the end.

Training the production team

The production team that will build the device is not the development team that designed it. Even when the people overlap in a small startup, the roles do not. The production operator executes the work instructions as written. The development engineer knew what the work instructions meant to say. The gap between those two is the gap transfer must close, and the mechanism is training.

Clause 6.2 of EN ISO 13485:2016+A11:2021 requires that personnel performing work affecting product quality are competent on the basis of appropriate education, training, skills, and experience, and that records of training are maintained. At transfer, this general obligation becomes specific: every person who will perform a production task on the new device is trained against the work instructions, the inspection plans, the handling requirements, and the records they are expected to produce. The training is recorded against each individual. Authorisation to perform the task depends on the training being complete.

For a device with any non-obvious handling requirement — cleanroom entry, ESD control, torque sequencing, cure time, software signing — the training is where these requirements become operational. A work instruction that says "apply torque per spec" without training on how the torque tool is calibrated and how the sequencing works is not enough. The training is where the work instruction becomes behaviour.

Training at transfer is also the moment where development-team tribal knowledge is forced to become documented knowledge. If the only person who knows why a step is done in a specific way is the lead engineer who designed it, that knowledge leaves the company the day the engineer does — and the production process breaks without anyone understanding why. Training sessions at transfer regularly surface work instructions that are incomplete or ambiguous, and those findings are fed back into the design outputs under clause 7.3.9 change control. The first training run is often the most productive review of the work instructions the team will ever do.

Transfer in CMO arrangements

A substantial share of startups outsource production to a contract manufacturer rather than building their own line. Clause 7.3.8 applies identically whether production happens in-house or at a CMO. The obligation does not transfer with the manufacturing. The legal manufacturer (the startup) remains responsible for the design transfer, for the verification that outputs are suitable for manufacturing, for the confirmation that production capability meets product requirements, and for the records.

What changes in a CMO arrangement is the interface management. The startup and the CMO work to a written quality agreement that defines who is responsible for what: design output control, process validation, equipment qualification, incoming material control, in-process inspection, final inspection, non-conformance handling, change control, and deviation management. MDR Article 10 places the overall obligation on the manufacturer, and the QMS coverage required under Article 10(9) extends to activities performed by the CMO under the legal manufacturer's control. A quality agreement that leaves ambiguity on any of these items will surface as an audit finding or as a production problem, whichever comes first.

On-site verification is the move that saves time later. At transfer to a CMO, the legal manufacturer walks the line, watches first-article builds, verifies that the work instructions are being followed as written, checks that training records exist for the operators who will run the device, and confirms that the in-process inspection is being performed and recorded. This is not distrust. It is clause 7.3.8 being executed where the work actually happens. Startups that rely entirely on the CMO's assurance that transfer is complete, without walking the line themselves, regularly discover surprises at the first production batch.

The CMO's own QMS does not replace the startup's clause 7.3.8 obligation. The CMO may have an excellent QMS of its own. The legal manufacturer still owns design transfer. Both things can be true at the same time, and both usually need to be.

Common mistakes

  • Treating transfer as a meeting rather than a set of controlled activities with records. A signed slide deck does not satisfy clause 7.3.8.
  • Running design validation on prototype units, then transferring to a production process that builds different units. The validated design and the production device must be the same device under the same process.
  • Skipping process validation where clause 7.5.6 requires it. Sealing, sterilisation, moulding, cleaning, software build and signing, and similar processes need validation in the transfer step, not after the first batch has shipped.
  • Assuming a CMO's QMS absorbs the transfer obligation. The legal manufacturer owns clause 7.3.8 whether the line is in-house or contracted out.
  • No training records for the production operators on the new device. Clause 6.2 compounds clause 7.3.8: the production process is not capable if the people running it are not trained and recorded as such.
  • Transfer without the traceability back to design inputs and GSPR items. Annex II Section 3 of Regulation (EU) 2017/745 expects the manufacturing information to be traceable, and the transfer is where that traceability closes.
  • Back-writing transfer records after production has started. The transfer record is either the controlled handover that actually governed release to production, or it is a fiction that an experienced auditor will read in minutes.

The Subtract to Ship angle on design transfer

Subtract to Ship (post 065) applied to clause 7.3.8 is a discipline of running the transfer activities that actually answer the two questions the clause asks — are the outputs suitable for manufacturing, and is the production process capable — and cutting everything that is there because "transfer usually has it." Most bloated transfer packages are bloated because they repackage verification or validation evidence already filed elsewhere. Most thin transfer packages are thin because they skip the production-process work: the IQ/OQ/PQ, the first-article verification, the training records, the line walk.

The move that pays back most reliably is planning the transfer activities inside clause 7.3.2 design planning, at the start of the project, against the production process the team actually intends to use. The transfer package then accumulates in place as the project progresses, and the handover on the day of release is a review of a package that is already complete, not a scramble to assemble one. A lean startup can run an honest clause 7.3.8 transfer with a short transfer plan, a controlled document package, a focused IQ/OQ/PQ for the processes that need it, a first-article verification report, training records for the production operators, and a signed release to production. That is the whole job. Anything beyond that earns its place against a specific audit question or a specific production risk, not against the generic expectation that transfer documents should be thick.

Subtraction here is not cutting transfer. It is cutting everything in the transfer file that is not transfer.

Reality Check — Where do you stand?

  1. Can you point to a documented clause 7.3.8 transfer procedure, and to the transfer records for your current device at the most recent release?
  2. Were the design and development outputs reviewed for manufacturing suitability before they became production specifications, and is that review recorded?
  3. For every production process whose output cannot be fully verified on the finished device, is there validation evidence (IQ/OQ/PQ or equivalent) tied to the transfer?
  4. Were the design validation units under clause 7.3.7 built on the validated production process, or on a different setup that would not transfer?
  5. Are the production operators who will build the device trained and recorded as trained against the current revision of the work instructions?
  6. If you outsource manufacturing, is there a written quality agreement with the CMO that explicitly covers design transfer responsibilities, and have you walked the line yourself?
  7. Does the manufacturing information in Annex II Section 3 of Regulation (EU) 2017/745 trace back through the transfer package to the design outputs, inputs, and GSPR items?
  8. If an experienced notified body auditor asked today how you moved from development to production, would the answer be a single coherent transfer record, or a set of documents assembled after the fact?

Any "not yet" answer is a place to fix before the next audit window.

Frequently Asked Questions

When does design transfer happen in the project timeline? Design transfer follows design verification (clause 7.3.6) and design validation (clause 7.3.7) and comes before release for routine production. In a well-planned project, the transfer activities are reserved as explicit work in the design plan under clause 7.3.2 of EN ISO 13485:2016+A11:2021, and they run in parallel with the final stages of validation so that production is ready to start the moment validation is signed off.

Is design transfer the same as a Production Part Approval Process (PPAP)? No, although they overlap. PPAP is a supplier-to-customer approval mechanism used in the automotive sector and sometimes adopted in medtech supply chains. Clause 7.3.8 design transfer is the QMS obligation of the legal manufacturer to move a verified and validated design into production under control. A PPAP run by a component supplier does not replace the legal manufacturer's clause 7.3.8 transfer for the finished device, but PPAP-style evidence can feed into the transfer package where applicable.

Do I need full process validation for every production step? No. Clause 7.5.6 of EN ISO 13485:2016+A11:2021 requires validation only for processes whose resulting output cannot be or is not verified by subsequent monitoring or measurement. For processes that can be fully verified on the finished device through inspection or test, in-process and final inspection are adequate. The transfer plan states, for each process, whether validation is required and on what basis.

What goes into the Annex II Section 3 manufacturing information? Annex II Section 3 of Regulation (EU) 2017/745 covers the manufacturing information required in the technical documentation — identification of manufacturing sites, description of manufacturing processes, and information on suppliers and subcontractors to the extent required. The outputs of the clause 7.3.8 transfer feed this section: the validated production process description, the site information, and the manufacturing specifications at the controlled revision.

What if my CMO has its own QMS and ISO 13485 certificate? A CMO holding its own ISO 13485 certificate is helpful but does not absorb the legal manufacturer's clause 7.3.8 obligation. The legal manufacturer (the startup) remains responsible for the design transfer under the MDR, for the quality agreement that defines responsibilities between the parties, and for the confirmation that the CMO's production process is capable of meeting the device requirements. The CMO's certificate supports the arrangement; it does not replace the startup's obligation.

What happens if a change is needed after transfer? Any change after transfer is handled through clause 7.3.9 design and development changes, with impact assessment on inputs, outputs, verification, validation, risk, and the production process, and a controlled update to the transfer package where the change affects it. Post-market data from MDR Articles 83 to 86 frequently triggers such changes, and the QMS handles them through the same design control loop the original transfer ran through.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers), Article 10(9) (quality management system obligation including product realisation), and Annex II Section 3 (manufacturing information in the technical documentation). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 7.3.8 (Design and development transfer), with supporting clauses 7.3.2 (planning), 7.3.6 (verification), 7.3.7 (validation), 7.3.9 (changes), 7.3.10 (design and development file), 7.5.6 (validation of processes for production), and 6.2 (human resources and training). The harmonised standard providing presumption of conformity with the design and development portion of MDR Article 10(9).
  3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. The harmonised standard whose risk file is carried through transfer alongside the design outputs and process validation evidence.

This post is part of the Quality Management Under MDR cluster in the Subtract to Ship: MDR blog. Authored by Tibor Zechmeister and Felix Lenhard. The MDR is the North Star. EN ISO 13485:2016+A11:2021 clause 7.3.8 is the tool. Transfer is where a design stops being an idea owned by the people who drew it and starts being a product owned by the line that builds it — and the honest ones make that Monday boring on purpose.