Article
FDA Predetermined Change Control Plans (PCCP): A 2026 Playbook
Key takeaways
- A PCCP is not permission to change anything; it is permission to make specifically described changes, in a specifically described way, with specifically described verification.
- FDA's December 2024 final guidance applies to AI/ML-enabled devices across 510(k), De Novo, and PMA pathways, including SaMD and AI-enabled SaMD.
- The PCCP has three required components: Description of Modifications, Modification Protocol, and Impact Assessment. Skipping or thinning any one of them is the fastest way to a deficiency letter.
- Cybersecurity changes (model retraining on new data, threshold updates, telemetry pipeline changes) belong inside the PCCP and inside the SBOM and threat model, not as a separate workstream.
- Reviewers reject PCCPs that read like roadmaps. They accept PCCPs that read like bounded operating procedures with measurable acceptance criteria.
Why this matters
Before the PCCP framework existed, every meaningful change to a cleared AI/ML medical device, retraining the model on new data, adjusting a decision threshold, expanding the input modality, triggered a new submission. That created a perverse incentive: ship the model frozen, or carry the regulatory cost of every improvement. Neither served patients.
The PCCP closes that gap. Drafted well, it lets a manufacturer ship continuous improvements to a learning system without re-entering the queue for each one. Drafted poorly, it becomes a deficiency magnet that delays clearance by a full review cycle. Across the 250+ premarket cybersecurity packages my team at Blue Goat Cyber has supported, the PCCPs that clear on the first review are uniformly the most boring: tightly scoped, mechanically described, with acceptance criteria a reviewer can verify without calling the sponsor.
What is a Predetermined Change Control Plan?
A PCCP is a section of a premarket submission, authorized by Section 515C of the FD&C Act and detailed in FDA's final guidance issued December 4, 2024, that prospectively describes modifications a manufacturer may make to a cleared or approved device without filing a new marketing submission.
The PCCP itself is reviewed and authorized as part of the original submission. Once authorized, modifications that fall inside its bounds, implemented through its protocol, and assessed by its impact framework, can be deployed under the existing clearance. Modifications that fall outside, even slightly outside, require a new submission. There is no gray zone; the bounds are the bounds.
What are the three required components of a PCCP?
FDA requires every PCCP to contain three sections, in this order: a Description of Modifications, a Modification Protocol, and an Impact Assessment.
The Description of Modifications enumerates every specific modification the manufacturer intends to make. Each modification is named, scoped, and bounded with measurable parameters, not described as a category. 'Retrain the model quarterly on new data' is not a modification; 'Retrain the model on additional patient data from approved clinical sites, with no change to input features, output classes, or decision threshold, where the new training set adds no more than 30% to the cumulative training population per release' is.
The Modification Protocol describes, in operational detail, the methods used to implement, verify, and validate each modification: data management, retraining procedures, performance evaluation, update procedures, software verification and validation, cybersecurity assessment, labeling updates, and communication to users. The protocol is the part reviewers stress-test hardest, because it is the part that operates after clearance with no further FDA touch.
The Impact Assessment analyzes how the modifications, individually and in combination, could affect device safety, effectiveness, benefit-risk profile, and cybersecurity posture. It must address how the protocol mitigates each risk and what monitoring will detect failure modes in the field.
Which modifications belong inside a PCCP, and which do not?
Inside: bounded changes that are scientifically and clinically supported, can be fully verified and validated by the protocol, and do not change the device's indications for use, intended patient population, fundamental scientific technology, or risk profile beyond the assessed envelope. Typical fits include model retraining on additional approved-source data, recalibration against drift, threshold adjustments inside a pre-validated range, expansion of supported hardware platforms when bench-tested in the protocol, and labeling updates that follow the protocol's communication plan.
Outside: changes to indications for use, intended patient population, intended user, new clinical claims, fundamentally different algorithms, expansion of the input data type (adding a new imaging modality, for example), changes that alter the device's risk classification, and any modification the protocol cannot fully verify. These still require a new submission, and FDA has been explicit that attempting to stretch a PCCP to cover them is the wrong play.
A useful test: if the modification would have required a different premarket pathway had it been in the original submission, it does not belong in the PCCP.
How does cybersecurity fit into the PCCP?
Every modification in the PCCP has a cybersecurity dimension, and FDA's premarket cybersecurity expectations apply to changes implemented under the PCCP exactly as they apply to the original device. Model retraining can introduce new vulnerabilities through poisoned or adversarial training data. Telemetry pipeline changes can expand the attack surface. Threshold updates can change the impact of a successful manipulation. New supported hardware can introduce new SOUP and shift the SBOM.
The Modification Protocol must describe how cybersecurity verification will be re-performed for each modification class: SBOM regeneration, vulnerability re-scan against current CISA KEV and NVD data, threat model re-evaluation, and any required penetration testing or fuzzing. The Impact Assessment must explicitly address cybersecurity risks introduced by each modification class and how the protocol's verification activities bound them. Reviewers from CDRH's Digital Health Center of Excellence read the cybersecurity portions of the PCCP closely, and treating them as an afterthought reliably produces a deficiency.
What does the 2025 FDA AI-enabled device guidance change for your PCCP?
FDA's January 2025 draft guidance on AI-enabled device software functions sits on top of the December 2024 PCCP final guidance, and the two are read together during review. The AI guidance asks for a total product lifecycle account of the model: where training data came from, how representative it is of the intended use population, how performance is monitored after clearance, and how users are told what the model can and cannot do. The PCCP is where you commit to keeping those answers true while the model changes.
Practically, that means three additions to a PCCP written before 2025. First, name the performance metrics you will monitor in the field and the thresholds that trigger investigation, not just the metrics you will re-verify at release. Second, describe data management for retraining: provenance, labeling quality controls, and how you detect drift between the training distribution and the deployed population. Third, state how transparency artifacts (model cards, labeling, user-facing performance claims) get updated when a modification lands. A PCCP that upgrades the model but leaves the labeling stale is a deficiency waiting to happen.
How do you write a PCCP for SaMD when the model retrains continuously?
Continuous retraining is where most SaMD teams overreach. FDA does not authorize open-ended autonomous learning through a PCCP; it authorizes a bounded, described process. The workable pattern is a fixed retraining cadence with human release gates: retraining runs on a locked pipeline, candidate models are evaluated against a frozen benchmark dataset plus a current-population dataset, and a named role signs the release only when both clear predefined acceptance criteria.
Write the boundary explicitly. Architecture stays fixed. Inputs and output types stay fixed. Intended use, patient population, and clinical claims stay fixed. What varies is the weights, within the performance envelope you published. When the change would move any of the fixed items, that is a new submission and your PCCP should say so in one sentence. Reviewers reward a plan that names its own limits; a plan that seems to cover everything reads as a plan that bounds nothing.
Where does AI medical device cybersecurity intersect the modification protocol?
AI adds attack surface that traditional software risk analysis misses. Training data is an input path: poisoned or mislabeled records can degrade performance in ways that look like drift rather than compromise. Model artifacts are assets: an unsigned weights file pulled at deploy time is a supply-chain hole. Inference endpoints are exposed interfaces: adversarial inputs and model-extraction queries are abuse cases, not edge cases.
The Modification Protocol should tie each of those to a verification activity that reruns on every PCCP-authorized change. Sign and verify model artifacts. Regenerate the SBOM including ML frameworks and their transitive dependencies, which move fast and carry real CVEs. Re-run the threat model with the retrained model in scope, including adversarial input and data-poisoning paths. Keep evidence of each run with the release record, because the postmarket question is never whether you thought about it; it is whether you can show what you did.
What does a defensible Modification Protocol look like?
A defensible Modification Protocol reads like a Standard Operating Procedure, not a plan. It specifies: the data sources eligible for inclusion (and the qualification criteria for each), the data management and labeling controls, the retraining and validation methodology with explicit acceptance criteria, the cybersecurity verification activities, the software verification and validation tied to the QMS, the labeling change rules, the user communication plan, and the recordkeeping required at each step.
Acceptance criteria are the part most often underspecified. 'Performance must be maintained' is not an acceptance criterion. 'Sensitivity for the primary endpoint must not decrease by more than 2 percentage points from the version-of-record baseline, evaluated on a locked validation set that includes the demographic strata defined in Section 4.2, with the lower bound of the 95% confidence interval not falling below 0.85' is.
The protocol also has to describe what happens when acceptance criteria fail. A modification that fails its acceptance criteria is not deployed; if it cannot be reworked inside the PCCP, it triggers a new submission. The decision tree for failure has to be in the document, not in the team's institutional memory.
How does the PCCP interact with the QMS and postmarket surveillance?
Every PCCP-authorized modification has to be implemented under the manufacturer's Quality Management System under 21 CFR Part 820. Design control, risk management (ISO 14971), software lifecycle (IEC 62304), and usability engineering all apply to PCCP changes; the PCCP does not waive any of them.
Postmarket, the manufacturer must monitor the field performance of each PCCP-deployed modification and feed observed drift, failure modes, or unanticipated impacts back into the next iteration. FDA expects the postmarket surveillance plan to track PCCP modifications as distinct artifacts, with the version of the device under each modification traceable in adverse event reporting. The PCCP is not a substitute for postmarket vigilance; it is a structure that makes vigilance enforceable.
What are the most common deficiencies in submitted PCCPs?
Across the PCCPs my team has helped draft, defend, and review, the deficiency letters cluster around the same five mistakes. First, modifications described as categories rather than bounded operations. Second, missing or hand-waved acceptance criteria. Third, no failure path: the protocol describes success but is silent on what happens when validation fails. Fourth, cybersecurity treated as a one-line reference rather than an integrated verification activity. Fifth, an Impact Assessment that lists risks without showing how the protocol bounds each one.
A PCCP that addresses these five upfront, before the first internal review, clears far faster than one that addresses them after a deficiency letter. The cost of getting the PCCP right is days; the cost of getting it wrong is a full review cycle.
How Christian approaches this
At Blue Goat Cyber we draft PCCPs alongside the threat model, the SBOM pipeline, and the postmarket plan, not as a separate workstream. The Modification Protocol references the same SBOM and verification artifacts that govern the base device, so a PCCP-authorized modification flows through the same pipeline that cleared the original submission. The Impact Assessment reuses the threat model's risk register, with PCCP modification classes mapped to the assets and harms already enumerated.
The approach is documented in the cybersecurity-for-AI/ML chapter of my 2026 book, Medical Device Cybersecurity: An In-Depth Guide. The chapter on PCCPs is the one product leaders return to most often, because it is the bridge between regulatory authorization and day-to-day engineering practice.
Related guides: What the FDA actually wants in a 2026 premarket cybersecurity submission, SBOM hygiene for medical devices, Threat modeling connected medical devices, and Postmarket vulnerability management.