Documentation Practice
Design Controls
Developing a device under a controlled, documented process, so that what was built can be shown to meet what was needed.
- Where required
- ISO 13485:2016 clause 7.3. In the United States, 21 CFR 820.10(c) has required compliance with that clause since 2 February 2026; before then the requirement was 21 CFR 820.30
- Applies to (US)
- Class II and Class III devices, and a short list of Class I devices that includes any device automated with computer software
- Main record
- The design and development file (ISO 13485 7.3.10), formerly the Design History File
In short
Design controls are a set of linked activities: plan, define inputs, produce outputs, review, verify, validate, transfer to production, and control every change. They are not a methodology and can be met with a staged or an iterative process. The purpose is evidence that each requirement came from somewhere and was shown to be met.
The elements
| Element | ISO 13485 | Former 820.30 | What it means |
|---|---|---|---|
| Planning | 7.3.2 | (b) | Stages, reviews, verification, validation and transfer activities, responsibilities, and how traceability is kept. Updated as the work progresses. |
| Inputs | 7.3.3 | (c) | Functional, performance, usability, safety and regulatory requirements, and the outputs of risk management. Complete, unambiguous, verifiable and not in conflict. |
| Outputs | 7.3.4 | (d) | Specifications, code, drawings and acceptance criteria, in a form that can be verified against the inputs, and approved before release. |
| Review | 7.3.5 | (e) | Planned, systematic reviews at suitable stages, with records of who took part and what actions followed. |
| Verification | 7.3.6 | (f) | Confirmation that outputs meet inputs. |
| Validation | 7.3.7 | (g) | Confirmation that the device meets user needs and intended use, on representative product, before release. |
| Transfer | 7.3.8 | (h) | Outputs are shown to be suitable for production before they become production specifications. |
| Changes | 7.3.9 | (i) | Each change is identified, reviewed, verified or validated as needed and approved before implementation, with its effect on risk and on product already delivered. |
| Files | 7.3.10 | (j) | The records that demonstrate all of the above. |
On a software project
- They start when development starts. Research and feasibility work sits outside design controls, but prototype code that becomes product has to be brought under them: reviewed, traced and verified like everything else.
- The trace matrix is the backbone. User needs lead to design inputs, inputs to outputs, and outputs to verification and validation. See verification, validation and traceability.
- Iteration is fine; baselines are required. Inputs and outputs can evolve sprint by sprint, as long as reviews happen at defined points and formal verification runs against an identified baseline.
- Change control is the long-running cost. After a baseline, every change request records the rationale, the impact on requirements, risk and tests, the approval and the verification.
- For software, transfer means a controlled release. A repeatable build, an identified released configuration, and a documented installation or deployment procedure.
Worth knowing
- The US terms Design History File, Device Master Record and Device History Record are no longer defined in the regulation. Their equivalents in ISO 13485 are the design and development file and the medical device file. Many organisations still use the old names.
- The FDA’s 1997 design control guidance, the source of the widely reproduced waterfall diagram, was written for the earlier rule. The concepts carry over.
- IEC 62304 supplies the software-specific detail inside this framework, and ISO 14971 supplies the risk management that feeds the inputs.
Official sources
A summary for orientation. It is not regulatory or legal advice, and it is no substitute for the standard or regulation itself. Requirements change: confirm the current edition before relying on anything here. Last reviewed November 2026.