ISO 13485 Design and Development: Proven Essentials

Plan. Prove. Transfer.

Most device organizations inherited their design procedure from a quality base. That single fact explains the majority of what goes wrong with ISO 13485 design and development, because the requirements that have no ISO 9001 counterpart are precisely the ones that get lost when a procedure is adapted rather than written.

Design transfer is the clearest example. There is no Clause 8.3 equivalent, so a procedure built from an ISO 9001 template simply has nothing where transfer should be. Nobody notices, because no clause checklist derived from the quality standard points at the hole. The Design History File is the second example. The requirement for a documented procedure is the third.

This guide walks ISO 13485 design and development sub-clause by sub-clause, names what changes under the FDA's Quality Management System Regulation, and marks the specific places where ISO 13485 design and development departs from what a quality-derived procedure will already contain. It is the device counterpart to MSI's operational guide to the ISO 9001 design and development process, and it sits under the pillar Design and Development Procedure: 7 Marks Most Never Meet.

• ISO 13485 design and development sits at Clause 7.3, not 8.3 — the standard predates the harmonized ten-clause structure, so ISO 9001 numbering does not transfer.
• A documented procedure is mandatory. ISO 13485 names design and development explicitly among its required documented procedures.
• Design transfer at 7.3.8 has no ISO 9001 equivalent and is routinely absent from procedures adapted from a quality base.
• The Design History File at 7.3.10 must demonstrate the design was developed in accordance with the plan and the requirements.
• Since 2 February 2026, ISO 13485:2016 is incorporated by reference into 21 CFR Part 820 — design records are now inspectable by the FDA.
• Risk management under ISO 14971 must visibly drive design inputs, not sit alongside them in a separate file nobody cross-references.
• Design changes at 7.3.9 are a frequent finding source and, in the United States, now a federal obligation.

Why Is ISO 13485 Design and Development Now a Federal Requirement?

Incorporated. Inspected. Enforced.

The shift is easy to underestimate because the engineering discipline inside ISO 13485 design and development barely moved. Planning, inputs, outputs, review, verification, validation, transfer, changes, and the design record were all present in the legacy regulation. What changed is which document holds the authority, and what that means when an investigator arrives.

The FDA's QMSR overview states the mechanism plainly: the revised Part 820 incorporates the international standard by reference and harmonizes the agency's framework with the one other regulators already use. The regulation text itself is available through the eCFR, where the sections determined to be substantively similar to ISO 13485 now appear as reserved.

Two operational consequences follow, and both land on ISO 13485 design and development directly.

The Inspection Method Changed With the Rule

On the same date, the FDA stopped using the Quality System Inspection Technique and moved to the compliance program described in its QMSR frequently asked questions — Inspection of Medical Device Manufacturers, Compliance Program 7382.850. Organizations that trained their teams to expect QSIT's four-subsystem walk are preparing for an inspection that no longer happens that way.

For ISO 13485 design and development specifically, the practical effect is that the design record is examined against Clause 7.3 language rather than 820.30 language. Procedures still written in the old vocabulary — design history file described only as a DHF, verification and validation defined as the regulation defined them — create a translation burden at exactly the wrong moment.

Certification and Regulation Now Read the Same Text

The upside is real. An organization holding ISO 13485 certification and marketing in the United States no longer maintains two mental models of what design control means. One standard, read by a registrar and by a federal investigator, with jurisdiction-specific obligations layered on top rather than substituted underneath.

That convergence extends further than the United States. The Medical Device Single Audit Program, developed through the International Medical Device Regulators Forum, already audits ISO 13485 design and development alongside participating jurisdictions' own requirements in a single pass. MSI's coverage of the wider maturity picture is in the FDA Voluntary Improvement Program.

What Does ISO 13485 Design and Development Require at Clause 7.3?

Ten. Sub-clauses. Sequenced.

The structural point about ISO 13485 design and development matters before the detail does. ISO 13485:2016 deliberately retained the older clause architecture rather than adopting the harmonized ten-clause structure used by ISO 9001:2015. Design lives inside Clause 7, Product Realization. Nothing about ISO 9001 clause numbering transfers, and a cross-reference table built on the assumption that it does will mislead everyone who uses it.

7.3.1 General — The Procedure Is Not Optional

ISO 13485 requires documented procedures for design and development. This is the first and most consequential departure from the quality standard, which leaves documentation decisions to the organization. Under ISO 13485 design and development, the absence of a procedure is not a judgment call an organization gets to defend — it is a missing requirement.

What that procedure has to do is another matter. MSI's standard for whether a procedure works rather than merely exists is set out in the seven marks of an effective ISO procedure — a real trigger, one accountable owner, thresholds stated as numbers, the record as the gate, a defined exception path, trainable in one sitting, and an event-based review trigger.

7.3.2 Planning — Including Who Verifies and Who Validates

Planning under ISO 13485 design and development must determine the stages, the review, verification, validation, and transfer activities appropriate at each stage, responsibilities and authorities, methods for traceability of outputs to inputs, and the resources needed including personnel competence.

Two of those deserve emphasis because quality-derived plans commonly thin them out. Traceability of outputs to inputs is named as a planning obligation, not left as good practice — the method has to be decided before the design starts, not reconstructed at the end. And transfer activities appear in the planning list, which means an organization is expected to have thought about production readiness from the first planning document rather than at handover.

7.3.3 Inputs — Four Doors, One of Them Risk

Design inputs under ISO 13485 design and development must cover functional, performance, usability, and safety requirements according to intended use; applicable regulatory requirements and standards; applicable outputs of risk management; and, where appropriate, information derived from previous similar designs. Inputs must be reviewed for adequacy, approved, complete, unambiguous, verifiable, and free of conflict with each other.

Usability sits in the requirement text explicitly. So does risk. The phrase “applicable outputs of risk management” is the hinge that connects ISO 13485 design and development to ISO 14971:2019 as a requirement rather than as an adjacent activity — a linkage examined in its own section below.

Requirements that arrive through several doors at once are the ones most likely to be dropped. Cybersecurity is the current example: it enters as a safety requirement, a regulatory requirement, and a risk output simultaneously, and belongs to nobody unless the procedure assigns it. MSI's treatment of that translation problem is in medical device threat modeling.

7.3.4 Outputs — Including Safe and Proper Use

Outputs from ISO 13485 design and development must meet the input requirements, provide appropriate information for purchasing, production, and service provision, contain or reference acceptance criteria, and specify the characteristics essential for safe and proper use. That last item has no counterpart in ISO 9001 and is frequently under-evidenced: the design has to identify what makes the device safe to use, not only what makes it function.

Outputs must also be approved before release. A traceability matrix — one row per input, the output that satisfies it, the verification evidence — is the least expensive way to make the 7.3.2 traceability obligation visible and the approval defensible.

7.3.5 Review — With Representation From the Functions Concerned

Systematic reviews across ISO 13485 design and development must be performed at suitable stages to evaluate whether results meet requirements and to identify and propose necessary actions. Participants must include representatives of the functions concerned with the stage being reviewed, plus other specialist personnel as required. Records of reviews, results, and actions are required, including the identity of participants.

“Functions concerned” is doing real work in that sentence. A design review attended only by engineering does not satisfy the requirement when the stage under review affects production, purchasing, or regulatory. Recording who attended and in what capacity is the evidence — and the reason attendance lists belong in the record rather than in a calendar invitation.

7.3.6 and 7.3.7 Verification and Validation — Separated Deliberately

ISO 13485 design and development gives verification and validation their own sub-clauses rather than folding them into controls. Each requires documented plans containing methods, acceptance criteria, and — where appropriate — statistical techniques with a rationale for sample size. That sample-size rationale is a specific and commonly missing record.

Validation carries device-specific conditions. It must be performed on representative product — production units, batches, or their equivalents, with the equivalence justified. Where the device connects to or interfaces with other devices, validation must confirm requirements are met when so connected. Clinical evaluation or performance evaluation forms part of validation where regulation requires it. And validation must be completed before release for use.

Organizations that record only one activity under both names almost always turn out to be verifying. The tell is the absence of any use-environment evidence: bench data proving the output matches the input, and nothing demonstrating the device performs in the hands of the intended user.

Transfer, Changes, and Files: Where ISO 13485 Design and Development Stands Alone

Handover. Control. Evidence.

7.3.8 Design Transfer — The Sub-Clause That Simply Is Not There in ISO 9001

Transfer inside ISO 13485 design and development requires documented procedures for translating design outputs into manufacturing specifications, and it requires verification that the outputs are suitable for manufacturing before they become production specifications. It also requires confirmation that production capability can meet product requirements.

Read that carefully. It is not a handover meeting. It is a verified translation with a recorded outcome, plus an affirmative statement that the production process can actually make what the design describes. An organization whose transfer consists of releasing drawings into the ERP system and telling manufacturing they are live has a documented gap in ISO 13485 design and development, however good the drawings are.

MSI's practical guidance is to define transfer as a gate with named criteria: process validation status, tooling and fixture readiness, inspection method availability, operator training completion, and the supplier qualification status of anything critical. Each criterion gets an owner and a state. Transfer is approved when they are all satisfied or when a documented deviation says otherwise. The downstream side of that boundary is covered in MSI's guide to the production and service provision procedure.

7.3.9 Control of Changes — Now Federal Law in the United States

Changes to ISO 13485 design and development outputs must be reviewed, verified, validated as appropriate, and approved before implementation. The review has to determine the significance of the change to function, performance, usability, safety, and applicable regulatory requirements, and it has to evaluate the effect on constituent parts and on product already in the field.

The product-already-delivered obligation is the one that catches organizations. A change that improves a device going forward may create a question about the devices already with customers — and 7.3.9 requires that question to be asked on the record, not left implicit. This is also why 7.3.9 shows up so often as a finding source: the change record exists, the significance determination exists, and the field-population evaluation is blank.

Since the QMSR took effect, this sub-clause is part of a federal obligation for devices marketed in the United States, which raises the cost of a change process that runs on email. MSI's treatment of building the workflow properly is in change management automation, and ISO 10007:2017 on configuration management is the guidance standard worth reading alongside it.

7.3.10 The Design and Development File — What Actually Belongs in It

ISO 13485 design and development requires a file maintained for each device type or family. It must contain or reference records demonstrating conformity to the design requirements and records of changes. In United States practice this is the Design History File, and it is where an investigator goes early because it is the fastest way to see whether the design was developed the way the plan said it would be.

The file is allowed to reference rather than contain. That is a significant permission and organizations should use it deliberately: an index that points to controlled locations is more maintainable than a folder that duplicates records and drifts out of date. What matters is that following any reference actually lands on the current approved version.

Note the distinction from the Medical Device File at Clause 4.2.3, which is a different requirement covering the device's general description, specification, manufacturing, and installation and servicing procedures. The two are related and routinely conflated. The design file evidences how the design was developed. The Medical Device File describes what the device is and how it is made.

How Does ISO 13485 Design and Development Differ From ISO 9001 Clause 8.3?

Stricter. Broader. Numbered differently.

Organizations running one system against both standards face a design decision before they face a design procedure: write once at the stricter level, or maintain two documents. MSI's consistent recommendation is to write once. The requirements that differ are additive rather than contradictory, and an ISO 9001 organization gains from carrying transfer discipline and a design file whether or not a standard demands it.

Exclusion Is the Difference Nobody Expects

ISO 9001 permits design and development to be excluded from scope where it genuinely does not apply, provided the exclusion is justified and documented. ISO 13485 does not offer that route for organizations that design. A contract manufacturer building strictly to a customer's specification may legitimately have no design activity; a specification developer never does.

The practical consequence is that the first question for an ISO 9001 organization is whether Clause 8.3 is in scope at all, while for a device organization the first question is how thoroughly ISO 13485 design and development is evidenced. Those are different conversations, and starting the second one with the first one's assumptions wastes a cycle.

What Transfers Cleanly Between the Two

Most of ISO 13485 design and development transfers structurally. Planning, inputs, outputs, review, verification, validation, and change control exist in both, and the discipline that makes them work — thresholds instead of intentions, records as gates, defined exception paths — is standard-agnostic. What does not transfer is the numbering, the documentation obligation, and the three device-specific sub-clauses covered above.

For the measurement layer on top of all this, MSI's work on design control metrics sets out nine measures across input integrity, traceability, and transfer readiness — seven of which apply unchanged to an integrated system. For an honest read on where a device system currently stands overall, MSI publishes a self-scoring ISO 13485 Gap Analysis that treats Clause 7.3 as multiple separate line items rather than one.

How Does ISO 14971 Connect to ISO 13485 Design and Development?

Linked. Traceable. Continuous.

Almost every organization running ISO 13485 design and development has a risk management file. Far fewer can demonstrate the linkage running both directions. Forward: this hazard produced this risk control, which became this design input, which was verified by this test. Backward: this design change was evaluated against the risk file and the conclusion was recorded.

Where a risk control is implemented through the user rather than through the design — a warning, an instruction, a required training step — the linkage carries an extra obligation, because the control only exists if the information reaches the user. That is a design output question under 7.3.4's requirement to specify the characteristics essential for safe and proper use.

MSI's recommendation is a single traceability artifact that carries hazard, risk control, design input, verification evidence, and residual risk conclusion in one row. Organizations that maintain risk and design traceability separately spend the difference at every review, every change, and every audit.

Who Owns ISO 13485 Design and Development?

Named. Titled. Accountable.

Responsibilities and authorities across ISO 13485 design and development must be defined by title rather than by individual. People leave; roles persist. A procedure naming a person creates a vacancy the day that person moves on, and in a regulated context that vacancy is visible in the record.

Typical roles across ISO 13485 design and development include a design project lead, design engineers, the regulatory affairs lead, the quality manager, risk management ownership, production or manufacturing engineering for transfer, purchasing for supplier-dependent inputs, and clinical or usability specialists where the device requires them. External resources — test houses, notified body contacts, contract manufacturers — belong in the plan named by function.

Two authorities deserve to be named explicitly and rarely are: who can stop a design from advancing past a stage gate, and who approves design transfer. If either is undefined, the gate is decorative. Naming both by title, with alternates for absence, is among the highest-value lines in the whole procedure. MSI's internal audit services and ISO 13485 consulting both start from exactly this kind of role clarity, and MSI's guide to ISO 13485 management review covers how design performance should reach leadership.

ISO 13485 Design and Development: Common Questions

Answered. Clearly. From Experience.

The eight questions below are the ones MSI hears most often from device organizations building or rebuilding ISO 13485 design and development. Each answer is drawn from engagements rather than from the standard's wording.

Which clause covers design and development in ISO 13485?

Does ISO 13485 require a documented design and development procedure?

What is design transfer and why does it get missed?

What is the difference between the design file and the Medical Device File?

Can a device organization exclude design and development from scope?

How did the FDA QMSR change design control obligations?

How should risk management connect to design inputs?

Can one procedure serve both ISO 9001 and ISO 13485?