---
title: The Predetermined Change Control Plan (PCCP) for AI Medical Devices
description: PCCP is FDA terminology. Here is how to build an equivalent change control plan for AI medical devices under the MDR significant change framework.
authors: Tibor Zechmeister, Felix Lenhard
category: AI, ML & Algorithmic Devices
primary_keyword: predetermined change control plan AI MDR
canonical_url: https://zechmeister-solutions.com/en/blog/pccp-ai-medical-devices
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# The Predetermined Change Control Plan (PCCP) for AI Medical Devices

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

> **PCCP is FDA terminology. There is no formal equivalent under MDR. Under MDR, changes to a CE-marked AI device are governed by the "significant change" framework anchored in Article 120 and interpreted through MDCG 2020-3 and MDCG 2019-11 Rev.1. You can still build a PCCP-style plan under MDR — a locked envelope of pre-specified update categories, acceptance criteria, and evidence retention — but it operates informally as part of your QMS change control, not as a formally approved FDA-style instrument.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- "Predetermined Change Control Plan" is FDA terminology formalized in the 2023 FDA guidance on PCCPs for AI/ML-enabled device software functions. MDR has no equivalent formal instrument.
- Under MDR, change management for an AI device is governed by the QMS under EN ISO 13485:2016+A11:2021, software lifecycle requirements under EN 62304:2006+A1:2015, and the "significant change" test anchored in Article 120 and interpreted via MDCG 2020-3 and MDCG 2019-11 Rev.1.
- A significant change requires a new conformity assessment. A non-significant change can be handled within your existing QMS change control.
- You can still pre-specify which updates you intend to perform, what evidence you will generate, and what controls bound them. This is good engineering and good regulatory hygiene — but it does not get pre-approved by a Notified Body the way an FDA PCCP gets pre-approved.
- For startups targeting both EU and US markets, aligning your internal PCCP-style document to serve both regimes is practical and efficient.
- Do not call your EU document a "PCCP" in technical documentation. Call it a "change control plan" or "software update plan" to avoid creating the impression of a regulatory instrument that does not exist under MDR.

## Why this matters

Every AI founder I talk to has read about PCCPs. The FDA published its final guidance in 2023, and suddenly the MedTech press started treating PCCPs like a global concept. They are not. The PCCP is a US regulatory instrument, specific to FDA, with a clear legal basis in Section 515C of the Federal Food, Drug, and Cosmetic Act as added by the Food and Drug Omnibus Reform Act of 2022. None of that exists in EU law.

The founder question that follows is reasonable: "Okay, so what's the EU equivalent?" The honest answer is: there isn't one, and anyone who tells you otherwise is oversimplifying. The closest equivalent is the "significant change" framework under MDR Article 120, interpreted through MDCG 2020-3 (originally written for legacy MDD devices transitioning to MDR, but whose significant change reasoning is widely applied) and MDCG 2019-11 Rev.1 for software-specific change assessment.

This matters because if you build your AI update strategy around an FDA PCCP without understanding the EU gap, you will hit the first significant update and discover that your Notified Body wants a full change review that you did not plan for. The consulting demand here is not manufactured — it is the direct consequence of a genuine regulatory mismatch between two major markets.

## What MDR actually says

MDR is silent on AI. It is also silent on PCCPs. What it does say about changes is scattered across several articles.

**Article 120 — Transitional provisions**, as amended by Regulation (EU) 2023/607. The article governs the continued validity of certificates issued under the old directives and, critically, the principle that no "significant changes in design or intended purpose" may be made to legacy devices without triggering a new MDR conformity assessment. Although Article 120 is written for legacy transitions, the "significant change" concept it relies on has become the reference test used by Notified Bodies for all devices when assessing whether an update requires a new conformity assessment.

**Annex IX — Conformity assessment based on a QMS and on assessment of technical documentation.** Section 2.4 is the piece that matters for ongoing changes: "The manufacturer shall inform the notified body which approved the quality management system of any plan for substantial changes to the quality management system or the device-range covered." Substantial changes to a CE-marked device must be approved by the Notified Body. Non-substantial changes flow through your QMS change control.

**Annex I §17.2** — Software-specific state of the art requirement. The state of the art includes planned change management. EN 62304:2006+A1:2015 §6 is the software maintenance process that operationalizes this. Changes must be analyzed, classified, verified, validated, and documented.

**EN ISO 13485:2016+A11:2021 §7.3.9** — Control of design and development changes. Changes must be identified, reviewed, verified, validated, and approved before implementation. This is where your internal change control lives.

**MDCG 2020-3** — Guidance on significant changes regarding the transitional provision under Article 120 of the MDR. The guidance provides a flowchart and decision criteria to determine when a change is "significant." Although it was written for the transitional context, the decision logic (changes to intended purpose, to design or performance specifications, to software, etc.) is now the lingua franca for significant-change assessment across the industry.

**MDCG 2019-11 Rev.1** — Guidance on qualification and classification of software in Regulation (EU) 2017/745. While primarily a classification guidance, it informs how software changes should be assessed — particularly whether a change to an AI model alters the intended purpose or claimed performance.

Nothing in any of these documents grants you a pre-approved envelope of "allowed future changes" the way an FDA PCCP does. Under MDR, each significant change is assessed at the time it is made, by the Notified Body, against the current technical documentation.

## A worked example

A startup has CE-marked a Class IIa AI device for stratifying patients by fall risk from accelerometer data. Intended purpose: "Estimate fall risk over the next 90 days in adults over 65 in residential care settings, based on seven days of continuous wearable accelerometer data."

The founder wants a retraining cadence: quarterly updates using fresh anonymized data from deployment sites, with model weights updated but architecture and intended purpose held constant. In the US, this would map onto a PCCP that specifies the data sources, retraining protocol, acceptance metrics, and performance envelope, submitted to FDA and pre-approved as part of the device authorization.

Under MDR, here is how the same plan looks.

**The change control plan (internal document, not an FDA-style PCCP):**
- **What may change:** model weights only. Architecture, preprocessing, input features, output interpretation, intended purpose, and labeled risk categories are locked.
- **Trigger criteria:** quarterly retraining using the prior quarter's deployment data, subject to data curation and bias checks passing.
- **Acceptance criteria:** new model must match or exceed the locked validation performance envelope (sensitivity, specificity, calibration) on the held-out test set, with no subgroup degradation exceeding 2 percentage points.
- **Evidence retention:** each retraining produces a dated validation report, signed, stored in the design history file, referenced in the risk management file.
- **Change classification process:** each retraining is assessed against MDCG 2020-3 and MDCG 2019-11 Rev.1 criteria. If the change meets the definition of significant, the Notified Body is notified and a new conformity assessment is triggered before deployment.
- **Locked envelope philosophy:** as long as performance stays within the pre-defined envelope and no subgroup regresses, the change is analyzed as non-significant, handled in QMS change control per EN ISO 13485 §7.3.9, with full documentation.

**What this plan does:**
- Forces discipline at the engineering layer. The team cannot push a retrained model without the validation evidence.
- Demonstrates to the Notified Body at audit that you have thought through change control rigorously.
- Creates a paper trail that survives personnel changes.
- Aligns with what an FDA PCCP would look like if you later file in the US.

**What this plan does NOT do:**
- It does not get pre-approved by the Notified Body as an envelope of allowed changes. Every update still passes through the significant-change test at the time it is made.
- It does not exempt you from informing the Notified Body when the change is significant per Annex IX §2.4.
- It does not create a legal safe harbor. If a reviewer later disagrees that a particular retraining was non-significant, you may face a finding.

For most startups, this is the honest state of play. Build the plan. Call it a change control plan, not a PCCP. Use it to run your engineering process cleanly and to present a credible change management story at audit.

## The Subtract to Ship playbook

**Step 1 — Decide if your device is locked or adaptive.** A locked model with planned periodic retraining is the default path under MDR. A continuously learning system is regulatorily unresolved under current EU law — see our [locked vs adaptive AI algorithms under MDR](/blog/locked-vs-adaptive-ai-algorithms-mdr) post for the framework.

**Step 2 — Write the change control plan early.** Not after CE. Before. It forces you to think through what you will change, how you will know it is safe, and how you will prove it.

**Step 3 — Classify each planned change using MDCG 2020-3 decision logic.** The flowchart asks: does it change intended purpose? Does it extend indications? Does it affect safety or performance in a way not covered by the existing assessment? Does it change the software architecture or core algorithm? If any of these, the change is likely significant. Document the reasoning in writing.

**Step 4 — Keep the envelope tight.** The narrower your pre-specified update categories, the easier the significant-change argument becomes. "Weight updates within a ±2 point subgroup performance envelope" is defensible. "Model improvements" is not.

**Step 5 — Name it correctly.** In your technical documentation, do not call the document a "PCCP" because that creates the impression of a regulatory instrument that does not exist under MDR. Call it a "Software Change Control Plan" or "AI Update Management Plan." Save "PCCP" for your FDA track if you have one.

**Step 6 — Align US and EU documents.** If you are pursuing both markets, you can maintain a single internal document that serves both a formal FDA PCCP and an informal EU change control plan. The content overlaps heavily. The regulatory weight differs. See [FDA AI/ML PCCP](/blog/fda-ai-ml-pccp) for the US specifics.

**Step 7 — Treat every retraining as an EN 62304 maintenance release.** Verification, validation, regression testing, risk file re-assessment, change log entry. No shortcuts. EN 62304 §6 and §8 govern the mechanics.

**Step 8 — Talk to your Notified Body.** Not after you push the update. Before. "Here is our planned change control approach, here are the categories of updates we intend to make, here is how we will classify each against MDCG 2020-3." A Notified Body that knows what to expect is a Notified Body that approves changes faster.

The subtract: any pretense that you can pre-approve a blanket envelope of future AI updates under MDR. You cannot. What you can do is build the discipline that survives contact with a reviewer.

## Reality Check

1. Have you documented which elements of your AI device are locked and which you plan to update?
2. Is your change control plan titled and described in a way that avoids implying an FDA-style pre-approved instrument under MDR?
3. Do you have a written procedure for classifying each change against MDCG 2020-3 and MDCG 2019-11 Rev.1?
4. Does every planned update have pre-specified acceptance criteria, including subgroup performance envelopes?
5. Is your Notified Body aware of your planned change strategy, and have you discussed it in writing?
6. Does each retraining trigger a full EN 62304 maintenance cycle and a risk management review?
7. If the Notified Body later decided a change you classified as non-significant was actually significant, do you have documented reasoning to defend the original classification?
8. Are your US and EU change control documents aligned, or are you running two incompatible processes?

## Frequently Asked Questions

**Can I use the FDA PCCP document as my MDR change control plan?**
The content can overlap heavily. The regulatory framing must differ. Under MDR, the document is an internal QMS artifact, not a pre-approved instrument. Label it accordingly.

**Does EU law allow continuously learning AI medical devices?**
Not cleanly under current MDR. Continuous learning poses a significant-change problem because the device changes in ways that may not have been part of the original conformity assessment. Most EU AI devices are therefore deployed as locked models with controlled retraining cycles.

**What happens if I deploy an update without classifying it?**
You are operating outside your QMS change control. At the next audit, this is a non-conformity. If the update turns out to have been significant, it can become a serious regulatory finding.

**Is there a Notified Body that will pre-approve an AI update envelope?**
No Notified Body can grant a formal pre-approval equivalent to an FDA PCCP under current MDR law. Some Notified Bodies will review and comment on a change control plan as part of the QMS audit, which creates alignment but not legal pre-approval.

**Will the EU AI Act change this?**
The EU AI Act creates additional obligations for high-risk AI systems, including many medical AI devices, but it does not create a PCCP equivalent or replace the MDR significant-change framework. The two regimes apply in parallel.

**How often should I update my change control plan?**
Whenever the update strategy changes, whenever MDCG guidance is revised, whenever a Notified Body provides feedback, and at least annually as part of management review under EN ISO 13485.

## Related reading
- [Locked vs adaptive AI algorithms under MDR](/blog/locked-vs-adaptive-ai-algorithms-mdr) — the design choice that drives your change control strategy.
- [Continuous learning AI under MDR](/blog/continuous-learning-ai-mdr-2026) — what is and is not feasible today.
- [AI/ML change management and retraining assessment](/blog/ai-ml-change-management-retraining-assessment) — the operational playbook.
- [Significant change for medical device software under MDR](/blog/significant-change-software-mdr) — the general framework.
- [FDA AI/ML PCCP guidance](/blog/fda-ai-ml-pccp) — the US counterpart.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 120; Annex IX §2.4; Annex I §17.2.
2. Regulation (EU) 2023/607 amending the transitional provisions of Article 120.
3. MDCG 2020-3 — Guidance on significant changes regarding the transitional provision under Article 120 MDR.
4. MDCG 2019-11 Rev.1 (October 2019, Rev.1 June 2025) — Qualification and classification of software in Regulation (EU) 2017/745.
5. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems.
6. EN 62304:2006+A1:2015 — Medical device software — Software lifecycle processes.
7. EN ISO 14971:2019+A11:2021 — Application of risk management to medical devices.

---

*This post is part of the [AI, ML & Algorithmic Devices](https://zechmeister-solutions.com/en/blog/category/ai-ml-devices) 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).*