# IEC 62304 Software Lifecycle Documentation Checklist > Source: https://netray.co/tools/iec-62304-software-lifecycle-documentation-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Check that your medical device software file covers planning, requirements, architecture, verification, release, maintenance and problem resolution. ## Category quality ## Industry Medical Devices ## Audience - Software engineer - Quality engineer - Regulatory affairs ## Tool **Kind:** checklist **Groups:** #### Planning and classification **Items:** **Text:** Software development plan exists and is approved **Critical:** true **Text:** Software safety class (A, B or C) is assigned for each software system with rationale **Critical:** true Plan defines life cycle model, deliverables, tasks and responsibilities Software configuration management plan or section is defined **Text:** Plan covers integration of software risk management with the device risk file **Critical:** true Software of unknown provenance (SOUP) items are listed with version Development standards, methods and tools are identified #### Requirements and architecture **Items:** **Text:** Software requirements are documented, uniquely identified and reviewed **Critical:** true Requirements include functional, performance, interface and security needs **Text:** Risk control measures implemented in software appear as requirements **Critical:** true Software architecture shows items, interfaces and segregation where relied upon SOUP functional and performance requirements and the system environment are specified Detailed design is documented where required by the software safety class **Text:** Traceability exists from system requirements to software requirements to tests **Critical:** true #### Implementation and verification **Items:** Unit acceptance criteria are defined and units are verified as required for the class Coding standards or conventions are defined and applied Integration test plan and results are recorded **Text:** Software system test plan covers every software requirement **Critical:** true Test procedures, expected results, actual results and pass or fail are recorded **Text:** Anomalies found during testing are logged and evaluated for risk **Critical:** true Regression testing is performed after changes Test environment and tool versions are documented #### Release **Items:** **Text:** All known residual anomalies are documented and evaluated **Critical:** true Software release documentation identifies version, build and content **Text:** Verification is complete before release **Critical:** true Archive of released version, source, build environment and documentation is retained Software risk management is confirmed complete before release Release process ensures the correct version is delivered to users #### Maintenance, problem resolution and configuration **Items:** **Text:** Software maintenance plan covers feedback, evaluation and change implementation **Critical:** true **Text:** Problem reports are recorded, investigated and linked to risk analysis **Critical:** true Changes are evaluated for impact, approved, verified and re-released under control Configuration items are identified and versions are controlled SOUP anomaly lists are monitored for published problems Cybersecurity updates and vulnerability handling are planned Records of changes to the software are retained **Scoring Note:** Each checked item scores one point. Treat unchecked critical items as findings to close before submission or audit. Which activities are mandatory depends on the software safety class, so mark items not applicable to your class with a documented rationale. ## Content **Intro:** IEC 62304 defines the life cycle processes for medical device software. This checklist lists the documents and records a software file normally holds, grouped by life cycle stage, so you can see gaps before an audit or submission. **Sections:** #### How to use it **Body:** Work through each group with the software lead and quality engineer. For each item locate the controlled document or record and tick it only when you can point to the evidence. Mark critical items first, since they are the ones most likely to cause a finding. Export the result to PDF or Excel and file it with the design history as a periodic completeness review. **Bullets:** - Tick only items with evidence you can show - Close critical items before others - Record not applicable items with a rationale #### Software safety classes **Body:** The standard assigns Class A when no injury or damage to health is possible, Class B when non-serious injury is possible, and Class C when death or serious injury is possible, after taking risk controls outside the software into account. The class drives the depth of documentation: detailed design and unit verification are expected at higher classes, while Class A requires lighter activities. Classification should be reviewed whenever risk analysis changes. #### How it fits with risk and regulation **Body:** IEC 62304 expects software risk management to run within the ISO 14971 process, and regulators generally ask for a software description, hazard analysis, requirements, architecture, verification and a traceability matrix in a submission. Cybersecurity expectations are growing, so many teams add security risk management and a software bill of materials to the same file. #### Common mistakes **Body:** Teams often write documents after the code instead of in sequence, skip traceability from risk controls to tests, list SOUP without versions or known anomalies, and let configuration slip so the tested build cannot be reproduced. Agile approaches are compatible with the standard when the required outputs and reviews are produced and controlled. **Cta:** If software release and problem records need to link to your ERP and complaint data, Netray can discuss how to connect them. **Faq:** #### Does IEC 62304 apply to all software? **Answer:** It applies to software that is a medical device or part of one, including software as a medical device. It does not replace the need for the manufacturer to decide what is in scope for their product. #### Can I use an agile process? **Answer:** Yes. The standard does not mandate a model. You must still plan, document requirements, verify, manage risk and configuration, and keep the outputs under control for each release. #### What is SOUP? **Answer:** Software of unknown provenance is software item not developed for use in the medical device, such as an operating system or third party library. You identify it, specify requirements for it and monitor its known anomalies. #### Is this checklist sufficient for FDA submission? **Answer:** It is a documentation completeness aid. FDA software guidance sets submission content by documentation level, so read the current guidance for your device. ## Search terms iec 62304 checklist, iec 62304 documentation list, medical device software documentation, iec 62304 class a b c, software development plan medical device, samd documentation checklist, iec 62304 template, software verification medical device --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json