Design controls are the backbone of safe medical device development — and the single most cited area of nonconformance in FDA 483 observations and ISO 13485 audits alike. According to the FDA, design control violations accounted for approximately 20% of all Class II medical device recalls between 2013 and 2022. Yet despite their importance, clause 7.3 of ISO 13485:2016 remains one of the most misunderstood and inconsistently implemented sections of the standard.
After working with 200+ medical device companies at Certify Consulting, I've seen the same pitfalls repeat themselves: design inputs that are too vague to be verified, reviews that exist on paper but never catch real issues, and design history files that collapse under audit scrutiny. This guide cuts through the confusion and gives you a practical, audit-ready framework for implementing ISO 13485 clause 7.3 from the ground up.
What Are Design Controls and Why Do They Matter?
Design controls are the systematic procedures that govern how a medical device is conceived, developed, verified, validated, and transferred to production. ISO 13485:2016 clause 7.3 establishes requirements for this entire lifecycle, ensuring that the final device actually meets user needs and intended use — not just engineering assumptions.
The regulatory rationale is straightforward: a device that is built correctly but designed incorrectly is still a dangerous device. Design controls create a documented, traceable chain from patient need to finished product, so that every design decision can be justified, reviewed, and — if necessary — recalled with precision.
Under 21 CFR Part 820.30 (the FDA's Quality System Regulation), design controls have been mandatory for most device classes since 1997. ISO 13485:2016 clause 7.3 aligns closely with these requirements and is recognized globally by regulators including Health Canada, the EU MDR/IVDR framework, and TGA in Australia.
ISO 13485 Clause 7.3 at a Glance: The Eight Sub-Clauses
Clause 7.3 is not a single requirement — it's a structured framework with eight distinct sub-clauses, each addressing a specific phase or control point in the design lifecycle.
| Sub-Clause | Title | Core Requirement |
|---|---|---|
| 7.3.1 | General | Establish documented procedures for design and development |
| 7.3.2 | Design & Development Planning | Define stages, reviews, responsibilities, and interfaces |
| 7.3.3 | Design Inputs | Document functional, performance, safety, and regulatory requirements |
| 7.3.4 | Design Outputs | Document outputs that meet inputs; specify acceptance criteria |
| 7.3.5 | Design Review | Conduct systematic reviews at defined stages |
| 7.3.6 | Design Verification | Confirm outputs meet inputs through objective evidence |
| 7.3.7 | Design Validation | Confirm device meets user needs and intended use |
| 7.3.8 | Design Transfer | Ensure design can be reproduced in manufacturing |
| 7.3.9 | Design Changes | Control and evaluate all changes to approved designs |
| 7.3.10 | Design & Development Files | Maintain the Design History File (DHF) |
Note: ISO 13485:2016 uses clause 7.3.2 through 7.3.10; some editions number slightly differently. Always reference your current version.
Clause 7.3.2: Design and Development Planning — Where Most Projects Go Wrong
Planning is where design control failures are born. I've reviewed DHFs where the "plan" was a single-page Gantt chart with no mention of review gates, responsible parties, or interface management. That's not a plan — it's a schedule.
A compliant design and development plan under clause 7.3.2 must address:
- Design stages: Define discrete phases (e.g., concept, feasibility, development, verification, validation, transfer). Each stage should have defined entry and exit criteria.
- Review, verification, and validation activities: Map these to specific stages and assign responsible functions — not just individuals, since personnel change.
- Interfaces: If mechanical, software, and electrical teams are working in parallel, clause 7.3.2 requires you to manage the communication and handoff points between them.
- Regulatory strategy: Your plan should reference the applicable regulatory pathway (510(k), PMA, CE marking, etc.) because this affects what validation evidence you'll need.
Practical tip: Treat your design plan as a living document. ISO 13485 explicitly acknowledges that plans should be updated as design evolves. Auditors don't penalize you for revising a plan — they do penalize you for having a plan that doesn't reflect reality.
Clause 7.3.3: Design Inputs — The Foundation of Everything
Design inputs are the requirements your device must meet. Get these wrong and every downstream activity — outputs, verification, validation — is built on sand.
ISO 13485 clause 7.3.3 requires that design inputs include:
- Functional and performance requirements (what the device must do, how well it must do it)
- Safety requirements (applicable standards such as IEC 60601-1, ISO 14971 risk outputs)
- Regulatory and legal requirements (applicable directives, device classification, labeling requirements)
- Information from previous similar designs (including complaint history and post-market data)
- Usability requirements (IEC 62366-1 outputs feeding into design inputs)
The "Incomplete or Ambiguous" Trap
Clause 7.3.3 states that incomplete, ambiguous, or conflicting requirements shall be resolved. This is the most frequently cited design input deficiency in audits. Requirements like "the device shall be easy to use" or "the device shall be reliable" are not acceptable design inputs — they cannot be verified.
Every design input must be specific, measurable, and verifiable. Compare these examples:
| Weak Design Input | Strong Design Input |
|---|---|
| Device shall be easy to clean | Device shall withstand 500 cleaning cycles with hospital-grade disinfectant per AAMI TIR17 |
| Battery life shall be adequate | Device shall operate for minimum 8 hours on a single charge at 25°C ambient temperature |
| Device shall be biocompatible | All patient-contacting materials shall meet ISO 10993-1 biocompatibility requirements |
| Software shall be reliable | Software shall achieve IEC 62304 Class B compliance; system uptime ≥ 99.5% |
Citation hook: Every ISO 13485 design input must be specific, measurable, and verifiable — vague requirements like "easy to use" or "reliable" cannot be verified and will be flagged as nonconformances in any competent audit.
Clause 7.3.4: Design Outputs — Proving You Built What You Planned
Design outputs are the documented results of each design stage: drawings, specifications, software code, labeling drafts, manufacturing instructions, and test protocols. Clause 7.3.4 requires that outputs:
- Be expressed in a form that can be verified against inputs
- Include or reference acceptance criteria
- Specify characteristics essential for safe and proper use
- Be approved before release
A common mistake is conflating design outputs with final product outputs. Your CAD model is a design output. Your manufacturing work instruction is a design output. Your IFU is a design output. All of them must trace back to specific design inputs.
Clause 7.3.5: Design Reviews — More Than a Rubber Stamp
Design reviews are formal, documented evaluations conducted at defined stages. Clause 7.3.5 requires that reviews:
- Include representatives of functions concerned with the stage being reviewed
- Include at least one person who is independent of the design function being reviewed
- Be documented with results and any necessary actions
The independence requirement is critical and frequently misunderstood. The independent reviewer doesn't need to be external to your company — but they cannot be a member of the team whose work is being reviewed. A quality engineer, regulatory affairs specialist, or clinical expert often fills this role.
What auditors look for in design review records: - Minutes that reflect genuine discussion, not just approvals - Open action items tracked to closure - Evidence that the independent reviewer actually participated - Linkage between review findings and design changes
Clause 7.3.6 vs. 7.3.7: Verification vs. Validation — The Critical Distinction
This distinction trips up even experienced quality professionals. The ISO 13485 standard defines both, but the practical difference is best understood through a simple question:
- Verification asks: Did we build the device right? (Did outputs meet inputs?)
- Validation asks: Did we build the right device? (Does it meet user needs in actual use?)
| Factor | Verification (7.3.6) | Validation (7.3.7) |
|---|---|---|
| Question answered | Do outputs conform to inputs? | Does the device meet user needs? |
| Who performs it | Internal engineering/QA | Often requires representative users |
| Methods | Lab testing, analysis, inspection, similarity | Clinical/usability testing, simulated use |
| Timing | Throughout development stages | Typically on final or near-final design |
| Reference standard | Design inputs | User needs, intended use |
| ISO 13485 clause | 7.3.6 | 7.3.7 |
Citation hook: ISO 13485 clause 7.3.7 requires design validation to be performed on representative final product under defined operating conditions — prototype testing or preliminary builds generally do not satisfy this requirement without documented justification.
Validation must be performed under defined operating conditions and, where practicable, includes clinical evaluation. For software-enabled devices, this increasingly means formal usability validation per IEC 62366-1.
Clause 7.3.8: Design Transfer — The Bridge to Manufacturing
Design transfer is the process of ensuring that the design, as validated, can be consistently reproduced in production. This is where many companies stumble — particularly startups that develop a prototype in an R&D lab and then struggle to manufacture at scale.
Clause 7.3.8 requires documented procedures to ensure that design outputs are verified as suitable for manufacturing before becoming production specifications. Key activities include:
- Manufacturing process validation (IQ/OQ/PQ where applicable)
- Verification that production methods can achieve design specifications
- Documentation transfer: Ensuring all drawings, BOMs, and work instructions are production-ready
- First article inspection or pilot builds to confirm reproducibility
A strong design transfer checklist should verify that every design output has a corresponding manufacturing control — and that no design-stage workarounds were baked into production.
Clause 7.3.9: Design Changes — Controlling What Changes After Approval
No design is frozen forever. Clause 7.3.9 requires that all design changes be identified, documented, reviewed, verified/validated as appropriate, and approved before implementation.
Critically, organizations must evaluate the effect of changes on constituent parts and delivered devices. This means asking:
- Does this change affect safety or performance?
- Does this change require re-verification or re-validation?
- Does this change trigger a regulatory submission (e.g., a 510(k) supplement or CE mark update)?
- Does this change affect devices already in the field?
A tiered change control system — where minor changes follow a lighter review path and major changes require full design review — is both compliant and practical, provided the categorization criteria are clearly defined.
Clause 7.3.10: The Design History File (DHF) — Your Audit Lifeline
The Design History File is the master record that demonstrates your design was developed in accordance with the approved design plan. It is not a single document — it is a collection (physical or electronic) that includes:
- Design and development plans
- Design input records
- Design output records
- Design review meeting minutes and action logs
- Verification protocols and reports
- Validation protocols and reports
- Design transfer records
- Change control records
Industry benchmark: According to FDA inspection data, DHF deficiencies are among the top five most cited issues in device manufacturer inspections, with incomplete verification or validation records being the most common finding.
Your DHF doesn't need to be perfectly organized at all times during development — but it must be complete and accessible at design lock and beyond. I recommend establishing a DHF index early in development and maintaining it throughout the project.
Traceability Matrix: The Thread That Connects It All
A design traceability matrix (DTM) is not explicitly required by name in ISO 13485, but it is the most practical tool for demonstrating compliance. A robust DTM maps:
User Need → Design Input → Design Output → Verification/Validation Test → Result
Every user need should trace to at least one design input. Every design input should trace to at least one design output. Every design output should be covered by at least one verification or validation activity. Gaps in this matrix are gaps in your compliance — and gaps that auditors will find.
Common Design Control Nonconformances — And How to Prevent Them
Based on audit experience across 200+ clients, these are the design control failures I see most frequently:
- Vague or unverifiable design inputs — resolved by requiring SMART criteria for all inputs
- Verification protocols written after testing — resolved by requiring protocol approval before testing begins
- Validation performed on prototypes, not final product — resolved by clearly defining "representative final product" in your procedure
- Design reviews with no independent participant — resolved by including the independence requirement in your review procedure and attendance records
- DHF assembled at audit time rather than maintained throughout — resolved by assigning DHF ownership and conducting periodic DHF readiness reviews
- Design changes implemented without going through change control — resolved by training all engineering staff on change control triggers and escalation paths
- No traceability between inputs and verification tests — resolved by maintaining a living traceability matrix from day one
Integrating Clause 7.3 with Other ISO 13485 Requirements
Design controls don't operate in isolation. Clause 7.3 intersects directly with:
- Clause 7.1 (Planning of product realization): Design planning feeds into broader product realization planning
- Clause 7.4 (Purchasing): Components specified in design outputs drive supplier qualification requirements
- Clause 8.2.1 (Feedback): Post-market surveillance data should feed back into design inputs for next-generation devices
- ISO 14971:2019: Risk management outputs (hazard analysis, risk controls) are design inputs and must be traceable through the design file
- IEC 62304 (for software): Software development lifecycle requirements integrate directly with clause 7.3
For a deeper dive into how design controls interface with your broader QMS, see our guide on ISO 13485 clause 7.1 product realization planning and our overview of ISO 13485 risk management integration.
A Practical Implementation Roadmap for Clause 7.3
If you're building or rebuilding your design control system, here's a phased approach that works for most medical device companies:
Phase 1 — Foundation (Weeks 1–4) - Draft or update your Design and Development Procedure (SOP) - Define design stages and gate criteria specific to your device types - Create standard templates: Design Plan, Design Input Record, Design Output List, Traceability Matrix - Train design and engineering staff
Phase 2 — Populate (Weeks 4–12) - Apply templates to active development projects - Conduct a gap assessment on existing DHFs - Establish your DHF index structure (physical or EDMS) - Identify and close traceability gaps
Phase 3 — Verify & Sustain (Ongoing) - Conduct internal audits of design control compliance (at least annually) - Perform DHF readiness reviews at each design gate - Track design control metrics: open action items, change control cycle time, verification protocol approval timing - Feed post-market data into design input records for next-generation planning
Working with a Consultant on Design Controls
For many small and mid-size device companies, the challenge isn't understanding what clause 7.3 requires — it's having the bandwidth to implement it rigorously while also building the device. At Certify Consulting, our team has helped 200+ medical device companies establish design control systems that pass first-time audits and actually serve as useful engineering discipline — not just compliance paperwork.
If your design control system is untested, inherited, or about to face its first notified body or FDA audit, a targeted design controls assessment is often the highest-ROI investment you can make before that audit date.
Citation hook: Companies that invest in design control infrastructure early in product development consistently experience shorter regulatory submission review times and fewer post-market corrective actions — because the evidence base regulators require is already built into their development process.
Frequently Asked Questions About ISO 13485 Clause 7.3
Q1: Is a Design History File required for all medical devices under ISO 13485?
A: ISO 13485:2016 clause 7.3.10 requires a design and development file (equivalent to the FDA's Design History File) for all products that fall within the scope of the organization's design and development activities. If your organization has excluded design controls from its QMS scope (permissible under ISO 13485 if you don't perform design), the DHF requirement does not apply — but that exclusion must be justified and documented. Most device manufacturers cannot legitimately exclude clause 7.3.
Q2: What's the difference between design verification and process validation?
A: Design verification (clause 7.3.6) confirms that design outputs meet design inputs — it's about the product specification. Process validation (clause 7.5.6) confirms that a manufacturing process consistently produces product meeting specifications — it's about the manufacturing method. Both are required, but they answer different questions and occur at different points in the development lifecycle. Design verification typically precedes process validation in a compliant development sequence.
Q3: How detailed does a design review need to be under ISO 13485?
A: ISO 13485 clause 7.3.5 does not prescribe a specific duration or depth for design reviews, but records must demonstrate that a systematic evaluation occurred, that relevant functions participated, that an independent reviewer was present, and that results and action items were documented. A one-paragraph meeting summary with "approved" as the only output will not satisfy an auditor. Reviews should be substantive enough to catch real design issues — that's their purpose, not just their compliance function.
Q4: Can design validation be performed by internal staff, or must it be done externally?
A: ISO 13485 does not require external parties for design validation, but it does require that validation be performed under defined operating conditions using representative final product. For usability validation under IEC 62366-1, testing with representative users is required — these users typically cannot be members of the design team, but they don't need to be sourced from an external firm. For clinical validation, regulatory requirements (not ISO 13485 alone) may impose additional independence requirements.
Q5: When does a design change require re-validation under clause 7.3.9?
A: Any design change that affects a design output that was previously validated — particularly if it affects safety, performance, or intended use — should be evaluated for re-validation. ISO 13485 requires the impact of changes on constituent parts and delivered devices to be assessed. A documented risk-based evaluation of each change, recorded in your change control record, is the correct approach. Not every change requires full re-validation, but that determination must be justified with documented rationale, not assumed.
Summary: Design Controls as Competitive Advantage
Design controls under ISO 13485 clause 7.3 are not bureaucratic overhead — they are the engineering discipline that protects patients, enables regulatory approval, and builds the evidentiary foundation for your entire product lifecycle. Companies that implement them well move faster through regulatory submissions, experience fewer costly design changes late in development, and build DHFs that withstand FDA and notified body scrutiny on the first attempt.
The eight sub-clauses of clause 7.3 form a coherent system: plan your design process, capture inputs rigorously, produce verifiable outputs, review at gates, verify against inputs, validate against user needs, transfer to manufacturing with confidence, control every change, and maintain a complete file. When each link in that chain is strong, your design control system becomes a genuine quality asset — not just a compliance checkbox.
Last updated: 2026-03-06
Jared Clark, JD, MBA, PMP, CMQ-OE, CPGP, CFSQA, RAC is the principal consultant at Certify Consulting, specializing in ISO 13485, FDA QSR/QMSR, and medical device regulatory strategy. With 8+ years of experience and a 100% first-time audit pass rate across 200+ clients, Certify Consulting helps device companies build quality systems that work.
Jared Clark
Certification Consultant
Jared Clark is the founder of Certify Consulting and helps organizations achieve and maintain compliance with international standards and regulatory requirements.