Design transfer hands the design file to the line

Design verification asks whether an output matches its input requirements. Design validation asks whether the device meets the needs of the people who'll actually use it. Between those two well-covered clauses sits a third one that gets quoted far less often: design and development transfer, ISO 13485:2016 Clause 7.3.8, the requirement that took over from the old Quality System Regulation's 820.30(h) once QMSR's February 2, 2026 compliance date passed. It's a short clause. It's also the one that decides whether everything design controls produced actually turns into a device someone can manufacture.

The step that comes after, not instead of

Verification and validation both close out design and development — one confirms the output matches the input requirements, the other confirms the device meets the user's actual needs. Transfer is a separate act that has to happen after both: taking a design that's already been verified and validated and turning it into something a production line can actually build, repeatably, at the tolerances the design assumed. A device can pass every verification and validation test in its file and still fail at transfer, if the drawings, work instructions, and inspection methods that reach the floor don't preserve what those tests confirmed.

What “verified as suitable for manufacturing” checks

Clause 7.3.8 requires documented procedures for transferring design and development outputs to manufacturing — procedures that ensure those outputs are verified as suitable for manufacturing before they become final production specifications, and that confirm production capability can actually meet the product requirements those specifications carry. That's two separate checks, not one. The first is a paperwork check: does the drawing, tolerance, or work instruction reaching the floor say the same thing the design output said, without drift introduced in translation. The second is a capability check: can the equipment, tooling, and process actually hit what the specification demands, at production volume, not just on a hand-built prototype. A transfer that only does the first check has confirmed the documents agree with each other and confirmed nothing about whether the line can build to them.

In practice, that capability check is usually where a transfer earns its keep across more than one build stage — a pilot build that surfaces a tolerance the tooling can't consistently hold, an engineering build that closes it, and a first-article inspection against the final production specification before the transfer is called complete. A transfer plan that names only a single review meeting, with no defined build stage where capability actually gets tested against production-representative equipment, is describing a signoff rather than a transfer.

Results have to be recorded, not just achieved

The clause doesn't stop at requiring the checks; it requires the results and conclusions of the transfer to be recorded. That's a different obligation than closing a design review with a verbal sign-off that production is ready. A recorded transfer shows which production specification traces to which design output, what capability evidence supported the conclusion that the line could meet it, and what, if anything, had to change on either side before the two matched. Without that record, a later nonconformance on the floor has no way to show whether the failure originated in the design, in the translation, or in a production process that was never actually confirmed capable in the first place. Auditors reading a design file after the fact tend to ask for this record specifically, because it's the one piece of evidence that shows the file's story didn't just stop at validation — that someone actually checked the design survived the handoff to a different team, working from different documents, on different equipment.

Where that record sits now

Transfer records don't live inside the medical device file that Clause 4.2.3 now requires — that file covers the device's specifications and procedures as they currently stand, not the evidence trail for how design output became those specifications. The transfer record sits inside Clause 7.3's own design-and-development records, alongside the verification and validation evidence it follows. A template for this step has to capture that trace explicitly — design output, production specification, the verification that ties them, the capability evidence behind it — which is the structure behind the design-controls template set previewed in the launch catalog; a team that's built a cleaner version of that trace is exactly who the contribution page is for.