IEC 62304 Medical Device Software Standard: A Working Guide

Every medical device software team eventually meets IEC 62304. The standard defines the software lifecycle that EU MDR and the FDA both expect. Teams read it as a document list, when reading it as a working build process saves months of rework.

This raises a practical question:
What does IEC 62304 medical device software standard compliance look like as a working engineering process, which software safety class applies and how do the deliverables land in MDR Annex II?

This guide walks through what IEC 62304 covers and what it leaves out, the harm-driven logic behind software safety Classes A, B and C, the lifecycle clauses as a working process and the crosswalk between IEC 62304 deliverables and MDR Annex II. It also names the five mistakes teams keep making. For the wider classification frame, our guide to EU MDR Rule 11 software classification sets the broader context.

Table of Content

Why IEC 62304 Is the Standard Teams Hit First

IEC 62304 is the international standard that sets the software life cycle processes for software inside a medical device, or software that qualifies as a medical device in its own right. Both EU MDR Annex II and the FDA's 2023 guidance on device software functions cite it. Therefore a software team building for either market lands on it early in the regulatory analysis.

The Harm-Driven Baseline

The IEC 62304 framework is harm-driven. Software gets classified into one of three safety classes based on the potential hazards and hazardous situations a software failure could cause. Each class then triggers a different depth of lifecycle activities.

For example, a logging utility (Class A) and an infusion-pump control loop (Class C) share the same standard but produce very different deliverable stacks. As a result, the class you land in shapes the whole software programme and not only the paperwork.

Why Integration Beats Documentation

Teams that read the standard as a checklist of documents to produce at the end of the build finish twice. And Teams that build the clauses into the working software development process from the start finish once. In practice, the standard rewards integration over documentation theatre.

So the useful mindset is simple. Treat IEC 62304 as a description of how a well-run software team already works, then add the traceability it asks for.

-> In short: IEC 62304 is the harmonised software lifecycle standard for medical devices under MDR and FDA. Harm-driven classification sets the depth and building it into the process beats bolting it on at the end.

What IEC 62304 Covers

IEC 62304 governs software that is part of a medical device, or that is a medical device in its own right, whether embedded software or standalone software. It defines the software life cycle processes:

planning
requirements
software architecture
detailed design
implementation
software integration
verification
software release
maintenance

Alongside these, it defines software-specific risk management, software configuration management and problem resolution.

The Five Process Areas

IEC 62304 splits its requirements across five process areas, each in its own clause:

Clause 5 covers development
clause 6 covers maintenance
clause 7 covers software risk management
Clause 8 handles software configuration management
clause 9 handles problem resolution

Each process area is a set of activities and outputs, not a document template. Moreover, the activities feed each other, since configuration management produces the SOUP inventory that risk management evaluates. A clean lifecycle therefore treats them as one connected system.

Where IEC 62304 Stops and Related Standards Start

IEC 62304 covers software activities, but not general device design controls. ISO 13485 covers the quality management system that wraps them.

Meanwhile ISO 14971 covers risk management at the device level. EN IEC 82304-1 covers general-purpose health software where the hardware platform is outside the manufacturer's control.

Cybersecurity is covered next to it. EN IEC 81001-5-1 adds the cybersecurity lifecycle on top of 62304 for connected health software. Our overview of medical device cybersecurity standards maps how that layer interlocks with the software lifecycle.

For a typical software-led device under MDR, the stack is ISO 13485, ISO 14971, IEC 62304 and IEC 81001-5-1. Each one then feeds MDR Annex II.

The MDR and FDA Cross-References

EU MDR Annex II expects software lifecycle evidence aligned to IEC 62304. On the US side, the FDA's 2023 premarket software guidance names IEC 62304 as an acceptable consensus standard. As a result, the same deliverable stack supports both submissions.

The two regulators ask for slightly different framing of the same evidence. However, both rely on the underlying IEC 62304 lifecycle outputs, so a team targeting the EU first can reuse most of the file for a later FDA route. We keep the EU MDR picture primary and treat the FDA angle as a bonus, not the core.

-> In short: IEC 62304 covers software lifecycle activities. It pairs with ISO 13485, ISO 14971 and IEC 81001-5-1. Both EU MDR and the FDA accept it as the baseline.

What To Do:

Confirm which standards in the stack apply to your product (QMS, device risk, software, cybersecurity) before scoping the work.
Read IEC 62304 clauses 5 to 9 once end to end so the connections between processes are obvious before you write any plans.
For dual EU and US submissions, plan one underlying IEC 62304 lifecycle and two reporting framings, not two separate evidence streams.

Software Safety Classes A, B and C

The IEC 62304 software safety class is the master variable. Get it wrong and every downstream deliverable is sized incorrectly. Get it right and the lifecycle scopes itself sensibly against the actual clinical risk.

The Harm-Driven Logic

Class A applies when no injury or damage to health is possible from a software failure.
Class B applies when non-serious injury is possible.
Class C applies when death or serious injury is possible.

Importantly, the classification is applied per software system or per software item everywhere, not only at the device level. Risk-control measures under clause 7 can then lower a software item's class if the architecture isolates the failure.

So a Class C system can contain Class A items when the design segregates them properly. This is what makes architecture matter, because it can shrink the documentation burden without changing the device.

SOUP and Decomposed Items

Software of Unknown Provenance (SOUP) covers third-party code:

libraries
frameworks
operating systems
open-source components

Every SOUP item carries its own classification. For instance, a Class C device using a SOUP TLS library has to evaluate that library at Class C depth, even though it was written for general use.

The SOUP inventory under clause 8 lists every component, its version, its function and its known anomalies. Moreover, it pairs with the cybersecurity SBOM required under EN IEC 81001-5-1. A clean configuration management process therefore produces both artefacts in one pass.

How the Class Shapes the Deliverables

Class A demands the development plan, requirements and system-level testing.
Class B adds architectural design and unit verification.
Class C adds detailed design per unit and a segregation analysis between items of different classes.

As a result, the gap between Class A and Class C is roughly twice the documentation effort. Most of that difference sits in design depth and per-unit verification.

Most Software as a Medical Device under MDR lands in Class B, so that is the default to plan against. Class C kicks in for closed-loop control of vital functions, pacemaker firmware or automated radiotherapy planning. In practice, Class A is rare for any software claiming a clinical purpose.

-> In short: Class is harm-driven and SOUP inherits the system's class. Architecture can isolate items into lower classes. Class B is the default for SaMD, while Class C is reserved for life-supporting paths.

What To Do:

Run the software safety class call in the same workshop as the device classification, since the harm scenarios feed both.
Use architecture segregation deliberately to lower the class on items that can be isolated, then document the argument so the notified body sees it.
Build the SOUP inventory at the same time as the SBOM, because the two share their input pipeline.

The IEC 62304 Lifecycle as a Working Process

Reading the IEC 62304 medical device software standard as a working process is the operator's shortcut. Each clause maps to engineering activities that already happen on any well-run software team. The standard names them and adds traceability.

Planning (Clause 5.1)

Clause 5.1 expects a Software Development Plan covering:

scope
deliverables
lifecycle model
configuration management approach
verification strategy
links to risk management

The plan is signed before serious work begins. Therefore you should set it up during sprint zero.

A good Software Development Plan is roughly ten pages. It captures the working approach the team already uses, named against the clause requirements. Plans that invent a separate process from how the team works always rot.

Requirements and Architecture (Clauses 5.2 and 5.3)

Clause 5.2 is the Software Requirements Specification, the output of software requirements analysis. Every requirement traces back to a higher-level system requirement and forward to verification evidence. For Class B and C, clause 5.3 then adds the software architecture:

the partitioning of the software into items
the interfaces between them
the SOUP placements

Architecture is also where segregation arguments for clause 7 get made. As a result, a clean architecture deliverable can lower the safety class of subsystems and shrink the rest of the work substantially.

Implementation and V&V (Clauses 5.4 to 5.7)

Clauses 5.4 to 5.7 cover software detailed design, software unit implementation, software integration testing and software system testing. Verification happens at every level appropriate to the class. For Class B, that means software unit verification at the architectural item level, integration testing at the subsystem level and system testing at the device level.

Good engineering hygiene, with implementation against agreed coding guidelines, already produces most of this. For example, CI/CD pipelines that run unit tests, integration tests and static analysis and produce coverage reports already generate the verification record. The standard simply requires that the record links back to requirements and to risk-control measures.

Maintenance and Problem Resolution (Clauses 6 and 9)

Clause 6 covers software maintenance after release, where change control analyses every request for safety impact before implementation. Clause 9 covers problem resolution:

bug intake
investigation
the decision on advisory notices
change-request creation

Together these two clauses bridge directly into the post-market surveillance system under MDR.

For SaMD, this is where most non-conformities show up at the second audit. Teams ship version one, plan maintenance lightly and find that clause 6 and 9 documentation has drifted from how they handle real bug reports. So write the software maintenance plan before the first release.

-> In short: Plan in sprint zero, build the architecture to enable segregation, then generate V&V from CI/CD with traceability. Above all, design the maintenance process before release.

Mapping IEC 62304 Deliverables to MDR Annex II

EU MDR Annex II is the structure the notified body reads and IEC 62304 produces the underlying software evidence. The crosswalk between them is what reviewers walk through during the technical file review. Building it explicitly inside the file, against Regulation (EU) 2017/745, saves the reviewer time and reduces query rounds.

Software Development Plan and SRS

The Software Development Plan from clause 5.1 lands in Annex II Section 4 on manufacturing information.
The Software Requirements Specification from clause 5.2 lands in Annex II Section 5 (the GSPR checklist) and Section 2 (the device description).

Both then feed traceability from the clinical claim down to verification evidence. In practice, this trace is the spine a reviewer follows, so it pays to make it explicit rather than implied.

Architecture, Design and Verification

The software architectural design (clause 5.3) and software detailed design (clause 5.4) land in Annex II Section 6.1, the pre-clinical part of the evaluation. Verification and validation evidence from clauses 5.5 to 5.7 lands in Section 6.2.

The risk management file under clause 7, linked to ISO 14971, then lands in Section 3 on benefit-risk analysis and Section 5 through the GSPR risk references. Each clause output therefore has a home in the file rather than floating loose.

SOUP Inventory and Maintenance

The SOUP inventory from clauses 5.3.3 and 8 lands in Annex II Section 4 as part of the software components description. It aligns with the cybersecurity SBOM under EN IEC 81001-5-1.

Maintenance and problem resolution outputs from clauses 6 and 9 land in Annex II Section 8 on post-market surveillance, feeding the PMS plan and the PSUR. As a result, the post-release clauses are not an afterthought but a documented input to the technical file.

-> In short: The crosswalk is concrete and stable. Build it into the technical file explicitly and the notified body review compresses.

Common Mistakes With IEC 62304

Five mistakes around the IEC 62304 medical device software standard come back consistently at notified body audits. Each one is recoverable, yet each one adds weeks of remediation and re-verification work.

1. Declaring Class A on Clinical Software

Teams claim Class A on software that delivers a clinical function. However, the harm analysis usually surfaces at least one path to non-serious injury, which is the Class B threshold. Most SaMD is at least Class B, so Class A is the exception rather than the default.

2. Treating SOUP as an Afterthought

SOUP is identified in week ten and assessed in month six. By then nobody remembers which library version was compiled in. Instead, build the SOUP inventory alongside the build pipeline, with version capture automated from the package manifest.

3. No Segregation Argument on Mixed-Class Software

The software has a Class C critical path and a Class A reporting layer. Without an explicit segregation argument under clause 7, the whole system gets treated as Class C. Therefore write the segregation argument early, in the architecture document, so the notified body sees it before they default to the higher class.

4. Traceability Broken Between Requirements and Tests

Requirements live in one tool, tests in another and risk controls in a third, with manual links between them. By audit time, several requirements have no linked tests. So pick a traceability tool early (Jama, Polarion, Helix ALM, Codebeamer or similar) and enforce the trace links as part of the CI pipeline.

5. Maintenance Process Invented After Release

Clauses 6 and 9 get drafted in week one and never updated, while real bug intake works differently from the plan. At the second audit, the notified body finds the gap and raises a non-conformity. Instead, write clauses 6 and 9 against how the team triages bugs, with a defined route from intake to release decision.

-> In short: Wrong class, late SOUP, missing segregation, broken trace links and invented maintenance are five reliable paths to a 62304 non-conformity. Each is avoidable with an early decision.

FAQs About IEC 62304 Medical Device Software Standard

Is IEC 62304 mandatory under MDR?

A1: IEC 62304 itself is voluntary but compliance with a recognised software lifecycle standard is not. MDR Annex II expects evidence of a controlled software lifecycle and IEC 62304 is the harmonised baseline notified bodies use to assess it. So while a manufacturer could in principle build an equivalent in-house process, every medical device software team uses IEC 62304 in practice.

Q2: Which class is most medical device software?

A2: Class B is the default for SaMD under MDR. Most diagnostic or therapeutic decision-support software lands there because at least one harm path leads to non-serious injury. Class C applies to life-supporting or vital-function control software, while Class A is rare because it requires that no injury at all is possible from a software failure.

Q3: Does IEC 62304 cover cybersecurity?

A3: Only at the lifecycle process level. EN IEC 81001-5-1 is the dedicated cybersecurity lifecycle standard for health software. The two interlock: 62304 covers the software activities, while 81001-5-1 adds threat modelling, vulnerability management and the cybersecurity SBOM. Most teams build both into one combined process.

Q4: Can we use Agile with IEC 62304?

A4: Yes. The IEC 62304 medical device software standard does not prescribe a lifecycle model, so waterfall, V-model, iterative and Agile approaches all work. The standard requires that each clause's activities are completed and traceable, not that they happen in a fixed order. Agile teams therefore iterate through requirements, design, implementation and verification in sprints, with traceability maintained through the backlog and CI pipeline.

Closing Thoughts

The IEC 62304 medical device software standard rewards integration over documentation. Teams that build the clauses into a working engineering process produce the evidence as a side effect of doing the work.

By contrast, teams that treat the standard as a separate deliverable stream rebuild their evidence twice and still find gaps at audit. The standard asks for traceability between intent, design, code and verification.

For software teams scoping IEC 62304 compliance for an MDR submission, a structured MDR consulting engagement is the fastest way to map the current development process against the clauses and surface the gaps before they become audit findings.