Change management in a regulated environment is the discipline of classifying every change by its impact on safety, performance, and the basis of conformity, and routing it through a process proportional to that impact. EN ISO 13485:2016+A11:2021 clauses 4.1.4 and 7.3.9, MDR Article 120, and MDCG 2020-3 define the frame. Speed comes from knowing which changes need a full loop and which do not, not from skipping the loop.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN ISO 13485:2016+A11:2021 clause 4.1.4 requires changes to QMS processes to be evaluated for their impact on the QMS and on the devices.
  • Clause 7.3.9 requires design and development changes to be identified, reviewed, verified, validated as appropriate, and approved before implementation.
  • MDR Article 120 and MDCG 2020-3 define what a "significant change in design or intended purpose" means for legacy devices under the transitional regime.
  • Not every change needs a Notified Body notification. The classification of the change drives the process.
  • Administrative, minor, and significant changes each have their own rhythm. Treating them all the same is the single biggest source of compliance drag in startups.
  • Pace without recklessness means disciplined triage, parallel paths, and decision documents that survive an audit.

Why this matters

In a startup, change is the product. You ship, you learn, you change. The uncomfortable truth about regulated product development is that the regulation was not written to stop you from changing things. It was written to make sure that every change is evaluated, the evaluation is recorded, and the device remains safe and compliant after the change. Those are two very different problems, and founders who conflate them end up either moving too slowly or moving unsafely.

We have watched startups freeze for six weeks because they thought every change needed a Notified Body review. We have also watched startups push a firmware update to a Class IIb device without any review at all, then spend four months in remediation when the next audit caught it. Both failures come from the same root: no internal change classification.

The good news is that the regulation and the standards give you a clear framework for this. You do not have to invent it. You have to implement it.

What MDR and the standards actually say

EN ISO 13485:2016+A11:2021 clause 4.1.4 requires the organization to evaluate the impact of changes to the quality management system on the medical devices produced under that system, and to control those changes in accordance with the requirements of the standard and applicable regulatory requirements. That is the general QMS-level rule.

Clause 7.3.9 Control of design and development changes. Changes to design and development shall be identified. Before implementation, the changes shall be reviewed, verified, validated as appropriate, and approved. The review of design and development changes shall include evaluation of the effect of the changes on constituent parts and product already delivered. Records of changes, their review, and any necessary actions shall be maintained. This is the specific rule for everything inside the device itself: requirements, architecture, components, software, labeling, instructions.

MDR Article 120 governs the transitional provisions for devices certified under the old Directives (the MDD and AIMDD), as amended by Regulation (EU) 2023/607. It constrains what changes can be made to such legacy devices without triggering a full MDR conformity assessment. Article 120(3) allows continued placing on the market provided there are no "significant changes in design or intended purpose." The question becomes: what counts as significant?

MDCG 2020-3 (Guidance on significant changes regarding the transitional provision under Article 120 of the MDR) answers that question with flowcharts. It distinguishes between changes in design, changes in intended purpose, changes in software, and changes in materials, and walks each category through a decision tree. The guidance is not legally binding, but Notified Bodies rely on it in practice, and any startup working with legacy certificates needs to know it cold.

For devices already certified under MDR, there is a separate logic: the certificate itself, the Notified Body agreement, and the device-specific Annex IX arrangements define which changes require prior notification to the Notified Body. In general, changes that affect the basis of the original conformity assessment (the design, the intended purpose, the manufacturing site, the key suppliers) need Notified Body involvement. Cosmetic, administrative, and non-safety-relevant changes generally do not, though they still need internal review under clause 7.3.9.

Plain-language translation: every change gets evaluated. The evaluation outcome decides whether the change is administrative, minor, or significant. Significant changes need a heavier process, potentially including Notified Body notification. Minor changes need a documented internal review, verification, validation as appropriate, and approval. Administrative changes need to be recorded and controlled, but do not need re-verification.

A worked example

Consider a Class IIb active wearable that measures a vital sign and runs an algorithm to alert the user. The device is CE-marked under MDR. Over one sprint the team makes four changes:

  1. Typo fix in the user manual — a missing comma in the warnings section.
  2. Alert threshold change — the algorithm's alert threshold is tuned based on PMS data, narrowing the sensitivity range by 10 percent.
  3. Replacement of the battery supplier — same chemistry, same specification, same form factor, different supplier.
  4. Addition of a new user-facing feature — a coaching screen that uses the measured data to suggest lifestyle changes.

A disciplined change process treats these four changes very differently.

The typo fix is administrative. Clause 7.3.9 still applies, which means the change has to be identified, reviewed, and approved, and the effect on product already delivered has to be considered (in this case, none). Document control updates, nothing more. No verification or validation. A startup that runs this through a full design review and a Notified Body notification is burning weeks for no reason.

The alert threshold change is a software change that directly affects the clinical function of the device. This is a substantive change under clause 7.3.9. It needs review, verification (does the algorithm still do what its requirements specify), validation (does it still meet user needs), risk management update (does narrowing the sensitivity change the risk profile), clinical evaluation update, and likely a Notified Body notification under the existing certificate, because it touches the basis of conformity. If this were a legacy MDD device under Article 120, MDCG 2020-3 would almost certainly flag it as a significant change.

The battery supplier replacement is a change to a design input and a supplier relationship. Clause 7.3.9 applies. Clause 7.4 on purchasing applies. The question is whether the new supplier's component is demonstrably equivalent: same specification, same qualification, same biocompatibility status, same electrical characteristics, same safety file. If the answer is yes and the team can document the equivalence, it can be a minor change handled with verification and supplier qualification records. If there is any functional or safety difference, it escalates.

The new coaching feature is a scope change. It potentially changes the intended purpose, which is the most sensitive of all changes. If coaching crosses into a new clinical claim, it could trigger re-classification, new clinical evidence requirements, updated labeling, and mandatory Notified Body involvement. Under MDCG 2020-3 logic, a change in intended purpose is categorically significant. This change needs to be triaged at the concept stage, before a line of code is written.

The point of the example: one sprint, four changes, four different paths. A startup that runs all four through the same heavy process wastes its time. A startup that runs all four through the same light process endangers its certificate and its users. The job of change management is to assign each change to the right path within hours of the change being proposed.

The Subtract to Ship playbook

1. Write a one-page change classification SOP. Three categories: administrative, minor, significant. For each category, define what it means, what evidence is required, who approves it, and whether the Notified Body has to be notified. This single document, correctly used, will save more time than any tool in your QMS.

2. Triage changes at proposal, not at implementation. The question "is this significant?" is cheap to answer at the whiteboard and expensive to answer after the code is written. Every proposed change gets a five-minute triage by a named role (usually the regulatory or QA lead) before it enters the backlog.

3. Run parallel paths. Non-significant work does not wait for significant work. A typo fix does not wait for a Notified Body notification. An internal infrastructure refactor does not wait for a clinical evaluation update. Clause 7.3.9 does not require serial processing. It requires controlled processing. Those are different things.

4. Keep a single change register. Every change, regardless of category, lands in one register with a ticket number, a category, an owner, a status, and links to the evidence. Auditors love a good change register. So do founders trying to understand what shipped last quarter.

5. For software, define "significant" before you need it. MDCG 2020-3 gives you the logic. Put the logic into your software change control SOP with worked examples specific to your device. When a developer asks "is this significant?" they should be able to self-answer in most cases, and escalate only the genuinely ambiguous ones.

6. Document the negative decisions. "We considered this change significant and concluded it is not, because X, Y, Z." That sentence, in a dated approved document, is what turns a potential audit finding into a non-issue. Under clause 4.2 and 7.3.9 together, the rationale is as important as the decision.

7. Budget time for Notified Body communication. Significant changes that require prior notification will take weeks to process on the Notified Body side. Plan for it. Put it in the product roadmap. Do not treat Notified Body response time as a surprise.

8. Review the change register at every management review. Clause 5.6 requires management review of the QMS. The change register is one of the inputs. Trends in the register (too many changes in one category, recurring change reasons, long cycle times) are diagnostic signals about your development process. Use them.

Reality Check

  1. Do you have a written change classification SOP that distinguishes administrative, minor, and significant changes?
  2. Can every engineer on your team self-classify a typical change in under five minutes?
  3. Do you have a single change register that spans product, QMS, labeling, and supplier changes?
  4. When you made your last software change, did you document the rationale for whether it was significant?
  5. Do your non-significant changes run in parallel with significant ones, or does everything wait in the same queue?
  6. If a Notified Body auditor asked for the change history of any one document in your technical file, could you produce it in an hour?
  7. Are the change categories in your SOP aligned with MDCG 2020-3 logic, even if your device is MDR-certified rather than legacy?
  8. When was the last time management review looked at change register trends rather than individual changes?

Frequently Asked Questions

Does every design change require verification and validation? EN ISO 13485:2016+A11:2021 clause 7.3.9 requires changes to be reviewed, verified, validated "as appropriate," and approved. "As appropriate" is doing real work in that sentence. A typo fix in the user manual does not need verification testing. A change to an algorithm that affects a clinical alert does. The classification of the change determines the depth of the required activities, and that classification must itself be documented.

Does MDCG 2020-3 apply to devices certified under MDR? Strictly, MDCG 2020-3 is written for the Article 120 transitional regime, which covers devices placed on the market under legacy Directives. For MDR-certified devices, the change control logic comes from the certificate itself, the QMS, and the agreement with the Notified Body. In practice, many startups use MDCG 2020-3 as a reference logic because it is clear and well known, but the formal legal basis is different.

What happens if we fail to notify the Notified Body of a significant change? At best, a major nonconformity at the next audit with required corrective action. At worst, suspension or withdrawal of the certificate, which in practice means the device cannot legally be placed on the EU market until resolved. This is not a theoretical risk. It is one of the more common serious findings.

How fast can a small team actually move under this framework? Fast, if the triage is disciplined. Most changes in most MedTech startups are administrative or minor. Those should move at startup speed. The handful of significant changes per quarter move at regulated speed. The total drag on the team is much lower than people fear, provided the classification happens at proposal and not after the fact.

Can we use agile sprints inside this? Yes. EN ISO 13485 does not mandate a waterfall process. It mandates controlled design and development with evidence. Agile sprints with proper story-level traceability, sprint-level reviews, and release-level design reviews satisfy the standard if implemented rigorously. The key is that the regulatory artifacts are produced continuously, not retrofitted at the end.

What about emergency changes to address a safety issue? Emergency change procedures are legitimate and common. They still need to be documented, approved, and evaluated for impact. Clause 8.3 on nonconforming product and the CAPA process in clause 8.5 interact here. An emergency change without a subsequent full review is an audit finding waiting to happen.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 120.
  2. EN ISO 13485:2016+A11:2021, Medical devices — Quality management systems — Requirements for regulatory purposes. Clauses 4.1.4, 7.3.9.
  3. MDCG 2020-3, Guidance on significant changes regarding the transitional provision under Article 120 of the MDR with regard to devices covered by certificates according to MDD or AIMDD.