What IMDRF's New PCCP Document Actually Requires, and Where Cybersecurity Fits

If you ship medical device software into more than one market, you have probably been treating predetermined change control plans as an FDA thing. That is no longer a safe assumption. The International Medical Device Regulators Forum has finalised Essential Principles and Content of Predetermined Change Control Plans, catalogued as IMDRF/SaMD WG/N90 FINAL:2026, and it sets out what regulators and manufacturers around the world should expect a PCCP to look like.

Let's be precise about its status. The document says it does not establish regulatory requirements, does not interpret or replace any jurisdiction's laws, and does not define which specific changes may go into a PCCP. It is a convergence document. This matters because some local regulators will build their own rules on top of it, and because it tells you now what those rules will probably ask for.

A PCCP cannot stretch what your device is for

The first of IMDRF's five principles constrains everything that follows. It calls this being focused and bounded. A PCCP describes planned changes with enough specificity to show the software stays safe and effective, and those changes are limited to modifications within the original intended use or intended purpose. So a PCCP is not permission for a product to evolve. It is permission to make changes you already scoped, inside a purpose you already declared. The document gives its own example of what stays inside the line: a model update using newer data to widen the subset of an existing patient population, which qualifies precisely because the intended purpose has not moved.

The remaining four principles describe how you stay inside that boundary. A PCCP should be risk-based, integrated into the risk management framework you already run rather than sitting beside it. It should be evidence-based, with evidence generated across the total product lifecycle showing that benefits continue to outweigh risks. It should be transparent, so that users understand how the software performs both before and after a change lands. And it should be built from a total product lifecycle perspective, taking in user input and new data as they arrive rather than only at submission.

A change that fails its own test must not ship

A PCCP is built from three parts, and they are meant to connect rather than sit side by side. You describe the changes you intend to make. You set out how each one will be verified, validated, deployed and communicated. Then you assess what those changes do to the device, individually and all together. IMDRF is explicit that the impact assessment is what links the first two, which means a plan where the sections were written separately and stapled together will read as incomplete to a reviewer.

The description of changes carries more than a list. Each change needs its own rationale, and the section is also where you say how a change reaches devices in the field. Will it apply uniformly everywhere, or differently depending on the clinical site or the individual patient? Will the software apply it automatically, or does someone have to act, review or decide first? Those are deployment questions, and they now sit in a regulatory document.

The change plan holds the part most worth stopping on. Alongside the verification and validation activities and the acceptance criteria, IMDRF expects a robust change plan to include a mechanism assuring that a change will not be implemented if it cannot meet those criteria, and to document how the failure was recorded. In plain terms, your pipeline needs a gate that refuses to ship a change that fails its own test, and a record proving the gate held. Most teams have some version of this already. Far fewer could produce the evidence on request.

Where security lands

Section 5.1.3 covers the Impact Assessment, which evaluates the benefits and risks of each change individually and all of them together. Inside that section IMDRF states that the assessment may include consideration of updated risks related to cybersecurity and interoperability. One clause easy to skim past, it puts security risk assessment inside the routine change authorisation path, not in a separate cybersecurity submission.

If your threat model is only revisited when someone reports a vulnerability, this is the signal to change that. IMDRF also says your existing quality system is the framework for conducting the impact assessment, so this is not new machinery. It is a question your change control process should already be able to answer.

Version control, and the cost of getting it wrong

The document is direct about version control. Both you and the regulator need to know which version of the PCCP was authorised, and you need to be able to track new authorised versions when you revise one.

Revisions carry a price. Because a PCCP contains changes that would otherwise need a new submission, IMDRF says revising an authorised PCCP is generally treated as a change affecting safety and performance and will likely require reauthorisation, though some jurisdictions may permit minor changes without it. Under scope your plan and the correction might get expensive.

What to do about it

N90 is final, so there is nothing to comment on. However, there is something to check. Confirm your planned changes sit inside your declared intended purpose. Then, confirm your change control process can produce a cybersecurity view of a planned modification, not just a functional one. Confirm you can evidence which build was authorised.

Then read Section 6.2.4. IMDRF states plainly that not all jurisdictions accept PCCPs, that jurisdictions define differently which changes need a new submission, and that responsibility for handling those differences sits with the manufacturer. A PCCP written for one market is not portable by default, and IMDRF has now said so in writing.

Sources:

1. IMDRF/SaMD WG/N90 FINAL:2026, Essential Principles and Content of Predetermined Change Control Plans, IMDRF Software as a Medical Device Working Group.

2. Ferdous Al-Faruque, "IMDRF details key principles for regulators to adopt PCCPs," Regulatory Focus, RAPS, 10 August 2026.