Your checklist here tracks coding standards and peer reviews.
Requirements must be uniquely identifiable, testable, and traceable to Risk Management (ISO 14971).
This is black-box testing against the Software Requirements Specification (SRS).
Below is a structured, comprehensive IEC 62304 compliance checklist you can paste into an Excel file. Each row represents one checklist item with suggested columns for tracking status, evidence, owner, and notes. Use the "Status" column values: Not Started / In Progress / Complete / Not Applicable. Adjust or remove columns to match your project process.
Columns (place in row 1):
Checklist rows (start at row 2):
1, 4.1, "Establish software lifecycle processes", Management, "Define, document and maintain software development and maintenance processes", "Software Development Plan, Software Maintenance Plan, SOPs", "Plans approved by management; versioned", Not Started, QA Manager, , , Medium,
2, 4.2, "Assign roles and responsibilities", Management, "Document responsibilities for software lifecycle activities", "Organizational chart, RACI, role descriptions", "Roles assigned and communicated", Not Started, Project Manager, , , Low,
3, 4.3, "Software safety classification", Planning, "Classify software according to safety impact (Class A/B/C)", "Safety classification report, scoring rationale", "Classification justified per IEC 62304 definitions", Not Started, Safety Engineer, , , High,
4, 5.1, "Software development plan", Planning, "Create plan covering scope, lifecycle model, verification/validation, configuration management, risk management", "Software Development Plan (SDP)", "Plan reviewed and baseline established", Not Started, Project Manager, , , High,
5, 5.2, "Software requirements specification (SRS)", Requirements, "Document functional and non-functional S/W requirements traceable to system requirements", "SRS document, trace matrix", "All requirements uniquely identified and testable", Not Started, Systems Engineer, , , High,
6, 5.3, "Architectural design", Design, "Define high-level architecture, interfaces, modules, data flow", "Software architecture document, UML diagrams", "Architecture supports requirements and safety classification", Not Started, Lead Architect, , , High,
7, 5.4, "Detailed design", Design, "Specify module-level design to support implementation and verification", "Module design specs, data structures, algorithms", "Design complete and reviewable", Not Started, Developers, , , High,
8, 5.5, "Implementation", Implementation, "Implement software according to detailed design, coding standards", "Source code repository, coding standards, code comments", "Code compiles, unit tests available", Not Started, Dev Team, , , High,
9, 6.1, "Software unit testing", Verification, "Define and execute unit tests for individual modules", "Unit test cases, automated test results", "Coverage per plan; unit tests pass", Not Started, Dev Team, , , Medium,
10, 6.2, "Software integration testing", Verification, "Test integration of modules and interfaces", "Integration test plan, test reports", "All integration test cases passed", Not Started, Test Lead, , , Medium,
11, 6.3, "Software system testing", Verification, "Verify software meets SRS in system configuration", "System test plan, executed test reports", "System tests trace to SRS and pass", Not Started, QA, , , High,
12, 6.4, "Software release testing (acceptance)", Verification, "Perform release/acceptance testing with release criteria", "Acceptance test reports, release checklist", "Release approval recorded", Not Started, Release Manager, , , High,
13, 7.1, "Software maintenance process", Maintenance, "Plan and implement maintenance activities including problem resolution and change control", "Maintenance plan, change control procedure", "Issues tracked; changes controlled", Not Started, Maintenance Lead, , , Medium,
14, 7.2, "Problem resolution and tracking", Maintenance, "Record, investigate, and resolve software anomalies", "Issue tracking system, CAPA records", "All issues logged and dispositioned", Not Started, Support Lead, , , Medium,
15, 8.1, "Configuration management plan", CM, "Establish CM for software items: baselines, versioning, build control", "CM Plan, baselined repository", "Source, deliverables, and baselines controlled", Not Started, CM Manager, , , High,
16, 8.2, "Identification and control of baselines", CM, "Define items under configuration control and baselines", "Baseline records, change records", "Baselines approved and auditable", Not Started, CM Manager, , , High,
17, 8.3, "Build and release procedures", CM, "Define reproducible build and release processes", "Build scripts, release checklist, environment definitions", "Builds reproducible; release artifacts archived", Not Started, Release Engineer, , , High,
18, 8.4, "Software item traceability", Traceability, "Maintain bidirectional traceability between requirements, design, code, and tests", "Traceability matrix", "All SRS items traced to design, code, and tests", Not Started, QA, , , High,
19, 9.1, "Risk management integration", Risk, "Integrate ISO 14971-based risk management with software lifecycle", "Risk management plan, risk file (hazards, mitigations, residual risk)", "Risks identified, controls implemented and verified", Not Started, Risk Manager, , , High,
20, 9.2, "Identification of hazardous situations from software", Risk, "Document hazards contributed by software and risk acceptability", "Hazard log, FMEA/FMECA", "Hazards analyzed and mitigations assigned", Not Started, Safety Engineer, , , High, Iec 62304 Checklist Xls
21, 9.3, "Verification of safety-related requirements", Risk, "Verify that risk control measures are implemented correctly in software", "Verification test cases, results", "Safety functions verified per requirements", Not Started, Test Lead, , , High,
22, 10.1, "Software problem resolution process (post-market)", Post-market, "Process for receiving and acting on field issues and incidents", "Post-market surveillance plan, incident handling SOP", "Incidents tracked; corrective actions implemented", Not Started, Vigilance Lead, , , High,
23, 11.1, "Software tools qualification", Tools, "Identify and qualify software tools that can introduce or detect errors", "Tool qualification records, V-model for tools", "Tools categorized and qualified where required", Not Started, Tool Owner, , , Medium,
24, 11.2, "Libraries and third-party components", Tools, "Control and document use of 3rd-party software, open-source, and libraries", "Bill of materials, license records, vulnerability assessment", "Third-party components evaluated and accepted", Not Started, Dev Team, , , Medium,
25, 12.1, "Document control", Documentation, "Ensure controlled documents: versioning, approvals, distribution", "Document register, document control procedure", "Documents current and archived", Not Started, Document Controller, , , Low,
26, 12.2, "Record retention", Documentation, "Define retention periods and storage for lifecycle records", "Records retention schedule", "Records retained per regulatory requirements", Not Started, QA, , , Low,
27, 13.1, "Usability and human factors consideration", Usability, "Address user interface safety aspects and use-related risks", "Usability engineering file, use scenarios, validation", "Use errors analyzed and mitigations implemented", Not Started, UX Lead, , , Medium,
28, 14.1, "Security requirements for software", Security, "Define security requirements (authentication, access control, encryption)", "Security requirements spec, threat model", "Security requirements implemented and tested", Not Started, Security Engineer, , , High,
29, 14.2, "Vulnerability management", Security, "Process to identify, track and remediate security vulnerabilities", "Vulnerability log, patch management process", "Vulnerabilities assessed and remediated", Not Started, Security Team, , , High,
30, 15.1, "Verification of requirements, design, implementation", Verification, "Plan and perform verification activities throughout lifecycle", "Verification plan and reports", "Verification coverage meets plan", Not Started, QA, , , High,
31, 16.1, "Validation of software in intended environment", Validation, "Validate final software in intended use environment including clinical workflow", "Validation protocol, validation report", "Validation shows software meets user needs and intended use", Not Started, Validation Lead, , , High,
32, 16.2, "Acceptance criteria for validation", Validation, "Define measurable acceptance criteria for validation", "Validation acceptance criteria in protocol", "Criteria met and documented", Not Started, Validation Lead, , , High,
33, 17.1, "Supplier management", Supplier, "Assess and control suppliers for software components or services", "Supplier assessments, contracts, quality agreements", "Suppliers qualified and monitored", Not Started, Procurement, , , Medium,
34, 18.1, "Training and competency", Training, "Provide training for personnel on software lifecycle processes and tools", "Training records, competency matrix", "Personnel trained and records stored", Not Started, HR, , , Low,
35, 19.1, "Audit and internal review", Quality, "Plan and perform internal audits of software lifecycle processes", "Audit schedule, audit reports, corrective actions", "Findings closed within target", Not Started, QA Lead, , , Medium,
36, 20.1, "Regulatory reporting and compliance", Regulatory, "Ensure processes for regulatory submissions and reporting", "Regulatory submission artifacts, correspondence", "Regulatory requirements addressed", Not Started, Regulatory Affairs, , , High,
37, 21.1, "Change impact analysis", Change Control, "Assess impact of changes on safety, performance, and regulatory status", "Change request, impact assessment", "Impact documented and approved", Not Started, Change Board, , , High,
38, 21.2, "Regression testing for changes", Change Control, "Run regression tests when software changes are introduced", "Regression test suite, results", "No regressions in safety-critical functions", Not Started, Test Lead, , , High,
39, 22.1, "End-of-life planning", Maintenance, "Define software end-of-life and transition plans", "EOL policy, customer notifications plan", "EOL criteria and communication defined", Not Started, Product Manager, , , Low,
40, 23.1, "Record of decisions and rationale", Documentation, "Maintain decision logs for safety-critical design choices", "Decision log, meeting minutes", "Rationales traceable and auditable", Not Started, Project Manager, , , Medium,
41, 24.1, "Clinical evaluation inputs", Clinical, "Include clinical input where software affects clinical decisions", "Clinical evaluation report or literature review", "Clinical risks assessed", Not Started, Clinical Lead, , , High,
42, 25.1, "Software release notes and labeling", Release, "Prepare release notes, user manuals, labeling reflecting changes and safety information", "Release notes, instructions for use", "Documentation updated and reviewed", Not Started, Technical Writer, , , Medium,
43, 26.1, "Backup and restore for data integrity", Data, "Define backup and restore procedures to protect user/clinical data", "Backup SOPs, test restoration records", "Data restored successfully in test", Not Started, IT Ops, , , Medium,
44, 27.1, "Logging and monitoring", Operations, "Ensure adequate logging for safety events, performance, and security", "Logging policy, logs retention", "Logs available for investigation", Not Started, DevOps, , , Medium,
45, 28.1, "Performance and reliability requirements", Non-functional, "Define and verify performance, timing, and reliability requirements", "Performance test plan, results", "Meets performance acceptance criteria", Not Started, Performance Engineer, , , Medium, Your checklist here tracks coding standards and peer reviews
46, 29.1, "Internationalization / localization considerations", Non-functional, "Address language/regulatory variations if applicable", "Localization plan, translated documents", "Localized versions validated", Not Applicable, Product Manager, , , Low,
47, 30.1, "Device-specific software considerations", Product, "Document any device/platform dependencies and constraints", "Platform compatibility matrix", "Compatibility tested and documented", Not Started, Engineering, , , Medium,
48, 31.1, "Traceability to system-level risk controls", Risk, "Ensure software contributes to and verifies system-level risk controls", "Trace matrix linking system risk controls to software functions", "All system risk controls implemented or noted as N/A", Not Started, Safety Engineer, , , High,
49, 32.1, "Evidence of management review", Management, "Periodic management reviews of software lifecycle status", "Management review minutes, action items", "Reviews performed per schedule", Not Started, QA Manager, , , Low,
50, 33.1, "Compliance gap analysis", Audit, "Perform gap analysis vs IEC 62304 and related standards (ISO 14971, IEC 62366, ISO 13485)", "Gap analysis report, remediation plan", "Gaps closed or tracked", Not Started, Compliance Lead, , , High,
Instructions for Excel formatting:
Optional additional sheets:
Use this checklist as a complete starting point; remove or adapt items not applicable to your product.
An IEC 62304 Checklist in Excel format is a tool used by medical device software developers to ensure compliance with the IEC 62304:2006 (and Amendment 1:2015) standard. It typically maps specific standard requirements to project activities and documentation, categorized by software safety classes (A, B, and C). Core Content for an IEC 62304 Checklist
A useful checklist should cover the following primary and supporting lifecycle processes defined by the standard:
Software Development Process (Section 5): Planning, requirements analysis, architectural design, detailed design, unit implementation, integration, system testing, and release.
Software Maintenance Process (Section 6): Establishing a maintenance plan and managing problem/modification analysis.
Software Risk Management (Section 7): Analysis of software contributing to hazardous situations and risk control measures.
Software Configuration Management (Section 8): Configuration identification, change control, and status accounting.
Software Problem Resolution (Section 9): Documenting, evaluating, and resolving software problems. Useful Resources & Downloads
Several platforms provide downloadable templates and detailed checklists:
Template: IEC 62304:2006 Mapping of Requirements to Documents
IEC 62304 Checklist XLS a spreadsheet-based tool used by medical device manufacturers to track and document compliance with the IEC 62304:2006 (including Amendment 1:2015) standard for software life cycle processes
. These checklists are vital for organizing the evidence required for regulatory submissions (like FDA or EU MDR) by mapping specific standard requirements to project artifacts. Core Components of the Checklist
A comprehensive checklist typically covers the five primary processes defined in the standard: Software Development Process (Clause 5):
Planning, requirements analysis, architectural design, implementation, and system testing. Software Maintenance Process (Clause 6):
Procedures for managing feedback and software modifications after market release. Software Risk Management (Clause 7):
Identifying hazards, documenting potential causes, and verifying risk control measures. Software Configuration Management (Clause 8):
Managing configuration items and controlling changes to the software system. Software Problem Resolution (Clause 9):
Tracking, investigating, and resolving software-related issues. www.qualityfwd.com Safety Classification Impact IEC 62304:2006/AMD1:2015 Checklist .xls file attached Checklist rows (start at row 2): 1, 4
To achieve compliance with , your checklist must cover the five primary software life cycle processes defined in the standard. Because requirements vary by Software Safety Class (A, B, or C)
, an effective Excel (.xls) template should include a column for safety classification to filter relevant tasks. www.qualityfwd.com Core Processes Checklist
An IEC 62304 compliance checklist is typically structured around Clauses 5 through 9: Software Development Process (Clause 5): Define the development lifecycle, tools, and roles. Requirements Analysis:
Document functional, performance, and risk-related software requirements. Architecture & Design:
Create a blueprint of software units and their interactions. Implementation & Verification: Coding and testing (Unit, Integration, and System testing). Software Maintenance Process (Clause 6):
Establish procedures for tracking bugs, assessing impact of changes, and re-validating modified code. Software Risk Management (Clause 7):
Identify software-specific hazards and document risk control measures (must align with Software Configuration Management (Clause 8):
Control source code versions and manage the development environment. Software Problem Resolution (Clause 9):
Formalize how bugs are reported, analyzed for root causes, and resolved. www.qualityfwd.com Recommended Excel Template Columns
For a practical .xls tool, organize your spreadsheet with these headers: IEC 62304 QMS Checklist for Medical Software Teams
The Medical Device Software Conundrum
Dr. Maria Rodriguez, a seasoned medical device software engineer, had just been assigned to lead a project to develop a new software-controlled infusion pump. The pump would be used to deliver precise amounts of medication to patients in hospitals and clinics.
As she began to plan the project, Maria knew that she had to ensure that the software met the rigorous requirements of the medical device industry. Specifically, she had to comply with the IEC 62304 standard, which defined the lifecycle requirements for the development of medical device software.
Maria had worked with IEC 62304 before, but she knew that it was a complex and detailed standard. To help her team stay on track, she decided to create a checklist in Excel (which she dubbed "IEC 62304 Checklist XLS") to ensure that they covered all the necessary requirements.
The checklist was a comprehensive spreadsheet that outlined all the IEC 62304 requirements, including:
Maria and her team used the checklist to methodically work through each phase of the software development lifecycle. They checked off each requirement as they completed it, and used the checklist to ensure that they didn't miss any critical steps.
As they progressed through the project, the checklist helped Maria's team to:
Thanks to the IEC 62304 Checklist XLS, Maria's team was able to deliver a high-quality software-controlled infusion pump that met all the relevant regulatory requirements. The pump was a success, and patients began to benefit from its precise and safe delivery of medication.
Example contents of the IEC 62304 Checklist XLS:
Here's an example of what the checklist might look like:
| Requirement | Description | Done | | --- | --- | --- | | 5.1.1 | Software development lifecycle processes | | | 5.1.2 | Software planning | | | 5.2.1 | Requirements analysis | | | 5.2.2 | Requirements validation | | | 6.1.1 | Design | | | 6.1.2 | Design verification | | | ... | ... | ... |
This is just a small sample of the many requirements and activities that are included in the IEC 62304 standard. The checklist would be much longer and more detailed, covering all the necessary requirements and activities for the software development lifecycle.
Title: IEC 62304 Compliance Checklist & Traceability Matrix Template
Abstract This document serves as a comprehensive checklist and implementation guide for IEC 62304:2006+A1:2015 (Medical device software — Software life cycle processes). It is designed to assist software developers, quality managers, and regulatory affairs professionals in establishing compliance for medical device software (SaMD). The content is structured to be easily transferable into an Excel (.xls) format, providing a framework for Software Life Cycle Process management, Safety Classification, and Deliverable Traceability.