Design controls — the part of the regulation that everyone in product development can recite from memory and still gets cited on — have a new street address. They’ve moved from §820.30 of the old Quality System Regulation to Clause 7.3 of ISO 13485:2016, which is now the law of the land thanks to QMSR §820.7 and §820.10.
The discipline is the same. The vocabulary, the structure, and a few of the receipts have changed.
If you’ve been doing design controls for a while, the steps are still the ones you can recite in your sleep: planning, inputs, outputs, review, verification, validation, transfer, changes. ISO 13485 §7.3 keeps all of them. It just adds two more subclauses, threads risk management through the whole sequence, and asks for a level of documentation specificity that some companies were politely hand-waving past.
What §7.3 Actually Says
ISO 13485:2016 §7.3 has ten subclauses, not the eight you sometimes see referenced in online summaries (those usually fold 7.3.1 General into 7.3.2 Planning, which the standard keeps separate). The full lineup:
7.3.1 General — establish documented procedures for design and development.
7.3.2 Design and development planning — plan the project, including stages, reviews, verification and validation activities, design transfer, responsibilities, and how design risk is managed.
7.3.3 Design and development inputs — capture functional, performance, usability, and safety requirements; applicable regulatory requirements; outputs from risk management; and anything else the design depends on. Then review them for adequacy.
7.3.4 Design and development outputs — must meet the inputs, contain or reference acceptance criteria, identify what’s essential for safe and proper use, and be approved before release.
7.3.5 Design and development review — systematic, planned, with participants from the relevant functions, and recorded.
7.3.6 Design and development verification — performed against a documented plan, with methods, acceptance criteria, and statistical techniques (including sample size rationale) where applicable.
7.3.7 Design and development validation — performed against planned arrangements on representative product, with clinical or performance evaluation if regulation requires it, and completed before release.
7.3.8 Design and development transfer — verify that outputs are suitable for manufacturing before they become production specifications. Keep the records.
7.3.9 Control of design and development changes — review, verify or validate as appropriate, and approve before implementation. The change record must include impact analysis on constituent parts, on product already in distribution, and on the inputs and outputs of risk management.
7.3.10 Design and development files — maintain a file for each device or device family that contains or references the records demonstrating conformity to §7.3.
That last one is the new home of your former Design History File. The DHF as an FDA-defined term is gone — FDA pulled the DHF, DMR, and DHR definitions out of §820.3 in favor of ISO 13485’s Medical Device File and Design and Development File concepts. Same idea, slightly bigger tent, organized at the device-or-family level rather than the project level.
What Changed From §820.30, in Spirit
The bones of the old design controls are intact. What changed is the level of explicitness in three places.
1. Risk management is woven through, not a guest appearance. Old §820.30 mentioned risk in exactly one spot — §820.30(g) Design Validation, requiring “risk analysis where appropriate.” ISO 13485 references risk in 7.3.2 (planning), 7.3.3 (inputs), 7.3.7 (validation), and 7.3.9 (changes). The broader QMSR also pulls risk into clauses 4.1, 7.1, 7.4, 7.5, 7.6, and 8.2. If you’ve been doing serious ISO 14971 work all along, this is a nothingburger. If your risk file has been getting bolted onto each project at the end, consider this your warning shot.
2. V&V plans are deliverables, not aspirations. ISO 13485 expects verification and validation to be performed “in accordance with planned and documented arrangements.” Translation: an actual plan, with methods, acceptance criteria, and — when statistical sampling is involved — a written sample size rationale. Inspectors will look for it. “We tested it and it worked” is not a V&V record.
3. Design transfer wants proof. Old §820.30(h) was one short paragraph. ISO §7.3.8 is similarly short, but the surrounding language is more explicit: outputs must be verified as suitable for manufacturing before they become production specifications, and the transfer must be documented. Tossing a folder of drawings over the wall to manufacturing is not a transfer.
The Class I Exemption Survived
If you’ve been waiting for me to say it: yes, FDA kept the design controls exemption for most Class I devices in QMSR §820.10(c). The list of carve-outs matches the old §820.30(a)(2) almost exactly. If your tongue depressor was outside the design controls scope before, it is still outside now. You’re welcome.
What to Actually Do
If you have a working design control system already, the practical work here is mostly translation and a couple of tightening passes:
Rename your DHF process to a DDF process and confirm the file is organized at the device or device-family level — not just the project level.
Make sure each verification and validation plan contains methods, acceptance criteria, and (where applicable) a sample size rationale, written down before the testing starts and not reverse-engineered after. This is the single most common gap I see in companies who built their QMS around the old QSR and assumed ISO 13485 would feel familiar.
Walk your risk management process through each design phase and confirm it is feeding inputs into design and pulling outputs back. The audit question is no longer “do you have a risk file?” — it is “where in your design and development records does the risk file actually show up?”
Design controls were never optional. ISO 13485 §7.3 just makes the scaffolding a little more visible and the receipts a little more demanding. None of this is meant to trip you up — but FDA inspectors now know exactly where to look, and the answers should be on the shelf, not in someone’s head.
For more context on how the QMSR pulls all of this together, see the earlier posts in this series: the QMSR overview, the Medical Device File and Quality Manual walkthrough, and last month’s pass through §7.1 and §7.2.