Design Controls, Supplier Management
Who Owns the Design File When Your Asian Factory Designed the Product?
The factory drew it, tooled it, and knows why every dimension is what it is. Your name is on the label. Regulators will ask you for the design file, and "the supplier has it" is not an answer that survives an inspection.
A common arrangement in home-use and consumer-adjacent medical devices: a U.S. company identifies a market, finds a Chinese factory already producing something close, specifies the changes it wants, puts its brand on the result, and sells it. The factory did the engineering. The factory owns the tooling. The factory knows why the thermal cutoff is rated where it is, because the factory chose it.
Then the U.S. company's name goes on the label, and with it the regulatory responsibility for a finished device whose design record it does not possess.
The question is not "who wrote it"
People hear "who owns the design file" as a question about authorship or intellectual property. It is neither. It is a question about authority: who decides what the device is, who is permitted to change it, and who has to be able to produce the record demonstrating that the current design is safe and effective for its intended use.
You can own no drawings, hold no patents, and employ no one who could design the product from scratch, and still be the party that owes the design file. If you are the specification developer or the labeler, the finished device is yours in the way that matters to a regulator.
"The factory has it" describes where a document is stored. It does not describe who is accountable for its existence, its accuracy, or its availability.
Why this stays broken for years
Nothing forces the issue. The product ships, customers are satisfied, and the arrangement works commercially. The design record's absence is invisible until something specific happens:
- An audit, and the auditor asks to see design inputs.
- A serious complaint, and you need to know what the device was supposed to do.
- A factory change (new site, new owner, new pricing), and you discover you cannot take the product anywhere else.
- A component goes obsolete and nobody on your side knows what constraints governed its selection.
- An acquirer runs diligence and asks what exactly they would be buying.
- The factory relationship sours, and the design record becomes leverage.
That last one deserves emphasis. A design file you cannot access is a commercial vulnerability long before it is a regulatory one. Companies that cannot move production have discovered this during price negotiations.
What you actually need to hold
Establishing design authority does not mean demanding the factory's entire engineering archive, which is usually unrealistic and occasionally unreasonable. It means holding the specific records that let you exercise the authority you already carry:
| What you need | Why it matters |
|---|---|
| Intended use and user needs | Only you can state these. The factory can build to a specification, but it cannot decide what the device is for. |
| Design inputs and requirements | The performance and safety characteristics the device must meet. This is where a supplier-designed product most often has nothing written down. |
| Risk analysis and risk controls | Hazards, their controls, and residual risk acceptance. Acceptance is a decision only the specification owner can make. |
| Design outputs sufficient to define the device | Drawings, BOM, critical specifications, firmware identity, labeling. You need enough to say what the product is, and enough to detect when it changes. |
| Verification and validation evidence | Proof the outputs satisfy the inputs, and that the device meets user needs in use. |
| Design transfer and process validation records | Evidence the design was translated into a manufacturing process capable of reproducing it. |
| Change history | What changed, when, why, who approved it, and what re-verification was performed. |
Some of these you author. Some the factory authors and you review and approve. A few of them, such as detailed process parameters, proprietary tooling design, and the factory's internal work instructions, can legitimately remain the manufacturer's, provided you can demonstrate that the process producing your device is validated and controlled.
The distinction that matters: you must be able to obtain and produce the records that demonstrate your device's safety and performance. That is different from owning every document the factory holds.
Reconstructing a design file that never existed
Most of this work is not creation. It is recovery, and it follows a sequence.
- Step one Establish what the device currently is. Capture the as-built configuration: the actual BOM, the actual firmware version, the actual critical components on today's production line, not the ones from the original quote. This is the baseline, and it is frequently the first time anyone has written it down.
- Step two Write the intended use and user needs. These are yours. They can be written today for a product that shipped years ago, and doing so is not backdating. It is stating a present understanding, dated today.
- Step three Derive design inputs from the device that exists. Work backwards: for each safety-relevant characteristic, state the requirement it satisfies. This is where you discover which characteristics nobody can justify.
- Step four Build the risk analysis against real use, including foreseeable misuse. Connect each hazard to the design feature controlling it.
- Step five Inventory existing test evidence and map it to requirements. Factories often hold more useful data than anyone realizes: safety certification testing, qualification runs, reliability data. Some of it will map cleanly. The gaps become your verification plan.
- Step six Close the gaps by testing, not by writing. Where evidence does not exist, generate it now and date it now.
- Step seven Establish forward change control, so the file you just built does not immediately drift out of date.
Step seven is the one companies skip, and it is the reason some companies do this exercise twice. A reconstructed design file with no mechanism to capture the next factory change is a snapshot that starts decaying the day it is finished.
The honesty constraint
There is a temptation, when reconstructing records, to make the file look as though it always existed. Do not. A design file assembled in 2026 for a product launched in 2019 should be dated 2026 and should say what it is.
Auditors are experienced at recognizing retrospective documentation, and a file that is honest about its own history is defensible in a way that a fabricated one never is. "We identified a gap and closed it" is a functioning quality system doing its job. Records that claim to have been created at a time they were not is a different category of problem entirely, and it converts a documentation finding into a credibility finding.
Where the factory relationship lands
The practical resolution is almost always a written agreement that allocates responsibility explicitly, backed by an arrangement where design records are accessible to both parties rather than held by one.
That is why we build engagements around a shared record both companies can work in. When the manufacturer proposes a change, the specification owner reviews the exact version proposed and approves it on the record. The design file stops being a thing one party holds and the other requests, and becomes the place where the decision actually happened.
That does not require the factory to surrender its process knowledge. It requires that the decisions affecting your device are visible to the company whose name is on it.
Working through this on a real product?
We help U.S. medical device companies control outsourced development and manufacturing in Asia: evidence, design transfer, and on-site supplier readiness. A short call is usually enough to tell whether we can help.
Book a discovery call Medical device services