What you will learn
By the end of this topic, you should be able to explain the purpose of ISO 13485, describe every part of Clause 7.3, distinguish verification from validation, recognise the evidence expected from a controlled development process and identify common weaknesses before they become audit or submission problems.
What ISO 13485 is—and is not
ISO 13485:2016 specifies requirements for a quality-management system used by organisations involved in medical devices and related services. It covers far more than product design: management responsibility, resources, purchasing, production, measurement, feedback, complaints, corrective action and other lifecycle controls all sit within the same system.
It is a management-system standard, not a product design specification. It tells an organisation which controlled processes and records it must establish; it does not tell an engineer what circuit, software architecture, material or mechanism to choose.
A certified ISO 13485 quality-management system can provide confidence in how an organisation works, but it does not by itself show that a particular device is safe, performs as intended or may legally be placed on a market.
Why design controls matter
Design controls provide the structure for turning an intended medical purpose into a device that can be reviewed, tested, manufactured and supported. They make important decisions visible and connect claims and needs to requirements, design outputs, risks and evidence.
Control uncertainty
Plans, reviews and staged evidence make technical and regulatory uncertainty explicit while it can still be managed.
Prevent omission
Traceability helps reveal needs, risks or requirements that have no design response or objective evidence.
Support reproducibility
Controlled outputs and transfer activities ensure the approved design can be produced consistently.
Enable safe change
Configuration records and impact assessment allow teams to understand what a change affects and what must be repeated.
Design controls do not require a rigid waterfall. Iteration is normal. The requirement is that evolving inputs, outputs, risks, reviews and evidence remain planned, reviewed, approved and traceable.
Clause 7.3 in practical terms
The subclauses form a connected system. None should be treated as an isolated document requirement.
General
Establish a documented and controlled design-and-development process appropriate to the device and organisation.
Typical evidence: Design-control procedure and defined project records.Planning
Define stages, reviews, verification, validation, transfer, responsibilities, interfaces, resources and traceability—and keep the plan current.
Typical evidence: Design and development plan, responsibilities, milestones and review strategy.Inputs
State the functional, performance, usability, safety and regulatory requirements the design must satisfy, including relevant risk-control requirements.
Typical evidence: Approved, testable and non-conflicting design inputs with source traceability.Outputs
Describe the resulting design clearly enough to verify it and to support purchasing, production, servicing and safe use.
Typical evidence: Specifications, drawings, code, formulae, acceptance criteria, labelling and production information.Review
At planned stages, assess whether the design can meet requirements, identify problems and agree actions with the right functions represented.
Typical evidence: Review agenda, inputs, participants, decisions, actions and closure records.Verification
Confirm through objective evidence that design outputs meet the corresponding design inputs.
Typical evidence: Approved methods and acceptance criteria, protocols, results, reports, deviations and traceability.Validation
Confirm that the resulting device fulfils user needs and intended use under actual or representative conditions before release.
Typical evidence: Validation plans and reports, representative product rationale, usability and clinical or performance evidence.Transfer
Ensure design outputs are suitable for manufacturing and that production capability can consistently realise the approved design.
Typical evidence: Transfer plan, manufacturing specifications, process qualifications, training and readiness records.Changes
Identify, review, verify or validate and approve changes; evaluate their effects on risk, constituent parts, production and delivered devices.
Typical evidence: Change request, impact assessment, approvals, updated traceability and resulting verification or validation.Design and development file
Maintain the records needed to demonstrate conformity with the design-and-development requirements for each device type or family.
Typical evidence: A controlled file or indexed collection that identifies the applicable records and change history.The design-control evidence chain
Good traceability is more than a matrix assembled before an audit. It should allow the team to navigate both forwards and backwards through the design logic.
Risk management crosses this chain. Hazards can generate design inputs; risk controls are implemented as outputs; implementation and effectiveness are verified; validation may expose new use-related risks; production and post-market information can trigger changes.
Using design controls well
- Define intended purpose, users, environments and claims before detailed requirements stabilise.
- Write inputs that are necessary, unambiguous, testable and traceable to their sources.
- Plan verification and validation while requirements and architecture are being developed.
- Use reviews to make decisions and resolve risk—not simply to collect signatures.
- Control interfaces between system, hardware, software, mechanics, packaging, manufacturing and suppliers.
- Identify the precise product configuration used for every important test or review.
- Plan transfer early enough for production knowledge to influence the design.
- Assess changes against requirements, risks, previous evidence, production and devices already supplied.
A competent person who was not part of the project should be able to follow the records and understand what was intended, what was decided, why it was acceptable, what was tested and which product configuration the conclusion applies to.
Regulatory context
United States
The FDA Quality Management System Regulation became effective on 2 February 2026 and incorporates ISO 13485:2016 by reference. Under 21 CFR 820.10(c), Clause 7.3 applies to manufacturers of Class II and Class III devices and specified Class I devices, including devices automated with computer software. Other FDA requirements continue to apply alongside the incorporated standard.
European Union
The EU MDR and IVDR require manufacturers to establish and maintain a quality-management system covering matters such as regulatory strategy, applicable safety and performance requirements, management responsibility, risk management, clinical or performance evaluation, product realisation, supplier control, post-market surveillance and change management. ISO 13485 is commonly used as the framework for implementing and demonstrating many of these controls, but the legal requirements remain the MDR or IVDR.
Other markets
ISO 13485 is widely recognised internationally, but its regulatory role, applicable edition, certification expectations and additional national requirements vary. The market strategy must therefore identify what applies to the particular device and jurisdiction.
Common misconceptions
“Design controls are Quality’s paperwork.”
No. Engineering and cross-functional teams create the decisions and evidence. Quality helps define and assure the controlled process.
“A passed test proves the device is validated.”
No. Verification addresses design inputs. Validation addresses user needs and intended use using representative product and conditions.
“The design file must be one document.”
No. It may be an indexed collection across controlled systems, provided the applicable records and relationships can be reliably identified.
“A design review is a presentation meeting.”
No. It is a planned, documented and appropriately independent evaluation of readiness, adequacy, problems and actions.
“Design transfer happens after development.”
No. Manufacturing, supplier, inspection and service considerations should influence requirements and design well before formal transfer.
Seven things to remember
- ISO 13485 governs the quality system; it does not prescribe the technical design.
- Clause 7.3 is a connected evidence system, not a collection of templates.
- Plan the development process and keep the plan current.
- Connect needs, risks, inputs, outputs and evidence through useful traceability.
- Verification asks whether outputs meet inputs; validation asks whether the device fulfils user needs and intended use.
- Transfer and change control are integral parts of design control.
- Certification supports confidence in the system but does not approve the product.
Authoritative references
- ISO 13485:2016 — Medical devices — Quality management systems — Requirements for regulatory purposes
- ISO overview: who ISO 13485 is for
- US FDA Quality Management System Regulation
- 21 CFR 820.10 — Requirements for a quality management system
- US FDA — QMSR Design and Development
- Regulation (EU) 2017/745 on medical devices