This scenario plays out across the medical device industry more often than most quality teams want to admit. Design controls exist to prevent exactly this failure mode. They're the FDA- and ISO 13485-mandated quality processes that create traceability from user needs through design inputs, outputs, verification, validation, and the design history file.
This guide covers the regulatory basis for design controls, the seven-phase process manufacturers follow, how FDA's new Quality Management System Regulation (QMSR) aligns with ISO 13485, the role of the design history file, and practical steps for staying audit-ready year-round.
Key Takeaways
- Design controls apply to all Class II/III devices, plus select Class I devices, under FDA and ISO 13485:2016 clause 7.3
- The process builds traceability: user needs → design inputs → outputs → verification → validation → transfer
- FDA's QMSR, effective February 2, 2026, incorporates ISO 13485 by reference, largely unifying US and international requirements
- The Design History File gives auditors objective evidence that the design was actually developed under control
What Are Design Controls? (And Why They Exist)
Design controls are a defined set of regulated quality practices that govern how a medical device design comes together. Their job is to make sure the final product meets user needs, matches its intended use, and satisfies every specified requirement, with paperwork to prove it.
That's different from product development in general. Product development includes budgets, timelines, marketing plans, and go-to-market strategy. Design controls are the regulated subset focused strictly on documentation, structured review, and traceability.
A team can run an excellent product development process and still fail an FDA inspection if the design control documentation doesn't hold up.
Which Devices Are Covered
Design controls apply to:
- All Class II devices
- All Class III devices
- Specific Class I devices, including:
- Devices automated with software
- Tracheobronchial suction catheters
- Non-powdered surgeon's gloves
- Protective restraints
- Radionuclide applicator/teletherapy systems
A Short Regulatory History
Congress authorized preproduction design controls through the Safe Medical Devices Act of 1990. FDA implemented them through the 1996 Quality System Regulation, effective June 1, 1997. The upcoming QMSR, effective February 2, 2026, folds these same expectations into ISO 13485:2016.
Regulators didn't add this burden arbitrarily. FDA's own 1990 analysis of device recalls from October 1983 through September 1989 found that roughly 44% of the quality problems behind voluntary recalls came from design errors or deficiencies. Adequate design controls might have prevented those issues, according to FDA's findings cited in the 1996 Quality System Regulation rulemaking.
That figure is decades old, but it's the reason this framework exists at all: design mistakes are expensive, and they're preventable.
The 7-Phase Design Control Process
Design controls unfold as a continuum. Each phase generates evidence the next phase depends on. FDA does not mandate a waterfall methodology. Concurrent engineering and iterative development are acceptable, as long as the traceability holds together at the end.
Design and Development Planning
Before any design work starts, manufacturers must establish, document, and continually update a plan. This plan describes design activities, assigns responsibilities, defines interfaces between teams, and sets review checkpoints. Skip this step or let it go stale, and every downstream phase becomes harder to defend during an audit.
User Needs and Intended Use
User needs capture who the device is for, what problem it solves, and how clinicians or patients will actually use it. Here's where teams often stumble: confusing intended use with indications for use.
- Intended use: general purpose of the device, such as "to monitor blood glucose levels"
- Indications for use: specific clinical circumstances, such as "for use in adult patients with Type 2 diabetes in an outpatient setting"
Design Inputs
Design inputs translate user needs into objective, measurable requirements covering function, safety, performance, regulatory obligations, and human factors. Resolve any ambiguous or conflicting requirement before design output work begins. "Easy to use" is not a design input. "Setup completes in under 90 seconds by a novice user" is.
Design Outputs
Design outputs are the specifications, drawings, and labeling that become the preliminary Device Master Record. They must trace back to design inputs and carry enough detail for purchasing, production, and servicing.
Design Reviews
Outputs need documented, cross-functional design reviews at defined stages. Include an independent reviewer who was not directly responsible for that stage of work when practical. Catching a flawed requirement during a design review costs a fraction of what it costs after tooling is cut.
Design Verification and Design Validation
This is the distinction quality teams get tested on constantly:
| Question | Focus | Method |
|---|---|---|
| Did we build it right? | Verification: outputs meet inputs | Testing, inspection, analysis |
| Did we build the right thing? | Validation: device meets user needs | Real or simulated use, actual end users |
Verification is internal and objective. Validation puts the device in front of real users (clinicians, technicians, patients) under actual or simulated use conditions.
Design Transfer and Design Changes
Design transfer moves the approved design into production specifications: manufacturing instructions, inspection criteria, and process validation. After transfer, any design change still requires documented identification, review, verification or validation, and formal approval before implementation. A "quick fix" without this paper trail is exactly the kind of gap inspectors flag.
FDA QMSR and ISO 13485: How the Requirements Now Align
For years, US manufacturers maintained two parallel quality systems: one built around 21 CFR Part 820 for FDA, another built around ISO 13485:2016 for international markets. The QMSR final rule, published by FDA in February 2024 and effective February 2, 2026, closes most of that gap by incorporating ISO 13485:2016 directly into Part 820.
How the Clauses Map
The correspondence between the two frameworks is close to one-to-one:
| ISO 13485:2016 | Legacy 21 CFR 820.30 |
|---|---|
| 7.3.2 Planning | 820.30(b) |
| 7.3.3 Inputs | 820.30(c) |
| 7.3.4 Outputs | 820.30(d) |
| 7.3.5 Review | 820.30(e) |
| 7.3.6 Verification | 820.30(f) |
| 7.3.7 Validation | 820.30(g) |
| 7.3.8 Transfer | 820.30(h) |
| 7.3.9–7.3.10 Changes and design files | 820.30(i)–(j) |
One notable gap remains. ISO 13485's review clause does not retain the legacy 820.30(e) requirement for an explicitly independent reviewer. Manufacturers who valued that safeguard should keep it in their own SOPs even if the regulation no longer spells it out.
What Doesn't Fully Align
QMSR harmonization doesn't erase every international obligation. Manufacturers still need to track:
- MDSAP participation for audits accepted across the US, Canada, Australia, Brazil, and Japan
- EU MDR technical documentation requirements under Article 10(4), which cover post-market surveillance and PSUR elements beyond the core design control overlap
Manufacturers can now build largely one quality system to satisfy both FDA and most international regulators, cutting down on duplicated documentation. Confirm FDA's current transition guidance directly, since implementation details continue to get refined as the 2026 effective date approaches.
Design History File and Risk Management Integration
Building and Maintaining the Design History File
The Design History File (DHF) is the compiled record proving a design was developed according to the plan and applicable regulations. It should function as a living file, updated continuously, not something assembled the week before an audit.
A solid DHF typically includes:
- The design and development plan and its revisions
- Documented design inputs and their approval records
- Design outputs, specifications, and drawings
- Design review minutes, including attendee roles
- Verification and validation protocols and results
- Design transfer records and change history
Many teams start with a spreadsheet-based traceability matrix linking user needs to inputs, outputs, verification, and validation. That works fine early on. It tends to break down once a project scales past a handful of requirements: versions drift, links go stale, and nobody's confident the matrix reflects reality anymore.
Integrating ISO 14971 Risk Management
Risk analysis shouldn't wait until validation. It starts during design inputs, where hazard identification informs what requirements even need to exist, and continues through verification and validation as risk controls get tested.
ISO 14971:2019 lays out a full life-cycle risk process covering hazard identification, risk estimation, risk control, and post-production monitoring. FDA's own regulation states that design validation "shall include software validation and risk analysis, where appropriate."
Design controls and risk management are complementary, not interchangeable. A well-documented design control process doesn't substitute for a genuine ISO 14971 risk management file, and vice versa. Auditors check both.
Best Practices to Get (and Stay) Audit-Ready
Strong design controls come down to a handful of disciplined habits:
- Build cross-functional design review teams. Include an independent reviewer at each stage so problems surface before they compound downstream.
- Kill vague design inputs early. Words like "easy" or "durable" aren't testable. Rewrite them as measurable, verifiable criteria before output work starts.
- Treat the DHF as a running package, not a deadline scramble. Update it as work happens, not the week before a submission or inspection.
These habits sound simple, yet they're where most quality teams lose ground. Building traceability manually across spreadsheets and shared drives eats hours that should go toward actual design work.
That gap is what QMS Learning's upcoming Medical Device & Life Sciences QMS pathway is built to close. It bundles ISO 13485:2016, FDA 21 CFR Part 820, ISO 14971, and HIPAA training into one practitioner-built curriculum, backed by an AI Workbench that drafts design history file entries and risk management plans from your team's inputs.
The pathway opens for its pilot cohort in Q3 2026, with early design-partner access at reduced pricing. Quality and regulatory teams can book a 30-minute working demo to see how the Workbench and Manager Dashboard map to their standards.
Frequently Asked Questions
What are design controls?
Design controls are the structured, regulated quality processes used to plan, define, review, verify, validate, and transfer a medical device design. They create traceability from user needs through to the design history file.
What are the requirements for design controls in medical devices?
Manufacturers must establish and document planning, design inputs, design outputs, formal reviews, verification, validation, design transfer, change control, and a design history file. These elements originate in 21 CFR 820.30 and now map closely to ISO 13485 clause 7.3.
Does ISO 13485 cover design controls?
Yes. ISO 13485:2016 clause 7.3 (Design and Development) covers the same elements FDA requires under design controls, and the two frameworks are now closely aligned under the incoming QMSR.
What is the difference between design verification and design validation?
Verification confirms outputs meet inputs: did we build it right? Validation confirms the finished device meets user needs under real or simulated use conditions: did we build the right thing?
What is a Design History File (DHF)?
The DHF is the compiled record demonstrating that a device's design was developed according to the design plan and applicable regulations. It's the primary evidence auditors review to confirm design controls were actually followed.
Which medical devices are subject to design control requirements?
All Class II and Class III devices are covered, along with a short list of named Class I devices, including software-automated devices, tracheobronchial suction catheters, and non-powdered surgeon's gloves.
