A scalpel has not changed meaningfully since before I went to medical school. The same cannot be said for any software product I have ever worked on.
That distinction matters more than most medical device manufacturers realize when they hit the post-market phase and start asking why their regulatory process feels like it was designed for a completely different category of device. Because, largely, it was.
Regulation in Europe was built with hardware in mind. The frequency of changes, the cadence of updates, the nature of risk: all of that was framed around physical products where modifications are slow, deliberate, and expensive. Software breaks every one of those assumptions. Algorithm updates, cloud infrastructure changes, cybersecurity patches, bug fixes: these are not annual events. They happen continuously, and the cost of slowing them down is not zero.
Understanding EU MDR change control for software devices requires working through three separate problems: a vocabulary problem the regulation created, a structural mismatch between the rules and how software actually works, and a set of practical tools that most manufacturers are underusing.
A quick clarification before getting into the EU MDR specifics. Change management is the broader organizational discipline of handling modifications to products, processes, and systems. Change control is the regulatory mechanism within a quality management system that documents, evaluates, approves, and records specific changes to determine what gets reported to your notified body and when.
The distinction matters because many manufacturers apply change management practices without having documented change control procedures that satisfy what notified bodies look for during surveillance, and that gap is where compliance problems tend to accumulate.
The EU MDR regulation compounds matters with a terminology problem. Two terms, "substantial change" and "significant change," get used interchangeably in conversation. They mean entirely different things within the regulation, and confusing them is one of the most common sources of unnecessary compliance overhead.
Under EU MDR, a substantial change is a modification that requires notification to a notified body, as defined in Annex IX. A significant change is different: it refers specifically to modifications made to legacy devices still covered under the EU Medical Device Directive (EU MDD), governed by Article 120 of the MDR. If your device was certified under the MDR rather than the MDD, significant change guidance does not apply to you.
The practical consequence of this confusion is that manufacturers end up over-reporting. They treat routine product changes as if they require notified body preapproval when, for most Class IIa and IIb devices, that is not what the regulation requires.
There is a second layer to the guidance problem. The most referenced EU guidance on change management is the NBOG (Notified Body Operations Group) document from 2014, which was written against the EU MDD, not the EU MDR. The MDCG 2023-3 guidance that came after it deals specifically with significant changes, meaning legacy MDD devices. For a manufacturer certified under the EU MDR with a Class IIa or IIb device, neither document is directly applicable. The result is variability: notified bodies and competent authorities interpret the requirements differently, and manufacturers absorb that uncertainty through slower release cycles.
The substantive requirements for EU MDR change control live in Annex IX, point 2.4. In short, it requires manufacturers to notify their notified body of substantial changes to the quality management system or device ranges covered.
Changes to the quality management system typically include modifications to approved processes (risk management, design, vigilance), material changes to organizational structure, and shifts in critical suppliers or distribution. For software, this can include fundamental architectural changes that alter how the device is designed.
Changes to device ranges covered are classification-dependent. For Class IIa devices, a substantial change is triggered at the level of the MDR code; for Class IIb, it is the EMDN code. Adding or removing a code counts. Everything else generally does not.
Here is the part that surprises most manufacturers: changes to the device itself, whether to the design, safety performance, or even a model retrain, are not listed as substantial changes under Annex IX for Class IIa and IIb devices. Changes to intended purpose that would upgrade classification are an exception, but short of that, you likely have more room to move than you think.
There are three possible categories for any change under EU MDR:
The third category is the one most manufacturers underuse. A change to intended purpose that does not reclassify a device may need to be reported, but your change control procedures can define it as not requiring preapproval. You do not have to wait.
The EU MDR review timeline for a substantial change runs between 30 and 140 days. For a hardware device that ships a new version every few years, that delay is manageable. For a SaMD team running agile sprints, it is a structural obstacle.
The mismatch goes deeper than timelines. IEC 62304, the state-of-the-art standard for the software development lifecycle, was built around a sequential waterfall model: requirements, design, development, verification, release, maintenance. Software engineering has moved well beyond that. Most teams today work in agile sprints, Kanban, or DevOps pipelines. The regulation assumes a process that most modern software teams do not and should not follow.
The cost of slow change is also underestimated. For machine learning models especially, performance degrades after deployment because real-world clinical workflows are messier than training data anticipates. Third-party dependencies (open-source libraries, cloud services, APIs) go out of date. Cybersecurity vulnerabilities accumulate. The NHS learned this when legacy Windows systems became incompatible with current security software, leaving vulnerabilities that could not be patched quickly enough because the change cadence was too slow.
The result of slow change cycles is usually the opposite of what manufacturers intend. Instead of careful, incremental updates, teams accumulate large batches of changes and push one major release, which carries far more risk than a series of smaller ones.
A predetermined change control plan (PCCP) is a document in which a manufacturer pre-agrees with their notified body on specific anticipated changes before those changes are made. The PCCP specifies what those changes will be, what verification and validation activities will be carried out, what the acceptance thresholds will be, and what the risk impact assessment looks like. Once approved, the manufacturer can implement changes within the pre-agreed scope without resubmitting for notified body review each time.
The FDA was first to implement PCCPs formally, and they have since become part of the IMDRF harmonization effort. The EU is moving in the same direction. The EU AI Act references PCCPs as an expected transparency mechanism, and the most recent UK MDR statutory instrument signals similar movement. PCCPs are currently being piloted by at least one notified body in Europe, Scarlet, the UK's only approved body and an EU notified body specializing in software and AI as a medical device. They are not yet embedded in EU legislation, but the regulatory trajectory is clear.
The benefit is not just faster reviews. A PCCP defines a change category once, gets it reviewed once, and then allows the manufacturer to implement that change repeatedly without re-submitting. A model retraining cycle that would otherwise require a new submission every six months gets reviewed as a category of change rather than as a series of individual submissions. That is a meaningful reduction in ongoing compliance overhead.
For Class III devices, which do require preapproval for changes affecting safety and performance, the PCCP benefit is even more direct: it replaces a wait of up to 140 days with a review turnaround measured in days, because the notified body can confirm that the manufacturer followed the pre-agreed plan rather than conducting a full fresh assessment.
There is also an internal benefit that applies even if you never file a formal PCCP with your notified body. The discipline of predefining change categories, specifying verification activities, setting acceptance thresholds, and establishing clear release pathways is valuable on its own: it shifts human reviewers from gatekeepers who must approve every change to auditors who confirm that a pre-agreed process was followed. Removing that bottleneck alone speeds up the release cadence in a meaningful way.
The regulatory environment is not going to simplify overnight, but there are concrete procedures that help regardless of where you sit in the certification process.
Traceability designed in from the start. Requirements need to connect to changes, and changes need to connect back to requirements. For teams working in Jira or similar tools, this does not require a separate documentation layer. It requires intentionality in how tickets and pull requests are written. Regulatory reviewers need to understand the rationale for a change, what was tested, and what the outcome was. If the documentation in your engineering tools can answer those questions without reconstruction, you are already most of the way there. The same principle applies regardless of whether your team runs agile development cycles or a more structured release process.
Modular architecture. A well-defined module structure limits the scope of any individual change. Knowing exactly which module a change affects, and how it traces back to requirements, turns a potentially system-wide impact assessment into a bounded, well-documented exercise. It also makes it easier to draw a clear boundary between the medical device components and the ancillary infrastructure that has no bearing on safety or performance.
PCCP-style internal procedures. Even without a formal agreement with your notified body, predefining change categories, specifying verification and validation activities, and setting acceptance thresholds removes the ambiguity that creates approval bottlenecks. Rather than requiring sign-off before every release, your RACA reviewer can validate changes retrospectively against pre-agreed criteria, which is the same surveillance logic that notified bodies use at the formal level applied internally to your own workflow.
Structured dialogue with your notified body. The relationship does not have to be adversarial. Regular dialogue about anticipated changes, especially before they happen, reduces the chance of a surveillance review finding that your evidence was insufficient after the fact. For teams considering a formal PCCP, that dialogue is where you start.
The underlying principle in all four approaches is the same: build the compliance evidence as part of the engineering process, not as a documentation sprint after the fact. The manufacturers who move fastest are the ones who have made traceability a default property of how they work rather than an afterthought they chase before submission. For a broader look at how change management works across medical device categories, that framework applies to hardware and software alike.
If you want to go deeper on EU MDR change control requirements, the mechanics of PCCPs, and how notified bodies are currently thinking about software-specific challenges, the full on-demand webinar covers all of it, including Q&A on generative AI models, Jira-based design specifications, and how PCCP versions get updated based on post-market surveillance findings.
If you are building out your software medical device quality and change management processes, these related guides go deeper on the key components: