IEC 62304: IEC 62304 – Tutorial (about 60 minutes)

IEC 62304 is the international standard that describes the software life cycle processes a manufacturer should follow when building and maintaining software for medical devices. Regulators in Europe, the United States and many other markets treat it as the recognised way to show that device software was developed with discipline proportionate to the harm it could cause. After this tutorial you will be able to read the standard's structure, classify software by safety class, plan the required activities and recognise what an auditor or regulator will expect to see.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the edition in force is IEC 62304:2006+AMD1:2015, Medical device software – Software life cycle processes, consolidated edition 1.1, published by the International Electrotechnical Commission (IEC) on 26 June 2015. It combines the first edition of 2006 with Amendment 1 of 2015 and is maintained by IEC subcommittee SC 62A (common aspects of medical equipment, software and systems) together with ISO technical committee TC 210. The IEC webstore shows a stability date of 2028. A second edition is in development but not published: an earlier draft was abandoned at the turn of 2021/2022, a new committee draft circulated in 2025, and a second committee draft was expected from August 2026. Drafts propose a wider "health software" scope and new process rigour levels instead of safety classes A, B and C, but these details may still change. The IEC's own forecast was October 2028, and commentators now expect the final draft no earlier than 2028, so publication could slip to 2029. This course teaches edition 1.1, the version regulators and auditors use today, and flags where the next edition may differ. Verified 2026-10-29 against the IEC webstore entry for IEC 62304:2006+AMD1:2015 and the 2026 status updates published by VDE and the Johner Institute.

Who it is for: software engineers, testers, architects, quality and regulatory specialists, project managers and product owners who are joining a medical device project, moving into health technology from another industry, or preparing for their first audit of a software development process. It is also useful for suppliers who write software components that end up inside a medical device.

Prerequisites: none. Some general familiarity with how software is developed (requirements, design, code, test, release) will help, but every term specific to the standard is explained.

Learning objectives. After the seven lessons you will be able to:

Explain why IEC 62304 exists, what software it applies to and which activities it deliberately leaves to other standards.
Use the core vocabulary correctly: software system, software item, software unit, SOUP, anomaly, safety class and the others.
Describe the five process groups in clauses 5 to 9 and how the general requirements in clause 4 frame them.
Assign a software safety class and explain how the class changes the amount of required work.
Plan the development, maintenance, risk, configuration and problem-resolution activities for a real product, including third-party components.
Explain how conformity is demonstrated to notified bodies and the US FDA, and why there is no single "IEC 62304 certificate" that settles the question.
Position IEC 62304 alongside ISO 13485, ISO 14971, IEC 62366-1, IEC 82304-1 and IEC 81001-5-1.

Lesson 1 – Origins, purpose and scope

Why a software life cycle standard for medical devices?

Medical devices have contained software for decades: infusion pumps, ventilators, patient monitors, imaging systems, pacemaker programmers and, more recently, mobile apps that interpret sensor data or recommend treatment. Software failures in such products have caused real harm. A frequently cited early example is the Therac-25 radiotherapy machine in the 1980s, where software defects contributed to massive radiation overdoses. Investigations of such accidents kept reaching the same conclusion: the problem was rarely a single bad line of code, but a development process that did not systematically find, analyse and control the ways software could contribute to harm.

Software is different from hardware in two ways that matter for safety. First, it does not wear out or fail randomly; when it fails, it fails because of a systematic defect introduced during specification, design, coding or change. The same input will trigger the same defect every time. Second, it is practically impossible to test every path through non-trivial software, so testing alone cannot prove that software is safe. The only practical defence is a disciplined process that prevents defects, detects them early, and ensures that every change is controlled. That process is what IEC 62304 describes.

Before IEC 62304, regulators and manufacturers relied on a mix of general software engineering standards, national guidance and in-house practice. The IEC and ISO committees responsible for medical equipment and quality management developed a common standard so that a manufacturer could follow one recognised framework and present one coherent body of evidence to regulators in many countries. The first edition was published in 2006. Amendment 1 followed in 2015 after nearly a decade of practical experience; it clarified the safety classification rules, added an explicit path for legacy software, and adjusted which requirements apply to which class.

What the standard is, and what it is not

IEC 62304 is a process standard. It tells you which processes, activities and tasks must exist and what their outcomes must be. It does not tell you which programming language to use, which life cycle model to adopt (waterfall, iterative, agile and hybrid approaches are all acceptable), which tools to buy or what your documents must be called. You decide how to organise the work; the standard defines what must be achieved and recorded.

It is also a risk-based standard. The more harm a software failure could contribute to, the more rigorous the required process. This proportionality is expressed through the software safety classes A, B and C, which you will meet in Lesson 2 and apply in Lesson 4.

Scope

The standard applies to the development and maintenance of medical device software. That covers two situations: software that is itself a medical device (often called software as a medical device), and software that is embedded in or forms an integral part of a physical medical device, such as pump firmware. It also applies when software is developed in-house by the device manufacturer or bought in, because third-party components must be managed through the same processes.

Three boundaries are important for beginners:

Validation and release of the whole device are excluded. IEC 62304 covers software verification up to and including software system testing and software release. Confirming that the finished device meets user needs in its intended use (device validation) and releasing the device to market are handled by the manufacturer's quality management system and by other standards, even when the device consists only of software.
It assumes a quality management system and a risk management process exist. The standard builds on them rather than replacing them. In practice that means ISO 13485 for quality management and ISO 14971 for risk management.
It is not a product safety standard. It does not set performance limits or test thresholds for a particular kind of device. Product standards (for example IEC 60601-1 for medical electrical equipment) set those, and some of them call on IEC 62304 for the software part.

Because the standard is recognised by regulators, it is usually described as "voluntary but expected". No law in the EU or the US says "you must apply IEC 62304", yet a manufacturer who chooses not to apply it must show by other means that its software process is at least as good, which is far harder to argue.

Lesson 2 – Key concepts and vocabulary

IEC 62304 uses a precise vocabulary, and auditors expect you to use it consistently. The terms below are explained in our own words; the standard's clause 3 holds the formal definitions.

Medical device software – software built either to go inside the particular medical device you are developing or to be a medical device by itself.
Software system – the complete, integrated set of software items that together deliver the intended functions. It is the top level of the software decomposition.
Software item – any part of the software that you can identify and name, from a large subsystem down to a single module. A software system is broken down into items, which may be broken down further.
Software unit – the smallest item in your decomposition: one you choose not to split any further. Where you draw the unit boundary is the manufacturer's choice; it is the level at which detailed design and unit verification are performed.
SOUP (software of unknown provenance) – ready-made software that exists independently of your device (off-the-shelf, open-source or platform software), or older software whose development records are missing or inadequate. Operating systems, open-source libraries, database engines and commercial runtimes are typical SOUP. "Unknown provenance" refers to the development process, not to whether you know the vendor.
Software safety class – the label A, B or C that the manufacturer gives a software system or item, based on how badly a patient, operator or other person could be hurt in a hazardous situation the software might contribute to. Class A means no injury or damage to health is possible; class B means non-serious injury is possible; class C means death or serious injury is possible.
Hazard, hazardous situation and harm – terms taken from ISO 14971. A hazard is a potential source of harm; a hazardous situation is a circumstance in which people are exposed to a hazard; harm is injury or damage to health, property or the environment. Software itself is not a hazard, but it can contribute to a hazardous situation.
Risk control measure – an action or design feature that reduces the probability or severity of harm. It may be implemented in software, in hardware, in labelling or in the clinical workflow. A measure that sits outside the software system is called an external risk control measure and can matter for classification.
Anomaly – anything the software does, or any state it is in, that differs from what you expected, whether that expectation came from a specification, a design document, a standard or plain experience. Not every anomaly is a defect, but each must be evaluated.
Problem report – a written record of software behaviour, seen or suspected, that someone thinks is unsafe, unsuitable for the intended use or not as specified.
Change request – a written description of a change someone wants made to the software. Changes are controlled through configuration management.
Configuration item – anything you place under version control and can identify unambiguously at a given point in time, such as a source file, a SOUP package at a given version, a build script or a document.
Release – a specific version that is handed over for a defined purpose, for example to device validation or to the market.
Legacy software – medical device software that is lawfully on the market and still sold, but whose development cannot be shown, with enough evidence, to have followed the current edition of the standard. Amendment 1 added a defined way to handle it.
Segregation – separation between software items that prevents one from affecting another, such as running them on separate processors or in protected memory partitions. Segregation is what allows different safety classes within one system.
Verification and traceability – verification confirms, with objective evidence, that specified requirements have been fulfilled. Traceability links hazards, requirements, risk control measures, design, code and tests so that you can show nothing was lost along the way.

How the decomposition fits together

Think of the software as a tree. At the top is the software system. Below it are software items, which can be nested. The leaves of the tree are software units. SOUP components appear as items in this tree like any other; the difference is that you cannot apply the full development process to them, so the standard asks for different evidence. The class is assigned first to the system, and then items may receive lower classes only when you can show they are properly segregated from riskier items.

Figure 1 – A software system decomposes into items and units; SOUP appears as items, and segregation allows a lower class for one branch.

Lesson 3 – Structure of the standard

The normative body of IEC 62304 is short compared with many standards; its value lies in how tightly the parts connect. The clause numbering below follows the published consolidated edition. Content is paraphrased.

Clauses 1 to 3: scope, references and terms

Clause 1 sets the purpose and field of application, explains the relationship to other standards and defines what compliance means: implementing all the processes, activities and tasks the standard identifies, as required for the software safety class. Clause 2 lists normative references, chiefly ISO 14971 for risk management. Clause 3 holds the definitions summarised in Lesson 2.

Clause 4: general requirements

Clause 4 sets the foundation that every other clause relies on:

4.1 Quality management system – the manufacturer must show it can consistently provide software that meets customer and regulatory requirements; a QMS conforming to ISO 13485 (or an equivalent national system) is the usual way.
4.2 Risk management – a risk management process conforming to ISO 14971 must be applied.
4.3 Software safety classification – the manufacturer assigns a class A, B or C to each software system and documents the rationale; items may be assigned classes too.
4.4 Legacy software – added by Amendment 1, a route for software already on the market that was not developed according to the standard.

Clauses 5 to 9: the five process groups

The heart of the standard is five processes. Each one is broken into activities (numbered like 5.1, 5.2) and each activity into tasks (5.1.1, 5.1.2 and so on). Every task states the classes it applies to, which is how proportionality is achieved.

Clause 5 – Software development process: eight activities from planning to release – 5.1 development planning, 5.2 requirements analysis, 5.3 architectural design, 5.4 detailed design, 5.5 unit implementation and verification, 5.6 integration and integration testing, 5.7 system testing, 5.8 release.
Clause 6 – Software maintenance process: 6.1 establishing a maintenance plan, 6.2 analysing problems and modifications (including feedback from the field), 6.3 implementing modifications using the development process.
Clause 7 – Software risk management process: 7.1 analysing how software could contribute to hazardous situations, 7.2 defining risk control measures, 7.3 verifying those measures, 7.4 managing risk when software changes.
Clause 8 – Software configuration management process: 8.1 identifying configuration items (including SOUP and versions), 8.2 controlling changes, 8.3 keeping configuration status records.
Clause 9 – Software problem resolution process: preparing problem reports, investigating them, informing relevant parties, using change control, keeping records, analysing trends, verifying the resolution, and making sure test documentation records the relevant details.

Clauses 7, 8 and 9 are often called supporting processes: they run continuously alongside development and maintenance rather than at one point in time.

Figure 2 – Clause 4 frames everything; development and maintenance are the primary processes, supported continuously by risk, configuration and problem management.

The informative annexes

The annexes do not add requirements but are worth reading. Annex A explains the rationale behind the requirements. Annex B gives guidance on applying each clause, including on life cycle models and on what "documented" means. Annex C describes the relationship to other standards such as ISO 13485, ISO 14971, IEC 60601-1 and general software engineering standards. Annex D gives advice on implementing the standard in an organisation, including small companies.

How class drives the requirements

Each task in clauses 5 to 9 is marked with the classes to which it applies. As a simplified picture of the consolidated edition:

All classes (A, B and C) need a development plan, documented software requirements, unit implementation, software system testing, a controlled release, a maintenance plan, device risk management under ISO 14971 (clause 4.2) with a safety-impact analysis of every software change, configuration management and problem resolution.
Class B adds a documented software architecture, decomposition into units, unit verification with acceptance criteria, integration testing and most of the software-specific risk analysis and risk control tasks of clause 7, along with more detailed requirements for SOUP (such as its functional and performance requirements, the platform it needs and a review of its published anomaly lists).
Class C adds detailed design of each unit and of the interfaces between units, verification of that detailed design, and additional unit acceptance criteria covering matters such as event sequences, data and control flow, fault handling and boundary conditions.

Always check the class marking of individual tasks in your copy of the standard; this summary helps you navigate but does not replace the clause text.

Lesson 4 – How it works in practice

Step 1: understand the device and its hazards

IEC 62304 starts from the device risk management performed under ISO 14971. Before you classify software, you need the list of hazards and hazardous situations for the device and an understanding of how the software is involved: does it control energy delivered to the patient, calculate a dose, display a value a clinician relies on, raise an alarm, or merely store and export records? Software risk analysis (clause 7.1) then identifies the software items that could contribute to those hazardous situations and the potential causes, including SOUP failures, incorrect specifications and foreseeable misuse.

Step 2: classify the software

Amendment 1 turned classification into a decision that considers risk control measures outside the software system. The logic, in plain words, is:

Could a failure of the software system contribute to a hazardous situation? If not, the system is class A.
If it could, is the resulting risk acceptable once you take into account risk control measures that are external to the software system (for example a hardware pressure relief valve, an independent monitor, or a mandatory clinical double check)? If yes, the system is class A.
If the risk is still unacceptable, look at the severity of the possible harm. Non-serious injury means class B; death or serious injury means class C.

Two practical points matter. First, classification depends on the severity of possible harm, not on an estimate of how often the software will fail. Because software failures are systematic and hard to predict, you should not argue a low class from a low failure probability. Second, the class must be documented with a rationale that an auditor can follow, linked to the risk management file. Where you are unsure, assume the higher class until analysis justifies otherwise.

Figure 3 – The safety classification decision after Amendment 1: external risk controls are considered first, then the severity of possible harm sets class B or C.

Once the system has a class, you decompose it into items. An item normally inherits the class of the item or system it belongs to. A lower class for a particular item is allowed only when the architecture shows that the item is segregated so that it cannot contribute to the more severe hazardous situations, and the rationale for that segregation is documented. Segregation in a single-process mobile app is hard to justify; separate processors, separate services with one-way data flow, or operating-system memory protection make the argument easier.

Step 3: plan

The development plan (activity 5.1) describes the life cycle model you will use, the deliverables, how traceability will be maintained between system requirements, software requirements, tests and risk control measures, the standards, methods and tools you will use, how integration and verification will be done, and how configuration management, documentation and problem resolution will work. The plan is a living document: it must be updated as the project evolves. Agile teams usually write a lean plan that describes the cadence (sprints, definition of done, review points) and shows where each required activity happens inside it. The AAMI technical information report TIR45 gives widely used guidance on combining agile methods with the standard.

Step 4: requirements, architecture and design

Software requirements (5.2) cover functions and capabilities, inputs and outputs, interfaces, alarms and warnings, security, usability-related requirements, data definitions, installation and acceptance, operation and maintenance needs, user documentation, regulatory requirements and – crucially – risk control measures implemented in software. Each requirement must be verifiable and traceable. The requirements are re-evaluated against the device risk analysis whenever they change.

For class B and C, the architecture (5.3) identifies the software items and their interfaces, the functional and performance requirements of any SOUP, the hardware and software that SOUP needs, and any segregation required for risk control. The architecture is verified, for example by review, to confirm that it implements the requirements and supports the safety arguments. For class C, detailed design (5.4) goes down to each unit and its interfaces so that a developer could implement it correctly, and that design is verified too.

Step 5: implement and verify

Units are implemented (5.5) and verified against acceptance criteria defined in advance: code review, static analysis, unit tests or other methods chosen in the plan. Integration (5.6) brings items together according to an integration plan, and integration tests check that items work together and that risk control measures behave as intended. Software system testing (5.7) verifies that the integrated software meets every software requirement. Test records must make clear what was tested, with which version, by whom, with what result, so that a test can be repeated. Anomalies found during testing enter the problem resolution process; regression testing shows that fixes have not broken anything else.

Step 6: release

Release (5.8) is a controlled step, not just a tag in the repository. Before release the manufacturer confirms that verification is complete, documents the known residual anomalies and evaluates that none of them contributes to an unacceptable risk, records exactly which version is being released and how it was built (the build environment and procedure), archives the software and documentation for the life of the device, and makes sure the software can be delivered to the point of use without corruption.

Figure 4 – The eight development activities of clause 5; each verification level checks the design level that defined it, and the class decides which activities are required.

Step 7: maintain

Software keeps changing after release: defects are reported, SOUP receives security patches, operating systems update and features are added. The maintenance process (clause 6) requires a plan for receiving, documenting, evaluating and resolving feedback, criteria for deciding whether feedback is a problem, and the use of the risk, configuration and problem resolution processes for every change. Modifications are implemented with the same development activities, scaled to what changed, and released in a controlled way. Field feedback must be analysed to decide whether it affects safety, and relevant parties (including regulators, where reporting rules apply) may need to be informed.

Step 8: run the supporting processes all the time

Software risk management (clause 7) continues through the life of the product. Each risk control measure implemented in software becomes a requirement, is verified, and is traced back to the hazard it addresses. Every change is analysed for its effect on existing risk control measures and for new ways the software might contribute to hazardous situations. Configuration management (clause 8) identifies every item, including each SOUP component and its exact version, so that any released build can be recreated. Problem resolution (clause 9) ensures that every reported problem is recorded, investigated for its safety relevance, resolved through change control, verified and analysed for trends.

Working with SOUP

Almost every modern device uses SOUP. The standard does not ban it; it asks you to manage it. You identify each SOUP item by name, supplier and unique version. For class B and C you specify the functional and performance requirements you rely on, state the system hardware and software it needs, evaluate the supplier's published anomaly lists (known bugs, security advisories) to see whether any could contribute to a hazardous situation, and keep monitoring those lists during maintenance. Risk analysis treats SOUP failure as a potential cause, which often leads to defensive design such as input validation, watchdogs or independent checks around the SOUP.

Legacy software

Clause 4.4 handles software already on the market that was developed without the standard. Instead of redoing everything, the manufacturer assesses feedback from field use (complaints, incidents, problem reports), performs a risk assessment, identifies gaps between the available documentation and what the standard requires, and plans proportionate actions to close the gaps that matter for safety, with a documented rationale for continued use. From then on, changes are made under the full maintenance process.

Lesson 5 – Assessment, certification and compliance

There is no single official certificate

IEC publishes the standard but does not run a certification scheme for it, and there is no IEC 62304 equivalent of an ISO 13485 QMS certificate that regulators require. Conformity is demonstrated through the manufacturer's own documentation and records, which are examined as part of the regulatory process for the device. Some test and certification bodies offer voluntary assessments or certificates of conformity for software processes or products; these can help with customer confidence or internal readiness, but they do not replace the regulator's or notified body's review and are not required by the standard.

European Union

Under the EU Medical Device Regulation (EU) 2017/745 and the In Vitro Diagnostic Regulation (EU) 2017/746, the general safety and performance requirements in Annex I require software to be developed and manufactured according to the state of the art, taking into account the development life cycle, risk management (including information security), verification and validation. The European adoption, EN 62304, is the usual way to show this. Notified bodies review the software documentation in the technical file and audit the processes during QMS audits. Manufacturers should check the current harmonisation status of the EN version in the Official Journal, because a harmonised standard gives a formal presumption of conformity, whereas a non-harmonised one is still evidence of the state of the art but without that presumption.

United States

The US Food and Drug Administration (FDA) lists IEC 62304 in its database of recognised consensus standards. A manufacturer can declare conformity to it in a premarket submission, which reduces the amount of evidence FDA needs to review for the process itself. The FDA guidance on the content of premarket submissions for device software functions (2023) asks for "Basic" or "Enhanced" documentation depending on the risk of the device software; this level is chosen by FDA's own criteria and does not map one-to-one onto the IEC 62304 class, although both reflect risk. The FDA quality system rules for design controls, now aligned with ISO 13485 through the Quality Management System Regulation, also apply.

What an assessor actually looks for

Classification rationale – a documented class for the system and items, consistent with the risk management file, with segregation arguments where items have lower classes.
Plans that match reality – a development plan and maintenance plan that describe what the team actually does, kept up to date.
Traceability – links from hazards to risk control measures to software requirements to tests and results, with no gaps.
Objective evidence – review records, test reports tied to specific versions, records of anomalies and their evaluation, release records with residual anomalies justified.
SOUP management – a list of SOUP with versions, requirements and anomaly-list evaluations, and evidence of monitoring after release.
Change control in maintenance – for each change, an impact analysis on safety and existing risk controls, and regression testing proportionate to the change.

Compliance is binary per task: either the required activity was performed and its outcome documented, or it was not. There are no maturity levels or scores in IEC 62304 itself. Assessors therefore sample records and follow a thread end to end – for example from one hazard through the requirement, design, code review, test and release – to see whether the process holds together.

Internal readiness

Many organisations run an internal gap assessment against the standard before their first notified body audit or FDA submission. A useful approach is a clause-by-clause checklist that records, for each task applicable to the class, which procedure covers it and where the evidence lives. Gaps are then planned and closed like any other work item.

Lesson 6 – Worked example

The following example is fictional but realistic. It shows how a small team applies the standard from the start of a project to its first maintenance release.

The organisation and the product

BrightDose Health is a 40-person company building a smartphone app for people with type 1 diabetes. The app connects to a glucose meter over Bluetooth, takes the user's planned carbohydrate intake and suggests an insulin bolus dose. A separate cloud service lets the user's clinician view weekly charts and download a PDF report. The company already holds an ISO 13485 certificate for a previous hardware product and has an ISO 14971 risk management procedure.

Hazards and classification

The risk management team identifies, among others, the hazardous situation "user injects an incorrect bolus dose suggested by the app". An overdose could cause severe hypoglycaemia, which can lead to death or serious injury. External risk controls are limited: the user is trained to judge the suggestion, but the team agrees that this cannot reduce the risk to an acceptable level on its own. The app is therefore classified as class C.

The cloud reporting service is a separate software system running on separate infrastructure. It receives copies of logged data and never sends anything back to the app. The worst credible effect of a failure is a misleading chart; the clinician reviews trends over weeks and makes decisions together with laboratory results, and the team's risk analysis concludes that the realistic harm is at most non-serious. The reporting service is classified as class B, with the one-way data flow documented as the reason it cannot affect dose calculation.

Inside the app, the team considers giving the "export logs" feature a lower class, but it runs in the same process and shares memory with the dose calculator. They cannot justify segregation, so every item in the app stays class C. This is a common, sensible outcome.

Planning in an agile setting

BrightDose works in two-week sprints. Its development plan describes the sprint cycle, the definition of done (code reviewed, unit tests passing, static analysis clean, requirement and trace links updated), how architecture and detailed design are updated as stories change them, when integration and system test campaigns run, and how a release candidate is frozen. It names the tools: an issue tracker for requirements, problems and change requests; a Git repository with protected branches; a continuous integration pipeline that records the build environment. The plan also lists the SOUP: the mobile operating system's Bluetooth stack, a UI framework, a cryptography library and a charting library, each with its version.

Requirements and risk control measures

The software requirements include the dose formula, units handling, input ranges and the risk control measures from the risk analysis: a hard upper limit on any single suggested dose, a confirmation screen that repeats the dose in large text, a check that rejects glucose readings older than a set time, and detection of corrupted Bluetooth data. Each risk control requirement carries a link to the hazardous situation it addresses.

Architecture, design and SOUP

The architecture separates the dose calculation into its own item with a narrow interface, so that its detailed design and verification can be very thorough. The SOUP section states what the team relies on from each library and how failures are contained. The Bluetooth stack's published issue list includes a known problem with dropped packets on some phone models; the team evaluates it, concludes it could cause stale readings, and relies on the age check already in the requirements as the control. That evaluation is recorded.

Implementation, verification and release

For the class C dose item, unit acceptance criteria cover boundary values, unit conversions, rounding, behaviour with missing data and error handling. Code is reviewed by a second developer, and unit tests reach the coverage target set in the plan. Integration tests exercise the Bluetooth data path with injected faults. System tests verify every software requirement, including each risk control measure, on the supported phone models. Three minor anomalies remain at release – for example, a chart label overlaps on very small screens. The release record lists them, explains why none contributes to an unacceptable risk, identifies the exact build and archives the source, build scripts and documentation.

Maintenance

Two months after launch, a security advisory is published for the cryptography library. The problem resolution process records it, the team assesses whether it could contribute to a hazardous situation (the library protects data in transit to the cloud service; a weakness could expose personal data and, in the worst case, allow tampering with logged values), and raises a change request. The change is implemented under change control, with regression tests chosen from the trace matrix, and released as version 1.0.1. The risk management file is updated, and the trend analysis notes that SOUP advisories are now the most frequent source of maintenance releases, which leads the team to subscribe to automated vulnerability alerts for all SOUP.

The audit

At the notified body audit, the auditor picks the overdose hazard and follows it through: risk analysis, the dose limit requirement, the design of the limit check, the unit tests, the system test results for build 1.0.0, the release record and the impact analysis for 1.0.1. Every link is present. The auditor raises one finding: the maintenance plan does not say how quickly safety-relevant problem reports must be evaluated. The team adds a target time to the plan and records the correction.

Lesson 7 – Relationship to other standards and frameworks

IEC 62304 is one piece of a family. Understanding the neighbours helps you avoid duplicating work or leaving gaps.

Standard	Focus	How it relates to IEC 62304
ISO 13485:2016	Quality management system for medical device organisations	Provides the QMS that IEC 62304 assumes (design controls, document control, training, CAPA). IEC 62304 adds the software-specific process detail.
ISO 14971:2019	Risk management for medical devices	Defines the overall risk process, hazard and harm vocabulary and acceptability decisions. IEC 62304 clause 7 adds software-specific risk analysis and control within it.
IEC 62366-1:2015+A1:2020	Usability engineering	Covers use-related hazards and user interface evaluation; software user interfaces need both standards.
IEC 82304-1:2016	Health software products, including product validation and accompanying documents	Covers the product-level requirements, validation and release of stand-alone health software that IEC 62304 leaves out, and calls on IEC 62304 for the software life cycle.
IEC 81001-5-1:2021	Security activities in the health software life cycle	Adds secure development and security maintenance activities that plug into the IEC 62304 processes.
IEC 60601-1	Basic safety and essential performance of medical electrical equipment	Its requirements for programmable electrical medical systems refer to IEC 62304 for the software development process.
IEC 61508	Functional safety of electrical, electronic and programmable systems in general	A broader, generic functional safety standard with integrity levels; IEC 62304 is a medical-sector process standard with simpler, harm-based classes.
ISO/IEC/IEEE 12207	Software life cycle processes in general	A comprehensive generic process framework; IEC 62304 draws on similar ideas but is focused on medical safety and regulatory evidence.

A practical way to picture the relationships is a stack. ISO 13485 is the management system around everything. ISO 14971 is the risk engine that feeds all design decisions. IEC 62304 governs how the software itself is built and maintained. IEC 62366-1 governs the user interface and use errors. IEC 81001-5-1 adds security activities. IEC 82304-1 (for stand-alone health software) or a product standard such as IEC 60601-1 (for electrical equipment) wraps the product-level requirements around the software.

Looking ahead: the second edition

The draft second edition, being prepared jointly by IEC and ISO committees, aims to widen the scope from medical device software to health software in general, relax the hard normative link to ISO 13485 and ISO 14971 in favour of product-level quality and risk management, and replace the three safety classes with process rigour levels. Drafts also make planning, architecture, static analysis, testing and traceability requirements more specific, address controlled change and decommissioning of cloud-based software, move the legacy software route into an informative annex, and add informative (non-binding) annexes on AI and agile development. These are proposals in a committee draft and may change before publication. Until a new edition is published and recognised by regulators, edition 1.1 remains the reference, and regulators usually allow a transition period after any new edition.

Common pitfalls and best practices

Pitfalls

Classifying by optimism. Teams argue for class A or B because "the software is well tested" or "it almost never fails". Classification depends on the severity of possible harm after external controls, not on confidence in the code.
Claiming segregation that does not exist. Giving a lower class to an item that shares a process, memory or data path with a class C item, without a technical argument, is a frequent audit finding.
Writing documents after the fact. Producing plans, designs and test reports just before submission creates records that do not match what happened and usually exposes gaps in traceability.
Ignoring SOUP. Treating open-source libraries and operating systems as "not our software" leaves unknown risks and missing anomaly evaluations; SOUP must be listed, versioned and monitored.
Stopping at release. Weak maintenance – patches pushed without impact analysis, regression testing or risk review – undoes the discipline applied during development.
Confusing software system testing with device validation. Passing all software tests does not prove that the device meets user needs; validation is a separate, required activity under the QMS.

Best practices

Integrate the process into daily tools. Make traceability links, reviews and test evidence part of the issue tracker, repository and pipeline, so compliance records are produced as a side effect of normal work.
Classify early and revisit. Do a first classification as soon as the intended use and main hazards are known, and update it as the architecture and risk analysis mature.
Design for safety arguments. Isolate the riskiest functions in small, well-defined items with narrow interfaces; this makes thorough verification affordable and segregation defensible.
Keep a living SOUP register. Record versions, the requirements you rely on, anomaly-list reviews and alerts, and connect it to your vulnerability monitoring.
Write lean plans that match reality. A short plan that the team actually follows beats a long template no one reads; update it when the way of working changes.
Rehearse the audit trail. Regularly pick one hazard and follow it end to end through requirements, design, code, tests and release to find broken links before an assessor does.

Summary and key takeaways

IEC 62304:2006+AMD1:2015 (edition 1.1) defines life cycle processes for medical device software; a second edition is in committee draft and not yet published.
It is a risk-based process standard: it defines required activities and outcomes, not tools, languages or life cycle models.
Clause 4 requires a QMS, ISO 14971 risk management, safety classification and, where relevant, a legacy software approach.
Clauses 5 to 9 define development, maintenance, software risk management, configuration management and problem resolution.
Safety class A, B or C follows from the severity of harm the software could contribute to after external risk controls, and it decides which tasks apply.
SOUP is allowed but must be identified, specified, evaluated against known anomalies and monitored.
Conformity is shown through documented evidence reviewed by notified bodies and the FDA; there is no mandatory IEC certificate.
The standard works together with ISO 13485, ISO 14971, IEC 62366-1, IEC 82304-1 and IEC 81001-5-1.

Reflection questions

Pick a software product you know (medical or not). If it were a medical device, which hazardous situations could it contribute to, and what safety class would you argue for? What evidence would you need to support that argument?
Your team uses two-week sprints and continuous integration. Where in that workflow would each of the eight development activities of clause 5 take place, and what records would the tools produce automatically?
List the third-party components in a system you work on. For each, what would a SOUP entry need to say, and how would you learn about new defects or vulnerabilities after release?
An architect proposes giving a logging component a lower class than the rest of the system. What questions would you ask to decide whether the segregation argument is sound?
Imagine a notified body auditor follows one hazard from risk analysis to release in your project. Where do you expect the trail to be weakest today, and what would you change first?