An MDR software compliance checklist for a MedTech startup runs fifteen sequential gates: (1) qualify the software as a medical device under Article 2(1) and MDCG 2019-11 Rev.1, (2) classify under Annex VIII Rule 11, (3) assign the EN 62304:2006+A1:2015 software safety class A, B, or C, (4) write the software development plan, (5) establish software requirements, (6) produce the software architecture, (7) produce the detailed design for Class B and C, (8) implement with coding standards and unit verification, (9) run software integration and system verification, (10) release the software with a documented release record, (11) operate the software maintenance process, (12) run software configuration management, (13) run the software problem resolution process, (14) layer EN IEC 81001-5-1:2022 cybersecurity activities across every stage, and (15) align every output with the Annex II technical documentation. EN ISO 14971:2019+A11:2021 risk management runs underneath all fifteen gates. This checklist is the minimum set of artefacts a Notified Body will look for in a Class IIa or higher SaMD review.

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

TL;DR

  • The MDR does not specify software activities directly. Annex I Section 17 sets the result, and EN 62304:2006+A1:2015 is the harmonised standard that tells you how to achieve it.
  • The software safety class (A, B, C) under EN 62304:2006+A1:2015 is a separate classification from the MDR device class under Annex VIII Rule 11. A Class IIa SaMD can be software safety Class B or C depending on the hazard analysis.
  • Cybersecurity is not a bolt-on. EN IEC 81001-5-1:2022 runs in parallel with EN 62304:2006+A1:2015 across the lifecycle and is the current state-of-the-art standard for MDR Annex I Section 17 security requirements.
  • Every gate in this checklist produces an artefact that lands in the Annex II technical documentation. A gate that has no artefact has not been passed.
  • The checklist is the same whether you are a two-person startup or a 200-person scale-up. What changes is the weight of each artefact, not the existence of any of them.

Why a checklist and not a framework

A Notified Body does not review your philosophy of software development. It reviews a technical file that either contains the required artefacts or does not. The gap between "we run a modern software process" and "we have an EN 62304:2006+A1:2015 compliant software lifecycle file" is the gap that most founders misjudge.

The fifteen-gate checklist below is the minimum set a Class IIa or higher SaMD submission has to pass. It is written as a sequence because the gates depend on each other — you cannot assign a software safety class before you have a hazard analysis, and you cannot write the software development plan before you know the class. Run the gates in order. Do not skip.

The Salzburg SaaS case we wrote about in post 417 is the version of this checklist that worked. The founder wrote down each gate, assigned an owner, produced the artefact, and moved on. No gate was skipped. No artefact was produced twice. The technical file at the end was 320 pages and the Notified Body review closed with two minor findings — both resolvable within the review cycle. That is what this checklist is designed to produce.

Gate 1 — Qualification under Article 2(1) and MDCG 2019-11 Rev.1

Before any software process starts, answer the qualification question in writing. Is the software a medical device under MDR Article 2(1)? Walk the MDCG 2019-11 Rev.1 (June 2025) decision tree step by step and reach a documented conclusion. The output of this gate is the qualification rationale — a standalone document that references the MDCG decision tree explicitly, names each test, and records the reasoning.

If the software is not a medical device, the rest of this checklist does not apply. If the software is a medical device, the qualification rationale sits at the top of the Annex II technical file. Post 371 covers the qualification question in depth and post 374 walks through MDCG 2019-11 Rev.1 in full.

Gate 2 — Classification under Annex VIII Rule 11

Classify the device under MDR Article 51 by applying the rules in Annex VIII. For SaMD, the governing rule is almost always Annex VIII Rule 11. Document which sub-paragraph of Rule 11 applies and why, with reference to the intended purpose from the qualification rationale.

The classification output is the single number — Class I, IIa, IIb, or III — that decides whether Gate 15 (the Notified Body conformity assessment) is self-certified or involves a third party. For Class IIa and above, a Notified Body is mandatory. Post 081 covers Rule 11 in full.

Gate 3 — Assign the EN 62304:2006+A1:2015 software safety class

The software safety class under EN 62304:2006+A1:2015 is distinct from the MDR device class. The standard defines three classes:

  • Class A: no injury or damage to health is possible.
  • Class B: non-serious injury is possible.
  • Class C: death or serious injury is possible.

The class is assigned by running the hazard analysis from EN ISO 14971:2019+A11:2021 against the software and asking what the worst foreseeable harm is if the software fails with no risk controls. The class drives the set of activities EN 62304:2006+A1:2015 requires — Class C has the most, Class A the fewest. The software safety class is recorded in the software development plan and can be assigned at the software-item level, not only at the software-system level. Post 377 covers the software safety classification in depth.

Gate 4 — Write the software development plan

EN 62304:2006+A1:2015 Clause 5.1 requires a software development plan that covers the development process, deliverables, traceability between system requirements and software items, software configuration and change management, software problem resolution, and the software safety class from Gate 3. The plan names the standards followed, the tools used, the roles responsible, and the entry and exit criteria for each lifecycle stage.

The plan is the reference document for the rest of the lifecycle. A weak plan produces a weak file. The plan is reviewed and approved before any implementation starts and is updated whenever the process changes.

Gate 5 — Software requirements

Clause 5.2 requires software requirements derived from the system requirements and the risk analysis. For SaMD, the system requirements come from the intended purpose, the clinical use case, the user needs, and the Annex I general safety and performance requirements. Software requirements cover functional and capability requirements, inputs and outputs, interfaces, alarms and warnings, security, usability, data definitions, and installation and acceptance requirements.

Every software requirement is traceable upward to a system requirement and downward to the design, the implementation, and the verification activity. The traceability is the artefact the Notified Body looks at first. A requirement without a test is a finding. A test without a requirement is a finding.

Gate 6 — Software architecture

Clause 5.3 requires a software architecture that describes the software structure, identifies software items and software units, documents the interfaces between them, and specifies the segregation mechanisms used to ensure that lower-safety-class items cannot compromise higher-safety-class items. For Class B and C software, the architecture is a gated deliverable that must exist before detailed design begins.

The architecture is the document that lets a Notified Body reviewer answer the question: if this one component fails, what else fails? A clear segregation argument — often based on process boundaries, network boundaries, or language-level isolation — is a strong architecture. A diagram without a segregation argument is not.

Gate 7 — Software detailed design (Class B and C)

Clause 5.4 requires detailed design of each software unit for Class B and Class C software. The detailed design is the level at which an engineer can implement the unit without guessing. For Class A software, this clause is not required.

The detailed design is typically produced as part of the development workflow — module specifications, interface definitions, data structures, algorithm descriptions — and stored in the configuration management system alongside the code. The Notified Body does not require the detailed design to live in a Word document. It requires it to exist, to be traceable, and to be under change control.

Gate 8 — Implementation with coding standards and unit verification

Clause 5.5 requires each software unit to be implemented and verified. Implementation runs against a documented coding standard. Unit verification covers code review, static analysis, and unit testing as appropriate to the software safety class. The acceptance criteria for unit verification are recorded in the software development plan and the verification records are retained.

For Class A, unit verification activities are minimal. For Class B and Class C, the activities escalate — Class C software typically requires code coverage metrics, static analysis with documented rule sets, and peer code review for every change. The point is not to produce theatre. The point is that the implementation of each unit is demonstrably correct against its design.

Gate 9 — Software integration and system verification

Clauses 5.6 and 5.7 require software integration, integration testing, and system verification. Integration testing verifies that software items combine correctly. System verification verifies that the software system meets the software requirements from Gate 5.

System verification is where the traceability closes. Every software requirement must have at least one verification activity, every verification activity must produce a recorded result, and every result must be reviewed against the acceptance criteria. The verification report is the artefact that lands in the Annex II technical file as evidence that the software achieves its specified behaviour. Post 376 covers the software lifecycle end-to-end.

Gate 10 — Software release

Clause 5.8 requires a documented software release process. Before release, the manufacturer has to verify that all software verification activities are complete, that all known residual anomalies have been evaluated, that the documentation is complete, and that the released software version and its build environment are uniquely identified and archivable.

The release record is the signed, dated artefact that authorises a specific software version for use in the medical device. A release record that does not identify the exact build, the tooling version, and the content of the release is a release record that cannot be reproduced — and irreproducible software cannot be maintained under MDR.

Gate 11 — Software maintenance

Clause 6 covers the software maintenance process. Maintenance is not optional. Every SaMD enters maintenance mode the moment it is released, and the maintenance process must be established before release, not after.

The maintenance plan covers how problem reports and change requests are received, how they are evaluated, how modifications are implemented and verified, and how modified software is released. Maintenance activities run the same lifecycle gates as the original development, scaled to the scope of the change. A critical fix does not escape verification just because it is urgent.

Gate 12 — Software configuration management

Clause 8 requires software configuration management. Configuration management identifies every configuration item — source code, tools, libraries, documents, test data — and places it under change control. Every change is recorded with author, date, reason, and approval. Every released version can be reconstructed from the configuration management system exactly.

For startups, this is where practices from general software engineering map cleanly onto EN 62304:2006+A1:2015. Git plus a release branching strategy plus signed commits plus pinned dependencies plus archived build environments satisfies most of Clause 8. What usually needs adding is the formal change record — the explicit link from a change request to the code change to the verification activity to the release.

Gate 13 — Software problem resolution process

Clause 9 requires a software problem resolution process. Every problem report — from internal testing, from user feedback, from post-market surveillance — is recorded, investigated, classified, and resolved through a documented process. The process feeds the risk management file and the post-market surveillance system.

The problem resolution process is one of the most-audited clauses of EN 62304:2006+A1:2015 because it is the interface between the software lifecycle and the vigilance obligations under MDR Articles 87 to 92. A weak problem resolution process is a vigilance gap waiting to happen.

Gate 14 — Cybersecurity under EN IEC 81001-5-1:2022

MDR Annex I Section 17.2 and Section 17.4 require manufacturers to address information security in the software lifecycle. EN IEC 81001-5-1:2022 is the current harmonised standard for cybersecurity activities in the health software product lifecycle. It runs in parallel with EN 62304:2006+A1:2015 and covers secure requirements, secure design, secure implementation, secure verification, secure release, secure maintenance, and secure decommissioning, along with a software bill of materials (SBOM), a vulnerability management process, and a coordinated disclosure policy.

Cybersecurity is not a Gate 14 that you run once at the end. It is a parallel track that produces artefacts at every stage of the EN 62304:2006+A1:2015 lifecycle — the requirements include security requirements, the architecture includes a threat model, the design includes security controls, the implementation includes secure coding practices, the verification includes penetration testing, the release includes an SBOM, the maintenance includes a vulnerability response process. MDCG 2019-16 Rev.1 remains the MDR-specific interpretive layer on cybersecurity and is read alongside the standard.

Gate 15 — Align every artefact with Annex II technical documentation

Annex II of the MDR specifies the structure of the technical documentation. Every artefact produced by Gates 1 through 14 must land somewhere in that structure, and the placement must be deliberate. The qualification rationale and classification sit at the top under device description. The software development plan, requirements, architecture, design, verification, release, maintenance, configuration management, problem resolution, and cybersecurity artefacts sit under design and manufacturing information and under product verification and validation. The hazard analysis and risk management file sit under benefit-risk analysis and risk management.

A technical file that has all the artefacts but none of the alignment is a file that is harder to review than it needs to be. A technical file that has the alignment but is missing artefacts is a file that fails. Both matter. Post 388 covers the orchestration of the Phase 2 build and how the artefacts land in Annex II.

The Subtract to Ship angle — what you can subtract and what you cannot

This checklist looks long. It is meant to. The temptation for a startup is to subtract gates to move faster. That temptation is the expensive mistake.

What you can subtract: duplication between artefacts, bureaucratic ceremony, tools that produce reports nobody reads, and work produced before it is needed. You do not need a 60-page software development plan for a two-person team building a Class B SaMD. You need an eight-page plan that names the standard, the class, the roles, the tools, and the gates. The plan must exist. The plan does not have to be thick.

What you cannot subtract: any of the fifteen gates. Every gate produces an artefact that the Notified Body will look for. Missing artefacts are findings. Findings delay certification. Delay costs more than the work of producing the artefact.

The Subtract to Ship discipline for software compliance is to produce each artefact at the minimum weight that satisfies the standard and the Notified Body, and no more. The instinct is to cut paperwork. The discipline is to cut paperwork without cutting gates. Post 065 covers the Subtract to Ship framework applied to MDR in full.

Reality Check — where are you on the software compliance checklist?

  1. Do you have a written qualification rationale that walks the MDCG 2019-11 Rev.1 decision tree explicitly?
  2. Have you classified the device under Annex VIII Rule 11 with reasoning tied to the intended purpose?
  3. Have you assigned an EN 62304:2006+A1:2015 software safety class at the software system level, and if appropriate at the software item level?
  4. Does your software development plan name the standard, the class, the tools, the roles, the gates, and the traceability strategy?
  5. Is every software requirement traceable upward to a system requirement and downward to at least one verification activity?
  6. Does your software architecture include a segregation argument that a reviewer can follow without asking questions?
  7. For Class B and C software, is detailed design produced, under change control, and traceable to the architecture?
  8. Is your implementation running under a documented coding standard with unit verification appropriate to the software safety class?
  9. Does your verification report close the traceability loop on every software requirement?
  10. Do you have a signed, dated release record that uniquely identifies every released software version and its build environment?
  11. Is your software maintenance process established and documented before release, not after?
  12. Is every configuration item — code, tools, libraries, documents, test data — under change control with a reconstructible history?
  13. Does your problem resolution process feed into the risk management file and the post-market surveillance system?
  14. Are cybersecurity activities running in parallel with the lifecycle under EN IEC 81001-5-1:2022, with an SBOM, a threat model, and a vulnerability response process?
  15. Is every artefact produced by Gates 1 through 14 mapped to a specific section of the Annex II technical documentation?

Any question you cannot answer with a clear yes is a gap. Close it before the Notified Body submission, not during.

Frequently Asked Questions

Is EN 62304:2006+A1:2015 mandatory under the MDR? The MDR does not name any standard as mandatory. What the MDR requires is compliance with Annex I Section 17 on software. EN 62304:2006+A1:2015 is the harmonised standard that provides presumption of conformity with the software-lifecycle aspects of Section 17. In practice, Notified Bodies expect to see EN 62304:2006+A1:2015 conformity or a fully documented alternative approach that achieves the same result. The alternative route is substantially more work than the standard.

What is the difference between the MDR device class and the EN 62304:2006+A1:2015 software safety class? The MDR device class under Annex VIII Rule 11 is about the regulatory risk of the device on the market — it drives the conformity assessment route and the Notified Body involvement. The EN 62304:2006+A1:2015 software safety class A, B, or C is about the hazard the software poses if it fails without risk controls — it drives the set of lifecycle activities the standard requires. A Class IIa SaMD under Rule 11 can be software safety Class B or C. Both classifications must be recorded.

Do we need EN IEC 81001-5-1:2022 if our software has no network connection? Yes in most cases. EN IEC 81001-5-1:2022 applies to health software across the lifecycle and is not limited to networked devices. Even software distributed as a local application has a supply chain, dependencies, an update mechanism, and configuration data — all of which have security implications under MDR Annex I Section 17. The depth of the cybersecurity activities scales with the threat model, but the activities are not optional.

Can we use a modern DevOps toolchain and still be EN 62304:2006+A1:2015 compliant? Yes. Git, continuous integration, automated testing, static analysis, containerised build environments, and code review tooling map cleanly onto EN 62304:2006+A1:2015 requirements. What DevOps tooling does not replace is the documented decision-making — the plan, the requirements, the architecture, the release record, the problem resolution record. Modern tooling produces most of the evidence. The documentation layer turns that evidence into a compliant file.

How big should the software development plan be for a two-person startup? Eight to fifteen pages is typical for a small team building a Class B SaMD. The plan has to name every element EN 62304:2006+A1:2015 Clause 5.1 requires, but each element can be brief. A plan that references the actual tools, the actual process, and the actual roles is more useful than a long plan full of boilerplate.

What is the most common finding a Notified Body raises on software files? Traceability gaps. A requirement with no test, a test with no requirement, a release with no recorded verification of a specific anomaly, a change with no problem report trail. Traceability is the connective tissue of the software file and is where weak files fail. A file where every artefact points to every other artefact is a file that passes review.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2 point 1, Article 51, Annex VIII Rule 11, Annex I Section 17, Annex II. Official Journal L 117, 5.5.2017.
  2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. Revision 1, June 2025.
  3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes.
  4. EN IEC 81001-5-1:2022 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle.
  5. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

This post is part of the Software as a Medical Device Under MDR category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim here — EN 62304:2006+A1:2015 and EN IEC 81001-5-1:2022 are the harmonised standards that provide presumption of conformity with MDR Annex I Section 17, not independent authorities. For startup-specific support on running this checklist in practice, Zechmeister Strategic Solutions is where this work gets done.