What Is IEC 62304? A Guide to Medical Device Software

IEC 62304 is the international standard for developing and maintaining medical device software, whether the software is a medical device on its own or built into one. Every software system it covers gets a safety class of A, B or C, based on the worst-case harm the software could contribute to, and that class decides how much planning, design, testing and documentation you have to produce.

FDA recognizes the current edition, so a 510(k) sponsor can cite it in a submission. FDA submissions should also show traceability from requirements to verification and risk controls. The sections below explain what each safety class requires, how risk controls trace to their verification, and how Software of Unknown Provenance (SOUP), code you use but didn’t develop for the device, is controlled at each class.

What Is IEC 62304?

The standard sets life cycle requirements for software that is itself a medical device and for software embedded in or integral to one. Validation and final release of the device are outside the standard’s scope, even when the device is entirely software, and the standard prescribes no life cycle model. Before any lifecycle work, a manufacturer needs a quality management system that satisfies ISO 13485. A risk management process that complies with ISO 14971 must also be in place, along with a safety class of A, B or C for each software system. Clauses 5 through 9 define development, maintenance, risk management, configuration management and problem resolution processes.

The edition in force is the consolidated Edition 1.1, published on 26 June 2015. Edition 1.1 combines the original IEC 62304:2006 with Amendment 1:2015. FDA lists the consolidated Edition 1.1 as recognized consensus standard 13-79 with complete recognition. A 510(k) sponsor can therefore cite it in a submission.

In the EU, notified bodies expect software documentation in technical files for the Medical Device Regulation (MDR) to follow EN 62304 and scale with the safety class, according to the notified-body association Team-NB. A technical file should cite EN 62304 as a benchmark, and claim presumption of conformity only once the Commission’s harmonized standards list for the MDR names it.

Software Safety Classes Set the Depth of Evidence

The safety class sets how much lifecycle evidence IEC 62304 requires, through the activities Table A.1 assigns to each class. Under Clause 4.3, each software system gets one of three safety classes, based on the worst-case harm it can contribute to after external risk controls:

• Class A: The software either cannot contribute to a hazardous situation or has acceptable risk after external controls.
• Class B: The software can contribute to a hazardous situation involving non-serious harm.
• Class C: The software can contribute to death or serious injury.

Unclassified software defaults to Class C, and the highest class of any component sets the class of the whole system. Under Amendment 1, classification assumes that software will fail to behave as specified. Severity and risk controls external to the software system determine the class, and reliability arguments, coverage figures and field history have no effect on it.

Activity	Clause	Classes it applies to
Software development planning	5.1	A, B, C (several planning items B and C only, one C only)
Software requirements analysis	5.2	A, B, C (one item B and C only)
Software architectural design	5.3	B, C (one item C only)
Software detailed design	5.4	C (one item B and C)
Software unit implementation	5.5	A, B, C
Software unit verification	5.5	B, C, with added acceptance criteria at C
Software integration and integration testing	5.6	B, C
Software system testing	5.7	A, B, C
Software release	5.8	A, B, C
Configuration management and problem resolution	8, 9	A, B, C

Table A.1 shows that Class A still requires planning, unit implementation, system testing, configuration management and problem resolution records. Class C differs from Class B chiefly in detailed design and in the additional unit acceptance criteria it requires. Code-based (white-box) testing happens primarily at unit level, according to FDA’s software validation guidance, so system tests alone don’t provide code-based coverage.

The IEC 62304 Software Development Lifecycle and the Records It Leaves

IEC 62304’s development process runs from planning to release, and each stage produces a record an auditor or FDA reviewer can request. The safety class decides which records exist, and FDA’s Documentation Level, Basic or Enhanced, affects how much of them goes into a submission.

Planning, Requirements and Release Apply at Every Class

Planning, requirements analysis and release records are required at every class, and Class B and C add items to the plan and the requirements. The software development plan names tools, methods and coding guidelines, and for Class B and C it covers how known defects are published. Where integration and system testing are combined, the plan must say so.

Teams document requirements at every class, including information technology (IT) security, networking and user interface requirements. Requirements that implement risk controls belong in the Software Requirements Specification (SRS). Each should translate readily into a verification acceptance criterion, which is the link an auditor follows from the risk file to the test record. Release documentation identifies the version under application, and notified bodies expect a list of known residual anomalies with a justification for releasing with each. A technical file should include a clearly identified safety classification with its justification, plus a traceability matrix linking requirements to protocols, reports and test data, according to Team-NB.

Architecture, Design and Verification Scale With Class B and C

Architecture is required for Class B and C software and identifies software items and units, specifies interfaces, and documents the requirements and prerequisites for each SOUP component. The architecture is also an input to the software risk analysis. Unit verification applies at Class B and C, and Class C adds acceptance criteria such as event sequences, fault handling, memory management and boundary conditions. Integration testing exercises data and control transfer across architecture interfaces. Together with unit verification, it shows whether lower-level and interface behavior support the system requirements.

Design and Development Requirements and the Submission Trace Under the QMSR

Under the Quality Management System Regulation (QMSR), § 820.10(c) requires manufacturers of class II, class III and certain class I devices, including those automated with computer software, to comply with the design and development requirements of ISO 13485. ISO 13485 sets those requirements out in Clause 7.3 and its subclauses. The QMSR has been in effect since 2 February 2026. FDA recommends tracing each identified hazard to its verified risk controls, from an SRS requirement and its tests to a user manual or training identifier. When one hazard traces to several requirements and tests, a separate document can connect the SRS, design specification, testing and identified hazards.

FDA sets an Enhanced Documentation Level where failure or a flaw of any device software function could present a hazardous situation with probable risk of death or serious injury, assessed before risk controls. Basic Documentation applies when Enhanced Documentation is not appropriate, although FDA also recommends Enhanced Documentation for certain device categories, including some blood-related devices, Class III devices, and device constituent parts of combination products. FDA sets one Documentation Level for the device as a whole, while IEC 62304 classifies each software system and its items, so the two schemes don’t map one to one. A sponsor can substitute a declaration of conformity to the recognized IEC 62304 for applicable development, maintenance and configuration management documentation.

Learn About the QMSR

Software Risk Management Under Clause 7 and ISO 14971

Software risk management under Clause 7 starts from hazardous situations already identified in the ISO 14971 system analysis. The team identifies which software items could contribute to each situation and records their potential causes, such as SOUP failures. Severity is taken from the system risk file, and the analysis works at least at software-item level.

For every documented potential cause, you define, document, implement and verify a risk control measure, often as a new requirement in the SRS. FDA ranks risk control options from design changes, through protective measures, to information for safety, in its premarket software guidance. Verification also checks whether a measure creates a new hazardous situation. For Class B and C software, the manufacturer documents four traceability links that connect system risk analysis to software implementation and verification, and the record should make each one explicit:

• Hazardous situation to software item: The system risk file names the item whose failure could contribute to the situation.
• Software item to software cause: The record explains how that item fails, including a SOUP failure or unexpected result.
• Software cause to risk control measure: The record links the control, usually a requirement, that addresses that cause.
• Risk control measure to its verification: The record cites the test or review showing the control was implemented and is effective.

At every class, Clause 7.4 requires a change analysis that looks for new causes and risk controls, including for SOUP changes. Class B and C must also analyze the impact on existing controls and act on the result. After release, the change is also covered by ISO 14971 post-production activities.

[MID-PAGE CTA: Promote the datasheet “FMEA Framework for Medical Device Development” | https://www.jamasoftware.com/datasheet/jama-software-fmea-medical-device-development-datasheet/. Button text: Get the FMEA Datasheet. Note for publishing: RM Hub, copy the button HTML from the reference template]

Software Maintenance Under Clause 6

Clause 6 of IEC 62304 is the process for changing medical device software after release. Its three activities are establishing a software maintenance plan, problem and modification analysis, and modification implementation. Every requirement in the clause applies at Class A, B and C, according to Table A.1, so you need a maintenance plan and change records even for Class A software.

Problem and modification analysis starts with monitoring feedback on software released for intended use. Each problem report is then evaluated for its effect on safety and for whether the software needs to change, using the software problem resolution process. A problem can also show that a software system or software item was placed in the wrong safety class. Each change request gets an impact analysis of its effect on your company, the released software and the systems it interfaces with, and each one needs approval. Approved changes are also communicated to affected users and regulatory authorities when required.

During modification implementation, you identify which Clause 5 activities the modification requires you to repeat, and you perform them. The modified software is then released through the standard’s software release activity. Risk management of software changes has its own requirements, set out in the risk management section above. Configuration management records link each change request to its relevant problem report and to its approval at every class, and the late-change walk-through below applies them to a Class C program. An auditor checking maintenance can ask for the maintenance plan, the evaluated problem reports and the linked change records.

Configuration Management and Problem Resolution Through a Late Change

Every late change passes through configuration management and problem resolution, which apply at every class. Configuration management identifies SOUP and every other configuration item. A controlled item changes only through an approved change request, and the team verifies, traces and logs the change in status accounting. Problem resolution produces a problem report, investigates it, advises relevant parties and evaluates trends.

A late change in a Class C program means re-checking the requirement that changed, the risk control that depended on it, and every verification record built on either. For that change, an auditor expects an approved change request and a cause investigation covering process, methods, tools or code. The record then shows updated requirements and architecture, plus class-scaled regression across unit, integration and system tests through release.

Archived test cases and prior verification and validation (V&V) results let you scope regression after a change. Xoran Technologies left unclear whether its regression analysis had determined which unit, integration and system-level tests to re-run after software changes, or whether code coverage matched the risk, FDA wrote in a December 2024 warning letter. Between 1992 and 1998, 192 of 242 software-related recalls came from defects introduced by changes made after the software’s initial production and distribution, according to FDA’s General Principles of Software Validation.

ISO 13485 Clause 7.3.9 requires teams to review, verify or validate design changes as appropriate and approve them. New app treatments that ZIIP, Inc. added in October 2025 lacked documentation or supporting V&V even though the company’s own procedures required review for repeat V&V, FDA found in a 2026 warning letter. Pensar Medical communicated a hold on one firmware change order only verbally, with no nonconformance report, and had submitted no documented formal risk assessment for a later firmware update, the agency found that year.

Controlling SOUP by Safety Class

SOUP control scales by class, with identification at every class and specification and anomaly evaluation added at Class B and C. Software qualifies as SOUP when it was already developed and generally available but wasn’t developed for the device, or when it was previously developed with inadequate development records. The medical device software system as a whole cannot be claimed as SOUP, although individual software items, including previously developed internal software lacking adequate development records, may qualify as SOUP. FDA’s off-the-shelf (OTS) software guidance covers the same ground without using the term SOUP.

Each SOUP item’s configuration record lists the title, manufacturer and a unique designator such as a version, release date, patch number or upgrade designation. The maintenance plan explains how the team evaluates upgrades, patches and obsolescence. Section 524B(b)(3) of the Federal Food, Drug, and Cosmetic Act requires cyber device manufacturers to provide a Software Bill of Materials (SBOM) covering commercial, open-source and off-the-shelf components. FDA asks for it in a machine-readable format in its cybersecurity guidance. An SBOM of that kind covers SOUP identification, the part of SOUP control owed at every class.

At Class B and C, the architecture states each item’s functional and performance requirements for its intended use, plus the hardware and software it needs. Verification confirms that the item works as specified on that hardware and software. Where SOUP failure could cause a hazardous situation, you evaluate the supplier’s published anomaly list for the version in use and record the potential causes in the risk management file. A record that names the sources searched, the search date, the anomalies found and the hazard analysis of each lets an auditor see that the evaluation was done.

Where IEC 62304 Edition 2 Stands

Edition 2 isn’t published yet, and the IEC lists it as in development. Publication is forecast for October 2028, a forecast that teams shouldn’t plan around. Its second Committee Draft (CD) 62A/1761/CD circulated on 7 August 2026 with comments closing on 27 November 2026, according to IEC Technical Committee 62, Subcommittee 62A.

The draft extends its scope to all health software, including software as a medical device (SaMD) and software with AI or machine learning (ML) algorithms, and is retitled to match. Conformity under the draft is assessed against what it calls a software process rigour level. Reviewers apply Edition 1.1 and its Table A.1 until the new edition is published.

How Jama Connect Supports IEC 62304

Jama Connect®, a web-based requirements management and traceability platform, can hold the SOUP list and its anomaly evaluations in custom item types, with a picklist field recording each software item’s safety class. Administrators can configure those item types and the pre-built medical device Traceability Information Model (TIM) to include SOUP records, configuration items and problem reports with required links, as the TIM already does for requirements and tests. When a requirement changes late in a Class B or C program, suspect links flag every linked test and risk item for review. Coverage gap detection identifies requirements without linked verification and any other missing link the TIM requires, such as a risk control.

For review and release evidence, Review Center records approvals with electronic signatures aligned to FDA’s 21 Code of Federal Regulations (CFR) Part 11. The medical device frameworks ship with pre-built risk analysis reports, so teams can analyze risk without first building report templates. Export templates aligned to regulatory submission requirements produce traceability matrices and risk management files from the linked records, which teams may organize as a Design History File (DHF) in the industry sense. Medimaps cut FDA submission preparation from over a week to a few hours. The same linked records give engineering and Quality and Regulatory Affairs teams a starting scope for change-impact analysis and regression review, including any Class C requirement whose verification record predates its last change.

Keep IEC 62304 Trace Links Current Between Releases

The next late change is easier to scope when each risk control already links to its verification and the SOUP anomaly evaluation names the version in use. If you update those links inside each change request, you can scope regression from the record and show an FDA reviewer or auditor which tests were re-run and why.

When the next release comes around, Jama Connect offers baseline comparisons that show which requirements, risk controls and tests changed between two releases. A free 30-day trial lets you scope your next release’s regression from the linked record.

Frequently Asked Questions About IEC 62304

Is IEC 62304 mandatory for FDA submissions?

IEC 62304 is voluntary for FDA submissions. The QMSR still requires manufacturers of class II, class III and certain class I devices to comply with ISO 13485 Clause 7.3, so design and development records are owed either way. A declaration of conformity to the recognized IEC 62304 can cover its applicable clauses in the submission. Teams that run medical device requirements management in Jama Connect can organize the class-scaled records that support the declaration and later inspection.

Does FDA’s Computer Software Assurance guidance apply to device software?

Computer Software Assurance (CSA) doesn’t apply to device software functions, because it covers software used in medical-device production or the quality management system. FDA issued the current final guidance on 3 February 2026, superseding the September 2025 version, and its scope excludes cloud computing used as part of device software functions. Lifecycle evidence for device software is governed by IEC 62304 and the broader design and development requirements historically called design controls.

How does IEC 62304 differ from IEC 82304-1?

IEC 82304-1 (2016) covers the safety and security of health software products that run on general computing platforms without dedicated hardware. Its scope includes the product validation that IEC 62304 leaves out, and it references the IEC 62304 lifecycle processes. Software that is part of a medical device under IEC 60601-1 is excluded. Embedded software controlling medical electrical equipment follows the programmable electrical medical systems requirements in Clause 14 of that standard, which incorporate IEC 62304 requirements by reference.

What does IEC 62304 require for legacy software?

Legacy software is legally marketed medical device software that lacks sufficient objective evidence of development under the current standard, and Amendment 1 provides a route for evaluating it. The manufacturer compares existing documentation against requirements, architecture, system testing and risk management expectations, then completes the missing activities. Only genuinely inherited software qualifies for the route. Under the Edition 2 draft, the method for demonstrating legacy conformity moves to Annex G.

If I want to learn more about IEC 62304, what else should I read?

The ISO 13485 guide covers the quality management system that governs development records. For electronic records and signatures, read FDA 21 CFR Part 11.

This article was authored by Tom Rish and published on October 21, 2026.