The most complex and scrutinized requirement in ISO 13485. A complete guide to design planning, verification, validation, DHF structure, and FDA 21 CFR 820 alignment — with practical templates and real-world examples from 200+ medical device engagements.
By Jared Clark, JD, MBA, PMP, CMQ-OE, RAC — Updated February 2026
Design controls are the structured, documented methodology that ensures safety and effectiveness are engineered into a medical device from its earliest conceptual stages through manufacturing transfer. Defined in ISO 13485:2016 Clause 7.3 and mirrored in FDA 21 CFR 820.30, design controls represent the single most heavily scrutinized area during both certification audits and FDA inspections. When auditors open your quality system, the Design History File is typically the first document they request.
The rationale is straightforward: a medical device that is poorly designed cannot be saved by manufacturing excellence. If the design inputs are incomplete, the design outputs ambiguous, or the verification and validation activities insufficient, the resulting device carries inherent risks that no amount of process control can mitigate. Design controls exist to prevent these failures systematically — and to create an auditable evidence trail proving that every critical design decision was made deliberately, reviewed by qualified personnel, and verified against objective criteria.
For any organization that designs medical devices — whether manufacturing in-house or outsourcing production to a contract manufacturer — design controls are mandatory and non-negotiable. The obligation attaches to the design function, not the manufacturing function. A startup that designs a novel Class II diagnostic device and contracts its production to a third party is fully responsible for maintaining compliant design controls. This is a point that catches many first-time device companies off guard.
200+
Clients Served
100%
First-Time Audit Pass Rate
RAC
Regulatory Affairs Certified
The Design Control Framework
The classic waterfall diagram illustrates how each design control phase feeds into the next, with verification and validation forming the critical feedback loops that ensure design integrity.
User Needs
Intended use, user requirements, clinical need
Design Inputs
Functional, performance, safety, regulatory specs
Design Process
Development, prototyping, risk analysis
Design Outputs
Drawings, specs, DMR, labeling
Medical Device
Finished, production-equivalent units
Design Validation
"Did we build the right device?"
Simulated/actual use conditions
Design Verification
"Did we build the device right?"
Outputs meet inputs
Design Review
Systematic evaluation at each stage
Cross-functional gate review
Design Transfer
Ensure design can be correctly translated into production specifications — IQ/OQ/PQ process validation
Every design control process begins with a Design and Development Plan — a living document that defines the roadmap for bringing a medical device from concept to commercial release. ISO 13485 Clause 7.3.2 requires this plan to describe the design and development stages, the review, verification, and validation activities appropriate to each stage, and the responsibilities and authorities for design and development.
The design plan is not a static document created at project kickoff and filed away. It must be updated as the design evolves, as new information emerges, and as the project scope changes. Auditors will compare your original plan against the actual activities documented in your Design History File to verify that planning was maintained throughout the development lifecycle. Significant deviations between the plan and actual execution without documented justification are a common source of audit nonconformities.
Design inputs are the documented requirements that define what the medical device must do, how well it must perform, and what safety constraints it must satisfy. ISO 13485 Clause 7.3.3 requires that design inputs include functional and performance requirements, applicable regulatory requirements, applicable standards, risk management outputs, and information derived from previous similar designs. Every input must be complete, unambiguous, verifiable, and not in conflict with other inputs.
The quality of your design inputs directly determines the quality of everything downstream. Vague inputs produce vague outputs. Incomplete inputs produce gaps in verification. Conflicting inputs produce design decisions that cannot be traced to a clear rationale. The most common audit finding in design controls is inadequate design inputs — requirements that are too general to be objectively verified, or safety requirements that were not captured because the risk analysis was incomplete at the input stage.
Design outputs are the documented results of the design process. Per ISO 13485 Clause 7.3.4, design outputs must be provided in a form suitable for verification against design inputs, must be approved before release, and must identify the characteristics of the design that are essential for safe and proper use. Design outputs collectively form the basis of the Device Master Record (DMR) — the complete set of documents needed to manufacture the device.
A critical but frequently overlooked requirement: design outputs must reference or include acceptance criteria. Outputs that merely describe the device without defining measurable pass/fail criteria cannot be verified. For example, a drawing that specifies a dimension of 25mm +/- 0.5mm is a verifiable output. A drawing that simply shows "approximately 25mm" is not. This distinction matters enormously during both verification activities and manufacturing quality control.
Design reviews are formal, documented, systematic examinations of a design at defined stages to evaluate its adequacy, identify problems, and propose corrective actions. Per ISO 13485 Clause 7.3.5, design reviews must include representatives of functions concerned with the design stage being reviewed, as well as specialist personnel not directly responsible for the design. This independence requirement is essential — it prevents the design team from reviewing their own work without external scrutiny.
Design reviews are not status meetings, project updates, or informal discussions. They are decision-making gates where a cross-functional team evaluates whether the design has met its phase-specific criteria and is ready to advance to the next stage. Each review must have a defined agenda, documented attendees, recorded decisions, and assigned action items with responsible individuals and due dates. The meeting minutes become part of the Design History File and are scrutinized during audits. Auditors frequently check whether action items from design reviews were actually completed and verified before the design advanced.
A well-structured design review program typically includes four to six gates aligned with the development phases: Concept Review (is the clinical need validated?), Feasibility Review (is the design approach technically viable?), Design Freeze Review (are inputs complete and outputs defined?), Verification Review (do outputs satisfy inputs?), Validation Review (does the device meet user needs?), and Transfer Review (is the design ready for manufacturing?). The number and scope of reviews should be proportional to the device's risk classification and complexity.
Design verification confirms that design outputs meet design inputs. It answers the fundamental question: "Did we build the device right?" Per ISO 13485 Clause 7.3.6, verification must be performed in accordance with planned arrangements, and the results — including identification of the design being verified, the methods used, the acceptance criteria, and the statistical techniques applied — must be recorded.
Verification methods span a range of activities: inspections, dimensional analyses, bench testing, worst-case analyses, computational simulations, comparison to predicate devices, and biocompatibility testing per ISO 10993. Each design input must have a corresponding verification activity that objectively demonstrates the input has been met. This traceability — from input to output to verification — is the backbone of the Design History File and is one of the first things auditors check.
A critical distinction: verification testing may be performed on prototypes, engineering samples, or subassemblies — it does not necessarily require production-equivalent units. However, the test conditions and sample types must be documented and justified. If a verification test is performed on a prototype that differs materially from the final production design, that gap must be acknowledged and addressed, either through additional testing or a documented risk assessment.
Design validation confirms that the finished device meets user needs and its intended use under actual or simulated use conditions. It answers the question: "Did we build the right device?" Per ISO 13485 Clause 7.3.7, validation must be performed on representative product — typically initial production units or their equivalent. Validation cannot be performed solely on prototypes or engineering samples, because the purpose is to confirm that the production process faithfully reproduces the validated design.
Validation activities commonly include clinical evaluation (clinical studies, literature reviews, or equivalence analyses per MEDDEV 2.7/1), simulated-use usability testing (human factors validation per IEC 62366), biocompatibility testing on final-form devices, sterility validation (if applicable), shelf-life and packaging integrity testing, and software validation for devices with software components. The scope and depth of validation activities should be proportional to the device's risk classification — a Class III implantable device will require far more extensive validation than a Class I reusable instrument.
A common and significant audit finding is performing validation too early in the development process, before design outputs are finalized. If the device design changes after validation, the validation results may no longer be representative, and partial or full re-validation may be required. This is why the waterfall model positions validation after verification and after design outputs are frozen — validating a moving target is both wasteful and non-compliant.
Design transfer is the process of translating the finalized design into production specifications, manufacturing processes, and quality controls that ensure the device can be consistently and correctly manufactured. ISO 13485 Clause 7.3.8 requires that design transfer procedures ensure that the design outputs are verified as suitable for manufacturing before becoming final production specifications.
In practice, design transfer involves several critical activities: finalizing the Device Master Record (DMR) with all manufacturing drawings, material specifications, work instructions, and inspection procedures; completing process validation (Installation Qualification, Operational Qualification, and Performance Qualification — IQ/OQ/PQ) for all manufacturing processes whose outputs cannot be fully verified by subsequent inspection; establishing incoming inspection criteria for critical components and raw materials; training manufacturing personnel on new procedures; and verifying that initial production runs yield devices that conform to all design output specifications.
Design transfer is where many medical device companies stumble, particularly when development engineering and manufacturing engineering are separated by organizational boundaries, geographic distance, or outsourcing relationships. A design that works perfectly in the lab may fail to translate to the production floor if tolerances are too tight for manufacturing equipment, if material substitutions occur in the supply chain, or if assembly instructions are ambiguous. The design transfer phase exists precisely to catch and resolve these translation failures before commercial distribution begins.
Design changes are inevitable in any medical device development program. ISO 13485 Clause 7.3.9 requires that design changes be identified, documented, reviewed, verified, validated (as appropriate), and approved before implementation. The key word is "before" — implementing design changes without prior formal review and approval is one of the most serious violations an auditor can find, because uncontrolled changes to a medical device can directly impact patient safety.
Every design change must be evaluated for its impact on constituent parts, already-delivered products, risk management outputs, and existing verification and validation results. A change that appears minor — such as substituting a biocompatible adhesive for one with slightly different formulation — could have cascading effects on biocompatibility, sterilization compatibility, shelf life, and manufacturing process parameters. The change evaluation must consider all of these potential impacts and determine whether re-verification, re-validation, or updated risk analysis is required.
Change control discipline extends beyond the initial development phase into the entire commercial life of the device. Post-market design changes triggered by CAPA investigations, supplier changes, manufacturing process improvements, or regulatory requirement updates must follow the same formal change control process. The Design History File should contain a complete chronological record of every change, including the change request, impact assessment, approval decision, implementation evidence, and any re-verification or re-validation results.
The Complete Record
The DHF is the compilation of all records describing the design history of the finished medical device. Below is a recommended table of contents that satisfies both ISO 13485 and FDA expectations.
| Section | Document | ISO 13485 Clause |
|---|---|---|
| 1.0 | Design and Development Plan | 7.3.2 |
| 2.0 | User Needs Document | 7.3.3 |
| 3.0 | Design Input Requirements Specification | 7.3.3 |
| 4.0 | Design Output Documents (drawings, specs, BOM) | 7.3.4 |
| 5.0 | Design Review Meeting Minutes (all gates) | 7.3.5 |
| 6.0 | Design Verification Protocols and Reports | 7.3.6 |
| 7.0 | Design Validation Protocols and Reports | 7.3.7 |
| 8.0 | Design Transfer Records (IQ/OQ/PQ) | 7.3.8 |
| 9.0 | Design Change Orders (ECOs/DCOs) | 7.3.9 |
| 10.0 | Risk Management File (or reference to) | 7.1 / ISO 14971 |
| 11.0 | Traceability Matrix (inputs to outputs to V&V) | 7.3.3 / 7.3.6 / 7.3.7 |
| 12.0 | Biocompatibility, Sterilization, Clinical Evidence | 7.3.7 / applicable standards |
Important distinction: The DHF is not the same as the Device Master Record (DMR) or the Device History Record (DHR). The DHF documents the design history — how and why the device was designed as it was. The DMR contains the current production specifications — what manufacturing needs to build the device today. The DHR records the manufacturing history of each production lot or unit — evidence that a specific batch was built to the DMR. All three are required and serve distinct purposes.
Regulatory Alignment
With the FDA's QMSR incorporating ISO 13485 by reference, the alignment between ISO 13485 Clause 7.3 and FDA 21 CFR 820.30 is now essentially complete. A single, well-implemented design control system satisfies both frameworks.
The FDA's new Quality Management System Regulation (effective February 2026) directly references ISO 13485:2016 for design controls. Organizations with a compliant ISO 13485 design control process meet FDA expectations with minimal additional documentation. The historical gaps between 21 CFR 820.30 and ISO 13485 Clause 7.3 have been formally resolved.
Your design control outputs directly feed 510(k) premarket notification submissions. The performance data from design verification, the clinical evidence from design validation, and the risk analysis from your ISO 14971 file all become supporting evidence for your substantial equivalence argument. A well-organized DHF makes 510(k) preparation significantly faster and more defensible.
Devices with software components require additional design control rigor per IEC 62304 (software lifecycle processes) and FDA's guidance on software validation. Software-specific design inputs include software requirements specifications (SRS), software architecture documents, unit and integration test plans, and cybersecurity risk assessments. Software validation must address all levels of concern based on the software's safety classification.
Risk management per ISO 14971:2019 is not a parallel activity to design controls — it is inseparable from them. Risk analysis informs design inputs (what hazards must the design address?). Risk control measures become design outputs (how does the design mitigate identified risks?). Design reviews evaluate whether risk controls are adequate. Design verification confirms that risk controls function as intended. Design validation confirms that residual risks are acceptable under real-world use conditions. And risk monitoring continues throughout the product's post-market life, feeding new hazard information back into the design control process through formal change orders.
The practical implication is that your Risk Management File and your Design History File must be developed in parallel and cross-referenced extensively. Auditors expect to see bidirectional traceability: from each identified hazard to the design control activity that addresses it, and from each design decision to the risk analysis that informed it. Organizations that develop the risk management file after the design is complete — as a retrospective compliance exercise — invariably produce documents that auditors recognize as back-filled rather than genuinely integrated.
Design Inputs
Hazard identification and preliminary risk analysis define safety requirements that become mandatory design inputs.
Design Outputs
Risk control measures are incorporated into device specifications, labeling, and manufacturing procedures as design outputs.
Design Verification
Risk control verification confirms that each control measure functions as intended under specified test conditions.
Design Validation
Residual risk evaluation under actual or simulated use conditions confirms overall risk-benefit acceptability.
Post-Market Monitoring
Complaint data, field actions, and surveillance findings update the risk management file and may trigger design changes.
A medical device startup developing a novel in-vitro diagnostic instrument engaged our team to build their design control system from the ground up. We established the design plan, facilitated six design review gates, developed the complete verification and validation protocol suite, and assembled the DHF. The company achieved ISO 13485 certification on their first attempt with zero major nonconformities — and the DHF documentation directly supported their successful FDA 510(k) submission three months later.
View Case Studies →Design controls consulting is a core specialty within Certify Consulting. For a complete view of all ISO certification services — including ISO 9001, ISO 14001, ISO 27001, ISO 42001, and more — visit the hub.
Expert answers to the most common questions about ISO 13485 design controls, DHF requirements, and FDA alignment.
Design controls are the most complex and audit-critical requirement in ISO 13485. Schedule a free consultation to discuss your design control challenges, DHF structure, or FDA regulatory alignment strategy.
No commitment required. 200+ clients served with a 100% first-time audit pass rate.
JD, MBA, PMP, CMQ-OE, RAC
Jared Clark is an ISO 13485 consultant and medical device quality expert with deep expertise in design controls, risk management, and FDA regulatory compliance. His Regulatory Affairs Certification (RAC) from RAPS represents the gold standard credential for medical device regulatory professionals, qualifying him to bridge both ISO 13485 quality management system requirements and FDA regulatory strategy. With 200+ medical device clients and a 100% first-time audit pass rate, Jared has helped companies ranging from pre-revenue startups to established manufacturers build design control systems that withstand the most rigorous certification audits and FDA inspections.
Integrated quality management and FDA regulatory pathway support for 510(k) premarket notification submissions.
Complete quality management system implementation from gap analysis through successful certification audit.
The complete guide to ISO 13485:2016 medical device quality management system requirements and certification.