---
title: Significant Change in Software Under MDR: How to Evaluate If Your Update Is Significant
description: Not every software update is a significant change under MDR. Here is the evaluation framework that decides whether your update needs NB notification.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: significant change software MDR
canonical_url: https://zechmeister-solutions.com/en/blog/significant-change-software-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Significant Change in Software Under MDR: How to Evaluate If Your Update Is Significant

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **A software update is a significant change under MDR when it alters intended purpose, affects the classification of the device, changes the clinical decision algorithm or the interpretation of outputs, invalidates elements of the clinical evaluation, or moves the device outside the boundary of what the Notified Body already assessed. Everything else — defect fixes that restore intended behaviour, cybersecurity patches that preserve the intended secure state, refactors without behavioural change, infrastructure changes, and documentation-only updates — is normally not significant. The evaluation is made per change, against the criteria in MDCG 2019-11 Rev.1 and the framing in Annex IX Sections 2.4 and 4.10, with a written rationale attached to the change record in the EN 62304:2006+A1:2015 change control process. For legacy devices still on the market under the Article 120 transition, a separate significance test runs in parallel. The decision is not about code volume or effort. It is about whether the regulatory identity of the device has moved.**

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

---

## TL;DR

- Significant change for software under MDR is defined through Annex IX Sections 2.4 and 4.10 for certified devices and Article 120 for legacy devices in transition, operationalised for software by MDCG 2019-11 Rev.1 (June 2025).
- The evaluation is a per-change decision, not a per-release decision. A single release can contain one significant change and twenty non-significant ones, and each has to be judged individually with its own written rationale.
- A four-question test captures the substance of the guidance: has the intended purpose changed, has the classification changed, has the clinical or safety claim moved, and has the change left the boundary of what the Notified Body already assessed.
- Most defect fixes and security patches are not significant. Most changes to the clinical algorithm or intended purpose are. Borderline cases exist and should be discussed with the Notified Body in advance.
- The documentation that defends the decision matters as much as the decision itself. An auditor will rarely argue with a clean evaluation record against the MDCG criteria. An auditor will always open a finding on a decision made informally.

---

## Why this question is unavoidable

Every software team that ships a CE-marked device runs into the significant change question within months of release. A defect is found and a fix is ready. A customer requests a feature. A new operating system version breaks a dependency and the workaround changes behaviour in a small way. A vulnerability report lands and a patch needs to go out within the week. Each one triggers the same question: do we need to go back to the Notified Body before this ships.

The instinct in well-run teams is to ask the Notified Body for every change, because "safer to ask" feels defensible. The instinct in poorly run teams is to ask for none, because "it is just a bug fix" feels obvious. Both instincts are wrong. The regulation sets up a specific test that applies per change, and that test produces different answers for different changes in the same release. Running the test properly is the only way to make the decision defensible in both directions — no unnecessary Notified Body consultations, and no uncovered changes slipping onto the market.

Post 411 covered the higher-level question of when a software update requires a new conformity assessment. This post zooms in on the significance evaluation itself: how to run it, what questions to ask, where the borderline cases sit, and what the documentation needs to look like.

## The significant change question as MDR frames it

MDR uses "significant change" in two distinct structural places, and confusing them is the first mistake teams make.

Annex IX Section 2.4 applies to the approved quality management system. It requires the manufacturer to inform the Notified Body of any planned substantial changes to the QMS or the range of products covered, and the Notified Body assesses whether the changes affect the fulfilment of MDR requirements and confirms whether the existing approval remains valid or whether a supplementary assessment is needed. Annex IX Section 4.10 applies to the approved type or approved design. It requires the manufacturer to seek Notified Body approval for any changes to the approved design that could affect conformity with the general safety and performance requirements or the conditions prescribed for use of the device.

For a software manufacturer with a certified device in active maintenance, Section 4.10 is usually the operative provision: is this software change a change to the approved design that could affect conformity, or is it a change that sits inside what the existing certificate already covers. Section 2.4 sits alongside and captures changes to the QMS itself — a different scope.

Article 120 is the transitional provision. For a legacy device still on the market under a Directive certificate and benefitting from the extended MDR transition, Article 120 requires that there be no significant changes in design or intended purpose since the Directive certificate was issued. A significant change under Article 120 ends transitional coverage and forces the device onto full MDR conformity assessment. This is a separate test that runs in parallel with the Annex IX test for any legacy device still in transition.

For most new software manufacturers certifying under MDR from the start, the Annex IX test is the one that matters every day. For acquired or in-licensed legacy products in transition, both tests apply.

## MDCG 2019-11 Rev.1 — the software-specific framing

MDCG 2019-11 Rev.1 is the guidance document that operationalises qualification and classification of medical device software under the MDR, and Rev.1 (June 2025) is the version every team must work from. Alongside its classification content, the guidance addresses changes to software — framing which kinds of modification move a medical device software across the threshold into a change that requires fresh regulatory consideration.

The spirit of the guidance is consistent. Changes that touch the regulatory identity of the device — what the software does clinically, for whom, in what context, on what claim — are candidates for significant. Changes that preserve that identity while improving reliability, security, or implementation quality are candidates for non-significant. "Candidates" is deliberate: every change is still evaluated on its merits against the criteria, and the written rationale is what defends the decision at audit. The guidance does not remove the judgement; it structures it.

Two categories are misjudged the most often and deserve specific treatment. Cybersecurity patches that restore the intended secure state are normally not significant, because the device was always supposed to be secure and the patch is maintaining that state rather than altering it. Performance improvements to a clinical algorithm are often significant, because "better performance" usually implies a different clinical claim, and changed clinical claims are exactly what the significance concept is designed to catch. Both categories can invert in edge cases, which is why the evaluation must actually run.

## The four-question test

The substance of the evaluation fits in four questions. Run them in order on every individual change, with a documented answer and reasoning for each. If any answer is yes, the change is a candidate for significant and the next step is a structured evaluation against the full MDCG 2019-11 Rev.1 criteria and, if warranted, a Notified Body consultation. If all four answers are no with a clean rationale, the change is non-significant and handled inside the QMS with an EN 62304:2006+A1:2015 change control record.

**Question 1 — Has the intended purpose moved?** Does the change add a new clinical use, a new patient population, a new indication, a new clinical setting, a new claim in labelling or promotional material, or a new measurement or output that a clinician would rely on differently? A yes on this question is the strongest signal of significance.

**Question 2 — Has the classification changed?** Does the change cause the device to meet a higher classification rule — most commonly, Rule 11 considerations for software — or to require different conformity assessment? A yes here means the change is definitionally outside the scope of the existing certificate.

**Question 3 — Has the clinical or safety claim moved?** Does the change alter the clinical decision algorithm in a way that affects the output, alter how users interpret the output in a way that affects safety, invalidate part of the clinical evaluation, weaken a risk control, or introduce a new hazard that the risk file does not currently address? A yes on any of these is a candidate for significant.

**Question 4 — Has the change left the boundary of what the Notified Body assessed?** Would a reasonable auditor, reading the current technical documentation and the current change, conclude that the change introduces something the assessment did not cover — a new software architecture element, a new interoperability surface, a new operating environment, a new third-party component with its own risk profile? A yes means the picture the Notified Body signed off on is no longer complete.

Four no answers with documented reasoning is a non-significant classification. Any yes triggers the full evaluation and, in most cases, Notified Body consultation before release.

## Worked examples

A defect fix restoring intended behaviour. A calculation bug produces incorrect values in edge cases. The fix restores the intended behaviour described in the requirements and verified in the original V&V. Intended purpose unchanged. Classification unchanged. Clinical claim unchanged (the original claim always assumed correct behaviour). Boundary of assessment unchanged. Four no answers. Not significant. Handled through EN 62304:2006+A1:2015 change control with a normal change record.

A cybersecurity patch for a third-party library vulnerability. The patch updates a dependency to a fixed version. No functional behaviour changes. The device remains in its intended secure state. Four no answers. Not significant. Recorded with the rationale that the patch maintains the intended secure state rather than altering it.

An algorithm performance improvement retraining the model. The clinical decision algorithm is retrained on additional data and the published sensitivity and specificity change. Question 3 is a clear yes — the clinical claim has moved. Significant. Notified Body consultation before release, with the change substantiated by updated clinical evaluation.

A new measurement output added to the user interface. A new numerical value is displayed to the clinician alongside existing outputs, derived from existing data. Question 1 — intended purpose — is very likely a yes, because a new measurement the clinician may act on expands the clinical utility claim. Significant.

A refactor of the deployment pipeline with no behaviour change. The CI/CD pipeline is restructured. The build output is byte-identical. No device behaviour changes. Four no answers. Not significant.

A change to interoperability with hospital information systems adding new data fields. Question 4 — boundary of assessment — is a candidate yes, because the interoperability surface the Notified Body assessed has been extended. Depending on the data fields and the clinical use, possibly also Question 1. Likely significant.

These examples are illustrative, not binding. Every team runs its own evaluation on its own change.

## When to notify the Notified Body — and when not

Notify the Notified Body when the four-question test produces a yes on any question that survives the full MDCG 2019-11 Rev.1 evaluation, when the change is a substantial modification of the approved design under Annex IX Section 4.10, when the change would affect conformity with any general safety and performance requirement, or when there is genuine uncertainty on a borderline case. Notification happens before the change is released, not after.

Do not notify for changes that produce four clean no answers — defect fixes that restore intended behaviour, security patches that maintain the intended secure state, behaviourally-neutral refactors, infrastructure changes, documentation-only changes, or performance improvements that do not move the clinical claim. Handle these inside the QMS and the EN 62304:2006+A1:2015 change control process, with the evaluation record attached to the change.

The borderline cases deserve specific treatment. When a change sits close to the line — the evaluation is not unambiguously no on all four questions, but also not clearly yes on any — the right move is an informal conversation with the Notified Body contact before a formal notification, framed as "here is the change, here is our preliminary evaluation, does this match your view." Notified Bodies generally prefer the early conversation over either a formal submission for a non-issue or a skipped conversation on a real one.

## The documentation that supports either decision

The documentation behind the decision is often what determines whether the decision holds up at audit. For each software change, the record should contain: a description of the change, the affected items in the software architecture and in the technical documentation, the evaluation against each of the four questions with reasoning, the reference to MDCG 2019-11 Rev.1 Rev.1 and to Annex IX Sections 2.4 and 4.10, the decision (significant or non-significant), the name of the approver, the date, and the link to the EN 62304:2006+A1:2015 change control record that implemented the change.

For non-significant decisions, the record is the defence. An auditor reading a clean evaluation against the guidance, with documented reasoning on each question, will generally accept the decision. For significant decisions, the record is the starting point for the Notified Body submission and the input to the supplementary assessment.

The technical file, the risk management file, and the clinical evaluation must also reflect the change regardless of significance classification. Non-significant does not mean invisible. The technical documentation is always kept current, and EN 62304:2006+A1:2015 requires traceability from requirements through implementation to verification for every change.

## Common mistakes

**Treating significance as a per-release decision.** Every individual change in a release needs its own evaluation. A release that groups a defect fix, a cybersecurity patch, and an algorithm retrain must evaluate each of those three changes separately, not average them into one verdict.

**Using diff size as a proxy for significance.** Small changes can be highly significant. Large changes can be non-significant. The evaluation is about what the change does to the regulatory identity of the device, not how many lines of code moved.

**Substituting internal judgement for the MDCG 2019-11 Rev.1 criteria.** Internal judgement is fine as input. It is not an acceptable sole basis for the decision. The written evaluation references the guidance and the Annex IX provisions explicitly.

**Forgetting the Article 120 parallel test.** For legacy devices in transition, the Article 120 significance test runs alongside the Annex IX test on every change. Skipping it because "we already ran the Annex IX test" misses the independent legal test on transitional coverage.

**Skipping the documentation on non-significant decisions.** The decision that a change is not significant is only defensible if the evaluation record exists. A decision made informally, without written reasoning against the criteria, will not survive an audit challenge.

**Conflating EN 62304:2006+A1:2015 change control with significance evaluation.** EN 62304:2006+A1:2015 change control runs on every change regardless of significance. The significance evaluation runs on top. Collapsing the two layers into one — either by skipping EN 62304 on small changes, or by treating every EN 62304 change as significant — is a common failure mode.

**Over-reporting out of caution.** Flooding the Notified Body with notifications on non-significant changes drains your consultancy budget, slows down your real submissions, and trains the Notified Body to treat your changes as noise. The correct answer to "safer to ask" is not "ask every time" — it is "run the evaluation every time and ask when the evaluation says to."

## The Subtract to Ship angle

The Subtract to Ship framework (post 065) applied to significance evaluation strips the process down to what the regulation and MDCG 2019-11 Rev.1 actually require: a per-change evaluation against criteria that map to Annex IX, a written rationale, a decision, and a link to the EN 62304:2006+A1:2015 change control record. That is the whole process. Everything else — the weekly change boards, the multi-stage approval workflows, the ceremonial review meetings, the template forms with twenty pages of boilerplate — is optional and only justified if it makes the required evaluation happen more reliably.

The lean version is a one-page evaluation form, completed per change, signed by the named approver, and stapled to the EN 62304:2006+A1:2015 change record. One page because one page is enough for four questions with reasoning. Signed by a named approver because the regulation requires a decision and a decision needs an owner. Stapled to the change record because the significance evaluation sits on top of the change control process, not beside it.

Every extra layer added to this process should trace to a specific provision in Annex IX, MDCG 2019-11 Rev.1, or EN 62304:2006+A1:2015. If it does not, cut it. The process that survives the cut runs fast enough to apply on every change and rigorous enough to defend at audit — which is the only combination that works when releases are frequent.

## Reality Check — Where do you stand?

1. Do you have a written significance evaluation procedure that explicitly references MDCG 2019-11 Rev.1 and Annex IX Sections 2.4 and 4.10?
2. Is the evaluation run per change rather than per release, with individual rationale for each change in the release?
3. For the last ten software changes, can you show the completed significance evaluation record for each one?
4. Does your non-significant classification decision carry a documented rationale against each of the four questions, or is it implicit?
5. Is the significance evaluation integrated with the EN 62304:2006+A1:2015 change control record, or running as a separate parallel process?
6. If your device is a legacy product in Article 120 transition, are you running the Article 120 significance test alongside the Annex IX test on every change, with separate documentation?
7. When was the last borderline change you discussed informally with the Notified Body before a formal submission, and what did that conversation change?

## Frequently Asked Questions

**What makes a software change "significant" under MDR?**
A software change is significant under MDR when it alters the intended purpose, changes the classification, moves the clinical or safety claim, or leaves the boundary of what the Notified Body already assessed. MDCG 2019-11 Rev.1 provides the software-specific criteria and Annex IX Sections 2.4 and 4.10 provide the legal framing for certified devices. Changes that do not touch any of these elements — defect fixes, security patches that maintain the intended secure state, behaviourally-neutral refactors — are normally not significant.

**Is a bug fix a significant change?**
Normally no. A defect fix that restores the intended behaviour described in the original requirements and verified in the original V&V preserves the regulatory identity of the device and is handled inside the QMS with an EN 62304:2006+A1:2015 change control record and a documented non-significant rationale. The exception is a fix that changes the device's behaviour beyond restoring intent — for example, a fix that implements a new interpretation of the requirement rather than correcting a failure to meet the original interpretation.

**Can a single release contain both significant and non-significant changes?**
Yes, and this is the normal case. Significance is evaluated per individual change, not per release. A release that groups ten changes may contain one significant change and nine non-significant ones. Each change gets its own evaluation record, and the significant one triggers Notified Body consultation while the others do not.

**How does Article 120 significance differ from Annex IX significance?**
Article 120 applies only to legacy devices on the market under Directive certificates during the extended MDR transition and asks whether a change ends transitional coverage. Annex IX Sections 2.4 and 4.10 apply to devices already certified under MDR and ask whether a change requires Notified Body consultation on the existing certificate. They are independent tests answering different questions. A legacy device in transition runs both tests on every change; a device certified under MDR from the start runs only the Annex IX test.

**What documentation do I need for a non-significant decision?**
A written evaluation record that describes the change, answers the four significance questions with reasoning, references MDCG 2019-11 Rev.1 and Annex IX, records the decision and the approver, and links to the EN 62304:2006+A1:2015 change control record for the implementation. The record is the defence of the decision at audit. Without it, the decision is undocumented and unreliable regardless of whether it was substantively correct.

## Related reading

- [Software Updates Under MDR: When Does an Update Require a New Conformity Assessment?](/blog/software-updates-mdr-new-conformity-assessment) — the higher-level companion post on conformity assessment triggers.
- [MDR Design Changes: How ISO 13485 Helps You Manage Iterations Without Losing Compliance](/blog/mdr-design-changes-iterations) — the QMS-level design change control process that sits beneath software change control.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology behind the lean significance evaluation described above.
- [Software Change Control Under EN 62304, Part 1](/blog/software-change-control-en-62304-part-1) — the EN 62304:2006+A1:2015 change control process that every software change runs through.
- [Cybersecurity Patches and MDR Annex I Section 17](/blog/cybersecurity-patches-mdr-annex-i-17) — the specific case of security updates and why they are normally not significant.
- [Notified Body Consultations for Software Changes](/blog/notified-body-consultations-software-changes) — how to structure the borderline conversation with the Notified Body.
- [MDCG 2019-11 Rev.1 and Software Classification Under Rule 11](/blog/mdcg-2019-11-software-classification-rule-11) — the classification framework behind significance Question 2.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 120 (transitional provisions, including the significant change in design or intended purpose test for legacy devices), Annex IX Section 2.4 (information on substantial changes to the approved quality management system and product range) and Annex IX Section 4.10 (changes to the approved type or approved design requiring Notified Body approval). Official Journal L 117, 5.5.2017.
2. MDCG 2019-11 Rev.1 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR, October 2019, Revision 1 June 2025. The operational criteria for evaluating software changes against the significant change concept.
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). The harmonised standard defining the change control process that every software change runs through, independent of significance classification.

---

*This post is part of the Software as a Medical Device series in the Subtract to Ship: MDR blog, linking up to the MDR Fundamentals pillar at post 001. Authored by Tibor Zechmeister and Felix Lenhard. The significance evaluation is a judgement the regulation asks a software manufacturer to make on every change — and the defensibility of the judgement lives entirely in the written record against the criteria, not in the confidence of the person making it.*

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*