IEC 62304 Documentation Requirements: Every Deliverable by Class (Clear 2026 Guide)

IEC 62304 documentation requirements are not listed anywhere in the standard as a single table — which is why the same question arrives in every audit and every project kick-off: what, exactly, do we have to produce? The answer is scattered through clauses 4 to 9 as the deliverables of individual activities, and it depends on the software safety class. This guide pulls it together: the documents the standard names or plainly implies, the class at which each is required, and the rule that governs anything you decide to leave out.

What this guide covers

• Where IEC 62304 documentation requirements come from
• IEC 62304 documentation requirements by activity and class
• IEC 62304 documentation requirements for record content
• The “as appropriate” rule in IEC 62304 documentation requirements
• Where the IEC 62304 documentation requirements are filed
• Legacy software has a shorter list
• Meeting IEC 62304 documentation requirements without drowning in them
• Frequently asked questions

Where IEC 62304 documentation requirements come from

Three clauses set the frame. Clause 1.4 defines compliance as implementing all the processes, activities and tasks identified in the standard for the software safety class, and says compliance is determined by inspection of all documentation required by the standard, including the risk management file, plus assessment of the processes. Clause 5.1.8 requires the development plan to include or reference, for every document the life cycle will produce, its title or naming convention, its purpose, and the procedures and responsibilities for its development, review, approval and modification. And Annex D, the standard’s own implementation guidance, maps each activity to the quality system clause its records belong in.

So the IEC 62304 documentation requirements are the deliverables of the required activities, planned in advance, controlled as configuration items, and filed where an assessor can inspect them. The standard does not prescribe document titles or formats — it prescribes content and the fact of existence.

IEC 62304 documentation requirements by activity and class

The table lists the deliverables the standard names or requires by clear implication, with the class at which each is required. Counts follow Table A.1 of the standard; our guide to software safety classification explains the 57 / 92 / 98 split.

Read the Class A column and the point of the IEC 62304 documentation requirements becomes visible: a Class A file is smaller than a Class C file, but it is not small. Plans, requirements, system tests, release records, maintenance, configuration management and problem resolution are all there.

IEC 62304 documentation requirements for record content

Several IEC 62304 documentation requirements specify content, not just existence. The ones assessors check line by line:

• The development plan (5.1.1) — the life cycle model, defined or referenced; the processes; the deliverables; traceability between system requirements, software requirements, system tests and software risk controls; configuration and change management including SOUP and development-support software; and problem resolution at every stage.
• The software requirements (5.2.2) — twelve content areas as appropriate: function and capability, inputs and outputs, external interfaces, software-driven alarms and messages, security, user interface, data and database, installation and acceptance, operation and maintenance, IT-network aspects, user maintenance, regulatory.
• System test records (5.7.5) — seven items: a reference to the test procedure, the result with anomalies, the software version, the hardware and software configuration, the tools, the date, and the person responsible.
• Integration test records (5.6.7) — pass/fail with anomalies, enough to repeat the test, and the tester.
• Post-change test documentation (9.8) — results, anomalies, version, configuration, tools, date, tester.
• SOUP identification (8.1.2) — title, manufacturer and unique designator for every item including standard libraries. Our guide to SOUP under IEC 62304 covers the rest.
• The maintenance plan (6.1) — six items, from feedback procedures to SOUP obsolescence.

The “as appropriate” rule in IEC 62304 documentation requirements

Many IEC 62304 documentation requirements are qualified “as appropriate” — the twelve requirements content areas, the eight extra unit acceptance criteria, the five categories of potential cause. That is not a licence to skip. Clause 1.4 note 3 says that where a requirement contains “as appropriate” and was not performed, documentation for the justification is necessary for the compliance assessment. An undocumented omission is a gap; a documented one is a decision. The practical habit is a line in the relevant document — “content area k) user maintenance: not applicable, no user-maintainable elements” — rather than a silent blank.

Where the IEC 62304 documentation requirements are filed

Two files hold the outputs of the IEC 62304 documentation requirements between them, and the standard is specific about which.

Keeping software risk records in a separate software folder is one of the commonest findings. The standard requires them in the risk management file, or referenced from it, and our IEC 62304 vs ISO 13485 guide covers how the development file fits the QMS.

Legacy software has a shorter list

For software already on the market without full evidence, clause 4.4 scopes the IEC 62304 documentation requirements to a gap analysis against 5.2, 5.3, 5.7 and clause 7 only, with system test records as the minimum deliverable and a documented rationale for continued use as the output. Our guide to legacy software covers the route.

Meeting IEC 62304 documentation requirements without drowning in them

• Plan the documents first. The documentation plan of 5.1.8 is the contents list; write it before the first specification, not after the last test.
• Mark class applicability on every template. A Class A team should be able to see which sections it may leave blank, and record that it did so because of class.
• Generate registers from one source. The requirements register, traceability matrix and audit checklist drift apart when typed separately; derive them from one requirements list.
• Keep an index. A software development file index — every deliverable, its version, its location and whether it was required at the class — is the document an assessor opens first.
• Write the omission, not the silence. Every “as appropriate” decision gets a sentence.

The IEC 62304 Toolkit is built as exactly that file: 97 templates covering the deliverables above across the standard’s clauses, each marked with the classes it applies to; a requirements register pre-loaded with all 98 requirements that filters to 57, 92 or 98 rows from one settings cell; a software development file index; and a compliance statement for the technical file. The standard is licensed by the IEC; the requirements here are paraphrased from it.

Frequently asked questions

Does IEC 62304 prescribe document titles or templates?

No. It prescribes activities, the content of certain records, and the documentation planning that names each document’s title, purpose and control procedures. The titles and formats are the manufacturer’s.

How many documents do the IEC 62304 documentation requirements amount to?

There is no fixed number; the standard names deliverables, not files, and one file can carry several. A complete Class C set typically runs to several dozen distinct records across planning, requirements, design, verification, release, maintenance, risk, configuration management and problem resolution. Class A drops architecture, detailed design, integration and most of clause 7.

Can one document satisfy several IEC 62304 documentation requirements?

Yes. The standard explicitly allows the development plan to include the supporting plans rather than reference them, and allows integration and system testing to share one plan and one set of activities. What matters is that each required content item exists and can be found.

Do the documents have to be in the risk management file?

Only the risk-related ones — the class, potential causes, risk control measures, their verification and the traceability between them, plus problem-report updates. Those are required in, or referenced from, the ISO 14971 file. The rest belongs in the software development file.