Templates and records · ISO 13485 · Clause 7.3.10

ISO 13485 design and development file template

The thread connecting the idea to the manufactured product: every starting requirement, every design decision, every review and every test proving the result conforms.

In one sentence

A medical device's design and development file contains or references the design plan, inputs and outputs, reviews, verifications, validations and transfer to production, together with records of design changes, because clause 7.3.10 of ISO 13485 requires a file to be maintained for each device type or family demonstrating conformity with the design requirements.

Content reviewed on 17 October 2026

Where the standard requires it: ISO 13485 · Clause 7.3.10 Clauses are cited using the numbering of ISO 13485:2016, the current edition and the same one the Academy uses.
Type of information: Mandatory record File to be maintained with the records from 7.3.2 to 7.3.9 (7.3.10)
Who fills it in: The design project lead With quality and regulatory affairs in the reviews; each review must include at least one person without direct responsibility for the stage being reviewed
When: Throughout the project and beyond It stays open while the device is on the market, because it records design changes
How long it is kept: Product lifetime, at least two years ISO 13485 requires records to be kept for at least the lifetime of the device as defined by the manufacturer, and never less than two years from release (4.2.5); the MDR requires technical documentation to be available for ten years after the last device was placed on the market, fifteen for implantables (Article 10(8)).

What the standard requires

What ISO 13485 demands and what it leaves to your judgement

ISO 13485 requires documented design procedures and each project to be planned in stages, with its reviews, verifications, validations and transfer activities, responsibilities and means of tracing outputs back to inputs.

Each stage leaves a record: inputs are reviewed and approved, outputs are approved before release, design reviews record participants and decisions, and transfer to production checks that the outputs are suitable for manufacturing before full production starts.

The 7.3.10 file brings all of this together. It does not prescribe a traceability matrix, but without one it is hard to show that each input has its output and its verification, which is the first thing the auditor looks for.

Read it in context: Product realization, in the ISO 13485 Academy

Structure

Fields the template should include

Design plan: stages, reviews, responsibilities and timetable
Design inputs: functional, safety, usability, regulatory and risk management
Review and approval of inputs
Design outputs: drawings, specifications, software, labelling
Traceability matrix between inputs, outputs, verification and validation
Design review minutes with participants and decisions
References to verification and validation records
Transfer to production and its verification
Design change log

Example

Example: file for a fingertip pulse oximeter

Company, people and figures are fictitious: the example only shows what a properly completed record looks like.

Field	Content
Project	DHF-PX-2025 · Oxilite pulse oximeter (fictitious) · class IIa
Plan	5 stages: concept, design, verification, validation, transfer · approved on 10 February 2025
Inputs	42 requirements: SpO2 accuracy ±2% over 70-100%, 30 h battery life, IEC 60601-1, usability IEC 62366-1
Outputs	Board PX-PCB rev. C, firmware 1.4.2, housing P-PX-03, instructions IU-PX-01
Traceability	Matrix MT-PX: 42 inputs with output and verification assigned, 0 gaps at 1 September
Stage 3 review	3 June 2025 · design, quality, regulatory and an independent reviewer · 2 actions open
Transfer	Pilot batch of 200 units made with the production documentation · conforming
Changes	2 design changes recorded after market launch (DCR-PX-01 and 02)

At the audit

Mistakes auditors commonly flag

Vague design inputs ("easy to use", "robust") that cannot be verified.
Design reviews with nobody independent of the stage being reviewed.
Requirements with no verification traced to them.
The file is reconstructed at the end of the project, with dates that do not add up.
Transfer to production is not recorded as a stage.

In Kimobox

How this record is kept in Kimobox

1The design file is managed with controlled versions, review and approval.
2Design reviews are set up as forms with an approval workflow, and the actions they produce are assigned with a date and a reminder.
3Each output document is linked to the device file and its change history.

Frequently asked questions

What people ask us before getting started

What is the DHF?

Design History File, the name the US FDA uses for the design file. ISO 13485 calls it the design and development file; the content is equivalent.

Can design be excluded under ISO 13485?

Only if the company does not design and justifies it in its manual, for example a contract manufacturer producing to its customer's design. Where applicable regulations allow it, the exclusion is declared in the scope.

Keep your ISO 13485 records without loose templates

We'll show you the module running with data similar to yours.

Request a demo

Keep exploring