Design change control under ISO 13485 §7.3.9

What §7.3.9 requires

The clause turns a design change into a controlled decision rather than an engineering edit. Paraphrased, it asks the manufacturer to:

1. Document a procedure for controlling design and development changes.
2. Identify each change to the design.
3. Determine its significance to the device's function, performance, usability, safety, applicable regulatory requirements and intended use.
4. Review and verify the change, validate it as appropriate, and approve it before it is implemented.
5. Evaluate the effect of the change on constituent parts, on product in process or already delivered, and on the inputs and outputs of risk management and product realization.
6. Keep records of the changes, their review and any actions that followed.

This is a summary in our own words. The authoritative text is the standard itself, available from ISO.

Two words carry most of the weight in practice. "Significance" decides how much evidence a change needs, so the reasoning behind it has to be written down. "Before" means the approval record must predate production release; an approval signed after the fact is one of the easiest findings an auditor can write.

Clauses a design change touches

A change is rarely contained in one document. These are the places a reviewer should expect to see it reflected.

Under FDA QMSR (since 2 February 2026)

FDA's Quality Management System Regulation took effect on 2 February 2026 and incorporates ISO 13485:2016 by reference. The old design change requirement in 21 CFR 820.30(i) is gone; FDA now inspects design changes against §7.3.9 itself, under a risk-based inspection program (CP 7382.850) that replaced QSIT.

The new inspection program lists, as an example of a serious finding, not evaluating changes "for risk and impact on product(s) prior to implementation." That is §7.3.9 in one line.

Does the change need a new 510(k)?

That is a separate decision from change control, and both need a record. Under 21 CFR 807.81(a)(3), a new 510(k) is required when a change could significantly affect safety or effectiveness, or is a major change in intended use. FDA's 2017 guidance Deciding When to Submit a 510(k) for a Change to an Existing Device, with a companion guidance for software changes, walks through that decision. If you conclude no submission is needed, document the reasoning and keep it with the change record.

Under EU MDR

The MDR adds a notified body to the loop, and what it expects depends on the device class. For Class III devices and the Class IIb devices covered by Article 52(4) second subparagraph, which go through technical documentation assessment, Annex IX section 4.10 requires approval from the notified body that issued the certificate for changes that could affect safety and performance or the conditions prescribed for use. Approval comes as a supplement to the technical documentation assessment certificate.

For all devices certified under Annex IX, section 2.4 requires the manufacturer to inform the notified body of planned substantial changes to the quality management system or the device range. For Class IIa and most Class IIb devices, that is the main route for design changes, alongside the notified body's sampling of technical documentation. Article 10(9) asks every manufacturer to take design changes into account in a timely manner.

For legacy devices still placed on the market under Article 120, MDCG 2020-3 Rev.1 sets out which changes count as significant and would end the transitional arrangement. Check your conformity assessment route, since other annexes carry equivalent change provisions.

Worked example: a catheter tip angle change

An illustrative case. An engineer releases revision C of part CT-1042 in the PDM system, changing a steerable catheter's tip angle from 15° to 22°. Here is what §7.3.9 expects to happen next, and the evidence each step leaves behind.

The steps are not hard. The hard part is that the trigger, a revision released in CAD, happens in a tool the quality system never sees. See this exact example in the interactive demo.

What auditors check

Auditors and FDA investigators usually sample a handful of recent changes and trace each one end to end. For every sampled change, have these ready:

• A change record that names the affected parts, documents and versions
• A significance assessment with the reasoning written out
• Risk management review, with risk file updates or a rationale for none
• Verification and validation evidence, or a justification for what was not repeated
• An assessment of product in process and already delivered
• A regulatory assessment: 510(k), notified body, or neither, and why
• Approval signatures dated before implementation
• Updated transfer documents and design file

Where change control usually breaks

• The change never enters change control. It lives in CAD, PDM, Jira or Git, and the quality team hears about it weeks later.
• Significance is asserted, not reasoned. "Minor change" with no explanation will not satisfy an auditor.
• The risk file falls behind. The design moves on and the hazard analysis still describes the old one.
• Approval comes after release. Signatures dated after production started are hard to defend.
• Delivered product is ignored. Nobody records whether units already shipped are affected.

Frequently asked questions