Most engineers reading IEC 62304 for the first time stop at Clause 5. That’s where the framework is interesting. Architecture. Verification. Traceability. Risk-classed unit testing. You can build a development process around it.
Clause 6 is where most teams get hurt.
Clause 6 is the software maintenance process — the rules that govern what happens to your software after you put your name on the development closure. Post-submission, post-clearance, post-deployment. It’s the part of 62304 that turns every git commit into a regulated event. And it’s the part nobody writes about, because it lives in the unglamorous middle of the product lifecycle.
Here’s a practical read on Clause 6 — what trips teams up, and the patterns that actually work.
What Clause 6 actually requires
Clause 6 has three sub-processes, and you need all three.
6.1 — Establish a software maintenance plan. Before you release, you commit in writing to how you’ll handle maintenance throughout the product lifecycle. How problems get reported. How they get evaluated. How modifications get implemented. Who has authority. What records get kept.
6.2 — Problem and modification analysis. Every reported problem — an internal bug, a customer complaint, a CVE in a dependency, a regulatory change — gets formally analyzed. Is this a defect? Does it affect safety? Does it warrant a corrective action? Does it require an MDR? Does it require notification to the FDA? The output is a documented decision with traceable inputs and reasoning. This is not Jira triage. This is a regulated process whose artifacts get audited.
6.3 — Modification implementation. If you decide to change the software, you re-enter the development process at the appropriate point. Not from the top. Not from where it’s convenient. From wherever the change actually affects. A change to a Class C component may require you to redo unit tests, integration tests, system tests, and risk analysis. A change to an isolated UI string may not. The judgment about where to re-enter is itself a documented decision.
That’s the shape of it. Three sub-processes, all of them required, all of them auditable.
Where teams get stuck
Some typical failure patterns are:
1. The patch backlog. Security patches, dependency updates, minor fixes pile up because nobody on the team is sure whether they "trigger" the Clause 6 process. The team is afraid that addressing them will start a chain of work that won’t end. So they don’t address them. Then a CVE lands on something they were already behind on, and now there’s no time to do it right.
2. The frozen risk file. ISO 14971 risk management is supposed to be a living document, updated for every change that affects risk. In practice, the risk file gets locked at submission and never reopened. Auditors notice. Patches that materially change the device’s risk profile go in without risk re-evaluation, and the audit trail can’t justify the decision.
3. Maintenance branches that drift. A "hotfix" branch gets created, ships once, and stays alive. Six months later there are three of them, each with different patches, none merged back to main, none with verification re-runs documented. The configuration management story falls apart fast.
4. Undocumented re-entry decisions. A team decides a change is small enough to skip re-running system tests. That decision may be right. But if it’s not written down with the reasoning, an auditor will assume it wasn’t made — which is worse than a wrong decision documented.
5. No criteria for the 510(k) line. Clause 6 doesn’t tell you when a software change requires a new FDA submission. That’s a separate question, informed by the FDA’s "Deciding When to Submit a 510(k) for a Software Change" guidance. But your Clause 6 process needs to trigger that question. Teams that don’t have a documented criterion end up making the call ad-hoc, under pressure, with the security patch already shipped.
Five patterns that work
Treat your bug tracker as a regulatory artifact. Every ticket gets fields for severity, regulatory impact, risk assessment status, and decision rationale. Templates enforce this. Reviewers reject tickets that skip them. It’s friction, but it’s the friction that keeps the audit trail intact when you need it eighteen months later.
Make Clause 6.2 a step in your standard ticket flow. Don’t bolt on a "regulatory review" process after the fact. Bake it in. Every bug, every dependency update, every customer complaint enters the same evaluation pipeline. The output of that pipeline is either "address through standard development" or "address through expedited maintenance" — never "skip."
Pre-define your re-entry rules. Decide, before you need to know, what kinds of changes require re-running which tests.
Architectural changes → full integration + system.
Component changes → integration.
Bugfixes within a unit → unit + relevant integration.
UI string changes → unit + smoke.
Write this into your maintenance plan. Then follow it.
Update the risk file like it’s code. Every modification goes through a risk impact analysis. If risk changes, the file changes, with traceability back to the modification request. Treat it like any other deliverable — versioned, reviewed, signed off.
Document the 510(k) criterion separately, and apply it always. Have a written decision framework for when a change crosses the threshold for FDA notification. Apply it to every change request, not just the obvious ones. The discipline of running the analysis even on changes that clearly don’t trigger a submission is what builds the audit story for the ones that do.
What this looks like in production
The teams that get this right have one thing in common: they designed for Clause 6 during development. They built their CI/CD to generate the evidence Clause 6 requires, not just run the tests. They built their ticket templates around the analysis Clause 6 demands. They built their release process around the re-entry rules Clause 6 implies.
The teams that struggle treated maintenance as an ops problem and discovered, around month four of post-market, that it was a regulatory one.
Clause 5 gets you cleared. Clause 6 is what keeps you cleared.
If your team is about to ship, or has recently shipped, the audit you should be most worried about isn’t the one for the device that launched. It’s the one for the device that’s been in the field for eighteen months — and your bug tracker has just become evidence.
Building or supporting a medical device software team? Hattrick helps medtech companies design FDA-compliant software processes — from IEC 62304 from scratch to retrofitting a maintenance process that will survive the next audit. Get in touch at [email protected].