IEC 62304 Software: Practical Guide to Medical Device Software Lifecycle Compliance

Overview

IEC 62304 is the international standard that defines software lifecycle processes for medical device software, covering development planning, requirements, architecture, verification, release, maintenance, configuration management, and problem resolution. If your software is incorporated into or used as a medical device, IEC 62304 applies, and the depth of required process rigor depends on the software safety class you assign.

The short answer

IEC 62304, titled "Medical device software – Software life cycle processes" according to NSF's analysis of the standard, specifies lifecycle requirements for developing and maintaining medical device software. It does not tell you how to write code. It tells you which processes must exist, which records must demonstrate they were followed, and how process depth scales with the potential for harm. The standard connects tightly to risk management under ISO 14971 and assumes a functioning quality management system, so compliant lifecycle records only carry weight when they reflect real engineering activity.

Who this guide is for

This guide is written for software engineering leads, quality assurance owners, regulatory affairs specialists, and workflow owners who need to turn IEC 62304 expectations into working practices and reviewable evidence. It assumes you already know your product may be regulated and are deciding scope, safety class, documentation set, and implementation sequence. It is not a clause-by-clause commentary, and it does not replace the purchased text of the standard or professional regulatory judgment.

What IEC 62304 covers

IEC 62304 covers software that is either incorporated into a medical device or is itself a medical device, as NSF summarizes the standard's definition. That scope includes embedded firmware, software components of larger systems, and stand-alone applications with a medical purpose. It also has known boundaries: NSF notes that software used to define and train machine learning models, when that tooling never ships in the device, does not fall within IEC 62304's defined scope, even though regulators still care about controls on data and models.

Understanding scope early matters because it determines which parts of your codebase need lifecycle evidence and which do not. Drawing that boundary carelessly in either direction is expensive: too broad, and you document tooling that never needed it; too narrow, and reviewers find regulated functionality without lifecycle records.

Here is a short worked example of how a scoping and classification decision plays out in practice. Suppose your company builds a mobile app that receives glucose readings from a regulated sensor and displays trend graphs, and a cloud service that generates dosing suggestions from those readings. Inputs: the display module cannot alter readings, the dosing module directly influences therapy decisions, and both share a common data-transport library. Constraints: your team wants one codebase and one release train. Outcome logic: the dosing module carries the potential for serious harm if it miscalculates, so it drives a high safety classification and full lifecycle rigor; the display module might justify a lower classification only if you can show through architecture that its failure cannot contribute to a hazardous situation; the shared transport library inherits the classification of the highest-risk module that depends on it unless you segregate it with documented, verified boundaries. The practical result is an architecture description that makes segregation explicit, a classification rationale for each software system, and a release process sized to the highest class in the train.

Stand-alone software, embedded software, SaMD, and SiMD

IEC 62304 applies whether the software runs inside device hardware (software in a medical device, SiMD) or ships as a stand-alone product with a medical purpose (software as a medical device, SaMD). A firmware module controlling a therapy delivery mechanism, a diagnostic image-analysis application, and a companion app that configures an implanted device can all fall in scope, though each raises different architecture and verification questions. Hybrid products deserve extra care: when a general-purpose mobile app connects to a regulated device, you need a documented rationale for where the medical functionality begins and how the communication layer is controlled. The operational takeaway is to write down your scoping decision and its reasoning before you plan lifecycle activities, because everything downstream depends on it.

Software systems, software items, and software units

The standard uses a decomposition vocabulary you will need for architecture and traceability: a software system decomposes into software items, which decompose into software units, the lowest level you verify individually. How you define units is a real design decision, not a formality. In a monolith, units may map to modules or classes; in a service-based architecture, you must decide whether a service, a library, or a function is the meaningful unit for verification and impact analysis. Define units at the granularity where you can honestly claim verification coverage and run impact analysis when something changes, and record that definition in your development plan so reviewers understand your structure.

SOUP and open-source components

SOUP (software of unknown provenance) is third-party software you did not develop under IEC 62304 processes, including most open-source libraries and vendor components. The standard expects you to identify SOUP, specify what you require from it, evaluate whether it can contribute to hazardous situations, and monitor it over time. In practice, teams maintain a controlled SOUP inventory that records, for each component, its name and version, its function in the system, the requirements placed on it, known anomalies relevant to your use, and the trigger for re-evaluation when a new version or vulnerability appears. An abandoned open-source library in a safety-critical module is a classic finding: the code works, but there is no evidence anyone evaluated its failure modes or is watching its vulnerability disclosures. Treat SOUP management as an ongoing lifecycle activity, not a one-time list.

IEC 62304 is not just a software checklist

Treating IEC 62304 as a documentation checklist produces polished records with weak hazard coverage, which is exactly what experienced reviewers probe for. The standard is a safety framework: its lifecycle requirements exist to make sure hazards are identified, controlled, verified, and kept under control through maintenance. Qualio's review of common compliance mistakes identifies five major failure patterns among medical software manufacturers, including weak design control and unverified problem resolution, and these are process failures rather than paperwork failures. If your documents describe a process your engineers do not actually follow, you have both a compliance gap and a safety gap.

How IEC 62304 connects to ISO 14971

IEC 62304 does not contain a complete risk management method; it plugs into the medical device risk management process defined by ISO 14971. Rimsys notes that the standard's software risk management chapter covers identification of hazardous situations, risk control, and verification of those controls, all of which depend on the device-level risk file. In day-to-day development, this means software hazards feed the risk analysis, risk controls become software requirements, and verification of those requirements becomes risk-control verification evidence. Keep the risk file live throughout development rather than updating it at design freeze, because classification decisions, architecture choices, and test priorities all depend on current hazard analysis.

How IEC 62304 connects to ISO 13485 and the QMS

IEC 62304 assumes your organization already operates controlled processes for documents, records, training, reviews, and change management, which is the territory of ISO 13485 and your quality management system. Your software development plan, review gates, problem resolution workflow, and change control need to live inside the QMS rather than beside it. A common failure mode is a software team running its own informal process while the QMS describes a different one; auditors compare the two. Align your engineering procedures with QMS document control and review requirements early, so lifecycle evidence is generated in a controlled state instead of being retrofitted.

Where IEC 82304-1, IEC 81001-5-1, and regulatory guidance may enter

IEC 62304 is one piece of a larger standards ecosystem, and adjacent expectations often apply alongside it. IEC 82304-1 addresses product-level requirements for health software, IEC 81001-5-1 addresses security lifecycle activities such as vulnerability handling and secure development practices, and regulators including FDA and EU notified bodies publish their own software documentation expectations. You do not need to master every adjacent standard to start, but you should map which ones apply to your product and market and note the interfaces in your planning documents. Cybersecurity-adjacent artifacts, such as a software bill of materials and vulnerability monitoring for SOUP, increasingly sit at the junction between IEC 62304 configuration management and security lifecycle expectations. Scope this mapping deliberately so your lifecycle plan does not silently omit an expectation a reviewer will ask about.

Software safety classification under IEC 62304

Safety classification is the single decision that most shapes your IEC 62304 workload, because required process depth scales with class. Rimsys notes that IEC 62304:2006 defines three classes based on the risk of harm from a hazardous situation the software could cause or contribute to. Classify early, document the rationale, and revisit the decision whenever architecture or intended use changes.

Class A, Class B, and Class C in plain language

The standard defines three safety classes, summarized by Perforce as follows: Class A means no injury or damage to health is possible, Class B means injury is possible but not serious, and Class C means death or serious injury is possible. Classification is about the worst credible harm the software could contribute to, not about how likely you believe a software failure is. Higher classes require more rigorous processes, including deeper design documentation and unit-level verification, so the class you assign directly determines the evidence you must produce. Classification can also be applied at the software item level, which is why segregation in architecture matters: a well-documented boundary can keep a low-risk item from inheriting a higher class.

Software safety classification decision matrix

The matrix below shows hypothetical classification reasoning for three scenarios. It is a reasoning aid, not a substitute for your own hazard analysis against the standard's classification rules.

Use the matrix as a template for your own rationale documents: state the worst credible harm, name the external risk controls you are relying on, and record why the class is not higher. A borderline Class B versus Class C decision should read like an argument a skeptical reviewer can follow, with the hazardous situation, severity reasoning, and any segregation evidence written down at the time of the decision.

Common classification mistakes

Several reasoning errors recur across teams. Lowering a classification because the software delivers strong clinical benefit confuses benefit-risk assessment with harm severity; classification looks at harm, not net value. Lowering a classification because a risk control is implemented in software is circular, since that software control itself must be developed at a rigor matching the harm it protects against. Assuming a low probability of software failure is also unreliable reasoning, because systematic software faults do not behave like random hardware failures, and casual probability claims rarely survive review. Finally, the assumption that Class A means low effort is misleading: a misclassified or undocumented Class A module can undermine the safety argument for the whole system, so even low-class items need a recorded rationale.

Core IEC 62304 lifecycle activities

The lifecycle activities form an ordered sequence: plan, capture requirements, design, implement, verify, release, then maintain under configuration management and problem resolution. Qualio's compliance-mistakes analysis highlights that problem resolution itself must be verified, a reminder that every lifecycle process needs its own evidence, not just the development phases. The sections below walk through the sequence at implementation level.

Planning and requirements

Start with a software development plan that names the processes, deliverables, responsibilities, review gates, and tools you will use, scaled to your safety class. Software requirements then translate intended use, user needs, and risk controls into testable statements, each with acceptance criteria and an owner. Requirements sourced from risk controls deserve explicit tagging, because reviewers will trace from the risk file into the requirements set and expect a clean join. A plan that reflects how your team actually works is worth more than an ambitious plan nobody follows, so write the plan you can execute and revise it under change control when reality shifts.

Architecture, detailed design, and implementation

The architecture description shows how the software system decomposes into items and units, where SOUP sits, and how segregation supports your classification decisions. Detailed design fills in the internals for higher-class items so that unit verification has something concrete to verify against. Granularity is a tradeoff: over-documenting every function creates a maintenance burden that guarantees drift, while under-documenting blocks impact analysis when changes arrive. Aim for the level of design detail that lets an engineer who did not write the code assess what a proposed change touches, and keep design documents versioned alongside the code they describe.

Verification, integration testing, system testing, and release

Verification evidence must connect back to requirements and risk controls, not merely demonstrate that tests ran. Kusari's overview of the standard notes that testing must cover both functional requirements and safety-related behaviors, with coverage expectations varying by classification. Integration testing confirms items work together as the architecture claims, system testing confirms the software meets its requirements, and the release step records exactly which versions, configurations, known anomalies, and residual risks ship. A release record should let someone reconstruct, years later, what was released, why open anomalies were acceptable, and who made the decision.

Maintenance, problem resolution, and post-release change control

Post-release, the lifecycle continues through maintenance and problem resolution: complaints, field issues, bug reports, and vulnerability disclosures enter a controlled process that analyzes each problem, assesses safety impact, and drives changes through the same rigor as original development. A practical maintenance flow looks like this: log the problem with its source, assess whether it affects safety or triggers a classification review, plan and implement the fix under change control, run regression testing scoped by impact analysis, and issue an updated release record. Security patches to SOUP components follow the same path, which is why the SOUP inventory needs version-level precision. Skipping regression evidence on "small" patches is one of the fastest ways to accumulate an audit finding, because the change history and the test history stop matching.

IEC 62304 documentation and evidence

IEC 62304 evidence is objective proof that your lifecycle processes ran: plans, specifications, records, and traceability that a reviewer can follow without a guided tour. The goal is not volume but coherence, where each artifact has a clear purpose, an owner, and a defined review point.

Core deliverables to plan for

Plan for the following core artifacts, scaled to your safety class:

• Software development plan: defines processes, deliverables, roles, and review gates; reviewed at project start and under change control.
• Software requirements specification: testable requirements including risk-control requirements; reviewed before design begins and at each significant change.
• Architecture description: system decomposition, SOUP placement, segregation rationale; reviewed before implementation of affected items.
• Risk-control traceability: links hazards, controls, requirements, and verification; reviewed alongside the risk file at defined milestones.
• SOUP inventory: components, versions, requirements, anomaly evaluation, monitoring triggers; reviewed at release and on relevant disclosures.
• Verification and test records: evidence tied to requirements and risk controls; reviewed before release.
• Release record: shipped versions, configurations, known anomalies, approval; created at each release.
• Maintenance and problem-resolution records: logged problems, safety assessments, changes, regression evidence; reviewed continuously.

Treat this list as a planning baseline rather than a maximum: your QMS, market, and adjacent standards may add artifacts, and your safety class determines how deep each one goes.

Traceability that reviewers can follow

Traceability is the connective tissue between artifacts: user needs to requirements, requirements to design and code, hazards to risk controls to verification, defects to changes to regression evidence, and everything to a release. A reviewer should be able to pick any risk control and walk to the requirement that implements it, the design element that realizes it, the test that verifies it, and the release that shipped it. Broken traces usually indicate broken process, not just broken records, which is why reviewers use trace sampling as a probe. Build trace links as work happens, because reconstructing them at audit time is slow and unconvincing.

Document control, version history, and shared review

Lifecycle evidence only holds up if everyone reviews against the same controlled version, with a visible history of who changed what and who approved it. Regulatory teams commonly lose time to rework, version drift, and manual status reporting, a problem Assyro describes directly in its positioning for regulatory, quality, and submission teams who need to review against the same version with shared comments, owners, and traceability. For IEC 62304 work, the practical requirement is the same regardless of tooling: synchronized source documents, controlled version history, named owners for each artifact, and review comments that stay attached to the version they addressed. Platforms such as Assyro's document management workspace address exactly this coordination layer, keeping source documents synced and version history intact across systems, though no tool substitutes for the review discipline itself.

Implementing IEC 62304 in modern software workflows

IEC 62304 does not require waterfall development, and modern engineering practices can generate strong lifecycle evidence when governed intentionally. The standard cares that processes exist, run, and leave records; it does not prescribe your project management method or toolchain.

Agile sprints and living traceability

Agile teams can satisfy IEC 62304 by treating backlog items, acceptance criteria, and sprint reviews as controlled lifecycle inputs rather than informal notes. A backlog item that implements a risk control should carry the trace link to that control, its acceptance criteria should be the verification basis, and the sprint review record should show who approved the outcome. Risk analysis stays live by revisiting affected hazards whenever a sprint touches safety-relevant functionality, instead of deferring risk work to a design-freeze event. The pattern that fails is bolting quarterly documentation sprints onto an agile pipeline, because the documents and the code immediately diverge.

Git, CI/CD, automated tests, and release branches

Your engineering systems already produce much of the evidence configuration management requires, if you govern them for it. Git history identifies versions and changes, CI runs record which tests executed against which commit, and release branches or tags define baselines, but IEC 62304 configuration management expects more than branching: formal baseline identification, controlled change procedures, and status accounting that shows the state of every configuration item. Define which repository events constitute a controlled baseline, require linked issues for changes to safety-relevant items, and make CI results retrievable as verification records tied to specific versions. The gap between "we use version control" and "we have configuration management" is documented governance over these systems, not additional tools.

Avoiding parallel paper processes

The most damaging implementation pattern is a documentation layer that describes an idealized process while engineering follows a different real one. Reviewers increasingly compare artifacts against actual development traces, such as commit history, test runs, and defect trends, and mismatches undermine every other record. The fix is to generate evidence from the systems where work happens, review it where it lives, and export or snapshot it under document control at defined points. If keeping a document current requires manual transcription from an engineering tool, expect it to go stale, and redesign the workflow so the controlled record and the working record are the same thing or are synchronized automatically.

Legacy software and IEC 62304 remediation

Codebases that predate formal IEC 62304 processes are common, and Kusari notes that organizations with existing medical device software face real challenges applying the standard to legacy systems not developed with it in mind. Remediation is feasible, but it needs scoping discipline to avoid paralyzing maintenance releases.

Start with a scoped gap assessment

Before writing anything, inventory what exists: current requirements coverage, architecture knowledge, test assets, defect history, SOUP components, release records, and any risk-control evidence. Map each against what your safety class requires, and rank gaps by safety relevance rather than by how easy they are to close. Pay particular attention to undocumented behaviors that clinical users rely on, because these are requirements in practice even if no document says so. The assessment output should be a prioritized remediation backlog with owners, not a generalized statement that documentation is incomplete.

Reconstruct only what is useful and reviewable

Reconstruct documentation to the level that supports review, impact analysis, and safe change, not to simulate a development history that never happened. That usually means writing current-state requirements for safety-relevant functionality, a current architecture description, a complete SOUP inventory, and verification evidence for the behaviors that matter most, in that order. Be honest in the records about what was reconstructed and when, because retrospective documents presented as contemporaneous ones create credibility problems worse than the original gap. Incomplete historical evidence is not automatically acceptable, so where reconstruction cannot close a safety-relevant gap, the risk file should say so and justify the path forward.

Plan forward controls for the next release

Remediation succeeds when the next release runs under controlled processes even while historical gaps are still closing. Put change control, impact analysis, regression testing, and release records in place for all new work immediately, then let the remediation backlog close historical gaps in priority order. Each maintenance release becomes an opportunity to extend traceability and test coverage into the areas it touches. Over several release cycles, the controlled surface grows until the legacy gap is a documented, shrinking exception rather than the operating norm.

IEC 62304 certification, assessment, and audit readiness

Certification language around IEC 62304 is a persistent source of confusion, and getting the vocabulary right helps you prepare the correct evidence. What gets assessed is your lifecycle process and its records, in whatever review context your market imposes.

Can software be IEC 62304 certified?

There is no universal mechanism by which a piece of software receives a stand-alone "IEC 62304 certificate" that regulators everywhere accept. What exists in practice is a set of distinct activities: certification bodies offer assessment services against the standard, QMS certification (typically against ISO 13485) covers the quality system your lifecycle processes live in, product conformity review and notified body assessment evaluate the device as a whole, and regulatory submissions carry your lifecycle evidence to an authority. Some sources, such as Qualio, describe IEC 62304 as a critical safety certification, and certification-style assessments do exist as commercial services, but you should treat any certificate as evidence about your processes rather than as market clearance. The operational conclusion is the same either way: build the lifecycle evidence, because every review path runs through it.

What evidence should be ready for review

Whatever the review context, assessors work through similar evidence categories. Have ready your lifecycle procedures and the software development plan, the safety classification rationale, requirements and architecture documents, risk-control traceability into the ISO 14971 risk file, verification and test records tied to versions, the SOUP inventory with evaluations, configuration baselines and change records, problem-resolution records with safety assessments, and release decisions with known-anomaly justifications. Two properties matter more than volume: internal consistency, so documents do not contradict each other, and currency, so records describe the software as it exists now. A dry run where someone outside the project traces a risk control end to end is the cheapest way to find weak joints before a reviewer does.

Common audit-readiness gaps

The recurring gaps are predictable. Traceability that breaks between the risk file and the requirements set, risk analyses frozen at design transfer while the software kept changing, SOUP components present in the build but absent from the inventory, problem resolution that logs issues without safety assessment or verification of fixes, and records describing a process visibly different from the team's actual workflow. Qualio's five-mistake analysis specifically flags unverified problem resolution as a major failure pattern. Each gap has the same root cause, evidence maintained as a separate activity from engineering, and the same remedy, generating records from the work itself and reviewing them continuously rather than before audits.

Choosing tools and workflows to support IEC 62304

No tool is inherently IEC 62304 compliant, because compliance is a property of your processes and evidence, not of software you purchase. Tools matter because they determine whether maintaining traceability, version control, and status visibility is sustainable or exhausting.

Capabilities to evaluate

When evaluating document, traceability, and workflow tooling for IEC 62304 work, look for:

• Controlled document versions with a complete, auditable history
• Named owners and review routing for each artifact
• Trace links between requirements, risks, tests, defects, and releases
• Issue and change linkage that connects engineering work to controlled records
• Baseline and release identification that supports configuration status accounting
• Readiness or completeness checks that surface gaps before formal review
• Exportable evidence in formats reviewers and submission processes can consume

Weigh these capabilities against your team's actual workflow, because a capable tool that engineers route around produces worse evidence than a simpler tool they actually use. Tailor unit definitions, trace rules, and review gates to your own risk profile rather than accepting vendor defaults marketed as compliant out of the box.

Where submission-management workflows can help

After lifecycle evidence exists, it still has to move through regulatory review and submission cycles, which is a coordination problem distinct from generating the evidence. Assyro positions its regulatory submission workspace for exactly this stage: pharma, biotech, and medical device teams drafting, validating, and routing submission content with shared comments, owners, and traceability against a single version. Its lifecycle management capabilities address deadline-driven submission cycles, and its eCTD validator supports validation checks where eCTD-format submissions apply. The boundary to respect is that these workflows coordinate and check evidence; they do not create IEC 62304 conformity, which your engineering and quality processes must produce first.

Practical implementation roadmap

The roadmap below sequences the work for a team moving from informal development to controlled IEC 62304 processes. Treat it as an ordered plan you adapt to your safety class and QMS maturity, not a one-week checklist.

From gap assessment to maintained release evidence

1. Scope the software: document what is medical device software, what is not, and why.

2. Classify safety: assign Class A, B, or C per system and item, with written rationale.

3. Map standards interfaces: identify where ISO 14971, ISO 13485, and security or product-level standards connect.

4. Define procedures: write the lifecycle procedures your team will actually follow, inside the QMS.

5. Inventory SOUP: list components, versions, requirements, evaluations, and monitoring triggers.

6. Create the plan and requirements: produce the development plan and testable requirements, including risk controls.

7. Document architecture: capture decomposition, segregation, and SOUP placement.

8. Build traceability: link needs, requirements, hazards, controls, tests, and defects as work happens.

9. Verify: execute and record verification tied to requirements, risk controls, and versions.

10. Release: record shipped versions, configurations, known anomalies, and approvals.

11. Monitor and maintain: run problem resolution, SOUP monitoring, and change control continuously.

12. Improve: review process performance and close evidence gaps each release cycle.

Run the sequence iteratively rather than as a single pass: each release cycle should leave your evidence more complete and your process friction lower than the last.

Frequently asked questions

Is IEC 62304 mandatory for medical device software?

IEC 62304 is a consensus standard rather than a law, but regulators and reviewers widely rely on it as the reference framework for medical device software lifecycle processes. Qualio notes that the standard is orchestrated across the European Union and the United States, and in practice manufacturers targeting those markets are generally expected to demonstrate lifecycle control consistent with it. Whether conformance is formally required depends on your market and pathway, so confirm the recognized or harmonized status of the standard for your specific jurisdiction. The safer planning assumption is that you will need the lifecycle evidence regardless of the exact legal mechanism.

How long does IEC 62304 implementation take?

There is no credible universal timeline, because effort depends on factors that vary by an order of magnitude between teams. The main drivers are your safety class, the state of any legacy codebase, the size and health of your SOUP inventory, QMS maturity, existing test coverage, tooling that supports or fights traceability, and the scope of the review you are preparing for. A greenfield Class A product inside a mature QMS is a fundamentally different project from remediating a legacy Class C system with undocumented behavior. Run the gap assessment first; it converts the timeline question from a guess into a scoped backlog you can estimate honestly.

How should IEC 62304 evidence be prepared for a regulatory submission?

Prepare evidence so a reviewer who has never met your team can follow it: consistent versions across documents, traceability that resolves end to end, classification rationale that matches the architecture, and release records that account for known anomalies. Submission preparation then becomes an organization and completeness problem, checking that every expected artifact is present, current, and internally consistent before it enters the dossier. This is where readiness checks and controlled document coordination earn their keep; Assyro's document management workspace, for example, keeps source documents synced with version history and shared review so regulatory, quality, and submission teams work against the same version. Whatever tooling you use, the principle holds: evidence organized continuously during development submits cleanly, while evidence assembled at the deadline exposes every gap at the worst possible moment.