IEC 62304 Standard: Requirements, Safety Classes and Evidence

IEC 62304 defines lifecycle processes for developing and maintaining medical device software. It covers software that is itself a medical device and software that forms part of a medical device. The software safety class determines which activities apply; the team's records need to show how those activities were carried out.

This guide covers IEC 62304:2006+A1:2015, consolidated edition 1.1. It explains classification, development planning, third-party software and the connection to US requirements, then follows one hypothetical software problem from risk analysis to release evidence.

In this guide

• What IEC 62304 covers
• Software safety classes A, B and C
• The five lifecycle processes and useful records
• Worked example: a stale sensor reading
• SOUP and component review
• IEC 62304, FDA submissions and QMSR
• How to review an existing software process
• Frequently asked questions
• Support for your team

What IEC 62304 covers

Start with the product's intended use and software boundary. A mobile interface, cloud service and embedded controller may all contribute to a medical function. A component does not fall outside the analysis simply because another team owns it or it runs on a remote server.

The standard addresses software release, but does not cover validation or final release of the complete medical device , including a device consisting entirely of software. Passing software tests therefore does not, by itself, establish that the finished device meets its intended use. Device-level validation and release remain part of the applicable product and quality-system work.

The IMDRF definition of Software as a Medical Device (SaMD) distinguishes software that performs its medical purpose without being part of a hardware medical device. Software intended to drive a hardware medical device does not meet that definition. Software in a Medical Device (SiMD), such as an embedded controller, can still fall within IEC 62304's scope.

In vitro diagnostic (IVD) describes a different aspect of a product: SaMD can itself be an IVD. Treating SaMD, SiMD and IVD as three mutually exclusive categories can obscure the actual function being assessed.

For a connected product, sketch the path from data acquisition to the output a person uses. Mark interfaces, shared components and responsibilities. Use the sketch to ask: if this component returns incorrect, delayed or missing data, which medical function could it affect?

Software safety classes A, B and C

The 2015 amendment uses a risk-based classification approach. Assess the hazardous situations to which the software can contribute, considering risk controls external to the software system. For this classification exercise, assume the probability of software failure is 1. That assumption concerns software failure, not the probability that a person will be harmed.

Summary of the amended classification approach

This is a paraphrase of amended clause 4.3 and Figure 3, not a complete classification procedure. Use the controlled standard and device risk analysis for the actual decision.

A classification record should make the reasoning inspectable. Identify the software system being classified, the hazardous situations assessed, any external controls relied on and the basis for accepting their effect. A bare “Class B” entry gives the next reviewer no way to reconstruct the decision.

Decomposition alone does not justify lowering a class. If two functions share a data parser, queue or operating environment, a fault in that shared element may affect both. Any argument based on separation needs an architectural rationale and verification appropriate to the claimed separation.

Software safety class is also separate from FDA device class. Do not infer A, B or C from a device's Class I, II or III designation. Revisit the rationale when intended use, interfaces or relevant controls change. Our guide to SaMD risk management discusses how software failure scenarios connect to the broader device risk assessment.

The five lifecycle processes and useful records

IEC 62304 organizes the work into software development, maintenance, risk management, configuration management and problem resolution. The table below is an operational example of records a team might use. It is not a complete clause checklist, and the examples do not mean every record or activity applies identically to every class.

Example records and questions for a lifecycle review

A software development plan is required. Clause 5.1.1 calls for a plan or plans for Classes A, B and C, appropriate to the work's scope, scale and safety class. Planning can sit within a wider system development plan; it must remain current as development proceeds. See the IEC standard preview for the planning provisions.

A useful plan resolves working decisions: who reviews a changed safety requirement, how a supplier update enters the build, when verification is complete and how unresolved issues reach the release reviewer. Naming tools without explaining these decisions leaves the process dependent on individual memory.

An Agile team can incorporate those decisions into its normal workflow. For example, a changed requirement can trigger risk review, an updated test and review of the resulting record. A sprint completion label alone cannot show that all three happened. Keep failed test results and their disposition alongside the subsequent retest, rather than retaining only the final passing run.

Worked example: a stale sensor reading

Hypothetical example: a monitoring application receives measurements from a sensor. A communication delay leaves an old measurement on screen, and the display makes it appear current. A user could then act on outdated information.

The example below shows one traceability chain, not a complete risk assessment or a sufficient control design for a particular device. The acceptable age limit and response to stale data must come from the product's intended use and risk analysis. No clinical threshold or safety class is assigned here.

From a failure scenario to reviewable evidence

Notice the difference between testing a screen and testing the proposed control. A screenshot showing a warning is weak evidence if the test never establishes the measurement's age or checks the boundary condition. The result should show which input produced the warning and whether the display behaved as specified.

The same traceability chain helps when the product changes. If a new caching layer is introduced, review its effect on timestamps, stored values and reconnection. Link the change to the affected requirement and tests; do not assume the earlier passing result covers the new data path.

For a team review, ask an engineer who did not implement the feature to follow R-017 through the records. If they cannot identify the tested build or explain the release decision, the missing connection is a concrete improvement task.

SOUP and component review

IEC 62304 uses software of unknown provenance (SOUP) for generally available software items developed for purposes other than incorporation into the medical device, and for previously developed items whose development records are inadequate or unavailable. SOUP can include internally developed items as well as third-party software.

A software bill of materials (SBOM) helps identify components and versions. It does not, on its own, explain whether a component is suitable for its role or what happens when it fails. That distinction matters when a component sits on a path that affects the medical output.

Consider a third-party parser used by the hypothetical monitoring application. An operational review could record:

• The exact version, source and intended role in the product.
• The input formats and error behavior the application depends on.
• Known anomalies relevant to that use, including the basis for judging an anomaly inapplicable.
• Tests of malformed, delayed or incomplete data at the application's interface.
• Who monitors updates and how a proposed replacement enters change control.

Adapt this example review record to the software's role and class, and check the applicable requirements in the controlled standard. Security-related component obligations also require a separate check against the device's applicable cybersecurity requirements.

IEC 62304, FDA submissions and QMSR

IEC 62304 is a voluntary consensus standard, not a US regulation in its own right. Using it does not establish that every requirement for a device, its quality system or its submission has been met.

The FDA's Quality Management System Regulation (QMSR) became effective on February 2, 2026. It incorporates ISO 13485:2016 by reference into 21 CFR Part 820, with additional FDA provisions. An updated quality-system mapping should account for that framework instead of relying only on the former 820.30 references.

FDA's Content of Premarket Submissions for Device Software Functions guidance addresses recommended submission documentation. It uses Basic and Enhanced documentation levels, assessed using the guidance's criteria before risk controls are implemented. Those levels are separate from IEC 62304 safety classes; there is no automatic A/B/C conversion.

For example, the guidance describes documentation for software requirements, architecture, testing, version history and unresolved anomalies. It also describes circumstances in which a declaration of conformity to the recognized IEC 62304 version can support the submission's account of development, configuration management and maintenance practices. That does not remove the need to address the rest of the submission.

An example working crosswalk, not a regulatory equivalence table

Assign an owner to each connection and test the crosswalk against an actual change. Differences between an engineering record and a submission summary should be explainable, especially if development has continued since the summary was written.

How to review an existing software process

Choose one recent change with a safety-related consequence. Review it with the engineer, quality lead and the person responsible for the risk assessment. Keep the discussion on that change so the findings identify missing work, rather than producing another general checklist.

1. Locate the starting decision. What problem or requirement triggered the change? Was its effect on intended use and affected functions considered?
2. Follow the implementation. Which software items and interfaces changed? Were shared components or suppliers involved?
3. Read the test result. Does it identify the tested version, relevant conditions and expected behavior? Can the team explain failures and their disposition?
4. Inspect the release decision. Were remaining anomalies assessed, and can the reviewer identify the released configuration?
5. Assign the repair. Give each gap an owner and an observable completion condition, such as reviewing a missing impact analysis or rerunning an affected test.

Automation can make records easier to collect. A build pipeline can capture versions, test inputs and results, while links between work items can reduce manual transcription. The people making risk and release decisions still need enough context to judge the result.

Where the gap is understanding, pair the repair with practice. Ask the engineer to write the next testable requirement or carry out the next change-impact review, then discuss the reasoning. Completing a training session alone does not demonstrate that the person can perform the task independently.

Frequently asked questions

Which edition does this guide cover?

IEC 62304:2006 with Amendment 1:2015, published as consolidated edition 1.1. Identify the edition in your controlled procedures and check the recognition status relevant to the market and submission.

Does IEC 62304 require a software development plan?

Yes. Clause 5.1.1 requires a plan or plans for Classes A, B and C. The planning can form part of a wider system development plan and must be maintained as the work evolves.

Is Class A software exempt from IEC 62304?

No. Class A does not mean no lifecycle work. Apply the activities specified for that class, including the development-planning requirement, and retain the rationale for the classification.

Can an Agile team use IEC 62304?

Yes. The workflow must accommodate the applicable lifecycle activities. Connect requirements, risk decisions, reviewed changes and verification results to the version being released; a sprint board alone does not provide that account.

Does IEC 62304 replace device validation or FDA requirements?

No. It addresses software lifecycle processes. Validation and final release of the complete device fall outside its scope, and applicable US regulatory and submission requirements still need separate assessment.

Support for your team

At IMSQ, the Institute of MedTech Software Quality, specialist support and learning can help your team address a specific software-quality gap and understand the reasoning behind the work. Bring a development plan, a troublesome change or an incomplete traceability example to the discussion. Book your IMSQ program review.