EN 62304:2006+A1:2015 clause 6 defines the software maintenance process — the controlled set of activities that apply once a medical device software product has been released. The process requires a maintenance plan, a problem and modification analysis activity, a modification implementation activity, and a release activity that together keep the software under lifecycle control across bug fixes, updates, security patches, and feature additions. MDR Annex I Section 17 obliges manufacturers to run the software lifecycle in accordance with the state of the art throughout the life of the device, which means the maintenance process is not optional — it is how the lifecycle stays alive after first release. The goal is to handle changes without re-doing the whole lifecycle, by scaling the activities to the scope and risk of each individual change.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN 62304:2006+A1:2015 clause 6 is the software maintenance process. It runs after initial release and covers every change to the software for the rest of its life on the market.
  • Clause 6 has three main activities: establishing a software maintenance plan, problem and modification analysis, and modification implementation. Release of the maintained software runs through clause 5.8.
  • The maintenance plan defines how feedback is received, how problems are evaluated, how modifications are decided, and how the software safety class and risk-management file are kept current.
  • Each change goes through problem analysis, an impact and risk reassessment, a decision to modify or not, and — if modified — the same development and verification rigour the initial release required, scaled to the change.
  • Regression testing is the mechanism by which a change to one software item is shown not to break other items. The regression scope is driven by the architecture and the software safety class, not by time pressure.
  • Clause 6 interacts tightly with clause 9 (problem resolution), clause 8 (configuration management), clause 5 (development), and MDR Annex I Section 17 for the regulatory obligation.
  • Maintenance is where most startups lose lifecycle discipline. Treating every patch as "too small to document" is the fastest way to fail the next surveillance audit.

Why the maintenance process is where lifecycles quietly break

Every medical software team we work with hits the same pattern around six months after the first release. The initial certification is done, the technical file is in the Notified Body's hands, the team is back to building, and the bug reports start coming in from real users. The first patch ships. It is small — a fix to a date-parsing bug that was only wrong for one locale. The team tests it, merges it, deploys it, and moves on. Nobody writes it up as a change. Nobody runs it through risk management. Nobody updates the release notes in the technical file. It is a one-character fix, and the engineering team treats it the way they would treat a one-character fix in any other product.

Six months later the team is on patch forty-seven. Some of those patches were tiny. Some added small features. A few touched the data layer. None of them were individually big enough to feel like "a change to a certified medical device." Collectively, the production software no longer matches the technical file the Notified Body reviewed, the risk file has not been updated since initial release, and the engineering team cannot produce a clean list of what changed and why. At the next surveillance audit the auditor asks a single question — show me how each post-release change was evaluated, risk-assessed, and released — and the team has nothing to show except Git history.

This is the pattern EN 62304:2006+A1:2015 clause 6 exists to prevent. The maintenance process is not there to make small changes hard. It is there to keep the lifecycle alive at a cadence that matches how real software teams actually work. A startup that runs clause 6 well ships faster after first release, not slower, because the questions are answered in advance and the evidence is produced as the work happens. A startup that ignores clause 6 ships fast for six months and then pays the bill all at once when the next audit asks where the records are.

MDR Annex I Section 17 requires that software be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management including information security, verification, and validation. (Regulation (EU) 2017/745, Annex I, Section 17.2.) The phrase "development life cycle" covers the entire life of the software, not just the activities before first release. Maintenance is part of the lifecycle. The obligation does not pause at release.

Clause 6 scope — what the standard actually covers

EN 62304:2006+A1:2015 clause 6 is titled the software maintenance process. The scope is the controlled set of activities that apply from the point the software is released — in the sense of clause 5.8 — for its intended use until the manufacturer decommissions it. Everything that happens to the software between those two points is a maintenance activity.

The clause is structured into three main sub-processes. Clause 6.1 requires the manufacturer to establish a software maintenance plan. Clause 6.2 is the problem and modification analysis activity, which decides whether and how to respond to incoming feedback. Clause 6.3 is the modification implementation activity, which executes approved changes under the same process discipline as the original development. The release of a maintained software version runs back through clause 5.8, the software release activity from the development process — clause 6 does not define a separate release path; it reuses the one the original release used.

Clause 6 does not stand alone. It is explicitly coupled with clause 9 (software problem resolution process), clause 8 (software configuration management process), clause 7 (software risk management process), and clause 5 (software development process). A single change flows through all of them. Clause 6 is the orchestration layer that connects the other processes to the reality of a released product.

One point that startups often miss — clause 6 applies to all software safety classes. The rigour scales, but the process is not optional for Class A. A Class A module with a bug fix still needs a maintenance plan, a problem analysis, a modification decision, and a release. The documentation can be lean. The process cannot be absent.

The software maintenance plan

Clause 6.1 requires a software maintenance plan. The plan is not a separate document from the software development plan if the manufacturer does not want it to be — a single lifecycle plan that covers both the development and maintenance processes is acceptable and, for startups, usually better. What matters is that the maintenance-specific content exists and is accessible.

The plan answers a set of concrete questions. How does the manufacturer receive feedback about the released software — from users, from post-market surveillance, from vigilance, from internal testing, from security monitoring? Where does that feedback land and who owns it? How is incoming feedback evaluated to decide whether it constitutes a problem that requires a response? What criteria trigger a modification, what criteria allow a problem to be accepted without modification, and who signs off on the decision? How is the risk file kept current when the software changes? How is the software safety class reassessed when the change touches items that contribute to hazardous situations? How are modifications classified by scope — minor fix, update, significant change — and what level of verification each scope requires? How is the regression testing scope decided? How is the release of the maintained software authorised and recorded?

For a small team, the maintenance plan is often five to fifteen pages. It names the feedback channels (support inbox, GitHub issues, vigilance reports, security advisories from dependency monitoring), the evaluation cadence (weekly triage, with an emergency path for safety-relevant items), the decision authority (named roles, not named people), the impact categories (cosmetic, non-functional, functional, safety-relevant, security-relevant), and the verification depth per category. The plan is a working document. It gets updated as the team learns what works and what does not.

Problem and modification analysis — clause 6.2

Clause 6.2 is where incoming feedback becomes a decision. The problem and modification analysis activity takes a reported problem, a feature request, a security advisory, or any other input that might drive a change to the released software, and runs it through a structured evaluation.

The activity starts by documenting the problem report itself — what was observed, by whom, under what conditions, on which version, with what impact. A report that does not make it into the record does not exist for clause 6 purposes. The team then analyses the problem to understand its cause and its scope. Which software items are involved. Which requirements are implicated. Which hazards the problem might affect. Which versions of the software are affected — the one in the field, the one on the main branch, any feature branches. Whether the problem is reproducible and under what conditions.

Once the analysis is complete, the team makes a modification decision. The options are not binary — modify or not modify. A single problem report can drive an immediate fix, a scheduled fix, a workaround documented in the IFU, an accepted risk with no action, a vigilance report to the competent authority, or some combination of these depending on the severity. Clause 6.2 requires that the decision be documented and that the reasoning tie back to the risk-management file. A problem that changes the risk profile must update the ISO 14971 file. A problem that does not change the risk profile must be documented as evaluated and unchanged.

The output of clause 6.2 is either a closed problem report — no modification needed, reasoning recorded — or a change request that enters clause 6.3. The transition between the two is an explicit decision gate with named authority, not a side-effect of someone fixing the bug on their own initiative.

Modification implementation — clause 6.3

Clause 6.3 is where the approved change gets made. The activity requires that modifications be implemented using the same development process discipline that the standard defines in clause 5 — the process that produced the original release. That is the core scaling rule of clause 6: maintenance does not get to skip development rigour, but it does get to scale the rigour to the scope of the change.

Practically, this means a small fix runs a small version of the development loop. The requirements implicated by the change are updated. The design, if touched, is updated. The code is modified. The verification activities at the unit, integration, and system level are run — scoped to the change and to the regression surface. The risk-management activities under clause 7 are re-run on the affected items. The configuration management records under clause 8 are updated to capture the change. The documentation that was produced during the original development for the affected items is updated to reflect the new state.

The scaling rule is that the activities required by the software safety class apply to the modified portions of the software. A Class C software item with a two-line fix still requires the Class C verification rigour on that two-line change. A Class A software item with a large feature addition requires the Class A rigour on the addition. The class does not change because the change is small; the scope of the work changes because the change is small. Ignoring this distinction is the single most common clause 6 mistake we see.

Regression testing — the mechanism for scoping impact

Regression testing is how the manufacturer demonstrates that a change to one part of the software did not break another part. The standard does not prescribe a regression test size. It requires that the verification evidence support the claim that the integrated software still meets its requirements after the change. The manufacturer decides the scope based on the architecture, the software safety class, and the analysis of which items the change could plausibly affect.

A lean regression approach for a small team looks like this. The full system test suite is automated and runs in CI on every change — the cost of running it is the cost of CI compute, which is negligible compared to the cost of a missed regression. The automated suite covers the critical paths for every software item that contributes to hazardous situations. Any change to a Class B or Class C item triggers the full automated suite plus an additional targeted manual or scripted test focused on the specific items touched by the change. Any change to a Class A item triggers at least the automated suite. The regression scope for each change is recorded in the change request, so the auditor can see that the decision was deliberate.

The activity does not have to be expensive. It has to be documented, scaled to the class, and run before release. Teams that build the automated suite during initial development are paid back on every single maintenance change for the life of the product.

Release of the maintained software — through clause 5.8

Clause 6 does not define a separate release activity. The release of a maintained software version runs through clause 5.8, the same release activity the original software used. The manufacturer confirms that all planned maintenance activities are complete, that known anomalies have been evaluated against the risk management, that the configuration of the release is identified and reproducible, and that the release is authorised by the named role.

The release record for a maintenance version typically lives in a release note that summarises the change, references the change request, references the updated risk file, references the verification evidence, names the version identifier, and is signed off. For a small team this can be a structured file in the same repository as the code. The regulatory artefact is the signed record, not the format.

For the full release process and its interaction with clause 5.8, see post 387 on the software release process.

Maintenance under clause 6 is the software-specific change control process. It lives inside the broader QMS change control framework that EN ISO 13485:2016+A11:2021 requires at the organisational level. The QMS change control process covers all changes to the medical device and the QMS itself — software, labelling, IFU, manufacturing, supplier changes, intended purpose. Clause 6 is the software-lifecycle implementation of that higher-level obligation for the code base.

The practical move for a small startup is to keep the two linked but not duplicated. The QMS change control procedure references clause 6 for software changes and does not re-specify the software process. The clause 6 maintenance plan references the QMS change control procedure for the higher-level governance (change classification thresholds, significant change assessments for the Notified Body, communication obligations). The two processes meet at the change request: a software change request is simultaneously a clause 6 modification request and a QMS change control record.

For the interaction with significant change notifications and Notified Body obligations under the MDR, see post 389.

Common mistakes startups make with clause 6

  • Treating patches as too small to document. Every post-release change goes through clause 6, including the one-character fix. The documentation can be short. It cannot be absent.
  • Running maintenance as a separate lifecycle from development. Clause 6 reuses the development, verification, risk, and configuration management processes from clauses 5, 7, and 8. Building a parallel maintenance process duplicates work and creates drift between the two.
  • Not updating the risk file when code changes. A bug fix in a software item that contributes to a hazardous situation is a risk-management event. If the risk file has not been touched since initial release and the code has, the file is wrong.
  • Leaving regression scope undocumented. The auditor will ask how the manufacturer decided what to test after a change. "We tested what seemed relevant" is not an answer.
  • Conflating the MDR significant change assessment with clause 6. Clause 6 is the software process. The significant change assessment is a separate MDR-level decision about whether the change requires Notified Body re-certification. Both are required, and neither replaces the other.
  • Letting the maintenance plan age. A plan written at initial release and never updated describes a team that no longer exists doing work that has changed. The plan is a working document.

The Subtract to Ship angle

Clause 6 is where subtraction compounds. Every maintenance change is an opportunity to run the minimum viable version of the process for the scope of the change, or the opportunity to repeat the full development dance in miniature for no added safety. The subtraction moves that earn their place are these. Scope each change to the smallest set of software items that need to be touched. Classify the change by impact and safety class at the start, and run only the activities that class and scope require. Use the automation built during initial development — CI, test suites, static analysis, release pipelines — to produce evidence, instead of writing evidence by hand. Keep the maintenance plan short and living, not long and stale. Link clause 6 to the QMS change control process instead of duplicating it. Do not run a parallel maintenance lifecycle; reuse the development lifecycle scaled to the change.

The anti-pattern in this category is the "full rerun" reflex — treating every change as a mini-certification and running every activity again at full depth. That reflex produces documentation weight without safety gain and burns runway for nothing. The standard does not require it. The class-scaled, scope-scaled, evidence-automated version of clause 6 is what earns its place in the file. For the broader framework applied to MDR, see post 065.

Reality Check — Is your maintenance process audit-ready?

  1. Do you have a written software maintenance plan that covers feedback channels, evaluation cadence, decision authority, impact categories, verification depth per category, and release authorisation?
  2. Is every post-release change captured in a change request that links to the problem report, the risk impact analysis, the verification evidence, and the release record?
  3. When a software change touches a software item that contributes to a hazardous situation, is the EN ISO 14971:2019+A11:2021 risk file updated as part of the change?
  4. Is your regression testing scope decided deliberately per change, based on the architecture and software safety class, and recorded in the change request?
  5. Is your automated test suite the primary source of verification evidence for maintenance changes, with hand-written reports only where automation cannot cover the activity?
  6. Are the software safety class and the required clause 5 activities reapplied at the scope of each change, not at the scope of the whole software?
  7. Is clause 6 linked to the QMS change control process under EN ISO 13485:2016+A11:2021, with a single change request that serves both purposes?
  8. Can you produce, for any given field version, a complete list of changes from initial release, the reasoning for each, the risk impact, and the release authorisation?
  9. Is the maintenance plan updated when the feedback channels, the tooling, or the team structure change, or has it not been touched since first release?
  10. Does your process distinguish clause 6 modification decisions from MDR significant change assessments, and run both where both apply?

Any question you cannot answer with a clear yes is a gap the next surveillance audit will find. Closing the gap while the change volume is still small is cheaper than closing it across forty-seven unreviewed patches.

Frequently Asked Questions

Does EN 62304:2006+A1:2015 clause 6 apply to small bug fixes? Yes. The clause applies to every change to released medical device software, regardless of size. The rigour scales to the scope of the change and the software safety class of the affected items, but the process itself is not optional. A one-character fix still needs a problem report, an impact and risk analysis, a modification decision, verification scoped to the change, a configuration management update, and a release record. The documentation for a small fix is short; it is not absent.

Is clause 6 the same as the MDR significant change assessment? No. Clause 6 is the software lifecycle process that governs how changes are made to the code. The MDR significant change assessment is a separate, higher-level decision about whether a change to a certified device is significant enough to require Notified Body re-review. Both are required. A non-significant change still runs through clause 6. A significant change runs through clause 6 and also triggers a notification to the Notified Body.

How much regression testing does clause 6 require? The standard does not prescribe a regression scope. It requires that the verification evidence support the claim that the software still meets its requirements after the change. The manufacturer decides the scope based on the architecture, the software safety class of the affected items, and the analysis of what the change could plausibly affect. Automated test suites that cover the critical paths are the efficient way to meet this; the scope for each change is recorded in the change request.

Can the software maintenance plan be combined with the software development plan? Yes. The standard does not require two separate plans. A single lifecycle plan that covers both the development and the maintenance activities is acceptable and, for small teams, usually preferable because it avoids drift between the two. What matters is that the maintenance-specific content — feedback channels, problem evaluation, modification decision criteria, risk and class reassessment, release authorisation — is present in the combined plan.

Does clause 6 require the risk file to be updated on every change? The risk file must be updated whenever a change affects the risk profile. Not every change does. A change that has no plausible effect on any identified hazard can be recorded as risk-assessed and unchanged, and the risk file stays as it is. A change that touches a software item contributing to a hazardous situation, or that could introduce a new failure mode, requires an update to the ISO 14971 risk file. The decision is documented either way.

How does clause 6 interact with post-market surveillance? Post-market surveillance under MDR Articles 83 to 86 feeds clause 6 with real-world data about how the device is performing. Complaints, trend data, vigilance reports, and PMS reports are inputs to clause 6.2 problem and modification analysis. The clause 6 process is how the manufacturer responds to what PMS finds. The two processes are coupled — PMS without clause 6 produces reports nobody acts on; clause 6 without PMS produces a maintenance process disconnected from real-world performance.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17. Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015), Clause 6 Software maintenance process, and Clause 5.8 Software release activity. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I.
  4. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for change control at the QMS level.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the software maintenance process under EN 62304:2006+A1:2015 clause 6 and its link to MDR Annex I Section 17. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 is the harmonised tool that operationalises the software maintenance obligation, not an independent authority. For startup-specific regulatory support on software maintenance, change control, and post-release lifecycle discipline, Zechmeister Strategic Solutions is where this work is done in practice.