ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An IEC 62304 software release checklist keeps a medical device software team from shipping a build it cannot defend. The release is the moment when all the plans, requirements, tests and risk files have to agree, and it is also where auditors and notified bodies look first when they want to see whether your process is real.
This guide walks through the release activity in clause 5.8 of IEC 62304, the standard for medical device software life cycle processes. It covers what must be complete before you release, how to treat known anomalies, what to record about the release and how to archive and deliver it. Requirements vary by software safety class, so check the standard and your own quality system for the exact tasks that apply to your device. Nothing here replaces your regulatory advice.
Free gap assessment
How much of ISO 13485 could you evidence today?
Score clauses 4 to 8, free, with the FDA QMSR and EU MDR duties kept separate so you can see what is the standard and what is the regulator.
Run the free ISO 13485 gap assessment → or View premium report sample
IEC 62304 defines a software release activity inside the development process. It expects you to confirm that verification is complete, that the planned activities are finished, that known residual anomalies are documented and evaluated, that the released version is documented together with how it was built, that it is archived and that delivery is reliable. Some of those tasks apply to all safety classes, and others only to the higher classes, so map them against your own classification.
The standard is one part of a bigger picture. Your quality system under ISO 13485 and your risk management under ISO 14971 supply the surrounding controls. For where they meet, read our articles on IEC 62304 vs ISO 13485 and IEC 62304 risk management. Start with the software safety classification so you know which release tasks are required.
Before anything ships, prove that you did what the plan said you would do. Collect the test reports for unit, integration and system testing, confirm that every requirement has a linked test and that all tests passed or have a documented justification for any deviation. Verification on a release candidate means testing the exact build that will be released, not an earlier one.
A traceability matrix from requirements to tests to results makes this check fast. A gap in traceability is a release blocker, because it means you cannot show a requirement was tested. Automated test systems help, but the report must still be retained and approved.
No real software is perfect. The standard expects you to document the known residual anomalies in the release and to evaluate whether any of them contribute to a hazardous situation. Keep the list current, and for each item record a description, the affected function, the severity, the evaluation result and the decision.
The evaluation links to risk management. If an anomaly could contribute to harm, it needs a risk analysis and possibly a fix before release. If it cannot, record why. Regulators often ask how a manufacturer decided that a known bug was acceptable, so a dated decision record with a named approver is the best answer. This step is where the term residual anomalies matters most in audits.
| Release task | What it means | Evidence to keep |
|---|---|---|
| Verification complete | Planned tests were run and passed | Test reports, traceability matrix |
| Plan activities complete | Everything in the development or maintenance plan is done | Plan with checked-off tasks |
| Anomalies documented | Known residual anomalies are listed | Anomaly list with status |
| Anomalies evaluated | Each one assessed for safety impact | Risk assessment records |
| Version documented | Released version is uniquely identified | Release record, version number |
| Build reproducible | How the release was created is recorded | Build procedure, tool versions |
| Archive and delivery | Release is stored and delivery is reliable | Archive location, delivery checks |
Identify the release with a unique version number and record what it contains: source revision, configuration items, third-party components and their versions, and build tools. The aim is that someone could rebuild the same release years later. If you use open-source or legacy components, see SOUP and legacy software for how they fit.
Record the build procedure as well. Include the environment, compiler or toolchain versions, and any build flags. For continuous integration, store the pipeline definition and the log of the run that produced the release artifact.
Archive the released software and its documentation for the retention period your quality system requires, which often follows the expected life of the device plus a margin. In practice that means tagging the source in version control, storing the signed build artifact in a controlled repository and saving the release record.
Reliable delivery means the customer or user gets the intended version without corruption or confusion. Use checksums or signatures, verify installation, control who can publish releases and keep instructions for installing, updating and, where appropriate, rolling back. Remember that software updates may also change your regulatory position; our article on FDA guidance and IEC 62304 covers how the US regulator views software changes.
Frequent releases do not remove the need for these tasks; they mean the tasks should be automated and repeatable. Put the release checklist in your pipeline as required gates: tests passed, traceability current, anomaly list updated, version tagged, artifact signed and record generated. Our guide on IEC 62304 and agile explains how to combine sprints with the required documentation.
Decide which changes count as a release that needs a full review and which are minor. Write that rule in your procedure, apply it consistently and review it when your device or process changes.
A release needs a small, predictable set of records. Keep them together so an auditor can follow the story in a single folder.
Templates make each release faster and reduce omissions. The IEC 62304 Toolkit includes editable templates for software development, maintenance, configuration and release documentation aligned to the standard, so your team can adapt a proven format.
For further reading on practical release documentation, see the OpenRegulatory guide to an IEC 62304 software release. Also plan ahead: a new edition of the standard is being developed, so watch IEC 62304 Edition 2 for timing.
Adapt this sequence to your quality system and put it in the pipeline or the release ticket. First, freeze the release candidate and record its version and source revision. Second, run the full verification suite on that exact build and attach the reports. Third, update the traceability matrix and confirm there are no untested requirements. Fourth, refresh the anomaly list, evaluate each item for safety impact and have the responsible person approve the decision. Fifth, confirm that the risk management file is current. Sixth, record the build procedure, tools and third-party component versions. Seventh, obtain the required approvals and sign the release record. Eighth, archive the source, artifact and documents. Ninth, deliver with checksums and confirm installation. Every organization adds its own steps, so treat this as a starting point.
An internal review of one release per quarter is a cheap way to keep the process honest. Choose a release at random, walk the evidence from approval back to the source tag and look for missing records. Auditors and notified bodies use the same technique, so every gap you find first is one they will not find. Record the review and feed lessons into your procedure so the IEC 62304 software release checklist improves with use rather than hardening into a ritual nobody questions.
Name the approver roles in your procedure. Typically the software lead confirms verification, the quality or regulatory representative confirms the records, and a risk owner confirms the anomaly evaluation. Segregating these roles gives an independent check on the release. Keep each signature dated, and make sure the approver can see the actual evidence rather than a summary. A signed IEC 62304 software release checklist with no underlying evidence is worth little when a reviewer asks to see the test results behind it.
Teams commonly test one build and release another. They keep an anomaly list in a ticket system but never evaluate the safety impact. They forget to record build tool versions, so a release cannot be reproduced. They archive source code but not the signed artifact. And they treat the checklist as a one-off, so the next release skips steps.
The fix is the same in every case: make the checklist a required gate, assign an accountable approver, and review a sample of releases each quarter.
It is the part of the development process, clause 5.8, that confirms verification is complete, documents known anomalies and the released version, and ensures the release is archived and delivered reliably.
No. Some tasks apply to all classes and others only to Class B and C. Check the standard against your own classification.
A known defect or unresolved problem in the released software. You must document it and evaluate whether it could contribute to a hazardous situation.
Only builds you actually release need the release activity. Define in your procedure what counts as a release and automate the checks.
As long as your quality system and regulations require, which commonly relates to the device lifetime. Confirm the period with your regulatory advisor.
October 1, 2026
