FDA PCCP Guidance for SaMD: How to Write a Predetermined Change Control Plan

Software changes constantly. For a device that relies on machine learning, the whole point is that the model improves as it sees more data. Under normal rules, many of those improvements would each need a new FDA marketing submission. A predetermined change control plan (PCCP) is the way around that: you describe the changes you intend to make, and how you will test them, in your original submission. If FDA authorises the plan, you can make those changes without going back to FDA each time.

This guide walks through FDA’s PCCP guidance for AI-enabled software, what each section of a plan must contain, and where companies most often go wrong. For the wider picture of AI-enabled devices, see our guide to AI-enabled medical devices and the FDA lifecycle approach.

Which FDA guidance covers PCCPs?

The key document is Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions. FDA first issued it on December 4, 2024 and reissued it on August 18, 2025. It is a non-binding guidance, grounded in section 515C of the FD&C Act, which Congress added through FDORA.

• What it covers: AI-enabled device software functions that you intend to modify over time, whether the changes are applied automatically (for example continuous learning), manually, or both.
• Which submissions: original PMAs and PMA supplements, traditional and abbreviated 510(k)s, and original De Novo requests. A special 510(k) may be appropriate to modify a PCCP that already exists.
• Combination products: it applies to the device part only, not the drug or biologic part.
• Software that is not AI-based: FDA has also published a broader draft guidance on PCCPs for all device types. Check FDA’s guidance pages for its current status before relying on it.

Always read the current version on FDA’s website. Guidance documents get updated, and this page is not a substitute for the source.

The three parts of a PCCP

Part	What it answers
Description of Modifications	What exactly will you change, and what performance must the device keep?
Modification Protocol	How will you develop, test and roll out each change, and what is the pass mark?
Impact Assessment	What are the benefits and risks of the changes, and how are the risks controlled?

1. Description of Modifications

This is the list of changes FDA is being asked to pre-authorise. For each modification, the guidance expects you to state:

• the specific change and the reason for it;
• the performance specifications it must meet;
• which labeling sections it will affect;
• whether it is applied automatically, manually or both (automatic updates need clear limits and guardrails);
• whether it is the same for every user (global) or tailored to a site or patient (local), with the factors that justify local changes;
• how often updates are expected, from periodic to continuous; and
• which performance evaluation activity will check it.

The guidance groups typical changes into three kinds: performance changes from re-training on data from the same population, changes to inputs or compatibility, and changes to use or subpopulations. In general the modifications should keep the device within its intended use and, generally, within its indications for use. A vague entry such as “improve model accuracy” will not work. Name the change and the measurable result.

2. Modification Protocol

The protocol is the core of the plan: it explains how each change will be made and verified, with acceptance criteria set in advance. The guidance describes four components.

Data management

• How new data will be collected, including inclusion and exclusion criteria where a clinical study is involved.
• How the reference standard (ground truth) is set, and the quality checks on it.
• How data are processed, stored and retained.
• Evidence that the data represent the intended patients and use environments, with identifiable subgroups properly represented across training, tuning and test sets.
• How training, tuning and test data are kept separate, and how access to test data is blocked during development. Test data should be independent and generally come from sites different from those used for training.
• How data used for the original and later versions relate to each other.

Re-training practices

• The objective of re-training and which parts of the model or device may change.
• Justification for any architecture changes, such as layers or hyperparameters.
• Triggers for re-training, for example a set amount of new data or observed data drift.
• How data separation is maintained during re-training.

Performance evaluation

• What triggers an evaluation.
• Study design, metrics, statistical analysis plan and pre-defined acceptance criteria for each modification.
• Testing on sequestered data that reflect the clinical population.
• Comparison of the modified device against both the original device and the last modified version.
• Where software drives hardware, evaluation of effects on the hardware as well.
• What happens on failure. If a failure cannot be resolved, the affected modification is not implemented.

Update procedures

• How updates are verified, validated and deployed, and whether they are automatic or manual.
• Cybersecurity risk management and validation for the update, as set out in FDA’s premarket cybersecurity guidance. See medical device cybersecurity.
• Communication to users: release notes, version information shown with device outputs, and whether users can review labeling or opt out.
• A device monitoring plan: tracking adverse events per update, real-world and subgroup performance, and whether there is a plan to roll back an update.

FDA recommends a traceability table that links each modification to the protocol methods that will verify it. It makes review easier and forces you to check that nothing is listed without a test.

3. Impact Assessment

The impact assessment explains why the changes are safe to pre-authorise. It should:

• compare each modification, applied on its own, with the device without modifications;
• assess the benefits and risks of each change, including harm and unintended bias;
• show that the verification and validation in the protocol are enough to keep the device safe and effective;
• explain how modifications interact with each other; and
• describe the cumulative effect of making all of them.

It should also look at effects on the rest of the device, including other software functions and hardware. Use your existing ISO 14971 risk management process as the framework, and cross-reference the main device risk assessment rather than duplicating it.

Labeling and transparency

FDA recommends that labeling say the device uses machine learning and has an authorised PCCP, so users know updates may change performance, inputs or use. When you implement a change under the plan, labeling should describe what changed and how users were told. Labeling should only describe changes that have actually been made, not changes planned for the future.

What if you change something outside the plan?

Significant modifications that are not in the authorised PCCP, or are not made as the plan describes, will likely need a new marketing submission before you implement them. Changes that would not need a submission anyway are not deviations; they are handled and documented under your quality system. Examples in FDA’s appendix show the line: adding a skin lesion app to smartphones and tablets might fit a plan, while adding a thermographic camera or a patient-facing version would need a new submission.

You can add a PCCP to a device that is already on the market through a new marketing submission, and you can change an existing PCCP the same way.

Quality system and the QMSR

Every change under a PCCP must be made under your quality system: design changes, nonconformances, CAPA and documentation. The guidance was written when the Quality System Regulation applied. Since February 2, 2026, FDA’s QMSR, which incorporates ISO 13485:2016, applies instead. See the QMSR implementation checklist and ISO 13485 and QMSR training. Software lifecycle controls, including software validation, carry straight over.

A practical checklist before you submit

1. Decide whether you really expect to change the model. If not, a PCCP adds work without benefit.
2. List every planned change in plain, measurable terms, and limit the list to what you can actually validate.
3. Write acceptance criteria before you see any results.
4. Keep test data separate from training data from day one, and document how.
5. Build the traceability table linking changes to tests.
6. Draft the impact assessment with your risk management team, not after the fact.
7. Plan labeling, version display and user communication.
8. Raise the PCCP strategy with FDA in a Q-Submission before you file. FDA recommends this in the guidance.

Common mistakes

• Too vague. A change description with no performance target cannot be authorised.
• Too broad. Listing changes you have no way of testing, or that stretch the intended use.
• Weak data separation. Test data that overlaps with training data, or comes from the same sites.
• No monitoring plan. Authorisation does not end FDA’s interest in how the model performs in real use.
• Treating it as a document exercise. The plan must match what your engineering and quality teams will actually do.

Frequently asked questions

Is a PCCP required for AI-enabled SaMD?

No. It is optional. It makes sense if you expect to update the model after clearance. Without one, each significant change is assessed under the usual rules for device modifications.

Can I add a PCCP after my device is cleared?

Yes. FDA’s guidance says a PCCP can be added to a device already on the market through a marketing submission that adds the plan.

Does a PCCP cover changes to intended use?

No. Changes should keep the device within its intended use and generally within its indications for use. A new intended use needs a new marketing submission.

Does a PCCP work for 510(k), De Novo and PMA?

Yes. The guidance covers original PMAs and PMA supplements, traditional and abbreviated 510(k)s, and original De Novo requests.

Does this apply to software that does not use AI?

The 2024/2025 guidance is specific to AI-enabled device software functions. FDA has a separate draft guidance for PCCPs across device types. Check FDA’s website for its current status.

This page is general information, not legal or regulatory advice. Confirm details in FDA’s current guidance and, for your own device, in a Q-Submission.

Talk to the AptSkill team

Need training on SaMD, AI-enabled devices or FDA submissions? Send us a message. See also our SaMD training guide and the SaMD Training course.