IEC 62304 vs ISO 13485: How the Two Standards Fit Together (Clause-by-Clause, 2026)

The IEC 62304 vs ISO 13485 question is usually asked the wrong way round. They are not alternatives. ISO 13485 is the quality management system a medical device manufacturer runs; IEC 62304 is the software life cycle that runs inside it. The standard says so in its first general requirement, and its Annex D is a checklist for slotting each software activity into the QMS clause it belongs to.

What makes the relationship awkward in practice is that IEC 62304’s own cross-reference points at ISO 13485:2003. The current edition is 2016, and it renumbered the design and development clause. This guide sets out the IEC 62304 vs ISO 13485 relationship as it actually stands today, clause by clause.

What this guide covers

• IEC 62304 vs ISO 13485: the short answer
• IEC 62304 vs ISO 13485: what the software standard leaves to the QMS — on purpose
• IEC 62304 vs ISO 13485 clause by clause — using the 2016 numbering
• Where the IEC 62304 vs ISO 13485 line blurs: SOUP, tools and validation
• IEC 62304 vs ISO 13485 on risk management: ISO 14971 sits between them
• IEC 62304 vs ISO 13485 on certification and regulators
• IEC 62304 vs ISO 13485: which do you need first?
• Frequently asked questions

IEC 62304 vs ISO 13485: the short answer

So the IEC 62304 vs ISO 13485 comparison is really a division of labour. One says have controlled design and development, with records; the other says here is what controlled software development consists of.

IEC 62304 vs ISO 13485: what the software standard leaves to the QMS — on purpose

The IEC 62304 vs ISO 13485 split is deliberate. Annex B.4.1 of IEC 62304 explains that a disciplined set of software processes includes organisational processes — management, infrastructure, improvement, training — and that these were omitted from the standard to avoid duplication and keep it focused on software engineering. They are expected to come from the quality management system.

That is why clause 4.1 asks the manufacturer to demonstrate the ability to provide software that consistently meets customer and regulatory requirements, and why its note lists ISO 13485 as one way to do so — alongside a national QMS standard or a QMS required by national regulation. IEC 62304 does not require the QMS to be certified; Annex D.2 says so explicitly. It requires it to exist.

The consequence for anyone weighing IEC 62304 vs ISO 13485: a software team that treats IEC 62304 as its whole quality system has no management review, no competence process, no CAPA and no internal audit. Those live in ISO 13485, and an assessor expects to find them there.

IEC 62304 vs ISO 13485 clause by clause — using the 2016 numbering

IEC 62304’s Annex C, Table C.1, relates its clauses to ISO 13485:2003. In that edition, design and development planning was 7.3.1. ISO 13485:2016 inserted a “General” sub-clause at 7.3.1, so planning became 7.3.2 and every later sub-clause shifted by one; it also added 7.3.8 on design and development transfer and 7.3.10 on design and development files, and split identification and traceability into 7.5.8 and 7.5.9. Transcribe Annex C and you cite clauses that no longer mean what you think.

Read the table one way and it shows ISO 13485 as the frame that every IEC 62304 activity fits into. Read it the other way and it shows how much of ISO 13485’s design control section a software team can evidence with records it was going to produce anyway.

Where the IEC 62304 vs ISO 13485 line blurs: SOUP, tools and validation

SOUP and purchasing

Off-the-shelf software — SOUP, in IEC 62304’s term — is a purchased product for ISO 13485 clause 7.4 purposes where it is procured, and even open-source components benefit from the same evaluation logic. IEC 62304 adds what the QMS does not: the requirement to identify every SOUP item by title, manufacturer and unique designator at every class, and at Class B and C to specify what you need from it and evaluate its published anomaly lists.

Development tools

ISO 13485 clause 4.1.6 requires validation of software used in the QMS, and 7.5.6 covers software used in production. Whether a compiler or a static analyser falls under either is a judgement; IEC 62304’s own answer is clause 5.1.4, which for Class C items requires the development plan to state the standards, methods and tools used, and 5.1.10, which for Class B and C brings tools and settings that could affect the software under configuration control.

Validation

This is the boundary most often misdrawn in IEC 62304 vs ISO 13485 discussions. IEC 62304 verifies software against its requirements and releases it for use at system level. It does not validate the device — clause 1.2 excludes that even when the device is entirely software. Validation is ISO 13485 clause 7.3.7, performed at device level, and for software-only products IEC 82304-1 supplies the product-level requirements.

IEC 62304 vs ISO 13485 on risk management: ISO 14971 sits between them

Both sides of the IEC 62304 vs ISO 13485 pair lean on ISO 14971. ISO 13485 clause 7.1 requires risk management to be documented throughout product realisation; IEC 62304 clause 4.2 requires an ISO 14971 process and its clause 7 adds the software-specific activities — identifying software items that could contribute to hazardous situations, their causes, risk controls, verification and traceability. Those outputs are required to sit in the risk management file, not in a separate software folder.

Our IEC 62304 risk management guide walks clause 7 step by step. Our guide to ISO 14971 covers the file itself; the software safety classification is the point where the two meet, because the class is decided on the device risk analysis.

IEC 62304 vs ISO 13485 on certification and regulators

ISO 13485 is a certifiable standard: a certification body audits the QMS and issues a certificate. IEC 62304 is not certified in that sense. Clause 1.4 says compliance is determined by inspecting the documentation the standard requires — including the risk management file — and assessing the processes, and that this can be done by internal or external audit. In practice a notified body or FDA reviewer inspects the software file as part of the device’s conformity assessment.

Here the two part company in Europe. EN ISO 13485:2016 is a harmonised standard under the MDR; EN 62304:2006/A1:2015 is not — it was harmonised under the former Directive and does not appear on the Commission’s MDR or IVDR lists, so notified bodies expect it as the state of the art rather than as a presumption of conformity (see our guide to MDR harmonised standards).

Both matter in the US: FDA recognises IEC 62304 as a consensus standard, and the Quality Management System Regulation in 21 CFR Part 820, effective 2 February 2026, incorporates ISO 13485:2016 by reference. The QMSR vs ISO 13485 comparison covers what FDA added on top, and our IEC 62304 FDA guidance guide maps the software submission elements.

IEC 62304 vs ISO 13485: which do you need first?

The IEC 62304 vs ISO 13485 sequencing question has a plain answer. If you are a device manufacturer starting from nothing: ISO 13485 first, because IEC 62304 assumes it exists and cannot stand alone. If you already hold ISO 13485 and are adding software: IEC 62304 next, integrated into the design controls you already run rather than bolted alongside them. If you are a software company entering medical devices: both, and the honest sequencing is a QMS scoped to what you do, with IEC 62304 as the design and development content of it.

The IEC 62304 Toolkit is built on that assumption. It carries an interfaces document naming every hand-off between the software life cycle and the QMS, a mapping to ISO 13485:2016 clause 7.3 written from the requirements’ intent rather than transcribed from the 2003 annex, and a small-company checklist in the shape of the standard’s Annex D — renumbered to the 2016 edition. ISO 13485:2016 itself is published by ISO.

Frequently asked questions

Do I need ISO 13485 certification to comply with IEC 62304?

No. IEC 62304 requires a quality management system to exist and names ISO 13485 as one route; Annex D.2 says certification is not required. Regulators in most markets require a QMS in any case, and certification is the usual way to evidence it in the EU.

In the IEC 62304 vs ISO 13485 pair, does ISO 13485 cover software development on its own?

Only at the level of generic design controls. It requires planned, reviewed, verified and validated design with records, and it requires software validation where software is used in the QMS or production. It does not say what a software life cycle consists of; IEC 62304 does.

Which edition of ISO 13485 does IEC 62304 map to?

The standard’s own Annex C maps to ISO 13485:2003. The current edition is 2016, which renumbered clause 7.3 — planning moved from 7.3.1 to 7.3.2 and later sub-clauses shifted by one. Map from the requirements’ intent to the 2016 edition rather than transcribing the annex.

Is IEC 62304 vs ISO 13485 the same question as IEC 62304 vs IEC 82304-1?

No. ISO 13485 supplies the management system around the software life cycle. IEC 82304-1 supplies the product-level requirements — use requirements, validation, accompanying documents — for software-only products, which IEC 62304 stops short of. A software-only medical device typically needs all three.