Written and maintained by CASRAI Editorial Board
Last updated
An IEC 62304 checklist translates the normative clauses of IEC 62304:2006+AMD1:2015 (Medical device software — Software life cycle processes) into auditable design history file (DHF) deliverables for Notified Body technical documentation audits and U.S. FDA premarket reviews. For quality assurance engineers and clinical AI developers building Software as a Medical Device (SaMD) or embedded medical device software under IEC 62304, IEC 82304-1, and AAMI TIR45 Agile medical device software guidance, verifying compliance requires auditing the Clause 5.1 Software Development Plan (SDP), the Clause 5–9 deliverable applicability matrix across Safety Classes A, B, and C, and the 2015 Amendment 1 provisions mapped to FDA’s 2023 Premarket Software Submissions guidance.
What Must Be Included in an IEC 62304 Clause 5.1 Software Development Plan (SDP)?
Under IEC 62304 Clause 5.1, the Software Development Plan is the master roadmap that governs all subsequent software engineering, verification, and configuration management activities. Auditors check the SDP against 12 specific sub-clauses (5.1.1 through 5.1.12), whose applicability scales by Software Safety Class (A, B, or C):
- 5.1.1 Software Development Plan (Classes A, B, C): Defines the software development life cycle model (sequential V-model, iterative, or Agile sprints per AAMI TIR45), processes, and deliverables to be produced.
- 5.1.2 Keeping Software Development Plan Updated (Classes A, B, C): Procedures for updating the SDP as development progresses and scope evolves.
- 5.1.3 Reference to System Design and Development (Classes A, B, C): Inputs from system-level requirements (ISO 13485 Clause 7.3) and system risk analysis (ISO 14971) into software development.
- 5.1.4 Software Development Standards, Methods, and Tools Planning (Class C only): Coding standards (e.g., MISRA C/C++, PEP 8, static analysis rules), modeling notations, and compiler/toolchain validation required for Class C software.
- 5.1.5 Software Integration and Integration Testing Planning (Classes B, C): Strategy for incremental build integration and interface testing (may be combined with system testing).
- 5.1.6 Software Verification Planning (Classes A, B, C): Defines when deliverables require formal verification, acceptance criteria, and regression testing rules.
- 5.1.7 Software Risk Management Planning (Classes A, B, C): Plan for conducting Clause 7 software hazard analysis, Software of Unknown Provenance (SOUP) anomaly evaluation, and risk control verification.
- 5.1.8 Documentation Planning (Classes A, B, C): Title, purpose, naming convention, and approval authority for every lifecycle document.
- 5.1.9 Software Configuration Management Planning (Classes A, B, C): Version control, baseline branching, SOUP version locking, and build reproducibility per Clause 8.
- 5.1.10 Supporting Items to Be Controlled (Classes B, C): Control of compilers, build scripts, automated test harnesses, and configuration files.
- 5.1.11 Software Configuration Item Control Before Verification (Classes B, C) & 5.1.12 Identification and Avoidance of Common Software Defects (Classes B, C): Placing items under configuration control prior to formal verification and selecting defensive programming practices to prevent memory leaks, race conditions, or buffer overflows.
What Are the Clause-by-Clause Audit Checklist Items in IEC 62304:2006+A1:2015?
The following audit matrix summarizes the mandatory deliverables across Clauses 4 through 9 of consolidated IEC 62304:2006+AMD1:2015:
| IEC 62304 Clause | Required DHF / Technical File Artifact | Class A | Class B | Class C |
|---|---|---|---|---|
| 4.1 – 4.4 General Requirements | QMS alignment (ISO 13485), ISO 14971 Risk Management File, Safety Classification justification (4.3), Legacy Software gap report (4.4 if applicable) | Required | Required | Required |
| 5.1 Development Planning | Software Development Plan (SDP) covering applicable 5.1.1–5.1.12 items | Basic (5.1.1–3, 6–9) | Standard (all except 5.1.4) | Full (5.1.1–5.1.12) |
| 5.2 Requirements Analysis | Software Requirements Specification (SRS) including functional, cybersecurity, usability, SOUP, and risk-control requirements + bidirectional traceability | Required | Required | Required |
| 5.3 Architectural Design | Software Architecture Document defining software items, interfaces, SOUP functional/hardware specs (5.3.3–5.3.4), and segregation controls (5.3.5) | Not required (unless segregating) | Required | Required |
| 5.4 Detailed Design | Detailed design verified for each software unit and external interface | Not required | Refine into units (5.4.1) | Full detailed design (5.4.1–5.4.4) |
| 5.5 Unit Implementation & Verification | Source code implementation, unit verification procedure, acceptance criteria (5.5.3), additional Class C static/dynamic unit criteria (5.5.4), and unit test results (5.5.5) | 5.5.1 (Implement units) only | 5.5.1, 5.5.2, 5.5.3, 5.5.5 | Full (5.5.1–5.5.5) |
| 5.6 Software Integration & Integration Testing | Integration test protocol, regression tests, and integration test report | Not required | Required | Required |
| 5.7 Software System Testing | Verified system test protocols and results tracing to every SRS requirement (5.2) | Required | Required | Required |
| 5.8 Software Release | Release notes, known residual anomaly evaluation (5.8.2–5.8.4), build environment archival (5.8.7–5.8.8), and formal release sign-off | Basic (5.8.1, 5.8.2, 5.8.4, 5.8.6) | Full (5.8.1–5.8.8) | Full (5.8.1–5.8.8) |
| Clauses 6, 7, 8 & 9 | Software Maintenance Plan (Cl. 6), Software Risk Management File (Cl. 7), Configuration Management / SOUP List (Cl. 8), and Problem Resolution / CAPA logs (Cl. 9) | Cl. 6, 8, 9 (subset of Cl. 7) | Full Cl. 6, 7, 8, 9 | Full Cl. 6, 7, 8, 9 |
How Did Amendment 1 (2015) Update IEC 62304 for Legacy Software and Safety Classification?
In June 2015, the IEC published Amendment 1 (IEC 62304:2006/AMD1:2015), introducing two critical updates that regulatory auditors inspect closely during EU MDR and FDA submissions:
- Formal Pathway for Legacy Software (Clause 4.4): Prior to 2015, manufacturers with proven medical devices already legally on the market that lacked complete historical Clause 5 V-model documentation faced an impossible choice between rewriting working software from scratch or fabricating retroactive design history files. Clause 4.4 established a legitimate four-step compliance pathway for Legacy Software: (a)Clause 4.4.2 Risk Management Activities (evaluating post-production field feedback, complaints, and hazardous situations), (b) Clause 4.4.3 Gap Analysis (comparing existing deliverables against required deliverables for the assigned safety class), (c) Clause 4.4.4 Closure Activities (executing a plan to generate missing SRS, architecture, system test, and risk control verification records), and (d) Clause 4.4.5 Rationale for Continued Use.
- Risk-Based Safety Classification & Class A Tightening (Clause 4.3): Amendment 1 replaced the original 2006 classification rule (which assumed 100% probability of software failure without crediting external hardware/procedural mitigations prior to initial classification) with a structured risk-based flow chart that accounts for risk control measures external to the software system, while simultaneously requiring Class A software to document residual anomalies and satisfy stricter release and maintenance rules.
Frequently Asked Questions
What must be included in an IEC 62304 Clause 5.1 Software Development Plan (SDP)?
Under IEC 62304 Clause 5.1 (sub-clauses 5.1.1 to 5.1.12), a Software Development Plan (SDP) must define the lifecycle model (V-model, incremental, or Agile), deliverables, traceability to system requirements, development standards/methods/tools (Class C), integration and integration testing plan (Classes B/C), verification plan, risk management plan per Clause 7, documentation plan, configuration management plan per Clause 8, and SOUP/change control procedures.
What are the clause-by-clause audit checklist items in IEC 62304:2006+A1:2015?
An IEC 62304 audit checklist verifies nine normative clauses: Clause 4 (ISO 13485 QMS, ISO 14971 risk management, Clause 4.3 safety classification, and Clause 4.4 legacy software), Clause 5 (Software development processes 5.1–5.8 from planning through release), Clause 6 (Software maintenance 6.1–6.3), Clause 7 (Software risk management 7.1–7.4 including SOUP), Clause 8 (Configuration management 8.1–8.3), and Clause 9 (Software problem resolution 9.1–9.8).
How did Amendment 1 (2015) update IEC 62304 for legacy software and safety classification?
Published in June 2015, IEC 62304 Amendment 1 (consolidated as IEC 62304:2006+AMD1:2015) introduced two major structural updates: (1) Clause 4.4 establishing a formal risk-based gap-analysis pathway for Legacy Software previously placed on the market without full IEC 62304 records, and (2) a revised Clause 4.3 risk-based decision tree allowing external risk control measures to reduce a software system’s assigned safety class while adding baseline architectural and anomaly-tracking requirements for Class A software.
Sources
- International Electrotechnical Commission (IEC). IEC 62304:2006+AMD1:2015 CSV — Medical device software – Software life cycle processes. https://webstore.iec.ch/en/publication/22794
- U.S. Food and Drug Administration (FDA). Content of Premarket Submissions for Device Software Functions — Guidance for Industry and Food and Drug Administration Staff (June 2023). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions
