IEC 62304 software testing requirements

What does IEC 62304 require?

The standard describes processes. Clause 5 covers development, from planning in 5.1 through release in 5.8. Clause 6 covers maintenance. Clauses 7, 8 and 9 cover risk management, configuration management and problem resolution, and they keep running for as long as the product is on the market.

clause 5.7, Software system testing is the one an auditor opens first. It asks for the records it names: what was tested, against which requirement, on which build, with what result, and what happened to the failures. The standard names no technique, no tool and no coverage figure. It says what has to be written down.

Which clauses apply to your software?

Clause 4.3 assigns a safety class to the software system and to each software item inside it.

IEC 62304 software safety classes A, B and C, defined by the harm the software system can contribute to after external risk controls.

Class	The software system, once risk controls outside it are accounted for
A	Cannot contribute to a hazardous situation, or contributes to one that does not result in unacceptable risk
B	Contributes to a hazardous situation that results in unacceptable risk, and the possible harm is non-serious injury
C	Contributes to a hazardous situation that results in unacceptable risk, and the possible harm is death or serious injury

Amendment 1 rewrote these criteria in 2015, and the rewrite is easy to miss because the letters did not change. In the 2006 edition class A meant no injury or damage to health was possible at all. In Edition 1.1 the test is whether the residual risk is acceptable once risk controls outside the software are taken into account, which is a materially wider gate. Anything published against the older wording classifies more software into B and C than the current text does.

4.3 also allows a system initially classified B or C to be reclassified after additional external risk controls are put in place, including a revision of the architecture around it. A hardware interlock that makes the remaining risk acceptable can move an item down. Figure 3 is the decision path.

The class assignments are made in the clause text, not in the summary table most readers reach for. Clause 1.4 says the classes assigned to each requirement are identified in the normative text following it. Table A.1, "Summary of requirements by software safety class", collects them in Annex A, which is titled informative, so it restates the assignments rather than making them. Read from the markers in the clause text:

IEC 62304 requirements by software safety class, showing which clauses from 5.1.12 to 5.8.1 bind at class A, B or C.

Requirement	Clause	A	B	C
Identification and avoidance of common software defects	5.1.12	no	yes	yes
Identify segregation necessary for risk control	5.3.5	no	no	yes
Subdivide software into units	5.4.1	no	yes	yes
Detailed design for each unit and for interfaces	5.4.2, 5.4.3	no	no	yes
Establish a unit verification process	5.5.2	no	yes	yes
Verify software integration	5.6.2	no	yes	yes
Evaluate integration test procedures	5.6.5	no	yes	yes
Software system testing, all five subclauses	5.7.1 to 5.7.5	yes	yes	yes
Verification complete and evaluated before release	5.8.1	yes	yes	yes

Two consequences follow for a test plan. Class A software still needs system testing, and in Edition 1.1 that is explicit rather than inferred: Amendment 1 moved 5.7.1, 5.7.2 and 5.7.3 from class B and C into class A as well, and wrote 5.7.4 and 5.7.5 to bind at every class. Under the 2006 edition they did not. Class B is where unit verification, integration verification and the detailed design of the subdivision become records an auditor can ask for, and that is usually where the test effort on a project changes shape.

If you are working out which of these apply to a product you are building now, the validation scope estimate walks the same decision points.

What does IEC 62304 leave out?

Clause 1.2, Field of application, says the standard "does not cover validation and final release of the medical device, even when the medical device consists entirely of software".

That sentence decides what a 62304 package can be used for. It is evidence about the software life cycle. It is not evidence that the device is safe and effective in clinical use. Device level validation, clinical evaluation and usability engineering sit in other standards and other files. A submission built only from 62304 records has a gap, and the gap is found by a reviewer rather than by the team.

The standard's regulatory standing has the same shape, and it differs by market. FDA recognises it as a consensus standard in full, under recognition number 13-79, with no transition date. The EU does not: EN 62304 appears nowhere in the lists of harmonised standards published under the MDR or the IVDR, so conformity with it carries no presumption of conformity with any general safety and performance requirement. It was harmonised under the superseded Directive 93/42/EEC, and there only as EN 62304:2006 with its 2008 corrigendum, never the amended text. Notified bodies still expect the standard as state of the art, which is an argument you make rather than a presumption you cite.

The neighbouring question, which standard covers the quality system that produced those records, is answered in IEC 62304 compared with ISO 13485.

What happens to third party code?

The standard calls it SOUP, software of unknown provenance. clause 5.3 requires functional and performance requirements for each SOUP item, plus the hardware and software that item needs in order to work. clause 7.1 requires you to evaluate published anomaly lists for SOUP and decide which of the known defects could contribute to a hazardous situation in your device.

A dependency list generated from a package manifest does not satisfy this. It has no versions pinned to an anomaly source and no record of the decision made about each anomaly. Testing SOUP components covers how to build the inventory and what evidence to attach to each entry.

What about code written before the standard applied?

clause 4.4, added by Amendment 1, covers legacy software. It lets you use risk management activities and objective evidence from field use in place of development records that were never produced. It asks for a gap analysis against the deliverables the standard expects, a plan to close the gaps that matter, and a written rationale for continuing to use the software.

This is the clause that decides whether a rewrite is necessary. Teams reach for one because they assume the standard demands documents they cannot recreate. Often the field history they already have is admissible.

Where does an IEC 62304 audit go wrong?

• Test records name a feature rather than a requirement, so traceability has to be reconstructed under time pressure during the audit.
• The classification is written once at kickoff and never revisited, although the architecture changed twice since.
• Regression evidence exists for the release that shipped and not for the patches that followed it, which is a clause 6 finding rather than a clause 5 one.
• The SOUP list has versions and no anomaly evaluation.
• Problem reports are closed without the verification clause 9.7 asks for.

What do we run against IEC 62304?

We work from the classification outward: confirm the class per software item, derive the clause set that binds, then build the test suite and the record structure that produce evidence for that set. The output is the artefact list above, in a form an auditor reads without a guided tour.

The work itself is described in medical device software testing, and the record side of it in validation documentation. For products that ship on a release train, regression testing in a regulated environment covers how to keep clause 6 evidence current without rerunning everything.

Clause numbers and titles on this page were checked against the IEC catalogue entry for IEC 62304:2006+AMD1:2015 CSV.