Webinar: From Paper to eIFU: Preparing for the Next Global Step in Medical Device Compliance
Medical Device Design Control: A Complete Guide to ISO 13485 & FDA Requirements
Design control is the foundation of medical device regulatory compliance. Under FDA 21 CFR Part 820.30, every manufacturer must establish and maintain procedures for the planning, implementation, and control of the design of each device. ISO 13485:2016 Section 7.3 contains equivalent requirements. Design control is not a one-time compliance exercise—it is a structured process that must be applied to new device designs, design modifications, and design changes throughout the device's lifecycle.
The purpose of design control is to ensure that devices are designed to meet user needs, are safe and effective, can be reliably manufactured, and comply with regulatory requirements. When design control is weak or incomplete, devices may fail in the field, patients may be harmed, and the manufacturer faces recalls, warning letters, and potential legal liability. Conversely, well-executed design control demonstrates to regulators and customers that the device was developed systematically with appropriate risk management and verification.
What Is Design Control and Why Is It Mandatory?
Design control is the process of systematically planning, developing, testing, and verifying a medical device design before it is released for manufacturing and distribution. It requires defining what the device must do (design inputs), determining how the device will work (design outputs), verifying that the outputs meet the inputs (design verification), validating that the device works in actual use conditions (design validation), and ensuring that the design can be reliably manufactured (design transfer). This end-to-end approach ensures that no critical requirement is overlooked and that each design decision is documented and traceable.
The FDA considers design control to be essential to device safety and effectiveness. Products developed without formal design control are at high risk for design defects, unintended uses, or manufacturing problems that emerge after commercialization. During inspections, the FDA specifically examines design control documentation to assess whether the manufacturer has a disciplined, documented process for device development.
Design Control Under 21 CFR Part 820.30 and ISO 13485 Section 7.3
Both FDA and ISO 13485 regulations require design control, and the underlying principles are nearly identical, though FDA regulations are more prescriptive. FDA's 21 CFR 820.30 specifies eight design control elements that must be addressed: design planning, design inputs, design outputs, design reviews, design verification, design validation, design transfer, and design changes. ISO 13485 uses similar concepts but grants manufacturers more flexibility in how they structure and document their process.
For manufacturers seeking compliance with both standards—which includes most companies that export internationally—FDA's prescriptive approach provides a good roadmap. A design control process that satisfies FDA's eight elements will typically satisfy ISO 13485 requirements. The key is that the manufacturer must document the approach, show that it was followed, and maintain complete records.
The Eight Elements of the Design Control Process
1. Design and Development Planning
Design control begins with planning. A design plan (also called a design protocol or design plan document) must establish the scope of the design project, identify the team members and their responsibilities, define the design timeline and milestones, specify the risk management approach that will be used, and establish design control procedures that will be followed. The plan should also define the design inputs, design review schedule, verification and validation strategies, and the criteria for design transfer. The design plan is the roadmap that ensures all stakeholders understand the approach and that no design step is skipped.
2. Design Inputs
Design inputs are the documented requirements that the device must meet. These include functional requirements (what the device must do), performance requirements (how well it must do it), safety and regulatory requirements (what standards and regulations apply), and user needs (what problems does the device solve). Design inputs must be documented in clear, measurable, and unambiguous language. Requirements that cannot be measured or verified should be refined until they are objective. Design inputs must also be reviewed and approved by qualified individuals before design development begins.
3. Design Outputs
Design outputs are the results of design development—drawings, specifications, software code, and procedures that define how the device is constructed and what it does. Every design output must be reviewed and approved before it is used. Critically, design outputs must be traceable back to design inputs, meaning that each design output can be linked to the input requirement it addresses. This traceability ensures that all requirements are met and that there are no design outputs that are not supported by a requirement.
4. Design Reviews
Formal design reviews are required at appropriate stages of development—typically at least at the conceptual design, design development, and pre-commercialization stages. Design reviews are meetings where the design team presents their work to qualified reviewers who assess whether the design is technically sound, meets all requirements, addresses identified risks, and is ready for the next phase. Design reviews must include participants from multiple disciplines (design, quality, manufacturing, regulatory) and must be documented with minutes, issues identified, and resolution plans.
5. Design Verification
Design verification confirms that the design outputs (drawings, specifications, code) correctly implement the design inputs (requirements). Verification answers the question: Did we build what we said we would build? Verification activities include testing prototypes, simulating performance, reviewing calculations, and analyzing designs against specifications. Verification must demonstrate that the design outputs are correct and that any assumptions made during design are valid.
6. Design Validation
Design validation confirms that the device, as manufactured, will perform safely and effectively in actual use conditions. Validation answers the question: Does this device do what it is intended to do, and is it safe to use? Validation typically includes human factors testing, biocompatibility testing, sterilization validation, shelf-life testing, electrical safety testing, and clinical trials or performance testing in representative use conditions. Unlike verification, which tests against specifications, validation tests the actual manufactured device in real-world scenarios.
7. Design Transfer
Design transfer is the process of moving the design from development into manufacturing. It ensures that manufacturing can reliably produce the device to the design specifications established during development. Design transfer includes scaling from prototype to full production, validating manufacturing processes, qualifying suppliers, training manufacturing personnel, and establishing acceptance criteria for manufactured devices. Design transfer is complete when manufacturing can consistently produce devices that meet design specifications with documented evidence.
8. Design Changes
After commercialization, design changes may be necessary for improvements, corrections, or responses to field issues. Every design change must go through a change control process that documents the reason for the change, assesses the impact on safety and effectiveness, determines what re-testing or re-validation is needed, and ensures that all affected documentation is updated. Design changes must be evaluated using the same rigor as the original design, not as shortcuts.
Design Control Documentation: What You Need to Maintain
Design control requirements mandate maintaining a Design History File (DHF) that documents the entire design and development process. The DHF must contain all design control records, from initial planning through design transfer and into post-market phase. Key documents that must be included in the DHF are listed below. These documents must be organized, indexed, and maintained with appropriate version control and approval records.
Design plan or protocol defining the design development approach and responsibilities
Design input specifications with documented approval
Design output documentation (drawings, specifications, software code, algorithms) with traceability to design inputs
Risk management file demonstrating that design hazards have been identified and controls implemented
Design review meeting minutes, including pre-design, interim, and final reviews
Design verification test plans, test reports, and results
Design validation protocols, testing results, and biocompatibility/sterilization/clinical data
Design transfer records showing that manufacturing can reliably produce the device
Design change records for any modifications made after initial commercialization
21 CFR Part 820.30 vs. ISO 13485 Section 7.3: Key Differences
While both FDA and ISO 13485 require design control, there are some notable differences in how each regulation frames the requirements. FDA regulations are more prescriptive, explicitly naming the eight design control elements and requiring that manufacturers address each one. FDA also explicitly requires that design changes be addressed with the same rigor as the original design. ISO 13485 uses more general language, requiring that manufacturers establish procedures for design and development but allowing more flexibility in how the process is structured.
A second difference is terminology: FDA uses the term 'Design History File' (DHF) while ISO 13485 refers to 'design and development records.' The concept is equivalent—both require comprehensive documentation of the design process. FDA regulations also more explicitly address design transfer, human factors, and software as medical device components, though ISO standards cover these through referenced standards (IEC 62304 for software, ISO 14971 for risk management).
Practically speaking, a design control process that complies with FDA's eight elements and maintains a comprehensive DHF will satisfy ISO 13485 requirements as well. Many international device manufacturers use FDA requirements as their baseline, as FDA's prescriptive approach leaves no ambiguity about what must be done.
Most Common Design Control Failures in FDA Inspections
The FDA has published guidance on the most frequently observed design control deficiencies during facility inspections. One of the most common findings is inadequate design input documentation. Some manufacturers document their design inputs informally, fail to obtain approval before design begins, or do not clearly define performance requirements in measurable terms. Without clear, approved design inputs, it is impossible to verify that the device design is correct.
A second major deficiency is incomplete design verification and validation. Some companies conduct only limited testing, skip validation in actual use conditions, or conduct verification and validation only on early prototypes rather than on production-representative devices. FDA expects that design verification confirms the design is correct and that design validation demonstrates the device works as intended in representative use conditions.
Design inputs not documented, not approved, or stated in vague, unmeasurable language
No traceability between design inputs and design outputs, making it unclear which requirements are met by the design
Design reviews conducted informally without documented minutes, attendance records, or resolution of identified issues
Design verification limited to prototype testing without evidence that production devices continue to meet specifications
Design validation not conducted in actual use conditions or with representative users
Risk management not integrated into design control; hazards identified but not linked to design requirements and controls
Design changes not subjected to the same rigor as original design; changes made without impact assessment or re-testing
💡 Best practice: Treat design control as a process, not a documentation exercise. Engage the full development team—design, quality, manufacturing, and regulatory—in each design stage. Document decisions as they are made, not months later. Maintain clear traceability between design inputs, outputs, verification, and validation so that inspectors can quickly understand your design reasoning.
Request a demo and get started today.
See how Matrix Req connects your requirements, risks, tests, and documentation in one platform.
Thank you
A member of our team will be in contact within 48 hours.