IEC 62304 is a process standard, and its output is a defined set of documents – plans, specifications, test records, registers. That is exactly what an assessor asks to see, which is why medical device software documentation is the deliverable rather than a by-product.
On this page:
- The class decides what you owe, and 57 is the number Class A teams get wrong
- What is inside the medical device software documentation pack
- Agile is fine. Undefined is not.
- Who the medical device software documentation pack is written for
- What the medical device software documentation pack does not do
- Frequently asked questions
- Related toolkits
The class decides what you owe, and 57 is the number Class A teams get wrong
Compliance means performing the processes, activities and tasks required for the software safety class – A, B or C – decided on the worst-case harm the software could contribute to after risk controls outside the software are credited. Class C owes all 98 requirements. Class B owes 92. Class A owes 57.
Class A is not exempt, and 57 is the number most Class A teams get wrong. It still owes a development plan, requirements analysis with verification, unit implementation, all of system testing, most of release, all of maintenance, all of configuration management including SOUP identification, all of problem resolution, and the analysis of every change for new causes. We are Class A so this does not apply is the sentence that ends badly at a notified body audit.
Every per-system template marks the sections that apply only to Class B and C, or only to Class C. Three workbooks – the requirements register, the classification tool and the gap assessment – carry the class in one settings cell, and every Applies at this class column recalculates from it. That is what makes this medical device software documentation usable across a portfolio with mixed classes.
What is inside the medical device software documentation pack
97 editable templates covering clauses 4 to 9, with three workbooks shipping loaded with all 98 requirements.
- Clause 4 general requirements – the quality system interface, risk management interface and the software safety classification itself.
- Clause 5 development – the development plan, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and system testing, and release.
- Clause 6 maintenance – the maintenance plan, problem and modification analysis, and modification implementation.
- Clause 7 risk management – the software contribution to hazardous situations, risk control measures and their verification, and traceability.
- Clause 8 configuration management – configuration identification, change control and configuration status accounting.
- Clause 9 problem resolution – the process, the records and the change analysis.
- SOUP – identification, specification, verification and monitoring, handled at every class rather than only at C.
- Legacy software – the Amendment 1 route, which is a different path rather than a retrofit of the full lifecycle.
- Three pre-loaded workbooks – requirements register, classification tool and gap assessment, all keyed to a single class setting.
Agile is fine. Undefined is not.
The standard does not mandate a lifecycle model, and it does not prohibit iterative development. What it requires is that the activities are performed and the records exist. A team running two-week iterations can satisfy every requirement; a team with no defined process cannot, regardless of methodology.
The documents here are written so that the artifacts map onto sprint outputs rather than onto a waterfall gate review – the development plan describes the process you actually run, and the traceability is maintained continuously rather than reconstructed for an audit. SOUP is handled at every class, because SOUP identification and problem monitoring are Class A obligations too.
Legacy software has its own route. Amendment 1 introduced it precisely because retro-fitting the full lifecycle onto software that already exists is neither required nor sensible, and this medical device software documentation follows that route rather than pretending the history can be rewritten.
Who the medical device software documentation pack is written for
- Manufacturers of software as a medical device, and of devices containing software, at any safety class.
- Software teams inside device companies who have been handed a 62304 obligation.
- Regulatory and quality functions preparing for a notified body audit or an FDA submission.
- Organisations with legacy software that needs a defensible route rather than a rewrite.
What the medical device software documentation pack does not do
It is not a quality management system. ISO 13485 clause 7.3 sits above it and is sold separately.
It does not perform your risk management. ISO 14971 is the risk standard and the interface is documented here rather than duplicated.
It does not write your software requirements. It supplies the structure, the templates and the traceability; the content is yours.
Frequently asked questions
Which edition is this written against?
IEC 62304:2006 + Amendment 1:2015, Edition 1.1 – the edition in force. Edition 2 has been in development for years, a second draft followed in 2026, and publication is not expected before 2028 with a regulatory transition after that.
We are Class A. Do we need all of this?
You owe 57 of the 98 requirements, and the workbooks filter to exactly those from a single class setting. Class A is not exempt.
Is IEC 62304 harmonised under the EU MDR?
Checkably, it is not on the Commission list. Notified bodies nonetheless expect it as the state of the art, and the pack states the position rather than overclaiming.
What formats are the files in?
Native Microsoft Word and Excel, fully editable, with placeholders marked throughout.
Related toolkits
It sits under the ISO 13485 toolkit and beside the ISO 14971 toolkit for the risk management file. Manufacturers placing devices on the EU market also need the EU MDR toolkit. IEC publishes the standard at webstore.iec.ch.
Implementing for clients? The Consultant Package licenses all 86 toolkits and assessment tools on this site for unlimited client engagements, under one firm-wide licence. One payment of $1,399, no subscription and no per-client fee.
Delivery, format and licence
The medical device software documentation pack downloads immediately after checkout as native Microsoft Word and Excel files. Nothing is locked, nothing is a PDF you cannot edit, and no add-on or portal login is needed to open it. Every organisation-specific value is marked as a placeholder so you can see what still has to be decided.
One payment, no subscription and no annual renewal. The source files behind the medical device software documentation pack are yours to adapt for your own organisation for as long as you need them, including future revisions of your own documents.
Reviews
There are no reviews yet.