Predetermined Change Control Plan (PCCP): What the FDA's August 2025 Final Guidance Actually Requires of Manufacturers

The Regulatory Problem a PCCP Solves — and Its Statutory Foundation

Traditional premarket review was designed for static devices. Once cleared or approved, a device's performance characteristics are locked to what was demonstrated in the original submission. For software-based AI/ML devices that improve through retraining, that model breaks down quickly — every meaningful algorithm update would theoretically require a new 510(k), De Novo, or PMA supplement, creating a compliance overhead that makes continuous improvement practically impossible.

The Predetermined Change Control Plan mechanism addresses this directly. A PCCP is a prospective, pre-authorized document included in the original marketing submission that defines in advance which modifications the manufacturer may make, how those modifications will be developed and validated, and how the cumulative risk of those changes will be assessed. When a modification is executed exactly as the authorized PCCP specifies, it does not require a new premarket submission.

The statutory authority comes from Section 3308 of the Food and Drug Omnibus Reform Act (FDORA), enacted December 29, 2022, which added Section 515C to the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360e-4). That provision explicitly authorizes PCCPs for devices subject to PMA or 510(k) requirements. For the broader regulatory lineage — including the AI/ML SaMD Action Plan commitments that preceded this statutory authority — see the FDA AI/ML SaMD Action Plan implementation record. Readers who need foundational background on what a PCCP is and how it fits into the device approval framework should start with the FDA Predetermined Change Control Plan reference entry before proceeding. This article assumes that baseline and moves directly into what the August 2025 final guidance requires of manufacturers at the submission level.

What 'Final Guidance' Means Legally — and Why It Functions as FDA's Evaluation Standard

The August 2025 guidance (docket FDA-2022-D-2628) is a final guidance document issued jointly by CDRH, CBER, CDER, and the Office of Combination Products. Under 21 CFR 10.115, FDA guidances are nonbinding — they do not have the legal force of regulations, and manufacturers and FDA are not legally required to follow them. The guidance itself states this explicitly.

That legal framing does not reflect operational reality. During premarket review, FDA reviewers use the guidance as the de facto evaluation standard for PCCP submissions. A submission that deviates from the guidance's recommended content without a documented scientific rationale will generate deficiency letters and delay review. For practical purposes, the guidance defines what compliant PCCP submissions look like.

One important disambiguation: this guidance is not the same document as the January 2025 draft guidance on AI-Enabled Device Software Functions lifecycle management (docket FDA-2024-D-4488). Those are companion documents addressing overlapping but distinct aspects of AI device management. For a breakdown of the AI-DSF guidance's nine documentation requirements, see the FDA AI-DSF draft guidance analysis.

Component 1 — Description of Modifications: What FDA Requires

The Description of Modifications is the scope-defining component of a PCCP. It establishes the boundaries of what the manufacturer is authorized to change without a new premarket submission. FDA's guidance is explicit that this section must contain specific, verifiable parameters — not aspirational language about continuous improvement.

The core requirement is that all described modifications must fall within the device's original intended use as authorized in the marketing submission. Planned modifications that would expand indications, change the intended patient population, or alter the fundamental intended use are outside the scope of any PCCP and require a separate premarket submission.

Beyond scope, the Description of Modifications must address several specific elements:

• Projected update frequency — how often modifications are expected to be deployed, stated with enough specificity to allow FDA to assess the rate of change over time.
• Deployment approach — whether updates will be delivered automatically through software deployment systems, manually with healthcare provider intervention, or through hybrid approaches with user confirmation requirements. This distinction matters because automatic updates carry different risk profiles and require explicit guardrails.
• Update scope — whether modifications will apply globally across the entire device fleet or locally to specific sites, patient cohorts, or environmental contexts. Local adaptations (site-specific or patient-specific) require documented mechanisms to ensure the modification stays within authorized parameters.
• Guardrails against out-of-scope automatic updates — the PCCP must define the mechanisms that prevent automatic deployment from exceeding the authorized modification scope. Vague statements that the algorithm will be monitored are not sufficient; the guidance expects documented, verifiable boundary conditions.
• Rollback procedures — documented criteria and procedures for reverting to a prior version when a deployed modification fails performance criteria.

Component 2 — Modification Protocol: Mandatory Sub-Elements Added in the Final Guidance

The Modification Protocol is the methodological core of a PCCP — it documents how each planned modification will be developed, validated, and implemented. The August 2025 final guidance added several mandatory sub-elements that were not present in the 2023 draft, raising the bar substantially over what earlier submissions addressed.

The following sub-elements are now required or explicitly recommended in the final guidance, several of which were absent from the prior draft:

• Bias mitigation in data management — The protocol must document how the manufacturer will identify and mitigate bias in the data used to develop and validate modifications, including data selection criteria, demographic representativeness, and any known gaps.
• Reference standard determination — The protocol must explain how reference standards (ground truth) are established for performance evaluation of each planned modification. When clinician interpretation serves as the reference standard, this must be explicitly documented, including the qualification criteria for clinician readers and inter-reader variability controls.
• Unresolvable failure procedures — A documented procedure must describe what happens when performance evaluation of a proposed modification produces failures that cannot be resolved within the protocol. This includes decision criteria for abandoning a modification cycle, escalation paths, and documentation requirements.
• Post-market surveillance strategy — The protocol must include the manufacturer's approach for monitoring device performance after each modification is deployed, including what metrics will be tracked, at what frequency, and what thresholds trigger a response.
• Cybersecurity validation for update procedures — The update delivery mechanism itself must be assessed for cybersecurity risk. This includes validation that the software deployment system cannot be exploited to introduce unauthorized modifications.
• Pre-deployment testing and acceptance criteria — The protocol must specify testing protocols that must be passed before any modification is deployed, with defined acceptance criteria that can be objectively evaluated.
• Integration with quality management design controls — The Modification Protocol must explicitly map to the manufacturer's existing Quality Management System design control procedures, not operate as a standalone document.

FDA also expects a traceability table within the Modification Protocol — a structured mapping of each planned modification to the specific methods, testing protocols, acceptance criteria, and performance metrics that govern it. This table allows reviewers to verify that every modification described in Component 1 has a corresponding, methodologically complete protocol in Component 2.

Component 3 — Impact Assessment: The Cumulative Risk Requirement

The Impact Assessment is where many draft PCCP submissions fall short in a specific and consequential way. The final guidance does not ask manufacturers to conduct a generic benefit-risk analysis. It imposes a cumulative risk obligation that is analytically distinct and substantially more demanding.

The benefit-risk framework the guidance requires includes analysis of benefits and risks across intended populations and deployment environments, and must address the risk of harm as well as the risk of unintended bias for each change. The protocol's verification, validation, and mitigation measures must be explained in terms of how they maintain this balance across all planned modifications as they accumulate over the device's lifecycle.

For device-led combination products, the Impact Assessment carries an additional requirement: it must address how modifications to the device constituent part might affect non-device constituent parts — such as drug or biologic components — and must assess the impact on the combination product as a whole. This is not a requirement that applies to stand-alone software devices, but manufacturers of combination products must build it into their Impact Assessment structure or risk a deficiency.

• Individual modification risk analysis — for each planned modification, a benefit-risk assessment tied to the specific performance changes anticipated and the populations affected.
• Cumulative combination risk analysis — an explicit assessment of what happens when all planned modifications are considered together, including second-order interactions between modifications.
• Bias and equity risk — the guidance specifically calls out unintended bias as a category of risk that must be analyzed, not treated as a secondary consideration.
• Combination product constituent part interactions — required only for combination products; assesses how device constituent changes affect non-device constituents and the product system.
• Linkage to protocol mitigations — the Impact Assessment must connect each identified risk to the specific mitigations in the Modification Protocol, demonstrating traceability between risk identification and risk control.

Scope Rules: What Is In Bounds, What Requires a New Submission

The boundaries of what a PCCP can authorize are defined strictly. Manufacturers who treat a PCCP as a mechanism for open-ended device evolution will find that most significant device changes fall outside its scope.

The following modification types are outside the scope of any authorized PCCP and require a new, separate premarket submission:

• Changes to the device's intended use — any modification that alters the clinical purpose, patient population, or use environment in ways not captured in the original cleared or approved intended use.
• Indication expansions — adding new clinical indications, even if they seem closely related to authorized indications, requires a separate submission.
• Modifications not contemplated in the PCCP — even if a modification would be technically minor, if it is not described in the authorized PCCP, it cannot be implemented without a new submission.

The predicate device rule creates an important consideration for 510(k) submissions. When a manufacturer identifies a predicate device that itself had an authorized PCCP, the substantial equivalence comparison must be made to the predicate device as it existed before its PCCP changes were implemented. A manufacturer cannot claim substantial equivalence to a post-PCCP version of a predicate device.

Pathway-Specific Rules: The Special 510(k) Exclusion and What It Means

This exclusion has direct consequences for manufacturers who default to the Special 510(k) pathway for software device updates. The Special 510(k) is designed for modifications to a manufacturer's own legally marketed device that do not raise new questions of safety and effectiveness — a streamlined process that relies heavily on design controls rather than comparative performance data. The complexity of PCCP review is incompatible with that streamlined model.

For De Novo submissions, PCCP integration requirements follow the same three-component structure. Because De Novo is used for novel devices without a predicate, the PCCP must be particularly detailed about how the device's novel risk profile will be managed across planned modifications.

For PMA submissions, the enforcement implications are the most severe. FDA must deny PMA approval if manufacturing controls — which include the quality system processes governing PCCP implementation — do not conform to applicable requirements. A PCCP that is approved as part of a PMA becomes a binding obligation; deviation from it is not merely a compliance gap but grounds for enforcement action against the approved product.

Labeling and Transparency Obligations at Clearance and Post-Update

The August 2025 final guidance added significant clarity on labeling and transparency requirements, both at the point of initial clearance and as modifications are subsequently implemented. These obligations run throughout the device's lifecycle, not just at the time of submission.

At the time of initial clearance or approval, device labeling must:

• Inform users that the device incorporates machine learning and has an authorized PCCP.
• Describe the types of modifications the PCCP covers at a level sufficient for users to understand what may change over time.
• Explain how users will be notified when modifications are implemented.

As modifications are implemented under the PCCP, updated labeling must summarize:

• What changed in the modification — a clear description of the specific algorithm or software change deployed.
• The supporting data and evidence — a summary of the validation data and performance evidence underlying the deployed modification.
• Impacted inputs and outputs — which device inputs and outputs were affected by the modification.
• User notification method — how the user was or will be notified of the update, consistent with the notification approach described in the original PCCP.

Public-facing decision summaries issued at the time of clearance or approval must include a high-level description of the PCCP — not the full document, but enough information to allow external stakeholders to understand that an authorized PCCP exists and what general category of modifications it covers.

New Unique Device Identifiers (UDIs) are required when a PCCP modification results in a new device version or model. Manufacturers must plan their UDI management strategy in parallel with PCCP implementation planning. For health systems managing device inventories and governance workflows, these labeling changes create downstream tracking and verification obligations — a topic covered separately in the PCCP guidance analysis for health systems.

QMSR Integration: How the February 2026 Transition Raises the Compliance Bar

Every PCCP modification must be implemented within the manufacturer's quality management system. This is not a recommendation — it is a structural requirement. The guidance reiterates design control and record-retention duties as foundational to PCCP implementation, not ancillary to it.

That obligation intersects directly with the Quality Management System Regulation (QMSR) final rule, which aligned 21 CFR Part 820 with ISO 13485:2016 and became effective February 2, 2026. For manufacturers operating under the prior QSR framework who have not yet completed QMSR transition, PCCP compliance presents a compounded challenge.

The QMSR transition creates several new obligations that directly affect PCCP implementation:

• Design control procedures — ISO 13485 design controls are more prescriptive than the prior 21 CFR Part 820 framework in several respects, particularly around design transfer and post-market feedback integration. PCCP modification cycles must be managed within these updated design control procedures.
• Record retention requirements — The QMSR establishes specific retention periods and documentation traceability requirements for design and development records. Every PCCP modification cycle generates documentation — training data, validation records, acceptance criterion evaluations, deployment logs — that must be retained and traceable under the QMSR framework.
• CAPA integration — Corrective and preventive action procedures under QMSR must be triggered when a PCCP modification fails performance criteria or when post-market surveillance identifies safety signals related to a deployed modification.
• Supplier and software validation controls — If third-party data, cloud infrastructure, or software tools are part of the modification development or deployment pipeline, supplier qualification and validation requirements under QMSR apply to those components.

Enforcement Risk: Adulteration, Misbranding, and Clearance Consequences

The enforcement consequences for PCCP deviation are not abstract compliance concerns. The guidance states plainly that implementing a modification outside an authorized PCCP — or implementing a modification inconsistently with the terms of the authorized PCCP — can render the device adulterated or misbranded under the Federal Food, Drug, and Cosmetic Act.

The consequences differ by pathway:

• PMA devices — FDA must deny PMA approval if manufacturing controls, which include the quality system procedures governing PCCP implementation, do not conform to applicable requirements. For PMA supplements and post-approval modifications, nonconforming quality system controls are grounds for outright denial.
• 510(k) devices — Clearance can be withheld for a 510(k) submission if quality system regulation failures present a serious risk to device safety or effectiveness. A documented pattern of PCCP implementation failures that indicates quality system breakdown would meet this threshold.
• Post-market enforcement — Beyond submission-stage consequences, implementing out-of-scope modifications to a cleared or approved device exposes the manufacturer to post-market enforcement actions including warning letters, recalls, and civil penalties, on top of adulteration and misbranding liability.

Why Only ~8% of AI Devices Include a PCCP — and What Manufacturers Should Do

As of December 2024, the FDA's AI/ML-enabled Medical Device List included 1,016 authorized AI/ML-enabled medical devices. Industry analysis cited in secondary sources estimates that only approximately 8% of newly authorized AI/ML devices included an authorized PCCP as of 2025. That figure — drawn from a LinkedIn-sourced analyst estimate rather than a peer-reviewed dataset, and not independently verifiable from publicly available FDA data — should be treated as an order-of-magnitude indicator rather than a precise count. The underlying direction it reflects, however, is consistent across available sources: PCCPs remain rare and concentrated among manufacturers with substantial regulatory affairs infrastructure.

The barriers are structural, not just technical:

• Regulatory complexity — Building a compliant PCCP requires simultaneous expertise in software development methodology, clinical validation, regulatory strategy, and quality systems. Few small or mid-size AI device companies have all of these capabilities in-house.
• Data infrastructure requirements — Continuous performance monitoring, post-market surveillance, and version-controlled training data pipelines require engineering infrastructure that many device manufacturers do not have at the time of their first FDA submission.
• Upfront evidence burden — A PCCP increases the complexity and review burden of the initial submission. For companies focused on getting initial clearance efficiently, adding a PCCP can be a strategic trade-off against timeline and resource constraints.
• Limited regulatory affairs capacity — Startups and smaller firms may not have the regulatory affairs bandwidth to build and maintain the documentation infrastructure a PCCP requires over multiple update cycles.
• Most devices remain 'locked' models — The majority of cleared AI/ML devices use fixed algorithms that do not change post-deployment. For these devices, a PCCP is unnecessary and adds no regulatory value.

For manufacturers who are building adaptive AI systems — particularly those involving automatic updates, site-specific adaptation, or continuous retraining — the practical recommendation from the guidance is clear: engage the FDA's Q-Submission program before finalizing the PCCP submission package.

FDA specifically recommends Q-Submission engagement for:

• Higher-risk device classifications where PCCP scope and validation methodology questions are likely to arise during review.
• Devices with automatic update mechanisms, where guardrail design and deployment scope definitions require upfront alignment with reviewers.
• Local adaptation scenarios — site-specific or patient-specific modifications — where the global vs. local update distinction and associated bias risks are complex.
• Device-led combination products, where the Impact Assessment's constituent part interaction analysis benefits from pre-submission feedback on scope and methodology.

The Q-Submission process does not guarantee a specific review outcome, but it provides a documented record of pre-submission alignment that can reduce the likelihood of deficiency letters on the three-component structure. For manufacturers entering this process for the first time, that alignment is worth the investment.