IEC 62304 compliance for medical device software means running a defined software life cycle and keeping the records that prove it. Short answer: classify each software system as Class A, B or C under clause 4.3, then run the processes in clauses 5 to 9 at the depth that class demands: a development plan (5.1), verifiable software requirements traced to risk controls (5.2, 7.3.3), architecture and testing (5.3 to 5.7), release (5.8), maintenance (6), software risk management (7), configuration and change control (8) and problem resolution (9). Class C carries the most work, Class A the least. This guide maps each clause to the record an auditor or FDA reviewer asks for. Matrix Req is the tool we build to keep those records traced in one place.

We work at Matrix One, the company that builds Matrix Req, so read every product reference on this page as our view. The statements about the standard cite clause numbers, and the FDA points link to FDA's own pages, so you can check each one.

What is IEC 62304, and which software does it cover?

IEC 62304, Medical device software: Software life cycle processes, sets requirements for developing and maintaining medical device software. The version regulators work from is IEC 62304:2006 with Amendment 1 (2015); FDA's June 2023 premarket software guidance bases its clause references on ANSI/AAMI/IEC 62304:2006 & A1:2016. The standard applies to:

• Software embedded in physical medical devices (firmware)

• Software that operates as a standalone medical device (SaMD)

• Cloud-based software that performs a medical function connected to a medical device

It also reaches software you did not write. A third-party component, a cloud service included, is SOUP (software of unknown provenance) once it becomes part of your software system. You identify it under clause 8.1.2, specify the functional and performance requirements you rely on (5.3.3) and the hardware and software it needs (5.3.4), and evaluate its published anomaly list during software risk analysis (7.1.3). See our SOUP, OTS and SBOM guide for the documentation side.

Regulators lean on it from both sides of the Atlantic. In the EU, MDR Annex I section 17.2 requires software to be developed to the state of the art, taking into account the development life cycle, risk management including information security, verification and validation, and IEC 62304 is the usual way to show it (our EU MDR questions guide covers the wider regulation). In the US, the Quality Management System Regulation became effective on 2 February 2026 and incorporates ISO 13485:2016 by reference, which is the quality system IEC 62304 clause 4.1 expects around the software work.

How do you classify software under IEC 62304?

Clause 4.3 gives each software system a safety class from the worst harm that a hazardous situation it contributes to could cause, once risk control measures outside the software system are taken into account. The class sets how many of the clause 5 activities you owe.

What does Class A mean in practice?

Class A software cannot contribute to a hazardous situation that leads to injury, or controls outside the software prevent it. The work is lighter but it is not zero: you still plan the work, write software requirements, test the software system, control its configuration and resolve problems found after release.

What does Class B add?

Class B software could contribute to non-serious injury. It needs an architecture that identifies the software items and their interfaces, verification of software units, and integration testing, with software risk analysis linked to the design so each risk control measure implemented in software traces to the test that verifies it.

What does Class C add?

Class C software could contribute to death or serious injury. On top of Class B it needs detailed design down to the software unit and the additional unit acceptance criteria in clause 5.5.4, such as event sequence, data and control flow, fault handling, initialisation of variables, memory management and boundary conditions. IEC 62304 sets no code coverage percentage; a coverage target is a choice you justify in your plan.

Segregation decides how far a high class spreads. A software item can sit in a lower class than its parent system only when the architecture identifies the segregation that makes it safe (5.3.5). For most connected devices, firmware and any clinical alert logic in the cloud end up Class B or C, while administration and configuration functions can often be shown to be Class A.

Is the FDA Documentation Level the same as the IEC 62304 safety class?

No, and mixing them up is a common submission error. FDA's guidance Content of Premarket Submissions for Device Software Functions (June 2023, replacing the May 2005 software guidance) uses two Documentation Levels, Basic and Enhanced. Enhanced applies where a failure or flaw of a software function could present a hazardous situation with a probable risk of death or serious injury, assessed before risk control measures are applied.

IEC 62304 classifies after external risk controls, so the two can disagree: a Class B system can still need Enhanced documentation in a US submission. FDA says plainly that a Declaration of Conformity to the complete IEC 62304 is not needed, because of known differences in how the two categorise device software functions.

What the guidance does accept is narrower and useful. For the section on software development, configuration management and maintenance practices, a Declaration of Conformity to the FDA-recognised IEC 62304 can stand in for the written summaries: subclauses 5.1.1 to 5.1.3 and 5.1.6 to 5.1.9, clause 6 and clause 8 at Basic level, or subclause 5.1, clause 6 and clause 8 at Enhanced level. Our first SaMD submission guide walks through the rest of the package.

Which IEC 62304 clauses produce the records an auditor asks for?

If you want this as a deliverables list rather than a clause map, our IEC 62304 document checklist covers what is usually still missing before an audit.

What goes in the software development plan (5.1)?

The plan defines the processes, deliverables, tools, standards and responsibilities for the software life cycle, and how the development activities will meet IEC 62304. It also has to tie into the device's risk management process under ISO 14971, which our ISO 14971 process guide explains step by step.

What makes a software requirement compliant (5.2)?

Every software requirement is documented and traced to the system requirements and the intended use. Requirements cover functional, performance, interface and security needs, and each must be verifiable, meaning a test or analysis can show whether it has been met. Clause 7.3.3 then asks for traceability of each software hazard from the hazardous situation to the software item, the specific software cause, the risk control measure and its verification. A traceability matrix is the usual way to show that chain.

How detailed does the architecture need to be (5.3)?

Detailed enough to identify every software item and its interfaces, including interfaces to SOUP, and to show where segregation is relied on for risk control. Reviewers look for the safety-relevant items first, so mark them clearly.

Where does testing sit: units, integration or system (5.5 to 5.7)?

Unit implementation and verification is clause 5.5, integration testing is 5.6 and system testing is 5.7. Every class needs system testing; unit verification and integration testing start at Class B; Class C adds the 5.5.4 acceptance criteria. Record each result against the requirement it verifies, and evaluate every anomaly you release with under clause 5.8.

What does problem resolution require after release (9)?

IEC 62304 requires a formal process for receiving, investigating and resolving software problems found after release, analysing trends and verifying each fix. It connects to post-market surveillance under ISO 13485 and needs criteria for deciding when a problem means a field safety corrective action or a regulatory report.

How does IEC 62304 apply to cloud-connected medical devices?

When a device connects to a cloud platform, IEC 62304 extends to the cloud software that performs a medical function. In practice that means:

• The cloud software gets a safety class like any other software system.

• Its life cycle records have to be available for audit.

• Any change that touches clinical functionality runs through the maintenance process in clause 6 and change control in clause 8.2.

• Its problem resolution has to feed the manufacturer's post-market surveillance.

If you use a third-party connectivity platform, ask the vendor for an IEC 62304 documentation package: the safety class rationale, the development process followed, test records and the change management process. Matrix Connect, our cloud platform for connected devices, is described on its product page as having pre-built frameworks aligned with IEC 62304, HIPAA, GDPR, FDA and EU MDR, built under ISO 13485 certification (read 6 November 2026).

How does Matrix Req support IEC 62304 compliance?

Matrix Req is design control and risk management software for medical device and regulated product teams. Its SaMD page describes built-in support for IEC 62304 covering software life cycle processes, documentation and traceability, with Class A, B and C software handled in one platform and classification-appropriate processes, documentation and controls for each software system (read 6 November 2026).

For the clause 7 and 8.2 work, Matrix Req gives every design item a unique identifier and shows the impact of a change across requirements, risks and tests, with timestamped records, change history and approval workflows; every test run creates a timestamped result record (design control page, read 6 November 2026).

Its Compliance Checker imports a standard you hold, IEC 62304 included, as a PDF and turns it into a checklist evaluated against your project evidence, and every AI result goes through your team's review. It finds documentation gaps; it does not certify anything.

Our own data points at the same pressure. In real feedback from technical buyers at medical device companies, the pains raised most often were traceability kept in Excel, documents pulling engineers away from the product, and change impact worked out by hand (Matrix One technical buyer study, October 2026).

What do you need in place before Matrix Req works?

• A named owner for the requirements structure and the software safety classification.

• A decision on which items live in Jira and which in Matrix Req.

• Your existing trace matrix exported, so links can be mapped on import.

• The onboarding sessions booked; the onboarding page says teams that know an ALM tool are often productive within a few days, and most are running in under two months with a full migration package (read 6 November 2026).

What does an IEC 62304 compliance plan look like, step by step?

1. Define the intended use and the system requirements the software has to meet.

2. Classify each software system under clause 4.3 and record the rationale, including any segregation.

3. Write the software development plan (5.1) and the maintenance plan (6).

4. Write verifiable software requirements (5.2) and trace them to risk controls (7.3.3).

5. Document the architecture and identify SOUP (5.3, 8.1.2).

6. Verify at the depth your class requires (5.5 to 5.7) and evaluate known anomalies at release (5.8).

7. Run change control (8.2) and problem resolution (9) for as long as the software is on the market.

Where can you read more on IEC 62304 and connected devices?

• IEC 62304, ISO 14971 and ISO 13485 together

• Change impact analysis: the essential guide

• Build vs. buy: medical device cloud connectivity

• Cloud-based medical devices: architecture, benefits and compliance

• Remote patient monitoring platform: build faster with pre-built cloud infrastructure

Summary: how do you achieve IEC 62304 compliance for medical device software?

You achieve IEC 62304 compliance by classifying each software system under clause 4.3 and then running clauses 5 to 9 at the depth that class requires, with traced records for planning, requirements, design, testing, release, maintenance, risk, configuration and problem resolution. For a US submission, set the FDA Documentation Level separately, because it is judged before risk controls and can be higher than the safety class suggests. Matrix Req keeps requirements, risks and tests linked so those records stay current when the software changes.

1. Get the safety class right first (4.3), because it sets the scope of everything else.

2. Trace every software hazard to its risk control and its verification (7.3.3).

3. Keep change control (8.2) and problem resolution (9) running after release.

To compare tools for this work, see our ranking of the best IEC 62304 tools for medical device software, where Matrix Req ranks first.

Last updated: 6 November 2026.