IEC 62304 Software Documentation Checklist

0%

0 of 35 items complete

12 critical items still open - these are the highest-risk gaps.

Download checklist:

Planning and classification

Software development plan exists and is approvedCRITICALSoftware safety class (A, B or C) is assigned for each software system with rationaleCRITICALPlan defines life cycle model, deliverables, tasks and responsibilitiesSoftware configuration management plan or section is definedPlan covers integration of software risk management with the device risk fileCRITICALSoftware of unknown provenance (SOUP) items are listed with versionDevelopment standards, methods and tools are identified

Requirements and architecture

Software requirements are documented, uniquely identified and reviewedCRITICALRequirements include functional, performance, interface and security needsRisk control measures implemented in software appear as requirementsCRITICALSoftware architecture shows items, interfaces and segregation where relied uponSOUP functional and performance requirements and the system environment are specifiedDetailed design is documented where required by the software safety classTraceability exists from system requirements to software requirements to testsCRITICAL

Implementation and verification

Unit acceptance criteria are defined and units are verified as required for the classCoding standards or conventions are defined and appliedIntegration test plan and results are recordedSoftware system test plan covers every software requirementCRITICALTest procedures, expected results, actual results and pass or fail are recordedAnomalies found during testing are logged and evaluated for riskCRITICALRegression testing is performed after changesTest environment and tool versions are documented

Release

All known residual anomalies are documented and evaluatedCRITICALSoftware release documentation identifies version, build and contentVerification is complete before releaseCRITICALArchive of released version, source, build environment and documentation is retainedSoftware risk management is confirmed complete before releaseRelease process ensures the correct version is delivered to users

Maintenance, problem resolution and configuration

Software maintenance plan covers feedback, evaluation and change implementationCRITICALProblem reports are recorded, investigated and linked to risk analysisCRITICALChanges are evaluated for impact, approved, verified and re-released under controlConfiguration items are identified and versions are controlledSOUP anomaly lists are monitored for published problemsCybersecurity updates and vulnerability handling are plannedRecords of changes to the software are retained

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.

Optional software file completeness review

We can discuss how traceability between requirements, risks and tests is kept in your tools.

Optional. The tool and every export work without this. No spam.

How to use it

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.

Tick only items with evidence you can show
Close critical items before others
Record not applicable items with a rationale

Software safety classes

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

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

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.

Frequently Asked Questions

Does IEC 62304 apply to all software?

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?

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?

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?

It is a documentation completeness aid. FDA software guidance sets submission content by documentation level, so read the current guidance for your device.

If software release and problem records need to link to your ERP and complaint data, Netray can discuss how to connect them.

Talk to an Expert Explore More Free Tools

Related Tools

Compliance & Contracts

More Quality & Inspection tools

See all

IEC 62304 Software Lifecycle Documentation Checklist