MDR Annex I Section 17.1 requires every device that incorporates electronic programmable systems and every device that is software to be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management, verification, and validation. Section 17.2 repeats the lifecycle requirement explicitly for software itself. EN 62304:2006+A1:2015 is the harmonised standard that operationalises those requirements by defining the software development, maintenance, risk management, configuration management, and problem-resolution processes that a manufacturer can follow to obtain presumption of conformity with the software-lifecycle aspects of Annex I. The MDR is the North Star. EN 62304:2006+A1:2015 is the tool.

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

TL;DR

  • MDR Annex I Section 17.1 sets the legal requirement that software in or as a medical device be developed under a lifecycle process that reflects the state of the art.
  • MDR Annex I Section 17.2 narrows the requirement to software specifically and ties it to development life cycle, risk management, verification, and validation.
  • EN 62304:2006+A1:2015 is the harmonised standard referenced for the software lifecycle. Compliance with the standard provides presumption of conformity with the software-lifecycle aspects of Annex I.
  • The standard defines five main process groups: software development, software maintenance, software risk management, software configuration management, and software problem resolution.
  • EN 62304:2006+A1:2015 introduces a software safety classification — Class A, Class B, Class C — that is distinct from the MDR device class under Annex VIII Rule 11 and that scales the required lifecycle activities to the severity of possible harm.
  • Risk management under EN 62304:2006+A1:2015 is integrated with EN ISO 14971:2019+A11:2021 — the risk-management standard referenced for MDR Annex I — and the outputs of the ISO 14971 process feed the software safety class determination.
  • The QMS that wraps the whole lifecycle is EN ISO 13485:2016+A11:2021, the harmonised standard for medical device quality management.
  • The lifecycle is not back-fillable without rework. Startups who wait until the certification project starts to apply the standard almost always end up reconstructing documentation from code history, and reconstruction is more expensive than doing it in-flight.

Why this matters for your startup

Every medical software startup we meet reaches the same moment. The product works on real hospital data, the first paying pilot is live, and someone — usually an investor, sometimes a hospital procurement lead, occasionally the founder themselves at 2 a.m. — asks the question that starts the next 18 months of work. "What does your software development look like from a regulatory perspective?" At that moment there are two kinds of companies. The ones whose engineering team has been running a documented lifecycle aligned with EN 62304:2006+A1:2015 from the first commit, and the ones who have not.

The first kind has a hard conversation ahead of them — formalising processes, cleaning up documentation, running a gap assessment against the standard. The second kind has a much harder one — reconstructing documentation for code that was written without the discipline in mind, which in practice often means writing requirements and architecture documents that match code that already exists, running verification campaigns after the fact, and explaining to a Notified Body why the records look suspiciously clean for software that was in production before the QMS existed. Reconstruction is technically possible. It is always more expensive than doing the work in-flight, and it is always less convincing to an auditor.

MDR Annex I Section 17 is not a checklist you complete before certification. It is a set of lifecycle obligations that apply from the first line of code the manufacturer intends to become a medical device. EN 62304:2006+A1:2015 is the tool that turns those obligations into a process a real engineering team can follow. This post walks through both, shows how the main processes fit together, and explains how a resource-constrained startup can implement the lifecycle without building a process apparatus that buries the engineering.

What MDR Annex I Section 17 actually requires

Annex I of the MDR is the General Safety and Performance Requirements — the binding set of outcomes every device on the EU market must meet. Section 17 is the software-specific section, and it has two parts that matter here.

Section 17.1 addresses electronic programmable systems. It requires that devices which incorporate electronic programmable systems, and software that is a device in itself, be designed to ensure repeatability, reliability, and performance in line with their intended use, and that a single-fault condition be addressed by appropriate means. The section also requires that devices are designed and manufactured taking into account the principles of development life cycle, risk management, information security, verification, and validation. (Regulation (EU) 2017/745, Annex I, Section 17.1.)

Section 17.2 tightens the lifecycle requirement for software specifically. It 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 legal obligation that wraps Annex I is Article 10, the general obligations of manufacturers. Article 10(1) requires manufacturers to ensure that their devices are designed and manufactured in accordance with the requirements of the Regulation, and Article 10(9) requires manufacturers to establish a quality management system that covers, among other things, product realisation and design. (Regulation (EU) 2017/745, Article 10, paragraphs 1 and 9.) Section 17 is where those general obligations become concrete for software.

Two phrases in Section 17.2 do the work. "State of the art" is the mechanism the MDR uses to pull in harmonised standards without naming them in the Regulation text — the state of the art for software lifecycle is defined by the current harmonised standard, which is EN 62304:2006+A1:2015. "Principles of development life cycle" is the hook for the process architecture of EN 62304:2006+A1:2015 itself. Read together, Section 17.2 says: develop your software under a documented lifecycle that reflects the current harmonised standard, and be able to show the Notified Body how you did it.

The MDR text does not name EN 62304:2006+A1:2015 in Annex I. It does not have to. The harmonised-standards mechanism under MDR Article 8 — and the Commission's Official Journal list of harmonised standards — is how specific standards acquire presumption of conformity with specific Annex I requirements. For the software lifecycle, that standard is EN 62304:2006+A1:2015.

EN 62304:2006+A1:2015 as the harmonised tool

EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes — is the European version of IEC 62304:2006 with Amendment 1 from 2015. It is the harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2, and compliance with it gives the manufacturer presumption of conformity with the software-lifecycle aspects of Annex I.

The standard is process-based, not product-based. It does not tell you what the software should do — the intended purpose, the clinical function, and the performance claims come from the manufacturer. It tells you how to run the development and maintenance processes so that the resulting software meets the safety requirements the manufacturer has set for it. The standard is deliberately technology-neutral. It does not prescribe a programming language, a framework, a development methodology, or an architecture style. Waterfall works. Agile works. Continuous delivery works. What the standard requires is that whatever process you run, you run it with documented activities, outputs, and verification, and that the documentation reflects what actually happened in the code base.

The scope of EN 62304:2006+A1:2015 is specifically medical device software — software that is itself a medical device (MDSW) or software that is an integral part of a medical device. It does not cover general-purpose software used as a tool in the development process, and it does not cover software used in the manufacturing of a device. Those are addressed under EN ISO 13485:2016+A11:2021 as part of the broader QMS. EN 62304:2006+A1:2015 is the standard for the product code itself.

The standard interacts with two other harmonised standards and you cannot apply one without the others. EN ISO 14971:2019+A11:2021 is the risk-management standard referenced for MDR Annex I; EN 62304:2006+A1:2015 explicitly integrates with the ISO 14971 process and uses its outputs to determine the software safety class. EN ISO 13485:2016+A11:2021 is the QMS standard; EN 62304:2006+A1:2015 assumes the manufacturer operates under a 13485-aligned QMS and does not duplicate the QMS requirements inside the software process. The three standards form a triangle, and the MDR Annex I software lifecycle requires all three.

The main processes the standard defines

EN 62304:2006+A1:2015 is organised into five process groups. This section walks through each one at the level a founder or technical lead needs to plan the engineering work. It is not a full reading of the standard — that is the standard's job — but it covers the activities the Notified Body will expect to see evidence of.

Software development planning. The starting point is a software development plan that covers the scope of the software, the life cycle model the team will use, the deliverables, the responsibilities, the verification activities, the integration of risk management, the configuration management approach, and the problem-resolution approach. The plan is a living document; it is updated as the software evolves. For startups, the plan is often the shortest useful document in the whole lifecycle — five to ten pages is enough for a small team — but it has to exist before the development activities under the other processes begin, and it has to match what the team actually does.

Software requirements analysis. The requirements activity takes the system requirements and intended purpose and derives software-specific requirements that are verifiable, traceable, and consistent. Requirements cover functional behaviour, interfaces, performance, safety, security, user interaction, and constraints from the operating environment. Each requirement is traceable upward to the system requirements and downward to the design and the verification activities. Requirements are not user stories. They can be written as user stories in the team's tracker, but the traceable regulatory artefact is the requirements specification itself, and the traceability has to close.

Software architectural design. The architecture activity defines the software items — the top-level structural units of the software — and the interfaces between them. The architecture is where the manufacturer identifies the boundary between software items that can contribute to hazardous situations and software items that cannot, and where segregation arguments are made. This is the activity where the software safety class is applied: higher-class items require more rigour in the subsequent activities than lower-class items.

Software detailed design. Detailed design refines the architecture to the level where individual software units can be implemented. For Class C software, the standard requires detailed design at the unit level; for Class B, detailed design is required for software items (not necessarily down to units); for Class A, detailed design is not required by the standard. This is the first place where the scaling by class pays off — a Class A module that truly is Class A does not need the same design documentation as a Class C module.

Software unit implementation and verification. Implementation is the coding activity. Verification at the unit level — unit tests, code reviews, static analysis — checks that the code meets the detailed design and the coding standards. The verification activities required scale with the software safety class: Class C requires the most, Class A the least.

Software integration and integration testing. Integration brings software units together into software items and the items together into the complete software system. Integration testing verifies that the interfaces work and that the integrated software meets the architectural design. Integration testing is required for Class B and Class C software.

Software system testing. System testing verifies the software against the software requirements. It is the activity where the manufacturer demonstrates, with recorded evidence, that the software does what the requirements say it does. System testing is required for all classes, though the rigour scales with class.

Software release. Release is the controlled activity of making a specific, verified, documented version of the software available for clinical use. Release requires that the manufacturer has evidence that all planned activities are complete, that known anomalies have been evaluated against the risk management, and that the configuration of the release is known and reproducible. Release is not a deployment button; it is a gate with documented criteria.

Software maintenance. Maintenance covers everything that happens to the software after release: bug fixes, feature additions, security patches, compatibility updates. The maintenance process runs under a maintenance plan and uses the same development, verification, and risk-management activities — often at smaller scale — as the initial development. The maintenance process also feeds into the problem-resolution process.

Software risk management. Software risk management is the bridge to EN ISO 14971:2019+A11:2021. The software risk-management process identifies software-related hazards, analyses them, implements risk controls inside the software, verifies the controls, and feeds the results back into the overall risk management file. EN 62304:2006+A1:2015 does not replace ISO 14971; it integrates with it. The ISO 14971 process owns the risk-management file; EN 62304:2006+A1:2015 owns the software-specific activities inside it.

Software configuration management. Configuration management keeps the lineage of the software under control. Every item in the software — source code, design documents, build scripts, third-party libraries, tools — has an identifier, a version, and a controlled change history. A release is reproducible from the configuration management record. For most modern teams this is Git plus a release process, but the Git-plus-release-process has to be documented as the configuration management approach, not assumed.

Software problem resolution. Problem resolution is the process by which anomalies — bugs, unexpected behaviours, field reports — are captured, investigated, resolved, and verified. The process feeds back into risk management (does the problem change the risk profile?), configuration management (which versions are affected?), and release (is a new release needed?). Problem resolution connects the lifecycle to post-market surveillance under MDR Articles 83-86.

Software safety classification — Class A, Class B, Class C

EN 62304:2006+A1:2015 introduces its own classification system for software, distinct from the MDR device class under Annex VIII Rule 11. The software safety class is driven by the severity of the possible harm that could result from a software failure, before external risk controls outside the software are applied.

Class A — No injury or damage to health is possible from a software failure. Class B — Non-serious injury is possible. Class C — Death or serious injury is possible.

The class is determined by analysing the software's contribution to hazardous situations identified in the ISO 14971 risk-management process. External risk controls — hardware safeguards, procedural controls, clinical monitoring — can reduce the class, but only if they are effective and independent of the software. The determination is documented in the risk-management file and in the software development plan.

The practical consequence of the class is the depth of the required activities. Class C requires detailed design at the unit level, unit-level verification, integration testing, and the fullest set of documentation. Class B requires architectural design down to software items, integration testing, and system testing. Class A requires the minimum: development planning, requirements, and system testing against the requirements. A startup that can truthfully argue Class A for a module saves substantial work on that module. A startup that assumes Class A when the risk analysis would support Class B or Class C is building a technical file that will not survive audit.

The software safety class is not the MDR device class. A Class IIa MDSW under Rule 11 can contain Class A, Class B, and Class C software items inside it, and the classification has to be made at the level of the software item, not the device as a whole. We cover the software safety classification in full in post 377.

How startups implement this without over-process

The standard is often read as permission to build a heavy process apparatus. It is not. The standard scales with the risk, and a competent startup can satisfy it with a lean implementation that fits a small engineering team. The moves that work across the startups we have seen pass EN 62304:2006+A1:2015 audits are these.

Start the lifecycle with the first line of code that is intended to become medical device software. Not the first commit ever written — the first commit that is part of the product that will be certified. Before that point you can prototype freely. After that point, every commit is under the lifecycle.

Keep the documentation in the same repository as the code. Requirements, architecture, design, test plans, and risk-management outputs all live in the repo as markdown or as structured text. The documents are versioned alongside the code, and the traceability is maintained through cross-references that can be checked automatically. This removes the single largest source of lifecycle pain — the drift between a Word document on a shared drive and the code in production.

Automate the verification evidence. Unit tests, integration tests, static analysis, and build reproducibility can all be automated in CI. The regulatory artefact is the test run log, not a hand-written test report. The time to set up automated evidence capture is the first sprint, not the audit week.

Run risk management continuously, not as a pre-release activity. Every new feature, every change, every bug report goes through a short risk-assessment pass that updates the risk file. The risk file is not a 200-page document written once at the end; it is a living record that grows with the software.

Use the smallest viable configuration management: one source repository, semantic versioning, signed releases, release notes linked to tickets and tests. This is what most competent engineering teams already do. The lifecycle work is documenting it as the configuration management approach, not replacing it.

Keep the software development plan short. A five-page plan that the team reads and follows is worth more than a fifty-page plan that sits in a shared drive. The plan answers: what lifecycle model do we use, what are the process inputs and outputs, how do we verify, how do we handle risk, how do we manage configuration, how do we resolve problems.

Involve a reviewer who has seen the standard applied before, not just read it. The difference between a technically compliant process and an audit-ready process is judgement that is hard to acquire from the text alone. This is where the gap between knowing what should be done and doing it safely opens. A half-day review with an experienced practitioner at the plan stage is worth a month of rework at the audit stage.

The Subtract to Ship angle

EN 62304:2006+A1:2015 is the category where Subtract to Ship has the most leverage. The default response to the standard is to add process — templates, meetings, gates, sign-offs — until the team is drowning. The competent response is to subtract everything that is not required by the standard or by the software safety class of the item in question, and to keep only what earns its place in the file.

The subtraction moves that work in this category are these. Scope the medical module narrowly so the regulated code base is as small as it can honestly be — MDCG 2019-11 Rev.1 supports this, and it is the single largest saving in a software lifecycle. Assign the software safety class honestly at the item level, not bulk-assign Class C to everything to be safe. Class C is not the safe choice; it is the expensive choice, and assigning it where Class B is defensible is a subtraction the startup has given away. Use automation to produce evidence instead of human-written reports where the standard allows it. Keep the software development plan short. Do not build a separate risk-management process parallel to the ISO 14971 process; integrate them. Do not build a configuration management process parallel to the one the engineering team already runs; document the existing one.

The principle is the same as the broader Subtract to Ship framework: every process activity has to trace back to a specific clause of the standard and, through the standard, to a specific MDR Annex I obligation. Activities that do not trace come out. For the broader framework applied to MDR, see post 065.

Reality Check — Is your software lifecycle ready for an MDR audit?

  1. Do you have a written software development plan that covers scope, life cycle model, deliverables, verification, risk integration, configuration management, and problem resolution?
  2. Can you produce a traceable requirements specification that links upward to the system requirements and downward to the design and the verification activities?
  3. Is your software architecture documented at a level that lets you identify which software items contribute to hazardous situations?
  4. Have you assigned a software safety class — A, B, or C — to each software item, with the reasoning linked to the EN ISO 14971:2019+A11:2021 risk file?
  5. Is your unit, integration, and system testing evidence captured automatically and reproducibly from CI, not written by hand after the fact?
  6. Do you have a configuration management approach that makes every release reproducible from the source repository, with identifiers and version control over code, documents, and third-party dependencies?
  7. Do you have a problem-resolution process that captures anomalies, links them to versions, feeds them into risk management, and closes the loop back to release decisions?
  8. Is your software maintenance process defined and running, or are post-release changes happening without a documented maintenance cycle?
  9. Does your risk management integrate EN 62304:2006+A1:2015 with EN ISO 14971:2019+A11:2021 — one risk file, not two parallel files — and does the integration feed the software safety class determination?
  10. Does your lifecycle documentation reflect what the engineering team actually does, or does it describe a process that exists only on paper?

Any question you cannot answer with a clear yes is a gap between your current practice and what the Notified Body will want to see. The earlier in the lifecycle you close the gap, the cheaper it is to close.

Frequently Asked Questions

Is EN 62304:2006+A1:2015 legally required by the MDR? The standard is not named in the MDR text. MDR Annex I Section 17.2 requires that software be developed in accordance with the state of the art, taking into account the principles of development life cycle, risk management, verification, and validation. EN 62304:2006+A1:2015 is the harmonised standard that operationalises those requirements, and compliance with it gives presumption of conformity with the software-lifecycle aspects of Annex I. A manufacturer can technically demonstrate compliance with Annex I by other means, but in practice Notified Bodies expect EN 62304:2006+A1:2015 and deviations from it need a strong argument.

Can I use Agile development and still comply with EN 62304:2006+A1:2015? Yes. The standard is process-neutral and does not prescribe a lifecycle model. Agile teams comply by ensuring the required activities — planning, requirements, design, verification, configuration management, problem resolution, risk management — happen with documented evidence, at whatever cadence the team runs. Agile actually maps well onto the standard because the activities are already happening; the work is to capture the evidence and the traceability.

What is the difference between the MDR device class under Rule 11 and the EN 62304:2006+A1:2015 software safety class? The MDR device class (Class I, IIa, IIb, III) is assigned to the device as a whole under Annex VIII Rule 11 and drives the conformity assessment route with the Notified Body. The software safety class (A, B, C) is assigned to individual software items inside the software under EN 62304:2006+A1:2015 and drives the depth of the required lifecycle activities. A single MDR Class IIa device can contain Class A, Class B, and Class C software items at the same time. Both classifications are required, and they are related but not the same. Post 377 covers the software safety class in full.

Do I need EN 62304:2006+A1:2015 if my software is Class I under the MDR? Yes. MDR Annex I Section 17.2 applies to all software that is a medical device, regardless of MDR class. Class I software still has to be developed under a lifecycle process that reflects the state of the art. The depth of activities scales with the software safety class under EN 62304:2006+A1:2015, not with the MDR device class. A Class I MDR device with Class A software has a lighter lifecycle than a Class I MDR device with Class B software.

When should a startup start applying EN 62304:2006+A1:2015? On the first commit of the code that is intended to become medical device software. Prototypes and research code written before the decision to make a medical device are outside scope. Once the decision is made and the code base is intended to become the product, the lifecycle starts. Waiting until the certification project starts means reconstructing documentation for code that already exists, which is always more expensive than doing it in-flight.

Does EN 62304:2006+A1:2015 cover cybersecurity? Partly. The standard addresses information security as part of the software lifecycle, and the MDR Annex I Section 17.2 mentions information security explicitly. For the full cybersecurity lifecycle, the harmonised standard is EN IEC 81001-5-1:2022, and the MDCG guidance is MDCG 2019-16 Rev.1. EN 62304:2006+A1:2015 is the foundation; cybersecurity-specific activities layer on top of it.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10; Annex I, Section 17.1 and Section 17.2. 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). 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 the QMS under MDR Article 10(9) and Annex IX.
  5. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the software lifecycle obligations that apply once software qualifies as a medical device. 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 provides presumption of conformity with the software-lifecycle aspects of MDR Annex I Section 17, not an independent authority. For startup-specific regulatory support on software lifecycle implementation, software safety classification, and technical file scoping, Zechmeister Strategic Solutions is where this work is done in practice.