ISO 45001 Assessment Tool - Ultimate Solution
1 × $19.00 
QHSE Documentation Bundles - Comprehensive 1,395 Templates
1 × $199.00 
ISO 27001 Toolkit - 165 Comprehensive Templates
1 × $99.00 Subtotal: $317.00
The IEC 62304 Toolkit delivers 97 ready-to-use Microsoft Office templates for medical device software — 84 Word documents and 13 Excel workbooks covering every one of the 98 requirements in IEC 62304:2006+AMD1:2015 (Edition 1.1), the edition in force, applied as the state of the art under the EU MDR and recognised by FDA. Seventeen sections follow the standard’s own clauses, from software safety classification to problem resolution. Every document marks the classes it applies to, three workbooks filter all 98 requirements to your class — 57 at Class A, 92 at B, 98 at C — and the mappings are to ISO 13485:2016, ISO 14971:2019, IEC 82304-1, IEC 81001-5-1, FDA’s 2023 software guidance and EU MDR Annex I and II.
$99.00
✓ In stock — instant download after checkout
IEC 62304 is the standard every regulator points at for medical device software. Notified bodies expect it as the state of the art the EU MDR and IVDR require for software — although, checkably, it is not on the Commission’s list of harmonised standards under either regulation — FDA recognises it as a consensus standard, and it is the software life cycle ISO 13485 clause 7.3 expects to find under a device. It is also a process standard: its output is a defined set of documents — plans, specifications, test records, registers — and that is exactly what an assessor asks to see.
The IEC 62304 Toolkit is written against IEC 62304:2006 + Amendment 1:2015, Edition 1.1 — the edition in force — and it covers all 98 of its numbered requirements across clauses 4 to 9.
Compliance with IEC 62304 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. Every requirement in the standard carries a class tag, and the IEC 62304 Toolkit carries them too:
| Software safety class | Requirements that apply | What a lower class may leave out |
|---|---|---|
| Class C — death or serious injury possible | 98 | Nothing |
| Class B — non-serious injury possible | 92 | Class C standards and tools planning, segregation design, detailed unit and interface design, the eight extra unit acceptance criteria |
| Class A — no injury possible | 57 | Architecture, detailed design, integration testing, the clause 7.1–7.3 risk activities and a handful of planning items |
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.
The number most Class A teams get wrong is 57. Class A is not exempt. 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. The IEC 62304 Toolkit says so on the page, in the deployment guide and in the register, because “we are Class A so this does not apply” is the sentence that ends badly at a notified body audit.
Edition 2 of IEC 62304 has been in development for a long time. A Committee Draft circulated in 2025 and drew a very large number of comments; a second draft followed in 2026; publication is not expected before 2028, with a regulatory transition of two to three years after that.
Until then, and through the transition, Edition 1.1 is the edition a compliance claim is made against. Nothing in the IEC 62304 Toolkit cites Edition 2 content as a requirement, and a Regulatory Currency Supplement records the status of Edition 2, the harmonisation and FDA recognition position, and the date each was checked.
Annex C of IEC 62304 cross-references four other standards, and every one is superseded:
Transcribe Annex C and you ship clause numbers that no longer exist. The IEC 62304 Toolkit maps from the requirements’ intent to ISO 13485:2016 and ISO 14971:2019, and adds four mappings the standard predates entirely: IEC 82304-1 for software-only products, IEC 81001-5-1 for cybersecurity, FDA’s June 2023 software guidance at Basic and Enhanced documentation level with the QMSR, and EU MDR Annex I and Annex II. Every mapped row carries a confidence rating, because a mapping is an interpretation and saying so is what makes it usable.
It is for the manufacturer — the organisation that develops or maintains software that is a medical device in its own right, or is embedded in one, at any class. Software-only products, embedded firmware, mobile apps, cloud back-ends that are part of a device: the life cycle is the same.
It is not a QMS pack. IEC 62304 assumes a quality management system exists and plugs into it. If you need the QMS itself, that is the ISO 13485 Toolkit; this pack maps every hand-off to it.
It is not a device validation pack — the standard excludes validation and final release of the device, and so does this toolkit. And it is not a full cybersecurity process — it carries the security requirements the standard demands and shows how IEC 81001-5-1 layers on top, but a threat model and a security test plan are that standard’s deliverables, not this one’s.
Software of unknown provenance — operating systems, runtimes, libraries, frameworks, drivers, the language’s own standard library, and every transitive dependency — is the part of a medical device the manufacturer did not write and is still responsible for. The standard requires every SOUP item to be identified by title, manufacturer and unique designator at every class, including Class A, and the maintenance plan to address SOUP upgrades, patches and obsolescence.
At Class B and C it also requires the functional and performance requirements each item must meet, the hardware and software it needs, and an evaluation of the supplier’s published anomaly lists.
The IEC 62304 Toolkit carries a SOUP register built for that, a SOUP requirements specification, an anomaly-list evaluation procedure, and a maintenance plan with a SOUP obsolescence table — and a reconciliation step that checks the register against what is actually in the build at every baseline, because an item in the build and not in the register is the commonest SOUP finding.
Amendment 1 added clause 4.4 for software that was legally placed on the market before the current edition and lacks full life cycle evidence. Instead of reconstructing a development that already happened, you review post-production feedback, do risk management on continued use, run a gap analysis against the deliverables the class requires — from requirements, architecture, system testing and risk management only — create the missing deliverables that would reduce risk, and document a rationale for continued use. System test records are the one non-negotiable output. The IEC 62304 Toolkit carries the procedure and the record for that route.
The standard names no life cycle model and explicitly allows activities to overlap, iterate and recurse. What it requires is that the model be defined — which activities happen when, the milestones at which deliverables are verified, the release gate. A Life Cycle Model Selection Guide maps clause 5 onto sequential, incremental and agile models and lists the seven things agile teams most often leave undefined, with the fix for each.
| Workbook | What it does |
|---|---|
| Requirements Register and Class Applicability Matrix | All 98 requirements with clause, class applicability, owning document, evidence and status; a summary per clause; the Table A.1 view; a release-ready flag |
| Safety Classification Decision Tool | Walks the class decision per hazardous situation, checks item inheritance and segregation rationale, and filters the requirements to the class assigned |
| Gap Assessment Tool | Scores current practice against every applying requirement and gives a gap percentage per clause with an action plan |
They are generated from one requirements module, so they cannot drift apart from each other or from the documents. The other ten workbooks — traceability matrix with the four hazard links of clause 7.3.3 as separate columns, SOUP register, hazard analysis and risk control register, anomaly register, configuration item register and baseline log, change request register, problem report register with a trend dashboard, verification tracker, released versions register, and the standards and tools register — carry the dropdowns, frozen headers, filters and worked example rows the rest of the catalogue does.
| # | Section | Documents |
|---|---|---|
| 01 | Programme and Governance | 6 |
| 02 | Safety Classification and Legacy Software | 5 |
| 03 | Software Development Planning | 8 |
| 04 | Software Requirements Analysis | 4 |
| 05 | Software Architectural Design | 4 |
| 06 | Software Detailed Design | 3 |
| 07 | Unit Implementation and Verification | 5 |
| 08 | Integration and Integration Testing | 5 |
| 09 | Software System Testing | 5 |
| 10 | Software Release | 6 |
| 11 | Software Maintenance | 6 |
| 12 | Software Risk Management | 7 |
| 13 | Software Configuration Management | 6 |
| 14 | Software Problem Resolution | 5 |
| 15 | Registers and Workbooks | 10 |
| 16 | Compliance Audit and Evidence | 5 |
| 17 | Mapping and Regulatory Currency | 7 |
The IEC 62304 Toolkit is 84 Word documents and 13 Excel workbooks. Sections 02 to 14 are clauses 4.3 to 9 of the standard in order, so the pack is laid out the way an assessor reads the standard. Forty documents are adopted once for the organisation; fifty-seven are instantiated per software system.
Each of the 84 Word documents opens with a Requirements addressed table listing the requirement identifiers it satisfies, the classes each applies to, and what the document provides for it. You can hand any single document to an assessor and they can see immediately what it is for and whether it applies to your class.
All 98 requirements are covered, and the build fails if any one of them is left without a document — which is a check we run, not a claim we make.
| Document | Edition |
|---|---|
| IEC 62304 Medical device software — Software life cycle processes | Ed. 1.1: 2006 + AMD1:2015 (consolidated 2015-06) |
| ISO 14971 Application of risk management to medical devices | 2019 |
| ISO 13485 Medical devices — Quality management systems | 2016 |
| IEC 82304-1 Health software — General requirements for product safety | 2016 |
| IEC 81001-5-1 Health software — Security activities in the product life cycle | 2021 |
| FDA — Content of Premarket Submissions for Device Software Functions | June 2023 |
| 21 CFR Part 820 Quality Management System Regulation | Effective 2 February 2026 |
| Regulation (EU) 2017/745 (MDR) Annex I and Annex II | With MDCG 2019-11, 2019-16, 2020-3 |
Every edition was verified at source when the pack was issued, and the Regulatory Currency Supplement inside the pack records the date and what to re-check.
01 — Programme and Governance (6 documents)
02 — Safety Classification and Legacy Software (5 documents)
03 — Software Development Planning (8 documents)
04 — Software Requirements Analysis (4 documents)
05 — Software Architectural Design (4 documents)
06 — Software Detailed Design (3 documents)
07 — Unit Implementation and Verification (5 documents)
08 — Integration and Integration Testing (5 documents)
09 — Software System Testing (5 documents)
10 — Software Release (6 documents)
11 — Software Maintenance (6 documents)
12 — Software Risk Management (7 documents)
13 — Software Configuration Management (6 documents)
14 — Software Problem Resolution (5 documents)
15 — Registers and Workbooks (10 documents)
16 — Compliance Audit and Evidence (5 documents)
17 — Mapping and Regulatory Currency (7 documents)
The IEC 62304 Toolkit is a set of 97 editable Microsoft Word and Excel templates for medical device software life cycle processes — 84 documents and 13 workbooks across seventeen sections, covering all 98 requirements of IEC 62304:2006+AMD1:2015 (Edition 1.1), with the software safety class carried through every document, and mappings to ISO 13485:2016, ISO 14971:2019, IEC 82304-1, IEC 81001-5-1, FDA’s software guidance and EU MDR.
Edition 1.1 — IEC 62304:2006 with Amendment 1:2015, the edition in force and the edition FDA recognises. Its European version, EN 62304:2006/A1:2015, was harmonised under the former Medical Devices Directive; it is not listed among the harmonised standards under the MDR or IVDR (Commission summary lists generated 17 June 2026) and is applied as the state of the art that MDR Annex I 17.2 requires. Edition 2 is in development but not expected before 2028, followed by a transition period; the pack’s Regulatory Currency Supplement tracks it and nothing in the pack depends on it.
Yes, and you should. IEC 62304 is a licensed standard sold by the IEC and national standards bodies; it is not published free of charge. The IEC 62304 Toolkit cites requirement identifiers — 5.1.1, 7.3.3, 8.1.2 and so on — and states in our own words what each asks for, so you can work with it alongside your licensed copy. It does not reproduce the standard’s text, and no toolkit that respects IEC copyright can.
Yes — 57 of the 98 requirements apply at Class A. That excludes architecture, detailed design, integration testing and most of the clause 7 risk activities, but it includes a development plan, requirements analysis, unit implementation, all of system testing, most of the release gate, all of maintenance, all of configuration management including SOUP identification, all of problem resolution, and the analysis of every change for new causes and needed controls. Set the class to A in the requirements register and it shows you exactly those 57 rows.
On the worst-case hazardous situation the software could contribute to after risk control measures outside the software are credited, with the probability of software failure taken as one. The pack’s Safety Classification Procedure and Decision Tool walk it. It is not the FDA Documentation Level (Basic or Enhanced, decided before any mitigation) and not the MDR device class under Rule 11; the pack keeps all three separate and explains why a Class B system can need Enhanced documentation.
In full, at every class. Identification by title, manufacturer and unique designator; requirements and supporting hardware and software for each item; anomaly-list evaluation; upgrade, patch and obsolescence planning; and a register that is reconciled against the actual build at every baseline. Standard libraries and transitive dependencies are SOUP too, and the pack says so.
No. The legacy software route of clause 4.4 — added by Amendment 1 — lets you demonstrate compliance through a post-production review, risk management on continued use, a scoped gap analysis and a documented rationale, with system test records as the minimum deliverable. The pack carries the procedure and the record.
Yes. The standard requires the life cycle model to be defined, not to be sequential. The Life Cycle Model Selection Guide maps the clause 5 activities onto agile iterations, tells you which milestones and records the standard needs, and lists the seven gaps agile teams most often leave — stories that were never turned into identified requirements, a definition of done that ignores the acceptance criteria, pipeline results that were never retained — with the fix for each.
IEC 62304 assumes a QMS and an ISO 14971 process exist and plugs into them. The pack has a dedicated interfaces document naming every hand-off — which ISO 13485:2016 clause 7.3 control governs each software activity, and which risk management file entry each clause 7 output becomes — plus full mappings to both current editions. If you also hold our ISO 13485 Toolkit or ISO 14971 Toolkit, the hand-offs line up.
Yes. A mapping document takes each documentation element of FDA’s June 2023 guidance — software description, risk management file, requirements, architecture, design specification, development and maintenance practices, testing, version history, unresolved anomalies — and names the toolkit deliverable that supplies it at Basic and Enhanced level. It also covers the section 524B cybersecurity elements through the IEC 81001-5-1 mapping and notes that the QMSR incorporates ISO 13485:2016.
Yes. A mapping covers the software requirements of Annex I — sections 17.1 to 17.4, 14.2(d), 14.5 and 23.4(ab) — and the technical documentation elements of Annex II including 6.1(b) on software verification and validation, and records the accurate position of EN 62304 — expected as state of the art, not listed as a harmonised standard under the MDR — with the wording for a technical file. It reminds you that the MDR device class and the IEC 62304 class are separate determinations.
Microsoft Word (.docx) and Microsoft Excel (.xlsx) — 84 and 13 respectively — plus a how-to guide and an FAQ as PDF. Every file is fully editable, unlocked and unprotected, ready to be rebranded and populated with your own information. Workbooks carry drop-down validation, frozen headers, autofilters, class-driven formulas and worked example rows flagged for deletion.
The Toolkit Index and Deployment Guide sets out a nine-step order: adopt the governance and the organisation-wide procedures once; run the gap assessment; then, per software system, classify, plan, open the registers, execute clause 5, assemble and audit the development file, and hand over to maintenance. The guide is explicit that classification comes first — the class decides which of the other documents you need — and that until a class is recorded the standard treats the system as Class C.
Reviews
There are no reviews yet