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 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.