Software Development Plan, defined development phases, deliverables list, and configuration management strategy — standard SDLC planning artifacts.
Explicit known-defects list with safety impact assessments, SOUP review schedule, and IT security planning integrated into the plan.
Plan currency versus last software change — and whether the known-anomaly list is maintained with documented safety triage for each defect.
Maps to
IEC 62304: §5.1 Software development planning
ISO 13485: §7.3.2 Design and development planning
Pre-QMSR Part 820 (legacy QSR): §820.30(b) Design and development planning.
Requirement text
The manufacturer shall establish a software development plan covering development processes, deliverables, traceability requirements, configuration management, problem resolution, risk management activities, and verification approach. The plan shall be maintained throughout the development lifecycle.
Why this clause exists
A software development plan's regulatory function is not planning in the project-management sense — it is the binding declaration, made before development begins, of how the organization will demonstrate to an auditor that its processes met the standard's requirements. Without a plan, every subsequent artifact (architecture document, test protocol, SOUP list, release record) exists in an evidentiary vacuum: there is no pre-stated commitment against which the artifacts can be evaluated as adequate or deficient. IEC 62304:2006+A1:2015 clause 5.1 requires the plan because the alternative — inferring the intended process from the artifacts produced — inverts the audit logic and creates an opportunity to construct a post-hoc narrative around whatever evidence happens to exist. The 2015 amendment's addition of Section 5.1.12, requiring a list of known defects with safety-impact triage for each, reflects the field observation that organizations were clearing defect queues under time pressure without documenting which remaining defects were safety-relevant and which were cosmetic — a distinction that the plan must pre-specify how to make, so the release decision is governed by a documented standard rather than an undocumented judgment call at each release.
What changed
Amendment 1 (2015) expanded the scope to explicitly include health software and Software as a Medical Device (SaMD), not just software embedded in physical medical devices. A new compliance path for legacy software (Clause 4.4) was introduced, allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
The software safety classification criteria (Clause 4.3) shifted from severity-only to include probability of hazardous situations. External risk control measures (hardware or clinical procedures) can now reduce the software safety class, but internal software mitigations cannot. The standard clarified that logical segregation (not just physical) is acceptable for classification purposes.
The definition of SOUP was narrowed to apply only to software items — a complete medical device software system cannot be claimed as SOUP to bypass lifecycle requirements. New requirements were added for publishing known defects with risk assessments (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Common gaps (what we see in audits)
- Software development plan missing mandated deliverables — IEC 62304 requires a plan defining software safety class with rationale, standards and processes, deliverables at each stage, risk management approach, and configuration management plan. FDA's 2023 guidance additionally mandates an Architecture Design Chart and a process for generating a summary of Unresolved Anomalies. Many plans are incomplete or skip these elements entirely.
- Known defects list not maintained — The 2015 amendment added Section 5.1.12 requiring publication of known defects with associated triage and risk assessments demonstrating safety impact. Many manufacturers either do not maintain this list or fail to document the safety impact assessment for each known defect as part of the release process.