Design and development controls (Clause 7.3) are where most product risk is created and controlled. For diagnostics and software companies, they are also the source of much of the evidence regulators review.
The design control process
- Planning: a documented plan with stages, reviews, responsibilities, verification and validation activities, and how traceability will be maintained
- Inputs: functional, performance, usability and safety requirements, applicable regulations and standards, risk management outputs and lessons from previous designs
- Outputs: specifications, drawings, software, labeling and manufacturing information that can be verified against the inputs
- Reviews: planned, cross-functional checkpoints where the design is assessed and actions are recorded
- Verification: objective evidence that outputs meet inputs, such as testing, inspection and analysis
- Validation: evidence that the finished device meets user needs and its intended use, including clinical or performance evaluation and usability validation
- Transfer: moving the design into production or release in a controlled, reproducible way
- Changes: evaluating, verifying, validating and approving design changes, including their effect on risk and regulatory status
The design history file
ISO 13485 requires a design and development file for each device type. It should tell the complete story: what you set out to build, why, how you verified and validated it, and how you managed every change. A traceability matrix linking user needs, requirements, risks, tests and results is the backbone of a good file.
Design controls for agile software teams
Design controls do not require a waterfall process. Agile teams can meet the requirements by defining their lifecycle in procedures, treating each release as a controlled design output, capturing requirements and risk analysis in the backlog, automating verification and keeping traceability in their tools. The key is that the evidence exists, is reviewed and is approved before release.
Verification versus validation
| Verification | Validation | |
|---|---|---|
| Question | Did we build the device right? | Did we build the right device? |
| Compared against | Design inputs and specifications | User needs and intended use |
| Typical evidence | Test reports, code reviews, inspections, analytical performance studies | Usability studies, clinical or performance evaluation, simulated use |
Common pitfalls
- Design inputs that are vague, untestable or missing safety requirements
- Validation performed on prototypes that differ from the released product
- Risk management run separately from design rather than feeding it
- Changes made after release without impact assessment
- Traceability rebuilt at the end instead of maintained along the way
ISO 13485 guide
Overview · Understanding the Standard · Design and Development Controls · Risk Management (ISO 14971) · CAPA, Complaints and Feedback · Suppliers and Outsourcing · Software, Cybersecurity and AI · The Certification Roadmap · ISO 13485 and the FDA QMSR
Need help? Salto Partners guides diagnostics, genomics and medical device companies through ISO 13485 and IVDR. Send us an email and we will set up a conversation.
For general information only; not legal or regulatory advice. Regulations and deadlines change, so confirm current requirements with your notified body or regulatory counsel. Last updated October 2026.