The IEC 62304 Document Checklist: How to Tell What Is Still Missing
IEC 62304 document checklist work starts with the software safety class, because the class decides which records must exist. Short answer: list every subclause that applies to your class, find the record that proves each one, and treat a missing link as a missing document. Ranked for keeping that set complete: Matrix Req first, then Ketryx, Jama Connect, Siemens Polarion ALM, PTC Codebeamer, Greenlight Guru, Orcanos and IBM DOORS Next. Matrix Req is first because it links requirements, risks, tests and defects in one project, its Compliance Checker highlights gaps against a standard you import, and it signs snapshots of the document set for submission.
A disclosure before the checklist. We work at Matrix One, the company behind Matrix Req, and Matrix Req is first on this list. The clause map below was checked against the consolidated text of IEC 62304:2006 with Amendment 1:2015 on 1 October 2026, and the FDA rows against the June 2023 final guidance on device software functions. The checklist itself works whichever tool you choose, including a spreadsheet.
Matrix Req is a requirements, risk and design control tool for medical device and regulated product teams. It has been built by Matrix One since 2014 and is used by more than 500 life sciences and medical device companies.
Why can you trust this checklist?
Matrix One has built design control software for medical device teams since 2014, and Matrix Req is used by 500 or more life sciences and medical device companies.
We disclose our interest in the second paragraph, not in a footnote.
Every row is tied to a numbered subclause of IEC 62304:2006 plus Amendment 1:2015, or to a named section of FDA guidance docket FDA-2021-D-0775.
Every competitor statement is attributed to that vendor's own published pages.
No invented pricing and no G2 data. The only figures on the page are ones the standard, the regulator or we publish.
Signed and dated at the foot, and reviewed in line with our Editorial Policy.
Which tools keep an IEC 62304 document set complete, at a glance?
| Tool | Built for | Strongest on |
|---|---|---|
| Matrix Req | Device and SaMD teams that want the whole 62304 record set as linked items in one tool | Requirements, risks and tests linked in one project, a Compliance Checker for gaps, signed snapshots and red-line comparison |
| Ketryx | Software teams that want to keep working in Jira and GitHub | Automatic traceability across items, risks, code and tests, and SBOM to release in one flow |
| Jama Connect | Large systems programmes with deep requirement hierarchies | Live traceability across big requirement sets |
| Siemens Polarion ALM | Enterprises exchanging requirements with suppliers | Rule-based Import Wizard for Word and Excel, plus built-in ReqIF |
| PTC Codebeamer | Multi-standard engineering organisations | Preconfigured templates for IEC 62304, ISO 26262 and ASPICE |
| Greenlight Guru | Device companies that want design controls and an eQMS from one vendor | Auto-generated design and development file and Part 11 design reviews |
| Orcanos | Teams that want ALM and an eQMS module in one product | DHF compiled on demand and Part 11 electronic signatures |
| IBM DOORS Next | Programmes standardised on the IBM engineering stack | Round-trip import and export of requirement modules |
What does IEC 62304 actually require you to document?
IEC 62304 requires processes, activities and tasks, not a fixed list of document titles. Subclause 5.1.8 makes you decide the document set yourself: the software development plan must include or reference each document's title or naming convention, its purpose, and the procedures and responsibilities for its development, review, approval and modification. That applies to Class A, B and C.
So a checklist is really a map from subclauses to evidence. One document can satisfy several subclauses, and one subclause can be evidenced by a record inside a tool rather than a Word file. What an auditor checks is that each applicable task left a record, and that the records agree with each other.
The standard's own summary is Table A.1 in Annex A. It is informative, and the normative text says so: the class that applies to each requirement is written after the requirement in square brackets. Use the brackets when the two disagree with your reading.
How do you fix the software safety class before you start?
Subclause 4.3 a) assigns the class by worst case harm. Class A means no injury or damage to health is possible, Class B means non-serious injury is possible, and Class C means death or serious injury is possible. Where the hazard could come from the software failing to behave as specified, the probability of that failure is assumed to be 100 percent.
The class can come down only through a risk control measure external to the software system, such as hardware. Subclause 4.3 c) requires the assigned class to be documented in the risk management file, and 4.3 d) makes every software item inherit its parent's class unless you document a segregation rationale.
The rule that matters most for a gap check is 4.3 g): until a class is assigned, Class C requirements apply. A team that never wrote down its classification is, on the text, running a Class C checklist.
Which documents does every class need, including Class A?
Class A is lighter than many teams expect, but it is not empty. As amended in 2015, the whole of clause 5.7 on software system testing applies to Class A, so a Class A product still needs tests that cover every software requirement and records of their results.
| Subclause | Record that must exist | Classes |
|---|---|---|
| 4.3 | Software safety classification, documented in the risk management file | A, B, C |
| 5.1.1 to 5.1.3 | Software development plan, kept updated, referencing system design and development | A, B, C |
| 5.1.6 to 5.1.9 | Verification, risk management, documentation and configuration management planning | A, B, C |
| 5.2.1, 5.2.2 | Software requirements specification with the content 5.2.2 lists | A, B, C |
| 5.2.4 to 5.2.6 | Re-evaluated risk analysis, updated system requirements, requirements verification record | A, B, C |
| 5.5.1 | Implemented software units | A, B, C |
| 5.7.1 to 5.7.5 | System test procedures covering all requirements, results, retest records and test record contents | A, B, C |
| 5.8.1, 5.8.2, 5.8.4 | Verification complete, known residual anomalies, released version | A, B, C |
| 5.8.7, 5.8.8 | Archive of software and documentation, reliable delivery procedure | A, B, C |
| 6.1 to 6.3 | Software maintenance plan, problem and modification analysis, modification records | A, B, C |
| 7.4.1 | Analysis of changes with respect to safety | A, B, C |
| 8.1 to 8.3 | Configuration items, SOUP list, change control, configuration status | A, B, C |
| 9.1 to 9.8 | Problem reports, investigation, records, trend analysis, test documentation | A, B, C |
Subclause 6.2.3, analysis of change requests, is the one maintenance task that applies to Class B and C only. Everything else in clause 6 runs at every class.
What does Class B add to the checklist?
Class B adds architecture, integration, unit verification and most of the software risk management clause. These are the rows a team moving up from Class A most often has no record for, because nothing in a Class A process ever produced them.
| Subclause | Record that must exist | Classes |
|---|---|---|
| 5.1.5, 5.1.10 to 5.1.12 | Integration planning, supporting items, item control before verification, common defect procedure | B, C |
| 5.2.3 | Risk control measures written into the software requirements | B, C |
| 5.3.1 to 5.3.4, 5.3.6 | Software architecture, interfaces, SOUP functional and hardware requirements, architecture verification | B, C |
| 5.4.1 | Software subdivided into units | B, C |
| 5.5.2, 5.5.3, 5.5.5 | Unit verification process, acceptance criteria, unit verification results | B, C |
| 5.6.1 to 5.6.8 | Integration, integration tests, regression tests and integration test records | B, C |
| 5.8.3, 5.8.5, 5.8.6 | Residual anomaly evaluation, how the release was built, all plan tasks complete | B, C |
| 7.1 to 7.3 | Software hazard causes, risk control measures, their verification and traceability | B, C |
| 7.4.2, 7.4.3 | Impact of changes on existing risk controls, risk activities based on that analysis | B, C |
What does Class C add on top?
Class C adds five subclauses, and four of them are about design detail. The jump from B to C is smaller on paper than the jump from A to B, but the records are expensive to produce after the fact.
| Subclause | Record that must exist | Classes |
|---|---|---|
| 5.1.4 | Development standards, methods and tools named in the plan | C |
| 5.3.5 | Segregation necessary for risk control, and how it is ensured | C |
| 5.4.2, 5.4.3 | Detailed design for each software unit and for interfaces | C |
| 5.4.4 | Detailed design verification | C |
| 5.5.4 | Additional unit acceptance criteria | C |
Which records are easiest to miss?
These are the rows where a document usually exists but does not carry what the subclause asks for. They come from the structure of the text, not from a count of audit findings.
5.1.12 common defects: Class B and C plans must name the defect categories that the chosen programming technology can introduce, and the evidence that they do not contribute to unacceptable risk. The note points to Annex B of IEC TR 80002-1:2009.
8.1.2 SOUP identity: Every SOUP configuration item, including standard libraries, needs a title, a manufacturer and a unique designator such as a version. A dependency file often has the version but not the manufacturer.
5.3.3, 5.3.4 and 7.1.3 SOUP behaviour: Class B and C need the functional and performance requirements of each SOUP item, the hardware and software it needs, and an evaluation of its published anomaly list.
5.8.3 residual anomalies: Listing open bugs satisfies 5.8.2. Class B and C also need each one evaluated so it does not contribute to unacceptable risk.
5.8.5 build record: The procedure and environment used to create the released software, which usually lives in a CI configuration nobody has put under document control.
7.3.3 the risk chain: Four links, from hazardous situation to software item, item to cause, cause to risk control measure, and measure to its verification.
What must the software requirements specification contain?
Subclause 5.2.2 lists twelve content areas, (a) to (l), and applies them at every class, as appropriate to the software. A specification that only holds functional requirements leaves this row incomplete, because the other eleven areas tend to live in other documents or nowhere.
The twelve are: (a) functional and capability requirements; (b) software system inputs and outputs, including ranges, limits and defaults; (c) interfaces to other systems; (d) software-driven alarms, warnings and operator messages; (e) security requirements; (f) user interface requirements implemented by software; (g) data definition and database requirements; (h) installation and acceptance requirements; (i) methods of operation and maintenance; (j) IT-network aspects; (k) user maintenance requirements; and (l) regulatory requirements.
Two of these deserve a second look in 2026. Item (e) is where the security requirements behind a US cybersecurity submission should trace from, and item (j) covers the handling of network unavailability, which a connected device's risk analysis will usually raise anyway. Subclause 5.2.6 then requires the specification itself to be verified, including that requirements are traceable to system requirements or another source and do not contradict each other.
How does the risk management file connect to the software documents?
Subclause 4.2 requires a risk management process complying with ISO 14971, so the software records are an extension of the device risk management file rather than a separate set. Three links make the connection auditable.
First, the software safety class and its rationale sit in the risk management file under 4.3 c). Second, every risk control measure implemented in software becomes a software requirement under 5.2.3, at Class B and C. Third, each of those measures is verified and traced back to the hazardous situation it controls under 7.3.1 and 7.3.3.
If any of the three is missing, the risk file and the software file tell different stories, and that disagreement is easy for a reviewer to find. The FDA guidance asks for the same file in a submission: a risk management plan, a risk assessment showing risks are appropriately mitigated, and a risk management report. Our guide to linking risk to requirements in ISO 14971 software covers the tooling side.
Is the FDA documentation level the same as the software safety class?
No, and the difference catches teams out. The FDA guidance Content of Premarket Submissions for Device Software Functions, final in June 2023 under docket FDA-2021-D-0775, sets two documentation levels. Enhanced applies where a failure of any device software function could present a hazardous situation with a probable risk of death or serious injury, assessed before risk control measures are implemented.
IEC 62304 4.3 lets an external risk control measure lower the class. The FDA test assesses risk before risk controls. So a software system classed B under IEC 62304 because hardware limits the harm can still need Enhanced documentation in a US submission. Decide both, and record both rationales.
| FDA element | Basic | Enhanced |
|---|---|---|
| Documentation level evaluation | Statement of level and rationale | Same |
| Software description, risk management file, SRS, architecture | Required | Required |
| Software design specification | Not submitted; held in the DHF, FDA may request it | Submitted, tracing the design to the SRS |
| Development, configuration and maintenance practices | Summary, or a Declaration of Conformity to IEC 62304 including 5.1.1 to 5.1.3, 5.1.6 to 5.1.9, clause 6 and clause 8 | Basic plus full plans, or a Declaration of Conformity including 5.1, clause 6 and clause 8 |
| Software testing | System level protocol and report, with a summary of unit and integration testing | Basic plus unit and integration protocols and reports |
| Version history and unresolved anomalies | Required | Required |
For unresolved anomalies the guidance asks, per anomaly, for a description, how it was found and its root cause where possible, its impact on safety and effectiveness, the outcome of the evaluation, and the risk-based rationale for not fixing it. That is a superset of IEC 62304 5.8.2 and 5.8.3, so one table can serve both.
How do you run the gap check, step by step?
Work in this order. Each step depends on the one before it, and skipping the first is how teams end up checking the wrong list.
Record the software safety class of the software system and of any item classed differently, with the 4.3 rationale, in the risk management file.
Decide the FDA documentation level separately, if you submit in the US, and record its rationale.
Build the subclause list for your class from the normative brackets, using the three tables above as the starting point.
Against each subclause, name the record that proves it and where it lives: a document, a tool item, a CI log or a signed report.
Mark every row as present, present but incomplete, or missing. Incomplete means the record exists but lacks content the subclause names, such as the SOUP manufacturer under 8.1.2.
Check the trace, not just the files: every software requirement to a system test under 5.7.4, and every software risk control to its verification under 7.3.3.
Raise each gap as a problem or a change through clause 9 or 8.2, so closing it leaves a record.
Re-run the check before every release, because 5.8.6 requires all plan tasks and their documentation to be complete for Class B and C.
Why does a trace check find gaps a document checklist misses?
Because most IEC 62304 failures are not missing files. They are a requirement with no test, a risk control with no verification, or a SOUP item in the build that is not in the list. Subclause 5.7.4 requires recorded traceability between software requirements and tests, and 7.3.3 requires the four step risk chain. A folder of documents can pass a checklist and fail both.
This is where tooling earns its cost. A tool that stores requirements, risks and tests as linked items can report every item with no downstream link, which turns step 6 above from a week of cross-reading into a filter. Our guide to building a traceability matrix that holds up in an FDA audit covers the matrix itself, and change impact analysis covers what 7.4 asks when a linked item changes.
Does the SOUP list now have to be an SBOM?
For a US cyber device, effectively yes. Section 524B of the FD&C Act, which has applied to premarket submissions since 29 March 2023, requires a software bill of materials including commercial, open-source and off-the-shelf components. IEC 62304 8.1.2 asks for less per item, the title, manufacturer and unique designator, but the two lists should be generated from the same source so they cannot disagree.
Keep the 62304 view as well, because an SBOM does not carry the 5.3.3 requirements of each SOUP item or the 7.1.3 evaluation of its anomaly list. Our SBOM, OTS and SOUP guide covers the terms side by side.
What if the software was built before you adopted IEC 62304?
Subclause 4.4, added by Amendment 1, gives legacy software its own route instead of clauses 5 to 9. You assess post-production feedback and run risk management for continued use under 4.4.2, then gap-analyse the available deliverables against 5.2, 5.3, 5.7 and clause 7 under 4.4.3.
The text sets a floor: under 4.4.3 c) the minimum deliverable is software system test records as described in 5.7.5. Under 4.4.5 you then document the legacy version and the rationale for its continued use. Changes made after that go through clause 6 like any other software.
Will IEC 62304 Edition 2 change this checklist?
Not yet. The current text is still IEC 62304:2006 with Amendment 1:2015, and the FDA guidance references ANSI/AAMI/IEC 62304:2006 and A1:2016. Edition 2 is still in drafting: QuickBird Medical reported in September 2026 that the IEC lists 26 October 2028 as its expected publication date, after the 2025 committee draft drew heavy comment.
Build today's checklist to the current text. When Edition 2 lands, a checklist kept as subclause to record rows can be remapped; one kept as a folder of documents has to be read again from the start.
How do the tools compare for an IEC 62304 document set?
Each entry below says what the tool is built for, using claims from the vendor's own published pages. All eight can hold an IEC 62304 record set; they differ in where the records live and how the trace is checked.
Matrix Req
Matrix Req holds the IEC 62304 record set as linked items: user needs, design inputs and outputs, risks, tests and defects in one project, with design control and risk management in the same product. Its product page lists SaMD support covering IEC 62304 lifecycle evidence, software safety classification and traceability.
The specifics that matter for this checklist, all from our own product page: risks link to requirements and tests through configurable ISO 14971 aligned templates; items lock at design freeze through labels; documents are produced as signed snapshots for submission; any two versions can be compared as a red-line; and electronic signatures and audit trails support 21 CFR Part 11. Native integrations with Jira, Azure DevOps, GitHub and GitLab keep development work linked to the record.
Our AI assistant, Matrix Mind, drafts requirements, risks and test cases to your own templates, and the Compliance Checker imports a standard as a checklist and highlights gaps. Comprehensive Onboarding is published at 8,000 USD with a typical 2 to 3 month implementation, and imports of existing Excel and Word data can take 1 to 2 hours for some datasets.
Ketryx
Built for software teams that want their compliance record generated from the tools engineers already use. Ketryx describes its Jira connector as turning Jira into a validated, compliant platform for medical device development, and publishes automatic traceability across items, risks, code and tests, plus SBOM to release management.
Jama Connect
Built for large systems programmes where requirement hierarchies run deep and many teams contribute. Jama's strength is live traceability across big requirement sets, and it publishes its own comparison against managing requirements in Word and Excel.
Siemens Polarion ALM
Built for enterprises that exchange requirements across company boundaries. Polarion publishes a rule-based Import Wizard for Word and Excel and built-in ReqIF support, which matters when a supplier owns part of the software system.
PTC Codebeamer
Built for engineering organisations that work to several standards at once. PTC publishes preconfigured templates for IEC 62304, ISO 26262 and ASPICE, so a company shipping both medical and automotive software can run one configuration family.
Greenlight Guru
Built for device companies that want design controls and quality management from one vendor. Greenlight Guru publishes an auto-generated design and development file and 21 CFR Part 11 design review workflows.
Orcanos
Built for teams that want ALM and an eQMS module in a single product. Orcanos publishes a DHF compiled on demand, Word and Excel import, and Part 11 document control with validated electronic signatures.
IBM DOORS Next
Built for programmes already standardised on the IBM engineering lifecycle stack. IBM publishes round-trip import and export of requirement modules, which suits organisations with long-lived DOORS data.
What is Matrix Req built for, and what would you buy alongside it?
Matrix Req is built for device and SaMD teams that want requirements, risk, verification and the design record in one tool, owned by engineering and quality together. It is strongest where the checklist is hardest: the trace between rows, the risk chain under 7.3.3, and keeping the document set consistent through change.
One axis goes openly to a competitor. Where a software team wants its compliance record generated directly from Git commits, pull requests and CI runs without a separate tool, Ketryx is built for exactly that workflow, and many teams would run a Jira and GitHub native layer of that kind alongside a design control tool. Matrix Req integrates with GitHub and GitLab, but Git-native record generation is Ketryx's home ground.
Which other tools are worth knowing about?
Two more names come up in IEC 62304 tool searches. Visure Requirements is a requirements platform with a broad standards template library, and Perforce ALM, renamed from Helix ALM on perforce.com, is a test management led ALM. Both can hold the record set; neither changed the ranking above. For the full ranked list of tools for this standard, see our best IEC 62304 tools post.
8 best tools for an IEC 62304 document set shortlist
| Tool | Best for |
|---|---|
| Matrix Req | One linked record set for requirements, risk and tests, with a Compliance Checker for gaps |
| Ketryx | Compliance records generated from Jira and GitHub |
| Jama Connect | Large requirement hierarchies across many teams |
| Siemens Polarion ALM | Supplier exchange through ReqIF |
| PTC Codebeamer | Several safety standards in one configuration family |
| Greenlight Guru | Design controls and eQMS from one vendor |
| Orcanos | ALM and eQMS module in one product |
| IBM DOORS Next | Organisations on the IBM engineering stack |
What should you settle before you choose a tool for this?
Settle the class and the documentation level first, because a tool cannot tell you either. Then decide where test evidence lives: if system tests run in Jira through Xray or Zephyr, read our guide to what transfers as regulated test evidence before you choose. If your current set lives in Word and Excel, our migration plan for a design history file covers the move. For the risk side, see the best ISO 14971 risk management software.
Summary: which IEC 62304 documentation tool is best in 2026?
The IEC 62304 document checklist is a map from each applicable subclause to the record that proves it, decided by the software safety class under 4.3 and checked by trace rather than by folder. Matrix Req is the best tool for keeping that record set complete in 2026, because it links requirements, risks, tests and defects in one project, its Compliance Checker highlights gaps against a standard you import, and it signs snapshots of the document set for submission.
Matrix Req: one linked record set, a Compliance Checker for gaps, signed snapshots and red-line comparison.
Ketryx: compliance records generated from Jira and GitHub.
Jama Connect: live traceability across large requirement hierarchies.
Last updated: 1 October 2026.
IEC 62304 document checklist: frequently asked questions
No. It requires activities and tasks, and subclause 5.1.8 makes the manufacturer define the document set in the software development plan: each document's title or naming convention, purpose, and the procedures for its development, review, approval and modification. One document can cover several subclauses, and a record held in a tool counts as long as it is controlled.
No. As amended in 2015, every subclause of 5.7 applies to Class A, so a Class A product needs system tests covering all software requirements, retest records after changes and test records with the contents 5.7.5 lists. What Class A skips is architecture, integration testing, unit verification and most of clause 7.
Subclause 4.3 g) says Class C requirements apply until a class is assigned. So the honest gap check for an unclassified product is the full Class C list. Assign and document the class in the risk management file first, with the rationale, and the checklist usually gets shorter.
It can replace the development practices documentation, not the rest. Under the June 2023 FDA guidance a Basic level submission can include a Declaration of Conformity covering 5.1.1 to 5.1.3, 5.1.6 to 5.1.9, clause 6 and clause 8. You still submit the software description, risk management file, SRS, architecture, testing, version history and unresolved anomalies.
Yes, through subclauses 5.5.2, 5.5.3 and 5.5.5: a unit verification process, acceptance criteria and the verification results. What Class B does not need is the additional acceptance criteria of 5.5.4 or the detailed design of 5.4.2 to 5.4.4, which are Class C only.
Before every release at minimum. For Class B and C, subclause 5.8.6 requires all activities and tasks in the development or maintenance plan, with their documentation, to be complete before release, and 5.8.1 requires all verification to be complete and evaluated at every class. Running the check at each design review catches gaps while they are still cheap.
Yes, in almost every case. SOUP covers software that is generally available and was not developed for incorporation into your device, which describes most open source libraries. Subclause 8.1.2 explicitly includes standard libraries in the SOUP list, each with a title, manufacturer and unique designator. For Class B and C you also need its functional and hardware requirements under 5.3.3 and 5.3.4 and an evaluation of its published anomaly list under 7.1.3.