ISO 13485 design and development

ISO 13485:2016 7.3 requires documented design controls: a plan (7.3.2), inputs (7.3.3), outputs (7.3.4), reviews (7.3.5), verification (7.3.6), validation (7.3.7), transfer to production (7.3.8), controlled changes (7.3.9) and a design and development file for each device type or family (7.3.10).

The requirement in plain English

Procedures (ISO 13485:2016 7.3.1). Design and development follows documented procedures.

Planning (ISO 13485:2016 7.3.2). A documented plan, kept up to date, sets the stages, the review at each stage, the verification, validation and transfer work, who is responsible, how outputs will be traced back to inputs, and the people and skills needed.

Inputs (ISO 13485:2016 7.3.3). Inputs cover what the device must do, how well, how usably and how safely for its intended use, the regulations and standards that apply, the outputs of risk management, and lessons from earlier designs. They are reviewed and approved, and must be complete, unambiguous, testable and free of conflicts. Usability was added as an input in 2016.

Outputs (ISO 13485:2016 7.3.4). Outputs meet the inputs, give purchasing, production and service what they need, contain or reference acceptance criteria, and state the characteristics essential to safe and proper use. They are approved before release.

Review (ISO 13485:2016 7.3.5). At the planned stages, a review checks whether the design can meet its requirements and records the problems and actions. People from the functions involved in the stage take part, with specialists as needed. Records name the design, the participants and the date.

Verification (ISO 13485:2016 7.3.6). Documented plans prove the outputs meet the inputs, with methods, acceptance criteria and a rationale for sample sizes. If the device connects to other devices, verification covers the connected state.

Validation (ISO 13485:2016 7.3.7). Documented plans prove the finished device meets user needs and intended use. Validation uses representative product, such as initial production units or their equivalent, with the choice justified. It includes clinical or performance evaluation as regulations require, and is finished before the device is released for use.

Transfer (ISO 13485:2016 7.3.8). A documented procedure checks the outputs work as manufacturing specifications and that production can meet the requirements before they become final.

Changes (ISO 13485:2016 7.3.9). You judge how significant each change is to function, performance, usability, safety and regulatory requirements. Changes are reviewed, verified or validated as needed, and approved before they are made. The review considers parts already made, devices already delivered, and the risk management and realisation records.

File (ISO 13485:2016 7.3.10). Each device type or family has a design and development file that includes or references the records proving conformity, and the records of changes. Americans often call it the design history file, a term the US Food and Drug Administration retired from its rules on 2 February 2026.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 22-person company is developing a Class IIa smartphone-connected spirometer. Its design and development plan names six stages, from user needs to transfer, each ending in a design review with a decision to proceed, proceed with actions, or stop. Reviews include a clinician, the quality lead and someone from manufacturing, and are minuted, not just discussed.

Inputs live in a requirements specification: each one testable, numbered and linked to its source, whether a user need, a regulation, a standard or a risk control. The risk management file, built under ISO 14971 as clause 7.1 expects (ISO 13485:2016 7.1), feeds hazard controls into the inputs. A traceability matrix links every input to its output, its verification test and, for user needs, its validation activity.

Verification plans state acceptance criteria and sample sizes before testing starts. Validation uses units from the first pilot build, includes a summative usability study with representative users, and the clinical evaluation that EU MDR requires. Device software follows IEC 62304 and the user interface follows IEC 62366-1.

After release, every change goes through an impact assessment: does it touch a risk control, a claim on the label, or the notified body’s view of the device? The design and development file is an index of all of this, alongside the medical device file (ISO 13485:2016 4.2.3).

Evidence an auditor expects

Design and development procedures and plan (required): stages, reviews, responsibilities and traceability method, kept up to date.
Approved inputs (required): complete and testable, including usability, regulatory and risk management inputs.
Approved outputs (required): acceptance criteria and the characteristics essential to safe use.
Design review records (required): participants, date, design identification, decisions and actions.
Verification and validation plans and results (required): pre-set criteria, sample size rationale, representative product for validation.
Transfer records (required): manufacturing specifications verified and production capability shown.
Change records (required): significance assessed, verification or validation done, approval before implementation.
Traceability matrix: usual rather than named, and the fastest way to answer most auditor questions.

Common mistakes

Inputs nobody can test

“Intuitive” and “accurate” appear as requirements. Nobody can verify them, so verification proves nothing. Write each input with a measurable criterion, such as a reading accuracy within a stated tolerance.

Validation on the wrong units

Validation is run on hand-built prototypes, then production changes the materials. The auditor asks how the prototypes represent production. Validate on initial production units or justify the equivalence in writing.

Design controls written after the fact

A team builds the device, then writes the plan, inputs and reviews in the month before the audit. Dates and versions give it away. Start the plan when development starts and let records accumulate.

Changes that skip the risk file

A post-release software fix is tested and shipped, but nobody updates the risk management file or asks whether the change is significant to the notified body. Make the impact assessment part of every change, including hotfixes.

Reviews that are status meetings

The review is a project update with no decision and no record of open problems. Clause 7.3.5 asks for evaluation and actions. End each review with a decision and an action list.

How Sted helps

For ISO 13485 clause 7.3 Sted’s knowledge base carries the Design and Development Procedure (PRC-DDP) with its Design and Development Plan (REC-DDPL), Requirements Specification Record (REC-RSPEC), Design and Development Record (REC-DDR), Design Review Record (REC-DRR), Verification and Validation Record (REC-VVR) and Design Transfer Record (REC-DTR); for device software the Software Development Lifecycle Procedure (PRC-SDLP) with its Software Development Plan (REC-SDP), Software Requirements Specification (REC-SRS), Software Architecture Document (REC-SAD), Requirements Traceability Matrix (REC-RTM), Verification and Validation Plan (REC-VVP) and Software Release Record (REC-SR); and for design changes the Change Management Policy (POL-CHG) with its Change Record (REC-CR).
Design records are kept per activity; there is no single design and development file template, and records are part of the Full Management System plan.
Under the same Risk Management Procedure (PRC-RMP) Sted’s knowledge base carries an AI Risk Assessment Record (REC-ARA) for each AI system, with a suggested annual frequency, and for medical devices a Medical Device Risk Management Plan (REC-MDRMP), Medical Device Risk Management File (REC-MDRM) and Risk Management Report (REC-RMR).
Records are part of the Full Management System plan.
Every record template in Sted’s knowledge base sits under the policy or procedure it gives evidence for, such as the Access Review Record (REC-ARR) under the Access Control Policy (POL-ACC).
A record is opened, completed, submitted for closure and closed (or withdrawn); closure is reviewed by the document owner.

Sted holds design plans, reviews and test records as you complete them. It does not run your tests or judge whether a design change is significant to your notified body.

Risk assessment guide: hazard analysis feeding design inputs, with an ISO 13485 wound dressing example.
Product realisation: where design outputs become purchasing and production controls.
IEC 62304: the software life cycle that sits inside clause 7.3.
IEC 62366-1: the usability engineering process behind the usability inputs and summative validation.
Records in Sted: how a design review or verification record is opened, completed and closed.
ISO 13485 hub: how design fits the rest of the standard.

Frequently asked questions

Does ISO 13485 require a design history file?

Not by that name. Clause 7.3.10 asks for a design and development file for each device type or family. Design history file was the US term under the old Quality System Regulation; the FDA dropped it when its new rule took effect on 2 February 2026, though many teams still use it.

When do design controls have to start?

When you decide to develop a product, not just before the audit. Early feasibility work can sit outside design control, but once you commit to a device the plan, inputs and reviews should begin. Feasibility findings then become recorded inputs, which saves you recreating them later.