Design changes under the MDR are governed by clause 7.3.9 of EN ISO 13485:2016+A11:2021, traced to the product realisation obligation in MDR Article 10. The clause requires that every design change be identified, documented, reviewed, verified, validated where appropriate, and approved before implementation — and that the review include an evaluation of the effect of the change on constituent parts, on product already delivered, on inputs and outputs of risk management, and on product realisation processes. For legacy devices still certified under the Directives and covered by the extended transition under Article 120 of Regulation (EU) 2017/745, an additional question applies on top of clause 7.3.9: does the change count as a "significant change in design or intended purpose" that ends the transitional coverage? Iterate freely, but run every change through the clause 7.3.9 gate and, for legacy devices, the Article 120 significance check. Both tests fit on one page once the process is built.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • MDR design change control is governed by clause 7.3.9 of EN ISO 13485:2016+A11:2021, which sits inside the design and development section and traces to the product realisation obligation in MDR Article 10.
  • Clause 7.3.9 requires every design change to be identified, documented, reviewed, verified, validated where appropriate, and approved before implementation.
  • The review under 7.3.9 must evaluate the effect of the change on constituent parts and on product already delivered, and it must assess impacts on risk management inputs and outputs and on product realisation processes.
  • For legacy devices running under the extended Article 120 transition of Regulation (EU) 2017/745, a second test applies: whether the change is a "significant change in design or intended purpose" that ends transitional coverage and forces the device onto full MDR conformity assessment.
  • Software design changes are the highest-frequency case and are covered in detail in the software change control posts (411 and 412), where EN 62304 overlays the clause 7.3.9 process.
  • The fastest startups treat change control as a one-page form backed by a traceability matrix. The slowest either skip the form (and fail at audit) or build a twelve-stage change board (and stall the product).

Why iteration is the default state of MedTech development

Nobody builds a medical device in one pass. The first prototype is never the final device. The first clinical inputs are never the last. The first risk analysis misses hazards that only appear once users touch the thing. Design changes are not an exception to the process — they are the process. A team that runs two years of development without a single controlled design change is either not building anything or not writing down what it is building.

The problem is that every change is a potential compliance break. A small tweak to a mechanical part can invalidate a biocompatibility conclusion. A reworded screen label can invalidate a usability validation. A refactor of a calculation can invalidate a verification run. Under clause 7.3.9 of EN ISO 13485:2016+A11:2021, none of this is optional — the change has to be evaluated for its effects before it ships.

The discipline is not to stop iterating. It is to make iteration legible. A change that is written down, reviewed, and approved is cheap. A change that happens silently and is discovered during a design history file audit two years later is expensive — sometimes terminally so.

What clause 7.3.9 actually requires

Clause 7.3.9 of EN ISO 13485:2016+A11:2021 is the design and development changes sub-clause. In plain terms it obliges the organisation to identify design changes, document them, and before implementation review, verify, validate where appropriate, and approve them.

The review element is the heavy lift. Clause 7.3.9 requires that the review of a design change evaluate the effect of the change on constituent parts of the device and on product already delivered, and that the impact of the change on inputs and outputs of risk management and on product realisation processes be assessed. That is four distinct evaluation lenses on every change worth reviewing:

  • Effect on constituent parts. If you change a subsystem, what other subsystems does that touch? A change to a power module can ripple into EMC; a change to an API layer can ripple into data handling. The review identifies the reach.
  • Effect on product already delivered. If you have already shipped devices (whether investigational or commercial), does this change affect them? Do they need a field action, a retrofit, a recall, or nothing? This is the clause that links design change control into vigilance and PMS.
  • Effect on risk management inputs and outputs. Every change is evaluated against the risk file. Did the change introduce a new hazard? Alter an existing risk estimation? Invalidate a risk control? The risk file is updated as an integral part of the change, not as an afterthought.
  • Effect on product realisation processes. Does the change affect the manufacturing, inspection, packaging, sterilisation, or labelling process? If yes, those process changes also get caught and managed.

The change is then verified (does the implementation match the changed specification?), validated where appropriate (does the changed device still meet the user needs?), and formally approved by the authority the design plan named for this kind of decision. Records of the change review, including the actions from the review, are retained. Nothing ships until the approval is in place.

What counts as a design change

Not every edit is a design change under clause 7.3.9. A typo fix in an internal engineering note is not. A comment rewrite in source code that changes no behaviour is not. A reorganisation of a folder structure in the technical file is not. The clause targets changes to the design itself — the specifications, the drawings, the source code, the labelling, the intended use, the risk file, the verification and validation plans, and anything else that defines what the device is and how it is built.

A useful test is the traceability test. If the change affects an item that has an entry in the traceability matrix linking inputs to outputs to verification and validation, it is a design change and clause 7.3.9 applies. If the change touches no traceable item, it is maintenance, not design change control.

Common cases that do count:

  • Any change to user requirements or intended use.
  • Any change to design inputs, including performance specifications and functional requirements.
  • Any change to design outputs that implement those inputs — drawings, models, source code, firmware images, labelling content.
  • Any change to a risk control measure, including any change that weakens or removes an existing control.
  • Any change to the verification or validation plan or to the acceptance criteria those plans rely on.
  • Any change to the intended use environment or user population assumptions.

Common cases that do not count:

  • Internal workflow tweaks that do not alter the design record.
  • Comments, formatting, or documentation structure changes with no effect on content.
  • Test infrastructure changes that do not change what is being tested.

A startup that gets the boundary right stops wasting effort on change reviews for non-design edits, and stops missing real design changes that needed a review.

The change control process on one page

A lean change control process for a small team fits on one page of procedure and one template. The procedure says: every design change is raised as a change request; every change request is reviewed against the four lenses from clause 7.3.9; a change that is approved is verified, validated where appropriate, and closed with records; a change that is rejected is closed with the rejection rationale. The template captures the change description, the affected items, the four lens evaluations, the verification and validation impact, the risk file impact, the decision, and the approver.

What makes this work in practice is discipline about two things. First, the change request is raised before the implementation starts, not after. Retrospective change requests are evidence of a broken process and an auditor will read them as such. Second, the review is an actual review, not a rubber stamp. If the review takes two minutes on every change, either the changes really are all trivial (possible, but the record should say so) or the review is not happening and the process is cosmetic (more likely, and audit-visible).

The change review authority is the role named in the design and development plan under clause 7.3.2 as the approver for design decisions. In a three-person company this is often the technical lead with a second pair of eyes from a co-founder or an external advisor. In a larger team it is a change control board with clearly named members. Either structure satisfies the clause as long as the approver is named, independent where the review requires independence, and actually sees the change before it ships.

Design change versus significant change under Article 120

For devices still on the market under a certificate issued under the old Directives (93/42/EEC or 90/385/EEC) and benefitting from the extended transition set out in MDR Article 120 (as amended by Regulation (EU) 2023/607), there is a second test running in parallel with clause 7.3.9.

Article 120 allows legacy devices to continue on the market under their Directive certificate beyond the MDR date of application, subject to conditions — the manufacturer has a compliant QMS, has applied for MDR certification within specified timelines, and critically, has made no "significant changes in design or intended purpose" since the Directive certificate was issued. The moment a significant change happens, the transitional coverage for that device ends and the device needs full MDR conformity assessment to remain on the market.

This means legacy-device teams have to make two judgements on every design change:

  • Is this a design change under clause 7.3.9? If yes, the full internal change control process applies.
  • Is this a significant change in design or intended purpose under Article 120? If yes, the transitional coverage is broken and the device is on the MDR conformity assessment clock.

The second question is a legal judgement with hard commercial consequences. Getting it wrong in the direction of "not significant" when it actually is significant means continuing to sell a device whose legal basis has evaporated. Getting it wrong in the direction of "significant" when it is not loses transition time needlessly. The Commission has published guidance on how to interpret "significant change" in this context (MDCG 2020-3, with subsequent revisions) — any team with a legacy device in transition reads that guidance alongside clause 7.3.9 and does not rely on memory.

For devices going through MDR conformity assessment from the start — that is, most new startups — the Article 120 significance test does not apply. Only clause 7.3.9 applies. But for any team acquiring, in-licensing, or continuing a legacy product, both tests run in parallel on every change.

Software changes — see posts 411 and 412

Software design changes are the highest-frequency change class in most modern medical devices, and they have their own layered treatment. Clause 7.3.9 of EN ISO 13485:2016+A11:2021 sets the QMS-level change control obligation. On top of that, the software lifecycle standard adds a software-specific change control process with software-specific reviews, regression testing expectations, and software safety classification impact analysis. The detailed mechanics of software change control — including the software change request flow, the software change analysis, and the regression verification obligations — are covered in the software change control posts (411 and 412).

The short version for this post: every software design change runs through both the clause 7.3.9 QMS process and the software lifecycle process. They are not duplicate efforts when the team sets them up as one integrated flow. They are duplicate efforts when the team treats them as two separate change boards, which is a common failure mode that adds delay without adding safety.

Common mistakes

  • Skipping change control for "small" changes. Small is a judgement, not a fact. A change that looks small to an engineer can have large risk implications. Every design change goes through the clause 7.3.9 gate, even if the gate takes five minutes for a trivial case.
  • Back-dating change requests. Writing a change request after the change has shipped, and dating it as if it was done beforehand, is retrospective reconstruction and is detectable.
  • Treating the risk file as out of scope for change control. Clause 7.3.9 explicitly requires evaluation of the change's effect on risk management inputs and outputs. A change review that does not touch the risk file is incomplete.
  • Ignoring product already delivered. If devices have been shipped — even as investigational units — the change review must address what the change means for those units. Skipping this is one of the most common findings in change-control nonconformities.
  • Running two parallel change boards for hardware and software. One integrated change process that handles both, with software-specific steps layered in, is faster and safer.
  • For legacy devices: conflating clause 7.3.9 with Article 120 significance. These are two independent tests. A change can pass clause 7.3.9 cleanly and still be an Article 120 significant change that ends transitional coverage. Both tests must run on every change for legacy products in transition.
  • Over-engineering the change board. A twelve-stage approval process for a three-person company is theatre. One reviewer with clear authority, one template, one approval signature, and a traceable record is enough for most startups to satisfy clause 7.3.9.

The Subtract to Ship angle on change control

Subtract to Ship (post 065) applied to clause 7.3.9 is the same discipline as the rest of the design-controls cluster. Every element in the change control process must earn its place against clause 7.3.9 itself and, through it, MDR Article 10 product realisation. Every extra stage, extra approver, and extra form field that was added because "change boards usually have one" is cut.

What the clause requires is specific and short: identification, documentation, review across four lenses, verification, validation where appropriate, approval, records. A process that delivers those artefacts is compliant. A process that adds layers beyond them is spending runway on ritual. The sharpest startups build the process at exactly the weight clause 7.3.9 asks for and no heavier — and then defend that weight when the instinct to bolt on extra gates arrives.

The reverse failure is skipping the clause entirely because it "slows things down." A five-minute change review does not slow development. A post-hoc reconstruction of six months of uncontrolled changes does — and the reconstruction is never quite credible.

Reality Check — Where do you stand?

  1. Do you have a written change control procedure that references clause 7.3.9 of EN ISO 13485:2016+A11:2021 and names the approver authority?
  2. Can you show, for any design change in the last six months, a change request raised before implementation, a review against the four clause 7.3.9 lenses, verification and validation impact assessment, and a signed approval?
  3. Does your change review explicitly address the effect on risk management inputs and outputs and the effect on product already delivered, or are these lenses implicit?
  4. Is your change process integrated across hardware, software, labelling, and risk file, or are these running as separate tracks?
  5. For software changes specifically, is the clause 7.3.9 review integrated with the software lifecycle change process (posts 411 and 412), or are they duplicated?
  6. If your device is a legacy product in Article 120 transition, do you run the "significant change" test in parallel with clause 7.3.9 on every change, and is the test documented?
  7. Could an auditor pick any three design changes from the last year and follow each one from request to approval to implementation to verification record in under ten minutes?

Any "not yet" answer is a place to do the work before the next change arrives — and the next change is always closer than expected.

Frequently Asked Questions

Does MDR Article 10 directly require a design change control procedure? MDR Article 10 sets out the general obligations of manufacturers, including the requirement to establish, document, implement, maintain, keep up to date, and continually improve a quality management system that covers product realisation. The specific design change control obligation is carried by clause 7.3.9 of EN ISO 13485:2016+A11:2021, which is the harmonised standard providing presumption of conformity with the relevant parts of Article 10. In practice, an MDR-certifying manufacturer builds the clause 7.3.9 process.

What is a "significant change" under Article 120 of the MDR? Article 120 of Regulation (EU) 2017/745 allows legacy devices with valid Directive certificates to remain on the market during the extended transitional period, provided there are no significant changes in design or intended purpose. Guidance on how to interpret "significant" in this context is published by the Medical Device Coordination Group. A change that crosses the significance threshold ends transitional coverage and forces the device onto full MDR conformity assessment. The judgement has high commercial stakes and should be documented and justified against the current guidance.

How detailed does a change review need to be for a small team? As detailed as the four clause 7.3.9 evaluation lenses require for that specific change, and no more. A trivial change with clearly no cross-impact may yield a short review with short answers against each lens. A change that touches a risk control or affects delivered product will yield a much longer review. The depth scales with the change, but the four lenses are always addressed.

Who approves a design change in a three-person startup? The approver is the role the design and development plan (clause 7.3.2) names as the authority for design decisions. In a very small team this is usually the technical lead, ideally with a second reviewer — a co-founder, an external advisor, or a named independent party — for the review itself. The approver must be named, the approval must be documented, and the review must actually happen before implementation.

Do I need to update the technical documentation for every design change? The technical documentation must reflect the current state of the device. Design changes that affect items in the technical file — specifications, drawings, risk file, verification and validation records, labelling — require the relevant sections of the technical file to be updated. The update is part of the change implementation, not a separate bookkeeping task. The design and development file (post 298) carries the running record of the change history alongside the outputs.

What is the difference between clause 7.3.9 and software change control under the software lifecycle standard? Clause 7.3.9 is the QMS-level design change control requirement that applies to all design changes. The software lifecycle standard adds software-specific change control obligations on top, including software change analysis and regression testing expectations. For a software-containing device the two processes are integrated, not run as parallel duplicate boards. Posts 411 and 412 cover the software-specific mechanics in detail.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers, including the quality management system obligation) and Article 120 (transitional provisions, including the significant change in design or intended purpose test for legacy devices). Official Journal L 117, 5.5.2017, as amended.
  2. Regulation (EU) 2023/607 of the European Parliament and of the Council of 15 March 2023 amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards the transitional provisions for certain medical devices and in vitro diagnostic medical devices. Official Journal L 80, 20.3.2023. The amendment that extended the Article 120 transitional period.
  3. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 7.3.9 (Control of design and development changes). The harmonised standard providing presumption of conformity with the design change control aspects of MDR Article 10.

This post is part of the Quality Management Under MDR cluster in the Subtract to Ship: MDR blog, linking up to the QMS pillar at post 276. Authored by Tibor Zechmeister and Felix Lenhard. The MDR is the North Star. EN ISO 13485:2016+A11:2021 is the tool. Clause 7.3.9 is where a startup decides whether iteration is an asset or a liability — and the difference is whether the change was written down before it shipped.