ISO 13485 Clause 7.3: Design and Development (Design Controls)
Clause 7.3 gaps turn into audit findings fast
ISO 13485 Clause 7.3 is not about collecting design documents. It is about proving that design and development were controlled from planning through transfer and change control.
Most teams do not fail because they have no DHF. They fail because inputs, outputs, reviews, verification, validation, and transfer do not trace cleanly under audit.
Use this page to identify your design-control gaps, choose the right implementation path, or request direct support.
Use this if you need one aligned design-control system covering planning, inputs, outputs, review, verification, validation, transfer, and change control.
Design Controls Execution System (ISO 13485 Clause 7.3)
ISO 13485 Clause 7.3: Design Controls, DHF Requirements, Verification, Validation, Transfer, and Design Change Control
ISO 13485 Clause 7.3 is the medical device design and development clause that auditors use to test whether your design control system is actually working. It is reviewed as a trace: design and development planning, approved design inputs, controlled design outputs, formal design review, design verification, design validation, design transfer, and controlled design changes. A strong Design History File (DHF) is not just a document set. It is objective evidence that your development process is controlled, traceable, and audit-ready.
What this page answers
This page is designed to answer the questions buyers, QA/RA teams, startup founders, and auditors usually have around ISO 13485 Clause 7.3: what design controls require, what a DHF should contain, what the difference is between design verification and design validation, how design transfer should be evidenced, and how design changes should be assessed and controlled.
What ISO 13485 Clause 7.3 actually covers
ISO 13485 Clause 7.3 covers design and development controls for medical devices. In practical terms, it requires a company to prove how product requirements were defined, how those requirements were translated into outputs, how review decisions were made, how design verification and design validation were executed, how the released design was transferred into production, and how later design changes were assessed and controlled.
For most medical device businesses, Clause 7.3 is one of the highest-risk audit areas because it connects product realization, risk management, document control, traceability, technical evidence, and change control. If the trace between those elements is weak, auditors usually find the weakness quickly.
Design and development planning
Define stages, responsibilities, interfaces, review gates, design and development deliverables, verification and validation strategy, and decision criteria before development accelerates.
Design inputs
Capture intended use, user needs, performance requirements, safety requirements, regulatory requirements, applicable standards, and risk control requirements as controlled design inputs.
Design outputs
Create controlled specifications, drawings, bills of material, software requirements, labeling, test methods, and other outputs that are sufficient for manufacture, inspection, release, and service where relevant.
Design review
Run formal design reviews with the right functions involved, clear gate decisions, assigned actions, due dates, closure logic, and objective evidence that issues were resolved properly.
Design verification
Show that design outputs meet design inputs using defined methods, acceptance criteria, traceable evidence, controlled protocols, and defensible records generated before or during testing.
Design validation
Show that the final device meets intended use under defined use conditions using representative product, relevant users or use environments where needed, and a clear technical rationale.
Design transfer
Prove that the approved design became controlled production reality through DMR alignment, production-facing specifications, inspection criteria, training, release readiness, and first-build or implementation evidence.
Design changes
Control design changes through formal impact assessment across design outputs, design verification, design validation, risk, labeling, suppliers, production documents, and released configurations.
What auditors usually ask for first in ISO 13485 Clause 7.3
DHF structure and completeness
Auditors often start by checking whether the Design History File is a real design control system or just a folder of disconnected documents. They look for structure, logic, completeness, and traceability.
Design planning, inputs, and outputs
They sample whether planning was defined and followed, whether design inputs were approved and controlled, and whether design outputs are sufficiently detailed to support manufacturing, inspection, and release.
Design verification, design validation, and claims support
They frequently select one or more claims, intended-use assumptions, or risk controls and ask for the exact design verification or design validation evidence that supports them.
Design transfer and design change control
A common audit route is to take a recent design change and follow it into updated outputs, risk review, re-verification or re-validation decisions, and production-facing updates.
What makes Clause 7.3 fail in real audits
Traceability that looks good but cannot execute
A traceability matrix exists, but the team cannot clearly connect approved design inputs to outputs and then to objective design verification or design validation evidence.
Design reviews that are only meetings
Meeting notes record discussion but do not show formal decisions, accountable actions, closure dates, or evidence that open items were properly addressed.
Verification without solid acceptance criteria
Testing exists, but criteria were vague, retrospective, copied from elsewhere, or not linked back to controlled design inputs.
Validation that is not representative
Evidence exists, but the units, users, environments, or use conditions do not support the intended use or claims being made.
Weak design transfer evidence
The DHF appears complete, but manufacturing, inspection, labeling, or training records are still outdated, uncontrolled, or inconsistent with the released design.
Informal design changes
Changes were implemented through email, chat, or team discussion without formal impact assessment, risk review, or clear re-verification and re-validation logic.
Design verification vs design validation in ISO 13485
Design verification
Design verification answers the question: did we design the device correctly against defined requirements? It compares design outputs to design inputs and should use pre-defined methods, acceptance criteria, and objective evidence.
Design validation
Design validation answers the question: did we design the right device for its intended use? It focuses on whether the final device performs appropriately under actual or simulated use conditions with representative product.
What a good Design History File should demonstrate
A strong Design History File should show more than document existence. It should demonstrate development logic, controlled decision-making, traceability, objective technical evidence, and a clear link between planning, requirements, outputs, design review, verification, validation, transfer, and post-release changes.
- Approved design and development plan
- Controlled design inputs and design outputs
- Formal design review evidence and closure records
- Design verification and design validation records
- Design transfer evidence into production or release controls
- Controlled design change history with impact assessment
Shop by design-control gap
DHF structure, index logic, and audit readiness
Choose this if your main problem is scattered records, weak file structure, poor traceability, or a Design History File that will not hold up well under auditor sampling.
End-to-end design controls execution
Choose this if you need design planning, inputs, outputs, review, verification, validation, transfer, and design changes aligned into one working ISO 13485 Clause 7.3 operating system.
Risk controls, design controls, and validation linkage
Choose this if risk controls are not clearly flowing into design inputs, outputs, verification, validation, design transfer, and design change decisions.
Design-only or R&D-focused system buildout
Choose this if your business is design-led and you need a broader ISO 13485 operating structure around R&D instead of isolated templates.
Related pages for deeper implementation
Use these related pages if you want to connect Clause 7.3 to the wider ISO 13485 system, including product realization, documentation requirements, management responsibility, resources, services, and pricing.
FAQ: ISO 13485 Clause 7.3, DHF, verification, validation, and design transfer
What is ISO 13485 Clause 7.3?
ISO 13485 Clause 7.3 is the design and development section of the medical device quality management system. It covers design planning, design inputs, design outputs, design review, design verification, design validation, design transfer, and design change control.
What is a DHF in ISO 13485?
A Design History File, or DHF, is the design and development evidence set showing that the device was developed in accordance with the approved design plan and applicable design control requirements.
What is the difference between design verification and design validation?
Design verification shows that design outputs meet design inputs. Design validation shows that the final device meets intended use under defined use conditions using representative product and appropriate evidence.
What do auditors ask for first in Clause 7.3?
Auditors usually ask for the DHF structure, design and development plan, approved design inputs, controlled design outputs, design verification and design validation evidence, and at least one design change with impact assessment and downstream updates.
Why does design transfer fail so often?
Design transfer often fails because the DHF appears complete while production, inspection, labeling, training, or release records do not reflect the approved final design.
How do design changes create major nonconformities?
Design changes create major findings when impact assessment is weak, risk review is incomplete, re-verification or re-validation decisions are missing, or updated outputs do not flow into production-facing records and released configurations.
How do I prepare for an ISO 13485 design controls audit?
Prepare by making sure your design and development plan, design inputs, design outputs, design review records, design verification, design validation, design transfer evidence, and design change controls are complete, approved, controlled, and traceable.
Design Controls Gap Checker: Assess Whether Your Design and Development System Is Complete, Traceable, and Audit-Ready
This design controls gap checker is built for medical device teams that need a serious view of whether their ISO 13485 Clause 7.3 design and development system will hold up in audit. Assess the maturity of your design planning, inputs, outputs, traceability, design review, verification, validation, design transfer, DHF structure, and design change control, then move into the right solution path for remediation, implementation, or audit readiness.
What this tool checks
Design controls usually fail for one of five reasons: planning is weak, design inputs and outputs do not trace cleanly, design review decisions are poorly evidenced, verification and validation are not tightly linked to requirements and claims, or design transfer and change control do not hold together operationally. This tool is designed to catch those high-risk patterns early.
Who this is for
- Medical device startups building a first design control system
- QA/RA teams preparing for ISO 13485 or surveillance audits
- Businesses with fragmented or inherited DHF structures
- Teams with weak verification, validation, or traceability logic
- Companies needing design transfer or design change remediation
Complete the design controls diagnostic
Answer every question to generate a full design controls maturity score, domain breakdown, priority remediation view, and best-fit next step.
Get Audit-Ready in 4 Weeks
Browse our Design & Development Product Collection
-
Free DHF Audit Checklist & Index Template
Regular price $0.00 USDRegular price -
ISO 14971 Risk Management System
Regular price $599.00 USDRegular price -
ISO 13485 QMS-in-a-Box — Design-Only / R&D Entity
Regular price $1,290.00 USDRegular price -
Design Controls Execution System (ISO 13485 Clause 7.3)
Regular price $499.00 USDRegular price
Need Clause 7.3 fixed end-to-end, not just explained?
If your team is preparing for ISO 13485 certification, repairing design-control gaps, cleaning up design changes, or tightening DHF and transfer logic before scale, Clause 7.3 usually needs more than scattered templates. It needs a working structure that connects requirements, risk, design records, V&V, production handoff, and change control into one defendable system.
Use the products above if you already know the gap. Use our services if you need design controls built, repaired, or integrated properly into the rest of your QMS.