ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 13485 design controls are the structured requirements in clause 7.3 that govern how a medical device is planned, specified, reviewed, tested and handed over to production. Done well, they give you evidence that the device does what you claim and is safe.
This guide walks through all ten sub-clauses, explains the records auditors expect and offers a lean approach for small teams. It connects with risk management and the medical device file.
Free gap assessment
How much of ISO 13485 could you evidence today?
Score clauses 4 to 8, free, with the FDA QMSR and EU MDR duties kept separate so you can see what is the standard and what is the regulator.
Run the free ISO 13485 gap assessment → or View premium report sample
Clause 7.3 has ten sub-clauses: general, planning, inputs, outputs, review, verification, validation, transfer, control of changes and design and development files. Together they form the design control process.
The clause applies if you design or develop devices. If another party holds design responsibility, document that in your quality manual and keep control of the interfaces.
Read the wording in the ISO 13485:2016 page on iso.org and mirror its sequence in your procedure.
The general requirement is a documented procedure for design and development. The planning clause requires a plan that describes stages, the reviews, verification, validation and transfer activities appropriate to each stage and the responsibilities.
The plan should also address how design outputs trace to inputs and the methods that ensure traceability. Update the plan as the design evolves.
A one-page plan with a milestone table is enough for most small projects.
Inputs must include functional, performance, usability and safety requirements consistent with intended use, applicable regulatory requirements and standards, outputs of risk management and information from similar designs where appropriate.
Inputs must be reviewed for adequacy and approved. Requirements must be complete, unambiguous and capable of being verified.
Good ISO 13485 design controls start with a clear user needs list and a requirement specification that every later test points back to. Keep this in mind for every ISO 13485 design controls.
Outputs must meet input requirements, provide information for purchasing, production and service, contain or reference acceptance criteria and specify characteristics essential for safe and proper use.
Typical outputs are drawings, specifications, software code, labeling, packaging designs and manufacturing instructions.
Outputs must be approved before release, and records must show what they are. This becomes the bill of the device design.
Reviews are held at suitable stages according to the plan. Participants include representatives of functions concerned with the stage, and any specialists needed.
Records must show the design reviewed, participants, date, results and any actions. Keep reviews short and focused, with clear acceptance questions.
Typical review points are after inputs, after architecture, before verification, before validation and before transfer. This is where a ISO 13485 design controls is won or lost.
Verification confirms that outputs meet inputs. It uses documented plans with methods, acceptance criteria and sample sizes with a statistical rationale where applicable.
If the device connects to another device in its intended use, verification must include confirmation that requirements are met when connected. Records must show results and conclusions.
Typical activities are bench tests, inspections, analyses, software unit and integration tests and comparisons with similar designs.
| Sub-clause | Requirement in short | Typical record |
|---|---|---|
| 7.3.2 Planning | Stages, reviews, V&V, transfer, responsibilities | Design and development plan |
| 7.3.3 Inputs | Function, performance, usability, safety, regulatory | Requirements specification |
| 7.3.4 Outputs | Meet inputs, acceptance criteria, safe use characteristics | Specifications, drawings, code |
| 7.3.5 Review | Suitable stages with functions concerned | Review minutes |
| 7.3.6 Verification | Outputs meet inputs | Test protocols and reports |
| 7.3.7 Validation | Representative product meets intended use | Validation and clinical records |
| 7.3.8 Transfer | Outputs suitable for manufacturing | Transfer checklist |
| 7.3.9 Changes | Identify, review, verify, approve | Change records |
| 7.3.10 File | Records per device type or family | Design and development file |
Validation confirms that the device meets requirements for specified application or intended use. It must be performed on representative product, such as initial production units, batches or equivalents.
Validation includes clinical evaluation or performance evaluation as required by regulations, and it must be completed before release for use or delivery. Plans must cover methods, criteria and sample rationale.
Document clearly any justification for using a design that is not production-equivalent. Auditors judge your ISO 13485 design controls on exactly this point.
Transfer ensures that design outputs are verified as suitable for manufacturing before becoming final production specifications, and that production capability can meet product requirements.
Records must show results and conclusions. Link transfer to process validation, supplier qualification and training of production staff.
Late transfer planning is a common cause of delays in first production.
Changes must be identified and records maintained. Changes are reviewed, verified, validated where appropriate and approved before implementation.
The review must evaluate the effect of changes on constituent parts and product already delivered, on risk management inputs and outputs and on product realization processes.
Keep a change log linked to documents and risk records so the effect of each change is visible. Treat it as a standing rule for your ISO 13485 design controls.
For each device type or family, you must maintain a design and development file. It includes or references records generated to show conformity with requirements and records for design changes.
Many companies combine it with the medical device file required by clause 4.2.3. Organize it by stage so an auditor can follow the story.
See ISO 13485 medical device file for the overlap.
Risk management is required throughout product realization. Risk outputs feed design inputs, and risk controls become design outputs that must be verified.
Keep the risk file and requirements traceable in both directions. Our guide on ISO 14971 vs ISO 13485 explains how the standards relate.
A hazard without a verified control is a gap an auditor will find.
For software devices, design controls also touch lifecycle standards such as IEC 62304. See IEC 62304 vs ISO 13485 for how they fit together.
Usability requirements belong in design inputs, and usability validation belongs in validation records, not as an afterthought.
Software tools used in design and testing also need to be validated for their intended use.
Frequent mistakes include vague requirements, no traceability, reviews without records, validation on prototypes that differ from production and changes made without impact assessment.
Another mistake is creating the design file after the work is finished. Reconstructed records rarely match what really happened.
Keep the process light but real, and write records as you go.
The FDA Quality Management System Regulation, effective 2 February 2026, incorporates ISO 13485:2016, so clause 7.3 sits at the heart of US design control expectations. The QMSR vs ISO 13485 guide covers differences.
Under EU MDR, design documentation feeds technical documentation. See MDR technical documentation and the GSPR checklist for the European side.
One design file can serve both if you structure it with that in mind.
A design plan, requirements table, review minutes form, verification and validation protocol and report, transfer checklist and change form cover the clause.
The ISO 13485 Toolkit includes procedures and forms for each stage, which you can tailor to your device and team size.
Test the forms on a small project first, then adjust before applying them to the lead product.
Auditors usually sample a design project end to end, so choose a current one and keep its file tidy. The certification timeline shows where design evidence matters.
Pair this reading with the implementation guide to plan the full system.
If you are new to the standard, start with the startup roadmap.
Suppose a requirement says the device must deliver 5 mL within plus or minus five percent. The design output sets the pump specification and the acceptance test limits.
Verification runs the bench test against that limit, and the report cites the requirement ID. Validation then checks, with representative users, that the delivered dose supports the intended clinical use.
When every requirement has a matching output, test and result, the traceability matrix is simply a table that proves the story is complete.
The standard asks for evidence, not volume. A two-page review record with the right attendees and decisions beats a long document nobody reads.
Use templates with fixed headings, and store records with the design file so they are easy to retrieve during an audit.
That habit makes your approach to design controls easy to explain to any auditor.
Only if they design and develop products. Contract manufacturers who do not design may justify non-application of clause 7.3, if regulations permit.
Verification checks that outputs meet inputs. Validation checks that the device meets user needs and intended use, on representative product.
Detailed enough to record the design reviewed, participants, date, results and actions, and to show decisions were made.
The terms are used for the same concept in different frameworks. Under ISO 13485, clause 7.3.10 requires the design and development file.
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026