It's just a minor change" is the most expensive sentence in Class II change control

I've lost count of how many times I've heard "it's just a minor change." It shows up in Slack threads, in hallway conversations, in emails marked "quick fix." A supplier swaps a raw material. A firmware team tightens a timing parameter. A packaging vendor reformats a label layout. Every time, somewhere, a regulatory affairs manager quietly starts a 90-day timer they didn't ask for.

This is the post I wish I'd read four years ago, before I learned the hard way how much a single adjective can cost.

The trap with Class II

Class II is the awkward middle of medical device regulation. You're not exempt like most Class I, but you're not under premarket approval scrutiny like Class III. In the US, most Class II devices clear the market via 510(k). In the EU, they go through a notified body under MDR Annex VIII. The catch: change control expectations are written to be proportional, but in practice nobody — not the auditor, not the regulator, not your NB — will tell you in advance whether a specific change is "minor" or "substantial."

The decisions live in guidance documents:

• FDA's Deciding When to Submit a 510(k) for a Change to an Existing Device (the 2017 guidance, still in force)
• FDA's separate 2023 guidance specifically for software changes
• EU MDR Annex XIV, which ties post-market surveillance back into design changes
• IMDRF's "substantial change" framework for software
• ISO 13485:2016 §4.1.4 and §8.5.6, which require evaluation of changes for impact on the QMS, the risk management file, and regulatory submissions

None of these documents use the word "minor." They all say "could significantly affect" or "could impact safety or effectiveness." That threshold is a judgement call, every single time, and it cannot be delegated to the engineer who requested the change.

Why "minor" short-circuits the impact analysis

In our shop, the impact analysis is supposed to happen at change intake — before anyone touches a CAD file or merges a PR. The question it answers is deceptively simple: what does this change touch?

• Risk management file (ISO 14971)
• Design history file
• Labeling / IFU
• Sterilization validation
• Biocompatibility (ISO 10993)
• Software V&V (IEC 62304)
• Regulatory submission strategy
• Post-market surveillance plan
• Training / competency records

For a "minor" supplier material change, the list still includes biocompatibility re-evaluation and possibly a new sterilization validation. That's months of work, not a rubber stamp. For a "minor" firmware timing tweak, you may need a software V&V re-run, a cybersecurity review under FDA's 2023 cybersecurity guidance, and possibly a new 510(k).

The pattern I've seen over and over: the engineer making the change is the worst possible person to assess regulatory impact, because they don't know what they don't know. They're not being careless — they're being honest about their scope.

The cost that doesn't show up in the project plan

The direct cost — the submission fee, the NB review hours, the consultant invoice — gets budgeted. The hidden cost is worse:

• Rework when an impact analysis gets done after the change ships
• Audit findings for skipped change control (I've seen NB audits write up exactly this — "the firm could not demonstrate that change C-2023-0418 was evaluated for regulatory impact prior to implementation")
• A CAPA born from that finding, which then generates its own change requests, training records, and effectiveness checks
• The opportunity cost of your RA lead spending six weeks on something that should have been scoped in an afternoon

The worst version of this I ever saw wasn't a catastrophic field failure. It was a six-month delay because a "minor" packaging change — moving from a printed insert to an e-label — wasn't evaluated against EU MDR Article 23 on instructions for use. The change had shipped. The retraction and re-submission cost more than the original product launch.

What I'd build into intake if I were starting over

Three things, none of them exotic, none of them requiring a big process automation push:

1. A mandatory checklist before change triage closes. Not a free-text justification. A checklist of the nine categories above, with "evaluated, no impact" or "evaluated, impact noted" as the only valid answers. Anything else bounces.
2. A second pair of eyes specifically for regulatory classification. Even a junior RA person asking "have you considered X?" catches more than you'd think. We rotated this duty quarterly; the hit rate was surprisingly high.
3. A documented "minor change" threshold. Write down, in your QMS, what you consider minor. Then get your NB or auditor to disagree with you in writing. That disagreement is more valuable than any internal debate, because it forces your threshold to be defensible.

The third item is the one I'd push hardest for. If your definition of "minor" hasn't been pressure-tested by someone outside your company, it isn't a definition — it's an assumption. And assumptions age badly between audits.

What's still hard

Even with all of that, software changes still give me pause. The FDA's 2023 software guidance and IMDRF's substantial-change framework are clearer than they used to be, but a bug fix that touches a cybersecurity control, a UI affordance, and a logging behavior at the same time can read as three minor changes or one substantial one depending on who's reading. The "bundled changes" problem is where my confidence drops fastest.

How does your team handle change intake for software specifically — is there a separate triage path, or does everything funnel through one queue? I'm especially curious if anyone has cracked the bundled-change problem without making intake so heavy that engineers route around it.