Most founders building an AI-enabled device have heard the term Predetermined Change Control Plan by now. It shows up in every panel about SaMD regulation, every FDA guidance recap, every “what's new in medtech regulatory” newsletter.
On the other hand, founders building a non-AI device don't think about it. That might be a mistake, and we can make the case for why.
What a PCCP actually is
A PCCP is FDA's mechanism for pre-authorizing a defined space of future software changes as part of your original submission, so that changes falling inside that space don't each require a new marketing submission. You describe what you plan to change, how you'll implement and verify each change safely, and what the impact is — and FDA reviews and authorizes that plan once, up front.
The reason it's become an AI/ML topic is straightforward: models drift, get retrained, get retuned against new data, and the pace of that is hard to predict at submission time. A PCCP gives AI/ML device makers a way to plan for that uncertainty instead of filing a fresh submission every time the model changes.
But the underlying logic — describe the space of changes you expect to make, and get it pre-authorized — isn't specific to AI at all. It applies to any device with a real, non-trivial post-market software roadmap.
When this actually matters for you
Here's the test I'd apply, plainly: does your product have more than one planned software change after clearance? If the honest answer is “probably, but we haven't mapped it out,” that's exactly the founder this post is for.
Algorithm threshold tuning based on field data. If your device is going to get smarter, more sensitive, or more specific as real-world data comes in — even without being an “AI device” in the marketing sense — that's PCCP territory.
Multi-phase feature rollout. Planning to ship a leaner version at launch and add capability in defined phases afterward? That's a describable space of changes, which is exactly what a PCCP wants from you.
Firmware updates touching a risk-classified component. If your update roadmap includes changes to anything tied to a hazard in your risk file — not cosmetic UI, but something that could shift risk classification — you want to have thought about whether that space can be pre-scoped.
If none of that describes your roadmap, if your device is genuinely going to ship once and stay static, a PCCP isn't worth the effort. This isn't an “every company needs one” argument. It's a “more companies than currently consider one should” argument.
Where founders get this wrong
1. Treating it as an AI-only tool. This is the mistake this whole post is arguing against, but it's the single biggest reason non-AI founders never even evaluate whether one applies to them.
2. Scoping the change space too narrowly to get through review faster. We've seen founders describe an extremely tight space of allowed changes, assuming a narrower ask gets rubber-stamped faster. It often does get authorized faster — and then becomes useless within a year, because the actual changes the team wants to make don't fit inside it. You're back to filing supplements one at a time, which defeats the point.
3. Scoping it too broadly and getting pushback. The opposite mistake: describing a change space so wide that FDA can't reasonably evaluate the risk of everything inside it. This isn't a form to fill out generically — the modification protocol and impact assessment need to be specific enough that a reviewer can actually assess them.
4. Treating the impact assessment as a formality. The impact assessment is where your PCCP and your ISO 14971 risk file have to genuinely talk to each other — every change in scope needs its risk implications addressed, not just its clinical benefit. Founders who treat this section as boilerplate end up with a plan that looks complete and isn't.
5. Waiting until after submission to think about it. A PCCP has to be part of your original marketing submission. It is not something you add later as an amendment when you realize you need it. Founders who start thinking about this after clearance have already missed the window for this particular mechanism, for this particular device.
How to actually scope one
If your roadmap clears the bar above, here's the sequence that works:
Start from your roadmap, not from the template. List every planned post-market software change you can currently foresee, even loosely. Then sort: which of these are similar enough in kind and risk profile to describe as a single space, versus which are genuinely one-off and better handled as a future submission.
Write the modification protocol like an engineer, not like a lawyer. The FDA guidance rewards specificity: what data justifies the change, what verification steps confirm it's safe, what the acceptance criteria are. Vague language here is the fastest way to get sent back with questions.
Run the impact assessment against your actual risk file, line by line. Don't write a generic “benefits outweigh risks” paragraph. Walk through your existing hazard list and show, for each hazard a proposed change could touch, how risk stays controlled across every version inside the plan's scope.
Decide what's explicitly out of scope, and say so. A plan that's honest about its boundaries — “this covers X and Y, not Z” — reads as more credible to a reviewer than one that implies it covers everything. It also protects you later: changes outside the stated scope clearly still need their own submission, and everyone already agrees on that.
The honest bottom line
A PCCP doesn't mean “no more FDA submissions, ever.” It means the changes inside a well-defined, pre-authorized space can ship without a new one. Changes outside that space still need to go through the normal process — a PCCP doesn't eliminate that; it just narrows how much of your roadmap has to go through it one submission at a time.
For founders with more than one planned software change after clearance, that difference is worth thirty minutes of real thought before your submission strategy is locked in — not six months after your first update, when you're filing a supplement you could have seen coming from day one.
Building a device with a real post-market software roadmap? Get in touch at [email protected].