IEC 62304 vs ISO 13485

Which of the two does a regulator actually open?

Different regulators, different documents, and the split is clean enough to plan a budget around. ISO 13485 is the one an assessor is sent to look at. IEC 62304 is the one a reviewer reads in a file you submitted.

In the EU, MDR article 52(6) puts a class IIa device through Chapters I and III of Annex IX, including assessment of the technical documentation under Section 4 of that Annex for at least one representative device for each category of devices. article 52(4) does the same for class IIb, sampling at least one representative device per generic device group. A class I device is self-declared under article 52(7), with no notified body unless it is sterile, has a measuring function or is a reusable surgical instrument. Two consequences follow for a software company. The quality system is assessed in full, and the per-product evidence is assessed on a sample, which is why a company can pass an assessment with product files that would not survive being the sample next time. Which class your software lands in is decided by Rule 11, covered on the EU MDR software requirements page.

In the United States the two standards meet different parts of FDA. IEC 62304 is a recognised consensus standard, recognition number 13-79 on list 051, entered on 14 January 2019, with the extent of recognition given as "Complete standard". Recognition is a premarket instrument: it tells a reviewer what a declaration of conformity in a submission is worth. An investigator arriving at your site works from 21 CFR part 820, which since 2 February 2026 incorporates ISO 13485:2016(E) by reference and is titled the Quality Management System Regulation. No inspection citation names IEC 62304.

What does an ISO 13485 certificate say about the software you ship?

Nothing about its lifecycle, and the reason is a list. Entry 10 of the Annex to Commission Implementing Decision (EU) 2021/1182, in the version consolidated to 7 April 2026, is EN ISO 13485:2016 together with EN ISO 13485:2016/AC:2018 and EN ISO 13485:2016/A11:2021. MDR article 8(1) gives conformity with a listed standard a presumption of conformity, and its second subparagraph extends that presumption to process requirements including those relating to quality management systems. So the certificate buys a legal presumption, and the presumption stops at the boundary of what the standard covers.

That Annex runs to 51 numbered entries with no gaps, and not one of them is a software standard. Searching the whole Decision for "62304", "82304", "62366" and the word "software" returns no match. Applying IEC 62304 therefore confers no presumption of conformity with GSPR 17.2, the software lifecycle requirement in Annex I. A notified body still expects the standard, as state of the art rather than as a presumption you can cite, which means the argument is yours to make each time. The standing of the standard by market is set out on the IEC 62304 software testing requirements page.

There is a second and more expensive misreading of the certificate. ISO 13485 does have software validation clauses, and they point at the software you run rather than the software you sell. FDA's computer software assurance guidance cites that requirement as subclauses 4.1.6, 7.5.6 and 7.6 of ISO 13485, and then states in its own scope that it "does not provide recommendations for the design and development verification or validation requirements for device software functions". The guidance also sorts development tools that test or monitor software systems, or that automate testing activities, into the supporting bucket, which still has to be validated under those clauses. Your test automation framework is an ISO 13485 obligation. The product it exercises is an IEC 62304 obligation. Both are priced, and teams routinely budget for one. FDA computer software assurance covers how much effort the tooling side justifies.

What breaks when you have the quality system and no lifecycle records?

The technical documentation fails on one indent. Annex II Section 6.1(b) of the MDR asks, in its fourth indent, for software verification and validation describing the software design and development process and evidence of the validation of the software as used in the finished device, typically including the summary results of all verification, validation and testing performed both in-house and in a simulated or actual user environment before final release, and addressing all the different hardware configurations and, where applicable, operating systems named in the information supplied by the manufacturer.

Three obligations sit in that indent, and a certified quality system satisfies none of them by itself: a process description, results from before release, and coverage across every configuration you claim. A company that has run its software work outside any lifecycle standard has to reconstruct all three from whatever its pipeline happened to keep. What a pipeline can and cannot be made to keep is the subject of CI/CD for medical device software.

On the US side the same gap surfaces in a submission instead of an audit, and it surfaces per product. The shape of the package a reviewer expects is set out under the software documentation a 510(k) has to contain.

What breaks when you have the lifecycle records and no quality system?

IEC 62304 stops working, because it was written to sit inside one. Its introduction states that the standard assumes device software is developed and maintained within a quality management system and a risk management system, and clause 4.1, Quality management system is the first clause of the standard's general requirements. clause 1.4, Compliance then defines compliance as implementing all the processes, activities and tasks the standard identifies in accordance with the assigned software safety class, determined by inspection of all required documentation including the risk management file and by assessment of those processes.

A folder of test reports with no procedure behind it fails that definition on the process half. There is no route by which complete software records substitute for the system that was supposed to produce them, and the dependency runs one way. Introduction 0.1 of ISO 13485 offers the standard to any organisation involved in one or more stages of the device life-cycle, including suppliers of associated services, so it can be certified with no device code in the building. IEC 62304 cannot be demonstrated without a documented process. Which clauses of the quality standard reach software at all is set out on the ISO 13485 software validation page.

Which of the two can you not start late?

IEC 62304, and the reason is in one subclause. clause 5.7.5, Software system test record contents requires seven items in every system test record: a reference to the test case procedures with the required actions and expected results, the result as pass or fail with a list of anomalies, the version of the software tested, the relevant hardware and software test configurations, the relevant test tools, the date tested, and the identity of the person who executed the test and recorded the result. Amendment 1 made all five subclauses of 5.7 bind at class A as well, so no classification argument removes this record. Five of the seven items describe one particular run: the version, the configuration, the tools, the date and the person. A record written two years afterwards either describes a rerun on a build nobody ships any more, or it is wrong.

ISO 13485's own Contents carries no equivalent of 4.4. Its structure is eight clauses describing a system that exists now, and the sequence a company follows is to build the system and then have it assessed. The releases you make before the quality system is certified are not thrown away by that order. The releases you make before the software test records carry a version and a date are.

What changes in your testing, on each side?

How IEC 62304 and ISO 13485 each answer five testing questions: scope, test record contents, traceability, test tooling and who reads the evidence.

Question	Answered by IEC 62304	Answered by ISO 13485
Which software is in scope	The software system in the device, and each software item inside it, at its assigned safety class	Software used in the quality system, in production and service provision, and in monitoring and measurement
What a test record has to contain	The seven items of 5.7.5, at every class including A	Whatever your own procedures define, controlled under 4.2.4 and 4.2.5
Whether traceability is explicit	Yes. 5.7.4 requires the traceability between software requirements and tests to be recorded, at every class	Not as a testing requirement in anything readable. 7.3.10 is titled Design and development files, and its text sits behind ISO's paywall
What the test tooling counts as	Out of scope of the product lifecycle	In scope, as software supporting the quality system
When the evidence is read	By a reviewer, per product, in a submission or a technical file	By an auditor, per company, on a cycle

The traceability row is the one that changes a test plan first. Recorded traceability between requirements and tests at class A means the requirement identifier belongs in the test case from the first sprint. A matrix assembled afterwards is a reconstruction, and it reads like one. Holding the two evidence sets in one indexed package, so that neither the auditor's copy nor the reviewer's copy has to be assembled twice, is validation documentation.

One row has a practical consequence for who runs the tests. clause 5.7.5 requires the record to name the hardware and software test configurations, which turns the contents of your test environment into an auditable fact. Whatever data sits in that environment gets written into a record a notified body may read. We do not need production PHI to test. Environments run on synthetic and de-identified data. Where a test genuinely needs a real-world shape, the route to it is agreed in writing before an environment exists, and that answer sits with the rest of the environment terms at how we work with protected health information.

Sources for this page. The IEC 62304 clause numbers, titles, class markers and the contents of 5.7.5, 4.4 and definition 3.36 are read in Edition 1.1, the 2006 first edition consolidated with Amendment 1, checked against IEC's own preview on 2 September 2026. The ISO 13485 clause numbers and titles come from the Contents pages of ISO's published preview of the 2016 third edition, and the FDA incorporation from the codified text of 21 CFR part 820. The MDR article and annex numbers, and the 51 entries of the harmonised standards list, come from the consolidated text of Regulation (EU) 2017/745 as at 1 January 2026 and Commission Implementing Decision (EU) 2021/1182 as at 7 April 2026. The scope and bucket wording of the computer software assurance guidance comes from the version issued on 3 February 2026.