A Predetermined Change Control Plan is the FDA's mechanism for letting an AI/ML medical device evolve after authorization without requiring a new marketing submission for every change. This guide explains what belongs in a PCCP, what the FDA rejects, and how cybersecurity fits in under the February 2026 premarket cybersecurity guidance.
Last reviewed: June 2026 against the FDA December 2024 final guidance "Predetermined Change Control Plans for Medical Devices" and the FDA February 3, 2026 final premarket cybersecurity guidance.
Related: EU AI Act vs FDA AI/ML Cybersecurity covers how PCCPs map to the EU AI Act's "substantial modification" test. SaMD Cybersecurity Requirements covers the SaMD foundation a PCCP builds on.
TL;DR - What a PCCP is and isn't
| A PCCP is | A PCCP is not | |
|---|---|---|
| Scope | A pre-authorized envelope for specific, well-defined future changes | An open license to modify the device however you want |
| Form | Three structured artifacts: Description of Modifications, Modification Protocol, Impact Assessment | A roadmap, a wish list, or a "continuous learning" promise |
| Trigger | Submitted as part of the original 510(k), De Novo, or PMA - or added via supplement | A postmarket-only mechanism |
| Effect | Lets you implement listed changes without a new submission, provided the protocol is followed | A waiver from QSR/QMSR, design controls, or postmarket reporting |
| Cybersecurity | Must be addressed for every modification that could affect the threat model | Optional or implicit |
When you need a PCCP
You need a PCCP when your device will change in ways that would normally require a new submission, and you want to authorize those changes up front. The most common drivers:
- AI/ML SaMD model retraining on new data with the same architecture and intended use.
- Performance threshold updates as real-world data accumulates.
- Expansion of input data types within the cleared indication (for example, adding a new MRI scanner make/model to a radiology AI's validated input set).
- Adaptive algorithm updates governed by a locked retraining recipe.
- Cybersecurity control updates that change the device's security architecture (for example, rotating cryptographic primitives on a schedule).
You do not need a PCCP for bug fixes, security patches handled under your established postmarket cybersecurity plan, or changes that fall under the "Deciding When to Submit a 510(k)" letter-to-file thresholds.
The three required parts
The FDA's December 2024 final guidance, "Predetermined Change Control Plans for Medical Devices," is binding for any PCCP submitted to the agency. A compliant PCCP has three parts. Skipping or compressing any of them is the most common cause of rejection.
1. Description of Modifications
Enumerate every change the PCCP covers. For each:
- The specific parameter, threshold, dataset, model component, or control that can change.
- The bounded range of values it can take.
- The conditions that trigger the change.
- Whether the change is automatic, manual, or contingent on an event.
Vague entries like "periodic model retraining" or "performance improvements as data becomes available" are rejected. A clean entry reads: "Retraining of the diagnostic classifier on quarterly batches of de-identified images from the same five clinical sites, with the same model architecture (ResNet-50), the same input modality (chest CT), and the same intended use, when the new batch contains at least 5,000 confirmed labels."
2. Modification Protocol
This is the engineering and verification specification. For each modification class, the protocol must describe:
- Data management: how training, tuning, and test data will be collected, curated, labeled, and partitioned. How data drift will be detected.
- Retraining and update methodology: the algorithm, hyperparameter ranges, stopping criteria, and acceptance thresholds.
- Performance evaluation: the metrics, reference standards, and statistical methodology. Pre-specified non-inferiority or superiority margins.
- Verification and validation: bench testing, software unit/integration tests, and any clinical validation. Regression test coverage for unchanged functionality.
- Cybersecurity verification: threat model refresh, SBOM regeneration, vulnerability scan, regression of security controls, pen test scope decisions. See "Cybersecurity in the PCCP" below.
- Change management: how the change is documented in the DHF/DMR, who approves it, and how the QMSR/QSR design control loop closes.
The protocol is a real plan that the FDA can read and decide whether the resulting changes would still be substantially equivalent / safe and effective. Hand-waving here is the second most common rejection reason.
3. Impact Assessment
For each modification class, document how implementing it could affect:
- Benefit-risk profile of the device.
- Performance against the cleared indications for use.
- Safety for the intended patient population, including subgroup performance.
- Cybersecurity posture: confidentiality, integrity, availability of the device and its data flows; any expansion of the attack surface; any change to the trust boundary.
- Other modifications: how stacking changes over time could compound risk.
- Interactions with the existing risk management file (ISO 14971) and threat model.
The Impact Assessment is the FDA's main reasoning aid. It is what lets the reviewer agree that any change made under the protocol will not require a new submission.
Cybersecurity in the PCCP
The February 3, 2026 final premarket cybersecurity guidance does not have a dedicated "PCCP" section, but its expectations attach to every PCCP that touches a cyber device under Section 524B. In practice, the FDA expects the PCCP to demonstrate that the cybersecurity content of the submission stays current as modifications are implemented.
Threat model maintenance
The PCCP must commit to refreshing the threat model on a defined cadence and on specific triggers - new component, new interface, new data type, new trust boundary. The refresh has to be traceable: which threats were added, which mitigations changed, which risk acceptance decisions were re-evaluated.
SBOM regeneration and vulnerability management
Any change that modifies the software bill of materials (new dependency, version bump, model artifact swap) must regenerate the SBOM and run it through the established VEX/vulnerability triage. The PCCP states the tool, the schedule, and the disposition rules.
Regression testing of security controls
The Modification Protocol's verification section must include security regression - authentication, authorization, cryptographic primitive use, secure boot, update integrity, logging. Listing security control test cases as a fixed regression suite that runs on every modification is the cleanest pattern.
Penetration testing scope decisions
The PCCP should state which modification classes trigger a fresh penetration test versus a delta test versus no retest. The FDA expects a documented rule, not "as needed."
Postmarket monitoring tie-in
The PCCP modification cadence has to align with the postmarket cybersecurity plan required by Section 524B(b)(1). New components mean new monitoring scope; the PCCP says how that scope is updated.
Common reasons PCCPs get rejected
| Pattern | Why it fails | Fix |
|---|---|---|
| "Periodic retraining to maintain performance" | No bounded scope, no protocol | Specify dataset source, size threshold, model architecture lock, performance acceptance criteria |
| "We will follow our internal SOP" | The FDA cannot review an unstated SOP | Inline the relevant SOP content or attach it |
| Impact Assessment recycles the original 510(k) hazard analysis | Doesn't address the delta introduced by the modifications | Write a focused delta analysis per modification class |
| Cybersecurity is omitted | 524B applies; reviewers add a major deficiency | Add the five subsections above |
| PCCP includes changes that exceed the original intended use | PCCP is not a path to a new indication | Submit a new 510(k)/De Novo for any indication change |
| Modifications stack without bounding total drift | The cumulative device may not resemble the cleared device | Add a cumulative-change ceiling that triggers a new submission |
| Verification and validation collapsed into "we will test" | No protocol means no PCCP | Write the V&V protocol with metrics, datasets, acceptance criteria |
How a PCCP fits into the submission
For a 510(k), De Novo, or PMA, the PCCP is a labeled section of the submission. The FDA's review concludes with an authorized PCCP that becomes part of the cleared device's regulatory record. Any future change that conforms to the authorized PCCP is implemented and documented in the DHF; no new submission is required. Any change outside the PCCP is treated under the standard change rules and may require a letter-to-file analysis or a new submission.
For a device already on the market, a PCCP is added via supplement (PMA) or new 510(k) (510(k)-cleared devices). The agency will not retroactively authorize past changes through a new PCCP.
Standards and references
| Source | Relevance |
|---|---|
| FDA, "Predetermined Change Control Plans for Medical Devices" (final, December 2024) | The binding PCCP framework |
| FDA, "Marketing Submission Recommendations for a Predetermined Change Control Plan for AI-Enabled Device Software Functions" (final, December 2024) | AI/ML-specific PCCP recommendations |
| FDA, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" (final, February 3, 2026) | Cybersecurity content that attaches to every cyber-device PCCP |
| FDA, Section 524B of the FD&C Act | Statutory basis for cybersecurity requirements |
| AAMI CR34971:2023 | Risk management considerations for AI/ML medical devices |
| ISO 14971:2019 | Risk management framework that the PCCP Impact Assessment ties into |
| IEC 81001-5-1:2021 | Security activities in the software life cycle - foundation for the cybersecurity protocol |
Where Blue Goat Cyber fits
We author the cybersecurity portions of PCCPs for AI/ML medical device manufacturers, focused on what the FDA's February 2026 guidance actually requires - threat model refresh triggers, SBOM regeneration cadence, security regression suites, pen test scope rules, and postmarket monitoring tie-ins. Engagements typically run alongside the regulatory team writing the Description of Modifications and the Modification Protocol; we own the security-relevant content and stress-test the Impact Assessment for cyber gaps that get flagged in review.
Talk to us about your PCCP if you are scoping an AI/ML SaMD submission, or read the companion SaMD Cybersecurity Requirements guide for the underlying SaMD security baseline.
FAQ
Does every AI/ML medical device need a PCCP?
No. A PCCP is optional. You submit one when you expect specific, well-defined changes after authorization and want to pre-authorize them. A device that will be locked at clearance does not need one.
Can a PCCP cover cybersecurity-only changes?
Yes. A PCCP can authorize, for example, scheduled cryptographic primitive migrations or planned security architecture updates. The Modification Protocol and Impact Assessment have to be written the same way as for any other change.
What if a change falls outside the authorized PCCP?
You handle it under the standard change rules - letter-to-file analysis, new 510(k) supplement, or new submission, depending on the change's effect on safety, effectiveness, intended use, and the device's substantial-equivalence basis.
How does a PCCP interact with the postmarket cybersecurity plan?
They are complementary. The postmarket plan handles vulnerability response and patch deployment for the device as-is. The PCCP handles planned, structural changes. A patch to fix a known CVE goes through the postmarket plan; a scheduled migration to a new authentication scheme goes through the PCCP.
Does the FDA approve each individual modification implemented under a PCCP?
No. That is the point of a PCCP - the agency approves the framework once, and conforming changes are implemented without further submission. The manufacturer documents each change in the DHF/DMR and is responsible for the protocol's faithful execution.
How does an EU AI Act "substantial modification" relate to a PCCP?
The two regimes use different language but overlap in effect. The PCCP defines what changes do not require a new FDA submission; the EU AI Act's "substantial modification" test defines what changes do require re-conformance. A change authorized by a PCCP may still trigger substantial-modification re-conformance in the EU, so a single AI cybersecurity program should map both. The EU AI Act vs FDA AI/ML Cybersecurity guide has the side-by-side.