Usage Examples
- We cannot start design transfer until the open verification protocol deviations are closed.
- That class I device runs on firmware, so it is inside design controls whether we like it or not.
- The auditor asked for the design and development file, and our index still calls it the DHF.
What is Design Controls?
Design controls are the FDA-mandated design and development requirements for medical devices, governing how a device is planned, specified, verified, validated, and transferred to production, unlike production controls that govern manufacture of an already-approved design.
Design controls exist because a device's most expensive failures are locked in before the first unit is built. Once a specification is wrong, manufacturing perfectly to that specification still produces an unsafe device. Design controls force the manufacturer to state what the device must do, prove the design meets that statement, and prove the finished result works for its user.
Design controls cover class II and class III devices, class I devices automated with computer software, and five named class I devices such as non-powdered surgeon's gloves. Everything else in class I sits outside them. Design controls attach to the design of finished devices intended for human use, so bench research that never becomes a marketed device is not in scope.
Design controls are applied as a documented chain: user needs become design inputs, inputs become outputs, verification proves outputs meet inputs, and validation proves the device meets the user need. Design controls are audited through the design and development file, which must contain or reference every record needed to show compliance. Inspectors read the file, not the intent.
Not to be confused with
- Design history file (DHF)
- the DHF was the Quality System Regulation's name for the design record set. Under the QMSR the operative artifact is the ISO 13485 design and development file. Keeping a folder labelled DHF is harmless; citing 820.30(j) as its legal basis is not.
- Design verification
- verification is one step inside design controls, not a synonym for the framework. Verification only answers whether outputs meet inputs; design controls are the planned system that produces those inputs and outputs in the first place.
- Process validation
- process validation proves a manufacturing process reliably produces conforming output. Design validation proves the design itself meets user needs. Passing one tells you nothing about the other.
- QMSR
- the QMSR is the whole quality management system regulation at 21 CFR Part 820. Design controls are one obligation inside it, imposed by § 820.10(c) and executed through Clause 7.3.
There is no standalone design controls section anymore. These are the anchors that carry the obligation.
What you must do
- 1Comply with Design and Development, Clause 7.3 and its subclauses of ISO 13485, for every class II and class III device and for the named class I devices21 CFR 820.10(c)
- 2Treat any class I device automated with computer software as in scope for design and development, regardless of how light its other obligations are21 CFR 820.10(c)(1)
- 3Maintain a design and development file that contains or references all records necessary to establish compliance with the design and development requirementsISO 13485:2016 Clause 7.3.10
- 4Apply the quality management system to design alongside manufacture, packaging, labeling, storage, installation, and servicing of the finished device21 CFR 820.1(a)
- 5Operate against the QMSR text rather than the pre-2026 Quality System Regulation, which it displaced on 2 February 202621 CFR Part 820
Common mistakes
Citing 21 CFR 820.30 in live procedures
the QMSR took effect on 2 February 2026 and the design and development obligation now runs through 21 CFR 820.10(c) to Clause 7.3. An SOP that still cites 820.30 subparagraphs tells an inspector the quality system was never updated, and that inference costs more than the citation itself.
Assuming class I means exempt
a class I device automated with computer software is named in the regulation as in scope. Firms shipping firmware-driven class I products often discover this during an inspection rather than during development, and reconstructing design inputs after launch costs far more than capturing them once.
Treating validation as a larger verification
verification against your own specification cannot detect a wrong specification. Teams that run bench verification, call it validation, and skip use-environment evidence ship devices that meet spec and fail the user, which is precisely the failure design validation exists to catch.
When This Matters
- We cannot start design transfer until the open verification protocol deviations are closed.
- That class I device runs on firmware, so it is inside design controls whether we like it or not.
- The auditor asked for the design and development file, and our index still calls it the DHF.
Frequently Asked Questions
Design controls apply to all class II and class III devices, plus class I devices automated with computer software and five named class I devices including non-powdered surgeon's gloves and protective restraints. Every other class I device sits outside the design and development requirement in 21 CFR 820.10(c).
Related Use Cases
- Medical Devices Use Cases
Prepare 510(k), PMA, and De Novo submissions with AI-guided pathway selection
- Consulting Use Cases
Manage 15+ client programs from one dashboard with per-client workspaces and tracking
- Regulatory Affairs Workflows
Cut regulatory intelligence tracking from 10+ hours/week to automated, real-time alerts
- Quality/QA Workflows
Track GxP regulation changes and enforcement trends
