A compliant medical software release under EN 62304 clause 5.8 requires eight sub-activities: verify that integration and system testing are complete, document all known residual anomalies with risk justification, produce versioned release documentation, archive the exact built artefacts and their build environment, and ensure the build is repeatable. Skip any of these and your Annex II technical documentation has a hole an auditor will find in minutes.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN 62304:2006+A1:2015 clause 5.8 defines what "software release" means for a regulated medical device — it is not pressing Deploy.
  • Clause 5.8 has eight sub-activities (5.8.1 to 5.8.8) covering verification completion, known anomalies, documentation, archiving, and repeatability.
  • MDR Annex II point 6.1(b) requires verification and validation evidence for software in the technical documentation — your release record is the anchor for that evidence.
  • Every known residual anomaly must be evaluated against risk and justified in writing before release, not after.
  • Releases must be repeatable: the exact same source, tools, and environment must reproduce the exact same output years later.
  • If your release is a Jenkins job and a Slack message, you do not have a medical software release.

Why this matters

A founder showed me a release pipeline last month that pushed a Class IIa diagnostic app to App Store Connect every time a pull request merged to main. Fast, modern, beautiful. Also non-compliant. There was no release record, no anomaly list, no archive of the exact artefact that reached users, and no way to reproduce the build six weeks later because half the dependencies had drifted.

This is the most common gap I see in software-heavy startups. Teams write great code, run good tests, and ship fast. What they do not do is treat "release" as a regulated lifecycle event. Under EN 62304:2006+A1:2015, it is. And MDR Annex II expects the evidence.

Get release right and the rest of your software technical documentation stays clean. Get it wrong and every audit turns into an archaeology dig.

What EN 62304 and MDR actually say

EN 62304:2006+A1:2015 clause 5.8 is titled "Software release." It is the final process of the software development lifecycle and applies to all software safety classes (A, B, C), with increasing rigor. The sub-activities are:

  • 5.8.1 Ensure software verification is complete. Before release, you must confirm that all planned verification activities (unit, integration, system) have been executed and their results reviewed. Any deviations from the verification plan must be addressed.
  • 5.8.2 Document known residual anomalies. Every unresolved defect, bug, or deviation known at release time must be listed with a description, evaluation, and justification that it does not unacceptably affect safety.
  • 5.8.3 Evaluate known residual anomalies. This evaluation must consider the impact on the ability of the device to satisfy its intended use and, critically, whether any anomaly could contribute to a hazardous situation under EN ISO 14971:2019+A11:2021.
  • 5.8.4 Document released versions. The released software must be uniquely identified — version number, build identifier, date, and the exact list of configuration items that make it up.
  • 5.8.5 Document how the released software was created. Build environment, compilers, linkers, library versions, build scripts, signing keys — enough that a qualified person could reproduce the build.
  • 5.8.6 Ensure activities and tasks are complete. All planned development activities, including documentation, must be finished and approved before release.
  • 5.8.7 Archive software. The source code, build tools, documentation, and produced artefacts must be archived for the lifetime of the device plus the retention period required by MDR Article 10(8) — at least 10 years after placing the last device on the market, 15 years for implantables.
  • 5.8.8 Assure repeatability of software release. You must be able to repeat the release — not just theoretically, but practically. If your build only works because someone's laptop has a specific Node version, that is a finding.

On the MDR side, Annex II point 6.1(b) requires the technical documentation to contain results and critical analyses of verification and validation tests carried out to demonstrate conformity with the GSPR, in particular the applicable requirements of Annex I. Annex I §17.2 requires software to be developed and manufactured in accordance with the state of the art taking into account the principles of development lifecycle, risk management, verification and validation. EN 62304 is the harmonized standard giving presumption of conformity to Annex I §17.2, and clause 5.8 is the bridge between your engineering process and your Annex II evidence.

A notified body auditor reading your technical documentation will expect to see a release record that ties together the SOUP list, the anomaly list, the test reports, the build manifest, and the risk file. That single document is the anchor. Everything else hangs off it.

A worked example: releasing v2.4.0 of a Class IIa triage app

Let us walk through a real release. The device is a Class IIa symptom triage app (Rule 11), software safety class B under EN 62304, developed by a seven-person startup.

Trigger. Sprint 18 closes with a feature to add a new triage pathway for pediatric users. The product owner calls the release candidate v2.4.0-rc1.

5.8.1 verification complete. The software lead checks the verification plan. All 412 unit tests pass. All 68 integration tests pass. System test protocol STP-2.4 has been executed by QA — 94 of 96 cases pass, 2 are deferred with a written deviation and linked to the anomaly list. Verification completeness is signed off.

5.8.2 and 5.8.3 residual anomalies. The anomaly list for v2.4.0 contains 11 known issues. Each entry has: ID, description, affected function, reproduction steps, severity, and a risk evaluation referencing the hazard analysis in the risk management file. For example, anomaly A-2024-087: "Triage result screen renders incorrectly on Android 9 devices with font scaling >150%." Risk evaluation: does not change the triage output, only visual rendering; user can still read the recommendation; mitigated by label recommending supported OS versions; linked to hazard H-12 with risk control RC-12.3. The PRRC signs each anomaly individually.

5.8.4 release documentation. The release record lists: version v2.4.0, build identifier 2.4.0+b.8842, release date, git commit hash, the full SBOM (software bill of materials) including 147 SOUP components with their evaluated versions, and pointers to the test reports and risk file revisions that apply.

5.8.5 how it was built. The build happens in a pinned Docker image (node:20.11.1-alpine3.19@sha256:...) on a reproducible CI runner. The Dockerfile, the CI pipeline definition, and the exact toolchain versions are committed to the repository. The build manifest references the signed Docker image digest.

5.8.6 activities complete. The release checklist confirms the updated user manual, updated IFU, updated risk file, updated clinical evaluation (if applicable), updated PMS plan references, and design history file entries are all present and approved.

5.8.7 archive. The release artefact (signed bundle), the source snapshot (git bundle), the build environment (Docker image), the SBOM, the test reports, and the release record are stored in an immutable, access-controlled archive — typically an object store with versioning and legal hold enabled. Retention: lifetime of the device plus at least 10 years.

5.8.8 repeatability. Two weeks after release, an engineer on holiday cover executes the build script from a clean machine using only the archived inputs. Byte-identical output. That is the evidence of repeatability, and it goes into the release record as a signed reproducibility check.

Total elapsed release time: roughly four hours of human effort across five people. That is the price of a compliant release. It is not much once the template exists.

The Subtract to Ship release playbook

Here is the minimum-viable release process that satisfies clause 5.8 without drowning a startup in bureaucracy.

1. One release record template, versioned in your QMS. One Markdown file per release. It has sections matching 5.8.1 through 5.8.8. The template is a controlled document. Every release produces one instance, and the instance becomes a record.

2. Anomaly list as a queryable database, not a Word doc. Use your issue tracker (Jira, Linear, GitHub Issues) with a dedicated "Known Anomaly" label and required fields: severity, risk link, affected version, PRRC sign-off. At release time, the anomaly list is an exported snapshot filtered to "open at release" — not manually curated.

3. Reproducible builds from day one. Pin your toolchain. Pin your dependencies. Build in containers. Check in your Dockerfile. If you cannot reproduce your build today, you cannot reproduce it in seven years.

4. SBOM generation automated. Every build emits an SBOM (CycloneDX or SPDX). The SOUP list in your technical documentation references the SBOM — no manual maintenance.

5. Release gate with named owners. The release record requires signatures from: software lead (verification complete), QA lead (test reports complete), risk owner (anomalies evaluated), PRRC (regulatory sign-off), release manager (archive and build verification). Five names. No release without them.

6. Archive on day of release, not "later." The archive step is part of the release pipeline, not a promise. Releases that are not archived same-day are not released — they are drafts.

7. Quarterly reproducibility drill. Pick a random historical release. Reproduce it from the archive. If you cannot, file a CAPA. This is the only way to catch archive drift before an audit does.

8. Link the release record into Annex II from day one. Your technical documentation's V&V section should point to the release records directory. Notified body reviewers love this. It shortens their review and your findings list.

This traces directly to EN 62304:2006+A1:2015 clause 5.8 and MDR Annex II point 6.1(b). It is not extra. It is the minimum.

Reality Check

  • Can you reproduce your most recent release, byte-for-byte, from your archive right now?
  • Does every release have a written, signed record of known residual anomalies evaluated against your risk file?
  • Is your SOUP list generated automatically from your build, or maintained by hand?
  • If the engineer who set up your CI pipeline left tomorrow, could someone else still release?
  • Does your release record cross-reference the test reports, the risk file revision, and the SBOM?
  • Have you ever executed a reproducibility drill on a historical release? What happened?
  • Is your archive immutable, or can someone delete a past release artefact?
  • Does your PRRC review and sign every release, or only the big ones?

Frequently Asked Questions

Does clause 5.8 apply to software safety class A? Yes. All sub-activities apply to all classes, but the rigor scales. A class A release still needs a record, known anomalies, and an archive. The depth of evaluation for anomalies is lighter because the safety impact is by definition lower.

Do we need a full release for a hotfix? Yes. Any change that reaches users is a release under clause 5.8. Hotfixes often cause the worst audit findings because teams skip the record "just this once." Hotfix or not, the eight sub-activities apply.

How long do we archive released software? MDR Article 10(8) requires the technical documentation to be kept for at least 10 years after the last device of that type has been placed on the market, or 15 years for implantable devices. Your software archive must match.

Is "repeatable build" the same as "reproducible build"? Clause 5.8.8 uses the word "repeatability." In practice this means you can reproduce the release from the archived inputs. True bit-for-bit reproducibility is the gold standard and achievable with modern toolchains — aim for it.

Does continuous deployment violate EN 62304? Not inherently. You can automate the release pipeline end-to-end, but each release must still produce the clause 5.8 evidence and pass the gate. Automated does not mean undocumented.

What about over-the-air updates? OTA updates are releases. Each OTA-delivered version needs its own release record. Some devices release weekly — those devices need weekly release records.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex II point 6.1(b); Annex I §17.2; Article 10(8).
  2. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes. Clause 5.8 Software release, sub-activities 5.8.1–5.8.8.
  3. EN ISO 14971:2019+A11:2021 — Application of risk management to medical devices.